The gamer perception of this implementation is NOT positive. It crashes all the time, has massive performance issues, and generally is super negatively received.
The gamer perception of this implementation is NOT positive. It crashes all the time, has massive performance issues, and generally is super negatively received.
Is there evidence to support that it's the WASM Mod format that's the issue? Based on that page it's not like MSFS2024 is even running WASM, it's simply using WASM as an IL that is precompiled into a DLL on application startup.
WASM is surprisingly fast.
It didn't take long after release that every crash in the game was because of that damn "Nebula3 Engine!?!!1", even though almost none of those crashes happened down in the engine code, but somewhere up in the game logic :)
In any case, opening up a game for modding means the game needs to be prepared for a flood of poorly written and optimized mods, no matter whether the mods are scripted via a scripting language like Lua, compiled to WASM or native code. At least (unlike directly loading native DLLs), WASM gives you all the tools to catch errors without crashing the entire game process. The tricky part is to design the plugin runtime system in a way that such errors are easily recoverable without having to restart the whole flight-sim session.
Basic things like latitude/longitude/altitude/heading should be straightforward. But then you might have problems with mismatch scenery, like missing airports/runway, different terrain heights, etc. And then the weather synchronization is another can of worms. Matching what you see with the physic model can be challenging.
This means that my 9800x3D/3080Ti 12GB sort of runs out of VRAM and pages when used in VR or 4K desktop. I'm in the position where the same visuals (scenery/aircraft etc) for MSFS2020 (using DX11) when compared to the newer MSFS2024 is just generally worse and a lower framerate. In VR a bad framerate makes things unplayable. For desktop use you have DLSS which helps a lot, but in VR that blurry movement really impacts clarity.
As a team they have a pretty tough job because the audience is all of the place for a title like that, as in people with 'I can see my house!' being made happy vs 'My pressurization gauge cross-bleed reading is below the Boeing B738 manual official figure, unplayable'.
They've been talking about that since the launch of msfs2020 and there's not been any movement on it as far as I know.
I'm waiting for SU4 before I get back into it...
- The Windows API is not supported => would be a security nightmare if allowed
- C++ exceptions are not supported => not surprising, game code usually forbids exceptions anyway, along with RTTI
- C++ threads are not supported => really shouldn't be needed in a plugin system,
- The GDI+ wrapper is very incomplete => surprising that they even attempt to wrap GDI+
- The WebAssembly module must be compiled in Debug mode for C/C++ code for symbols to be visible while debugging => need to compile in debug mode in order to debug, doh.
So it actually does crash and gets memory corrupted, when using the wrong languages, like in a regular process.