Microsoft Flight Simulator 2024: WebAssembly SDK
docs.flightsimulator.com
docs.flightsimulator.com
The gamer perception of this implementation is NOT positive. It crashes all the time, has massive performance issues, and generally is super negatively received.
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...
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.
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.
So it actually does crash and gets memory corrupted, when using the wrong languages, like in a regular process.
- 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.
* some functions like fsRenderCreate return 0 or 1 depending on the operation result;
* some like fsMapViewCreate say that a value less than 0 is returned on error;
* fsIOOpen says you should also consult with the fsIOGetLastError function on failure.
Hope somebody considers adding the errno.
> In order to [move the addons API to WASM] without requiring a full rewrite of existing add-ons, a new platform toolset was designed for Visual Studio (...)
I recall at least one add-on developer for X-Plane (Zibo [1]) migrating some of their Lua code over to C++.
[1] https://forums.x-plane.org/forums/topic/138974-b737-800x-zib...
Is it for future proofing it in case MS wants to release the game in a different platform that is not windows ?
On the Windows side of things, there's also a push towards ARM hardware (with current Snapdragon-based hardware actually performing pretty well). Not sure if Flight Simulator is currently ARM-native, but having the ability to go ARM-native is probably desirable at least as a long-term goal.
The addons are developed by third parties that aren't Microsoft, so there's a serious risk of malware and other ways of getting the user pwned.
The added future-proofing/portability is a nice bonus, but I suspect maybe not the main motivator.
(unless UWP I suppose, which even Microsoft have kind of forgotten about)
https://github.com/s-macke/FSHistory/tree/master?tab=readme-...
Strongly rumored to be releasing on PS5, like most recent Microsoft games.
It could become a competitor for a lot of existing technologies. Some examples:
* embedded script languages (e.g.: Python in Blender and Gimp, Lua in games, VBScript in MS applications).
* add-on modules (e.g. COM on Microsoft platforms or COM-like for non-MS)
* finally, a run-anywhere platform? (what the JVM and .Net always wanted to be)
I keep going more and more to it when I try to design systems, in my mind at least, hoping I can put some to use
WebAssembly doesn’t include a system interface, i.e., any way to interact with the outside world, so it isn’t an apples-to-apples comparison.
WASI seems like it’s coming along nicely, but it has nowhere near the feature set of the JRE or .NET. Anything that even approaches that level of capability is going to run into the exact same bloat and platform compatibility problems that those runtimes did.
This can be quite an improvement for running add-ons from some arbitrary source.
While, of course, an way to access defined resources is needed.
(It seems like they want to implement one… someday. It’s vague: https://github.com/bytecodealliance/wasmtime/blob/main/docs/...)
It's very similar to how games would use a restricted subset of Lua which can only call into scripting APIs provided by the game, but not use random Lua stdlib features (like reading/writing files).
Challenge has been accepted. Let's see.
I believe that's WASI, which builds on top of the base wasm spec: https://wasi.dev/interfaces#presentation
e.g. the WASI 0.2 spec here mentions clocks, filesystem access, creating sockets, etc.
Lua is architected the same way - As host, you create a Lua VM with no I/O, and then the host decides which I/O interfaces the VM can or cannot see.
JRE and .NET are probably built the same way internally. The reason wasm is hyped more than VMs with a decade of momentum behind them is that wasm is lower-level, it isn't tied to any particular GC model, and there's already backends for popular low-level languages like C, C++, Rust, and Go to compile into wasm modules.
"More than 20 programming tools vendors offer some 26 programming languages — including C++, Perl, Python, Java, COBOL, RPG and Haskell — on .NET."
From https://news.microsoft.com/source/2001/10/22/massive-industr...
"The Amsterdam Compiler Kit (ACK) is a retargetable compiler suite and toolchain written by Andrew Tanenbaum and Ceriel Jacobs, since 2005 maintained by David Given.[1] It has frontends for the following programming languages: C, Pascal, Modula-2, Occam, and BASIC."
"Maximum portability is achieved by using an intermediate language using bytecode, called EM. Each language front-end produces EM object files, which are then processed through several generic optimisers before being translated by a back-end into native machine code. "
From https://en.wikipedia.org/wiki/Amsterdam_Compiler_Kit
"When IBM i was first released as OS/400, it was split into two layers, the hardware-dependent System Licensed Internal Code (SLIC)[15][1] and the hardware-independent Extended Control Program Facility (XPF).[16][8][33][34] These are divided by a hardware abstraction layer called the Technology Independent Machine Interface (TIMI). Later versions of the operating system gained additional layers, including an AIX compatibility layer named Portable Application Solutions Environment (originally known as the Private Address Space Environment),[5][35] and the Advanced 36 Machine environment which ran System/36 SSP applications in emulation.[1]"
From https://en.wikipedia.org/wiki/IBM_i#Technology_Independent_M...
Other examples can be retrieved from annals of history.
For a plugin system this sort of isolation from the outside world is pretty much a hard requirement. You don't want random plugins to read/write/delete random files in your filesystem.
I think there's a good argument for Flight Simulator to be in the top 100.
edit: i might be thinking of this talk? https://www.destroyallsoftware.com/talks/the-birth-and-death...
I think they did a great job focusing on the important parts of flying for the missions and such but things like ATC telling you to land on one run way and the visual assists leading to the wrong runway are terrible. My big pet peeve is unrealistic ground ops and rules where it is legal and expected to exit a runway and enter a taxi way you will randomly get dinged for entering a taxiway without permission (at smaller towered and towered fields).
At least with fseconomy you can reach out to loan sharks to get a loan for a beat up 737
At any rate with their budget Asobo are underperforming with this thing. 2024 in particular is enshittification 101.
I also have a mod that gets my plane's power curve mostly right which is good enough for most IFR practice.
WASM is awesome, but if I'm reading this right, they're choosing not to write DLLs so that they can create WASM modules which are recompiled into DLLs prior to runtime.
I think our entire industry has taken banned-by-the-Geneva-Conventions, weapons-grade Stupid Pills.
The only reason I can think of to do this, is so that you can't have arbitrarily malevolent code running in the DLLs that mod authors write. But we can't run the whole game in a sandbox such as a VM because of Nvidia GPU licensing disallowing virtual GPUs in consumer grade GPUs.
If that's why this work is being done, some serious muscle needs to be used to twist Nvidias arm so that they stop being knobheads and start being part of the solution to security issues, instead of part of the problem.
If I pay for that GPU, I should be able to issue work to it however I please. I should be able to split it up among VMs all day long without concern for anything Nvidia wants.
Is it? Granted, I'm a heavy mod user myself for various games, but only created mods myself for Cities Skylines and Cities Skylines 2 so I guess I know that ecosystem the best, and yes, there been a few cases of malicious mods, but "heavily plagued"? What ecosystem are you talking about?
Just learned Nexus mods is also pretty good about handling anything that's virus like, most of my modding experience has been external to that though.
As an only-tangentially-related aside, the difficulty of making mods for Windows games work on Proton also bums me out.
I wish some kind of cross-platform, sandboxed modding ecosystem existed solving enough problems that most modders would prefer to use it. I'm not sure that's even possible, though.
The mod API should not have to do this anyway. The OS should do this. It is beyond belief that most operating systems just allow programs to do anything they want simply because they’re being executed.
And if the OS can’t do this, you run in a VM which nvidia disallow you to do in a performant way.
This is the only reason and you go on to show that it is a reasonable thing to do given the state of the world.
That's much harder than what Microsoft is doing in this situation, so I understand (kind of) why they're doing this.
Malware overall isn't going to get better, or become less of a problem; it's going to get worse. Every day that these things are delayed, the more damage is done by malware that runs before this kind of OS level security gets implemented.
If this were in place, we could run DLLs all day long and if one of them decides that it needs full disk access or superuser access, you can simply not allow it when prompted. Or, Microsoft could recognize that in the context of a game that this is never ok, and simply not show you the prompt to begin with.
But no, because the OS is so fucking stupid we all have to think about these things. The OS is supposed to handle this level of thing. The OS should run the applications I tell it to run, and protect me from them if they try anything stupid. The OS is supposed to sandbox applications and protect the rest of the system from any malevolence they may contain. Instead we have game teams innovating solutions like this, which are entirely unnecessary if the OS team would do their fucking jobs.
long gone are the days of games with actual modding support (think of games like CS:1.6, half-life, civ4 where you had a dll src with the game)
the whole "mods can have malware" with them is just an overblown risk assessment, most people do the right thing. there's been like fewer than 10 malware incidents with minecraft modding over the years and most of it has been recently because trust in that modding community has basically evaporated.
it's a much better stance to just let mods do whatever and hold their authors accountable with their reputation. srsly.
I'll disagree here. Kerbal Space Program, Rimworld, Minecraft all have gigantic modding communities, just to name a few. There's many, many games like that. In the case of Rimworld, it's official support and in the case of Minecraft it might as well be at this point.
> where you had a dll src with the game
Agree :) But I don't see how that pertains to moddability in practice. In many cases, the existence of standardized modding APIs instead of everybody just poking around in the game's source is actually an upside, as it makes interoperability much easier.
I also agree with the malware side, at least for the time being. At some point, we'll probably have to deal with this and I don't mind starting the technical side now, but I don't subscribe to the idea that mods are riddled with malware.
I see what you mean, but there's a reason why I said modding support. From these, only Rimworld really counts - KSP's modding is unofficial and without support from the developers, Minecraft modding is also unofficial (you still don't have code or an API, you have to decompile! you do have datapacks but those can't do shit compared to proper modding)
Point is, all of these have unofficial modding communities because they are written in managed languages which are easy to reverse. But they don't give you a modding API to target, they don't give you documentation and they don't give you a clean/stable API. Look at how much Minecraft mods break with every minor update, it's nowhere near "official support".
> In many cases, the existence of standardized modding APIs instead of everybody just poking around in the game's source is actually an upside, as it makes interoperability much easier.
You're right but that's mostly just a consequence of the time which has passed. We no longer load just one mod. But the old model does work perfectly here - even if the modding is just "here's the DLL, replace it", the community can easily build a modloader on it which does support multiple plugins.
> At some point, we'll probably have to deal with this and I don't mind starting the technical side now, but I don't subscribe to the idea that mods are riddled with malware.
Semi-agree, it is a risk and one which can definitely be a huge issue, but I'd say this is much more of a social issue than a technical one. All these "lock things down to ensure security" initiatives throw the baby out with the bathwater, they don't really allow for anything substantial or creative to be made. And that's a huge loss, a way bigger one than malware spreading for a few days before getting inevitably found out and removed.
this convo is funny considering I'm working on a blocky game similar to Minecraft and one of the big design principles I have on my mind is drastically lowering the bar of entry for creating stuff. Even if you can theoretically modify many things, most users won't go and whip out a development environment on a whim, they'll just give up.... there's a few things which can make it drastically easier for users to become tinkerers, one of them is a compiler included with the game. If something is in the files, people can play around with it without friction, even better if some samples are included. IMO the benefits way outweigh the costs.
Not quite, I'm working on a Minecraft mod via Fabric at this time and you actually do just write code. You may want to decompile to look at the original code, but that takes one command, because people have already set up scripts to do all that. They also automatically apply source code mappings which give a lot of the decompiled code proper variable & function names.
Obviously, it's not official support and you're doing weird aspect oriented programming with what they call mixins, and its sorta hacky. But there's an API, it's just not made by Mojang. Which, honestly, may be a good thing lol
> Even if you can theoretically modify many things, most users won't go and whip out a development environment on a whim, they'll just give up
Yeah, absolutely. I was more talking about the state of modding and availability of mods in general, from a mod user perspective so to speak.
But I agree 100%. I'm fine with the ceremony, but the more people can get into modding easily, the better. To that point, I remember buying Crysis, poking around in the game file for fun and finding that they shipped the whole Cryengine level editor with the game and, what's really crazy, you were able to open the actual level files of the actual game with it.
That was mind-blowing to me. You could look at all the -horribly unmaintainable- visual scripts that defined enemy behavior - and change them. You could change the terrain. You could add the damn tornado they put in the game, which wasn't just a scripted sequence but actually hurled stuff around physically. And then you could...just play it, with your changes, right there.
Out of that grew a small, but fun modding scene with people building custom campaigns or just pretty-looking levels to walk around in (Strange Island, my beloved), considering the graphics of Crysis at the time. Also, my love of programming and tinkering with software pretty much started with this discovery :)
It's not quite the same as what you're describing, as they obviously didn't include the source for the engine itself, but I think it's still comparable to an extent.
So yeah, I'm with you on that. Do you have anything to share regarding your project? Sounds pretty interesting to me.
Yup, but it's very much not the same... you don't have the original documentation, you don't have the actual local variable names and stuff. And the build process is a mess, especially when you want to do cross-modloader mods. (or face users screaming at you for different modloader compatibility)
And you have two different sets of mappings too, alongside the 4 modloaders.
See this post for an example: https://emi.dev/blog/mappings-and-maven/
> Yeah, absolutely. I was more talking about the state of modding and availability of mods in general, from a mod user perspective so to speak.
Oh, from the users' perspective, it's quite a bit better. Except when your favourite mod doesn't work with the other mods. Or it's on a different modloader. But in something like KSP, it's fairly seamless, that's just a Minecraft problem.
> Also, my love of programming and tinkering with software pretty much started with this discovery :)
Yeah, this 100%. pretty much any game with easily accessible mod tools grows a modding scene around itself, just see CS or Portal custom maps, Paradox games, etc... and it's a good thing, many people get their love from that :)
> Do you have anything to share regarding your project? Sounds pretty interesting to me.
I'm pretty much making a retrofuturistic Minecraft-like. I loved the original beta versions which Notch made, but since he stopped developing it, all the soul has been gone from it, it just feels empty. Instead of adding random shit because it's cool, now it's replaced with traditional, polished but boring game design ;) I believe that it's possible to do better, add stuff like more emergent worldgen, even new dimensions, a bit deeper progression and random cool mechanics like playing sports or maybe even minigames.
In terms of modding, I favour a visible source model (it's on my github, my name's the same there), you can check it out if you want. Beware, it's not really playable yet, that's coming soon. The game's written in C#/.NET so it's kind of similar to Java in that regard.
Basically, I plan to make it so you'll have a fairly basic integrated modloader (load mods, maybe a few events) then the community can provide additional patches or hooks if needed. There will also be coremodding support (transforming the game dll before loading to add fields or completely rewrite classes) and I plan to ship Roslyn with the game so you can make plaintext .cs mods which are compiled on startup.
If people make something cool, I'm also open to adding it into the vanilla game (if they sign over the rights, etc.). I think that a huge part of Minecraft's success has been the strong community involvement - in 2010 that looked like posting and answering on Twitter because that was the new thing, today maybe it's Discord. Obviously, most games (including modern Minecraft!) do it only one way, there are the developers, and there are the players, the players play whatever the developers put out, and if the players complain too much, the developers might consider it. I think that it's possible to do better, although it definitely takes a degree of humility to pull it off.... especially if you're attached to something you've made. But I think it's possible, can't know if you don't try ;)