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.
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.
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?)
When did you last try it? The scenery and GPS/FMC has come a long way in the last 20 years I've been an X-Plane casual, but not so sure how much of that was in the last few.
I’m comparing X-Plane 12 to MSFS 24. MSFS 24 is a great aid and near picture perfect when preflying real world routes, with 3D buildings and everything, and the latest G1000 implementation is pretty complete too. But X-Plane still wins on physics realism and systems fidelity. I’d be happy if there was a way to combine the strengths of the two in one simulator somehow..
Yeah ... by now 2020 reached a beta quality, still plenty of bugs left to squash but most of them are minor. 2024 on the other side ... is just transitioning from tech demo to alpha quality. It needs a few more years to reach beta and then by 2035 or so it might actually become a reliable product.
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.
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.
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'.
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.
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 (...)
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.
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.
WASM provides a secure sandbox with predictable performance across platforms while giving Microsoft the ability to maintain compatibility if they port to Xbox, cloud, or other platforms without requiring developers to recompile their add-ons.
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)
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
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.
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++.
> 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.
Sure, but your add-ons will need access to some of the world, which right now requires giving them access to all of WASI, as far as I know. There’s no permissions model. That’s worse than the JVM.
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.
"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. "
"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]"
Because this idea has been done multiple times throughout the years with different kinds of bytecodes and VMs, since UNCOL in 1958, the WebAssembly folks just pretend they are always the first at something.
Yep, pretty sure that is what companies like Dylibso are working towards, making software into modules underpinned by plugins that are powered by WASM:
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
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.
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.
> 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?
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.
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.
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.
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.
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.
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.
you're being downvoted sadly, but you are 100% right ;)
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.
> long gone are the days of games with actual modding support
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.
> Kerbal Space Program, Rimworld, Minecraft all have gigantic modding communities, just to name a few.
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.
> 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)
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.
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.
> 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.
I wonder how much slower it is than C/C++ compiled dlls?
Already a quick look to "Known Issues and Limitations" is quite off putting to anyone thinking about doing mods.
It crashes when a developer writes code that crashes, which is not uncommon; its C++.
But but WebAssembly, the sandbox, security, best of all bytecode formats ever created and all that jazz.
So it actually does crash and gets memory corrupted, when using the wrong languages, like in a regular process.
"WASM crash?" must be one of the top live chat comments on flight sim streams these days.
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.
X-Plane is a good alternative.
https://www.x-plane.com/
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?)
When did you last try it? The scenery and GPS/FMC has come a long way in the last 20 years I've been an X-Plane casual, but not so sure how much of that was in the last few.
I’m comparing X-Plane 12 to MSFS 24. MSFS 24 is a great aid and near picture perfect when preflying real world routes, with 3D buildings and everything, and the latest G1000 implementation is pretty complete too. But X-Plane still wins on physics realism and systems fidelity. I’d be happy if there was a way to combine the strengths of the two in one simulator somehow..
I'm still waiting for the bugs in MSFS 2020 to be fixed.
Yeah ... by now 2020 reached a beta quality, still plenty of bugs left to squash but most of them are minor. 2024 on the other side ... is just transitioning from tech demo to alpha quality. It needs a few more years to reach beta and then by 2035 or so it might actually become a reliable product.
Thx - any details as to why, tough?
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.
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.
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'.
> They did talk about using some form of stencil/exclusion around cockpit displays but I think that didn't go anywhere as yet.
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.
Yep, that's the flight sim community in a nutshell.
I found DLSS4 Preset J much much improved, I prefer it to K.
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...
VR situation was much worse. On the hardware where 2020 was OKish, 2024 was unplayable.
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.
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 (...)
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.
This is what it uses behind the scenes: https://github.com/innative-sdk/innative
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 ?
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.
WASM brings a memory sandbox that prevents out of bounds access to arbitrary pointers.
The only bounds that are checked is the overall size of the linear memory block, there is no bounds checking inside the same segment.
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.
The real security for add ons would be to use external processes with OS IPC, even if it is more resource intensive.
But you'd also have to have an entire VM to run the separate process in, otherwise it still has access to the user's whole account and desktop.
(unless UWP I suppose, which even Microsoft have kind of forgotten about)
WASM provides a secure sandbox with predictable performance across platforms while giving Microsoft the ability to maintain compatibility if they port to Xbox, cloud, or other platforms without requiring developers to recompile their add-ons.
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)
Also it allows playing Flight Simulator inside Flight Simulator :-)
https://github.com/s-macke/FSHistory/tree/master?tab=readme-...
Potentially related: a detailed write-up on creating a JavaScript autopilot/interactive webpage
https://news.ycombinator.com/item?id=40267164
Does this still work?
gauges in JS? that's how all gauges with dynamic display works in MSFS 2020 and presumably 2024, so yes it still works.
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.
> 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.
It runs on Xbox as well so I imagine they want the flexibility there.
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
I was recently thinking about the most influential games of all time.
I think there's a good argument for Flight Simulator to be in the top 100.
Graphics are good but as a flight simulator it’s awful, in particular its (non) simulation of fluid dynamics. X-Plane has the opposite problem.
At any rate with their budget Asobo are underperforming with this thing. 2024 in particular is enshittification 101.
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.
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...
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)
> 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.
> 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.
Sure, but your add-ons will need access to some of the world, which right now requires giving them access to all of WASI, as far as I know. There’s no permissions model. That’s worse than the JVM.
(It seems like they want to implement one… someday. It’s vague: https://github.com/bytecodealliance/wasmtime/blob/main/docs/...)
> 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.
> WebAssembly doesn’t include a system interface, i.e., any way to interact with the outside world
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.
Like this?
"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.
Yes, I discussed WASI in my comment. It has maybe 1% of the feature set of the JRE/.NET core libraries, and I think that’s a generous estimate.
Because this idea has been done multiple times throughout the years with different kinds of bytecodes and VMs, since UNCOL in 1958, the WebAssembly folks just pretend they are always the first at something.
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/
Java applets say hello! Maybe they were just before their time, hobbled by slow computers, hard disks, and Internet connections.
The tooling doesn't seem to be there to run C++ / Rust / Go / whatever efficiently on a JVM, too
It is there for C++ on the CLR, or IBM i, or TenDRA, or ...
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
Extism is a plug-in framework based on WebAssembly:
https://extism.org/
Wasm "web components" should be helpful here.
Indeed, CloudFlare Workers does this. Would love to see more.
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...
Yavascript
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.
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.
> 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?
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.
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.
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.
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.
"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.
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.
No native support for fat binary dlls on Windows unlike Mac is kind of lame.
What I said is a solution but it is in no way the best solution.
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.
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
you're being downvoted sadly, but you are 100% right ;)
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.
> long gone are the days of games with actual modding support
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.
> Kerbal Space Program, Rimworld, Minecraft all have gigantic modding communities, just to name a few.
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.
> 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)
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.