[HN Gopher] Microsoft Flight Simulator 2024: WebAssembly SDK
___________________________________________________________________
Microsoft Flight Simulator 2024: WebAssembly SDK
Author : breve
Score : 97 points
Date : 2025-07-26 16:44 UTC (3 days ago)
(HTM) web link (docs.flightsimulator.com)
(TXT) w3m dump (docs.flightsimulator.com)
| two_handfuls wrote:
| This is great news for WASM, and looks like the Microsoft team
| really put in a lot of effort!
|
| > 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 (...)
| diego_moita wrote:
| This is one of those ideas that makes so much sense that you'd
| ask why didn't it catch on before: WASM as a modules for all
| sorts of platforms
|
| 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)
| tough wrote:
| wasm is the perfect abstraction to build a -modular- and
| pluggable codebase (say grpc/proto as contracts) so you can
| just swap any part of it as long as the wasm module abides to
| such contract.
|
| 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
| euroderf wrote:
| Wasm "web components" should be helpful here.
| rafram wrote:
| > finally, a run-anywhere platform? (what the JVM and .Net
| always wanted to be)
|
| 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.
| johannes1234321 wrote:
| > WebAssembly doesn't include a system interface, i.e., any
| way to interact with the outside world
|
| 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.
| euroderf wrote:
| > JRE or .NET. Anything that even approaches that level of
| capability is going to run into the exact same bloat and
| platform compatibility problems
|
| Challenge has been accepted. Let's see.
| jahewson wrote:
| Indeed, CloudFlare Workers does this. Would love to see more.
| esafak wrote:
| Java applets say hello! Maybe they were just before their time,
| hobbled by slow computers, hard disks, and Internet
| connections.
| 01HNNWZ0MV43FF wrote:
| The tooling doesn't seem to be there to run C++ / Rust / Go /
| whatever efficiently on a JVM, too
| astlouis44 wrote:
| Yep, pretty sure that is what companies like Dylibso are
| working towards, making software into modules underpinned by
| plugins that are powered by WASM:
|
| https://dylibso.com/
| naikrovek wrote:
| I feel like everyone is trying to do things in the most
| inefficient way possible and it is starting to make me a little
| bit batty.
|
| 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.
| Cieric wrote:
| When the modding community is so heavily plagued with mods that
| are malicious in some way, I don't think having a modding api
| that can be safe by convention yet recompiled to be fast would
| be a bad idea. So while I'm not sure it was the smartest
| choice, it's not so inanely stupid as you seem to be putting
| it.
| diggan wrote:
| > When the modding community is so heavily plagued with mods
| that are malicious in some way
|
| 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?
| Cieric wrote:
| Most recently in my memory it's been minecraft. There was a
| wave of mods that were stealing things like discord access
| tokens, I don't have clear memory on all of the cases that
| I've been through, just that I always try and verify all
| mods I can now. I think I remember one for Lethal Company
| and looking online I'm seeing some referenced for Dota 2,
| Sims 4 and Slay the Spire.
|
| 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.
| Scramblejams wrote:
| Yep, this really bums me out. Wanted to try plenty of
| Minecraft mods but never wanted to go to the trouble to
| set up a secure environment, so I never did either.
|
| 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.
| naikrovek wrote:
| If you're saying that there's no other way to create a mod
| API with clear security boundaries, I disagree.
|
| 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.
| Cieric wrote:
| While I agree that it's not the best situation, (and I'm
| wholly against nvidia in this case.) And yeah this isn't
| about the mod-game api boundary, this is more about the
| mod-os boundary since that is harder to control against.
| WASM from my research so far doesn't allow any of that by
| default and it has to be passed through by the runtime. In
| this case it would be passed through to the retargeting
| compiler. This can give additional benefits like allowing
| mods on consoles in a more secure way and allowing for
| targeting the game to future cpu architectures without
| requiring all mods to recompile their code (not that I
| think the latter is a reason microsoft cares about.) But
| the idea of recompiling code when launching a game is
| already kind of standard on the gpu side of things.
| spullara wrote:
| "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."
|
| 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.
| yellowapple wrote:
| The other reason is that it allows these modules to be cross-
| platform, rather than being limited to Windows on x86-64. I
| doubt Microsoft cares much about other operating systems, but
| they do seem to care quite a bit about ARM.
| spullara wrote:
| No native support for fat binary dlls on Windows unlike Mac
| is kind of lame.
| naikrovek wrote:
| What I said is a solution but it is in no way the best
| solution.
| spullara wrote:
| Absent fixing the vGPU problem (since Nvidia is unlikely to
| change their stance on this), what would be the best
| solution? WASM seems like a reasonable compromise to me.
| sorenjan wrote:
| Nvidia is supported on WSL2, which is a VM, so that shouldn't
| be the issue.
|
| https://docs.nvidia.com/cuda/wsl-user-guide/index.html
| whatever1 wrote:
| I am not sure I am following. The game runs on windows, why not
| compile the add-in code directly for the single target?
|
| Is it for future proofing it in case MS wants to release the game
| in a different platform that is not windows ?
| selectodude wrote:
| It runs on Xbox as well so I imagine they want the flexibility
| there.
| connicpu wrote:
| WASM brings a memory sandbox that prevents out of bounds access
| to arbitrary pointers.
| hamburglar wrote:
| Isn't there ARM windows too? Not sure if flight sim targets
| that platform or not, but if so, making the extensions more
| portable is a win.
| JonathonW wrote:
| Because the game already also runs on Xbox and, given MS's
| recent gaming strategy (which is putting less emphasis on Xbox
| exclusives), could conceivably come to Playstation or maybe
| even Switch 2 in the future.
|
| 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.
| potatolicious wrote:
| Security is the big one. C++ DLLs have relatively free reign
| and are difficult to sandbox. With WASM you have a much
| stricter security model where the host program has full control
| over what APIs it has access to.
|
| 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.
| 01HNNWZ0MV43FF wrote:
| In addition to the sibling comments, you can sandbox WASM's CPU
| time. You can say after a certain amount of time that it has to
| yield back to the host. With native plugins, you might never
| get your OS thread back, and there isn't a good way to safely
| abort it and free memory and everything
| p_l wrote:
| There were already parts in MSFS 2020, namely gauges aka
| everything in cockpit that had more dynamic display, that used
| JS based SDK in order to provide sandboxing and safe level of
| control over performance (because with sandboxes VM it's easier
| to preempt execution)
| anonymars wrote:
| Potentially related: a detailed write-up on creating a
| JavaScript autopilot/interactive webpage
|
| https://news.ycombinator.com/item?id=40267164
| dividuum wrote:
| Also it allows playing Flight Simulator inside Flight
| Simulator :-)
|
| https://github.com/s-macke/FSHistory/tree/master?tab=readme-.
| ..
| anonymars wrote:
| Does this still work?
| tapoxi wrote:
| > Is it for future proofing it in case MS wants to release the
| game in a different platform that is not windows ?
|
| Strongly rumored to be releasing on PS5, like most recent
| Microsoft games.
| shizcakes wrote:
| I have about 1000 hours into MSFS2024 and am a mod for a streamer
| that has streamed many hours more.
|
| The gamer perception of this implementation is NOT positive. It
| crashes all the time, has massive performance issues, and
| generally is super negatively received.
| NikolaNovak wrote:
| Thx - any details as to why, tough?
| daviding wrote:
| For me most of the performance issues with MSFS24 are now
| being VRAM limited. When they went to MSFS 2024 they rewrote
| for DX12 and while doing that upgraded a few things to look
| nicer. The texture management still seems to need some work.
|
| 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.
| thecosmicfrog wrote:
| DLSS also blurs the cockpit displays quite badly when
| there's anything moving on them (airspeed/altitude tape,
| etc.). It looks like temporal blur, which is interesting
| because the same blur doesn't happen with their TAA
| (*temporal* anti-aliasing) implementation.
| daviding wrote:
| Yeah, DLSS looks great outside the window and for people
| enjoying GA and VFR it's all good. For airliners with
| digital displays it is harder to use, as like you said it
| blurs. They did talk about using some form of
| stencil/exclusion around cockpit displays but I think
| that didn't go anywhere as yet.
|
| 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'.
| thecosmicfrog wrote:
| Yep, that's the flight sim community in a nutshell.
| Scramblejams wrote:
| That describes what I've seen. When I first compared 2020
| and 2024 in as apples-to-apples a way as I could, it seemed
| like 2024's frame rate was about a third lower than 2020's.
| This was on a 7900 XTX with 24 gigs of VRAM.
|
| I'm waiting for SU4 before I get back into it...
| thecosmicfrog wrote:
| "WASM crash?" must be one of the top live chat comments on
| flight sim streams these days.
| izacus wrote:
| I keep holding off on buying 2024 due to all the reported bugs
| and I'm still sad to hear it hasn't been fixed.
| RachelF wrote:
| X-Plane is a good alternative.
|
| https://www.x-plane.com/
| lovecg wrote:
| Unless you want realistic scenery or an up to date g1000
| implementation (I love X-Plane really but because of these
| two points I keep going back to MSFS - maybe there are some
| add-ons I haven't tried?)
| lsaferite wrote:
| > gamer perception
|
| 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.
| RachelF wrote:
| I wonder how much slower it is than C/C++ compiled dlls?
| nixpulvis wrote:
| It likely requires major updates, no? In that case many addons
| are probably poorly updated and having bugs due to being rushed
| and haphazardly ported.
| thescriptkiddie wrote:
| ah shit, nobody told them that that one blog post about a future
| in which javascript is a universal ABI was satire
|
| edit: i might be thinking of this talk?
| https://www.destroyallsoftware.com/talks/the-birth-and-death...
| affenape wrote:
| For something having 2024 in its name I expected a more
| consistent error handling, but guess what:
|
| * 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.
| boffinAudio wrote:
| I dunno, I think I would've preferred Lua bytecode as a
| deliverable executable target, rather than WebAssembly. The
| tooling would be simpler, more efficient, and would allow a far
| wider ranger of interoperability with other engines.
| thecosmicfrog wrote:
| One of the biggest factors for any flight simulation add-on is
| performance, and so most of the major add-on developers are
| building C++ modules (compiled to WASM) to eek out as much
| performance as possible. My understanding is that it's also
| possible to write some things in JavaScript (and perhaps
| TypeScript), but performance takes a hit. I would assume Lua
| falls into that same performance trap, as I know Lua can be
| used for X-Plane add-on development, but it's (again)
| considered the less performance-centric approach as compared to
| C++.
|
| 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...
___________________________________________________________________
(page generated 2025-07-29 23:00 UTC)