Why are standalone WASM modules so important?

So, I can do quite some Python programming (made my own Python Simconnect applications), but nowhere a professional developed. Could somebody explain why the WASM modules are so critical, why is that the only (?) way to access variables that cannot be accessed through Simconnect?

I’m really disappointed with all my stuff not working anymore, and would like to understand the programmic logic behind those WASM modules a bit better.

SimConnect SDK works inside and outside the sim, but the Gauge SDK only works in the sim via wasm/C++. When you use SimConnect externally you are paying costs for the sim to talk to your external app. This cost is pretty low but it’s about latency mostly, so the high cost things are disallowed externally. When running within the sim you are able to execute code on every sim and visual frame as well as access all the local variables which aren’t exposed at all through the external SimConnect SDK. A wasm module is not just able to use the SimConnect SDK but also use the Gauge SDK which is the feature set you are talking about, in addition to the core latency problem when running outside of the game process.

3 Likes

I suggest reading this post of mine from last February:

Of course, what’s happening here is exactly what I warned about: everybody is writing basically the SAME module, to do the same thing, which is getting access to the Gauges API calls, by using Simconnect as a transport.

This clearly defeats the purpose of “reducing latency” because, when multiple modules all doing the same thing, all running at the same time, the only result is they’ll clog the Simconnect communication channel with hundreds of requests, because each one is asking the sim for the same thing, and the sim has to keep up with all requests,coming from multiple sources.

So, when something happens, like with the last update, where WASM support for stand-alone modules went broken, MULTIPLE modules ( all doing the same thing ), are all failing together, so now we have multiple possible points of failure.

I’m fairly sure the crash will be fixed very soon, since it’s a very well documented issue, it’s known to Asobo and it affects lots of developers, but even after the fix, the main issues won’t just go away, because there’s an underlying design problem, which I’ll try to explain here:

The problem happens only with Stand-Alone WASM modules, not WASM Gauges.

Why developers need a stand-alone WASM module to begin with ?

In theory, a Stand-alone WASM module should be able to do anything, since it’s C++ code, and you could envision any kind of complex non-airplane (non-gauge) add-on made this way.

However, in practice, the only thing stand-alone WASM modules has been used for right now, is to get access to the Gauges API calls ( L or H Variables, execute Calculator code, send key events, etc. ), and then using Simconnect to give access to an outside Simconnect client application that, by running as an external .EXE, would have full access to the complete Windows OS API, something that is not possible with WASM, which is sandboxed in the way you cannot access any files outside your own package folder, and you don’t have access to the OS API.

If WASM was less restricted, it might have been possible to write a complete add-on entirely in WASM, with no need to “talk” with an outside application, but we know the only way to create add-ons in C++ for the XBOX will be WASM, which is why WASM won’t ever be allowed to do certain things, like unrestricted OS or file access.

So, while WASM for Gauges is surely useful, WASM for stand-alone is so restricted that, the ONLY thing is being used for right now, is to call the Gauge API on behalf of some external client, and use Simconnect to connect with it.

This way, the supposed benefit of lower latency is entirely lost, since you would still have to use client-server Simconnect in any case, just for send the data out, with the added aggravation that everybody is writing his own personal version of the same routine, increasing the traffic over Simconnect, likely causing loss of fps or stuttering.

ALL of this could be easily avoided is SImconnect would be upgraded to allow DIRECT access to the Gauges API, without requiring a WASM module.

Since we have to use Simconnect anyway, just to send the data out, why not just extend Simconnect to provide the data directly to external clients, without any need for each and every developer writing and having to maintain his own version of the same module, without any need to have users installing multiple modules increasing traffic over the Simconnect pipe for no reason ?

11 Likes

If one of these multiple developers would just open source their SimConnect<->GaugeAPI WASM module then we could ALL use it and thus avoid the problems you describe. If a developer needed additional functionality then they could code it in their local repository and send a pull request to the maintainer/s when the code is fully tested.

Edit: I just discovered this.

Now we just have to convince everyone to commit their code there (or to a similar project if it’s more appropriate).

2 Likes

Just a bump, MobiFlight moved from bitbucket to GitHub and the wasm module is now here:

There are still issues and pull requests on Bitbucket, but for any new development, the Github repository is the place to go.