MSFS 2020 SDK WASM Toolchain Issue

[N6722C]

Technical Report: MSFS 2020 SDK WASM Toolchain Issue

Developers targeting Microsoft Flight Simulator (MSFS) 2020 with WASM gauges or modules require the Emscripten SDK (emsdk) and LLVM toolchain, normally delivered inside the SDK’s WASM folder structure.

However, extensive investigation has shown that SDK Core installers from v0.18 through v0.24.0.0 never shipped the emsdk folder, making WASM builds impossible without external intervention.

Key Findings:
1. SDK Core installers contain bin (LLVM tools), include (headers), and lib (libraries), but never emsdk.
2. Early SDKs (0.14–0.19) offered a standalone ‘SDK Installer (WASM)’ via DevMode.

That MSI delivered emsdk.
3. Around SDK 0.20 (2022), Asobo announced WASM was merged into Core. In practice, emsdk has been missing since.
4. Developers who installed WASM support in 2020–2021 carried forward their toolchain and remain unaffected.
5. The MSFS 2024 SDK includes the full WASM toolchain, exposing a packaging regression for MSFS 2020.

Consequences: - New MSFS 2020 developers cannot compile WASM gauges with SDK 0.24.5 alone. -
Visual Studio builds fail to generate .wasm without emsdk present. - Community devs with legacy installs continue unimpeded, creating a two-tier situation.

Workarounds: (Not ideal) - Copy emsdk, LLVM, and wasi-sysroot from an older MSFS 2020 dev system or from MSFS 2024 SDK. - Retain MSFS 2020’s include and lib folders to avoid header/lib mismatches. -

Alternatively, manually install Emscripten SDK from GitHub and integrate, though version alignment may be tricky.

Recommendations for Asobo: -
Formally confirm whether MSFS 2020 WASM development is
supported in 2025. - Restore emsdk packaging to Core or reintroduce the standalone WASM installer. -
Update SDK documentation to clarify the delivery of WASM toolchain components.

Conclusion: The absence of emsdk in all MSFS 2020 Core SDK installers prevents new developers from building WASM gauges.

[tracernz]

What makes you think emsdk is required? I don’t have it on my machine at all and I can build WASM modules just fine. I just checked the FlyByWire dev-env and it also doesn’t have it, and that’s an isolated environment that works for dozens of devs + the CI which builds all releases delivered to users. I don’t think it’s required at all if you’re targeting WASI with LLVM from the last 6 years or so.

[N6722C]

After more digging and helpful feedback from others here (thank you tracernz!), I want to correct an earlier assumption in my technical report.

Originally, I believed the absence of an emsdk folder in recent SDK Core installers was the critical blocker for WASM development in MSFS 2020. However, this turns out not to be the case:

• The emsdk folder is not required to build WASM modules for MSFS today.
• The modern build flow relies on:
  • llvm\ (clang, wasm-ld, etc.)
  • wasi-sysroot\ (libc/libc++ runtime for WASI)
  • include\ (MSFS headers like MSFS_WASM.h)
  • lib\ (MSFS WASM static libraries)
• These are the only essential parts. emsdk was historically included in older SDKs, but with newer LLVM/WASI toolchains it is no longer needed.

What this means

• My 2023 backup SDK already had the correct toolchain (llvm, wasi-sysroot, include, lib) and is sufficient to build .wasm modules.
• The confusion came from comparing older documentation/screenshots which showed emsdk when it was still bundled.
• Current developers (e.g. FlyByWire, CI pipelines) confirm they successfully compile WASM modules without emsdk.

Takeaway

The real issue isn’t the absence of emsdk, but the lack of clear documentation about which components are required. The SDK still doesn’t explicitly state that llvm + wasi-sysroot are the active toolchain and that emsdk is obsolete.

Hopefully this clarification helps other new devs who hit the same question. The key is: if you have llvm, wasi-sysroot, include, and lib in your MSFS SDK\WASM\ folder, you’re good to go for WASM development in MSFS 2020 (and 2024).

[Arzop]

Hi,

I am a bit surprised by your post because we have never used emscriptem to compile Wasm. As far as I can go back with the first SDK we made, in april 2019, there is no trace of emscriptem.

Can you share with us the pages of the documentation that reference emsdk? If there are, that means that we have published screenshots of internal tests/??? (that I don’t know about).

For future addon makers, the only thing you need to install to start working on a MSFS(2024) addon is the latest Core installer that can be found in the DevMode. It will install:

• Every dependencies required to compile Wasm (in the WASM folder). It contains the toolchain used to compile, the VS platform toolset, the Wasi-libc, includes, WasmVersion lib…
• Tools that can help you produce content for MSFS (blender/3dsMax exporter), VS code extension for ModelBehaviors…

Best Regards
Maxime / Asobo

[N6722C]

Thank you for your response.

The issue I am having, is, for the 1st time since installing 2020 at release date, is to start developing wasm apps for 2020, and to get WASM projects to build in MSFS2020,

I am also trying to use ChatGpt to help write these wasm apps. It was Chat GPT that led me down this path of missing emscrtem, when wasm projects it was writing, would not compile on my system

Seems ChatCPT was “making stuff up again” ??

I am concluding that the real issue is that ChatGPT cannot write a Build-able WASM project !! (YET !! )

[N6722C]

Since I started this Forum Post, and have spent a ridiculous amount of time “Sparing” with ChatGPT, to help “create” Dev Tool Projects,and then to edit them, I will make one final post here, to document the findings, and what ChatGPT5 currently can do, and cannot, the reasons why…

Basically ChatGPT cannot get enough correct documentation information to be able to create new projects, but given a working project, it is capable of adding additional content and functionality, probably far faster than a human developer. so It does have a role to play in project development, if one choose to use it.

MSFS_WASM_Project_Failure_Report.pdf (2.9 KB)