Simconnect vs WASM

Hi everyone,
I am devolping drivers for home cockpits hardware and I am trying to understand difference between accessing sim data via WASM module for example through (it is listed in documentation in GAUGE API section ):

FLOAT64 aircraft_varget(
    ENUM  simvar,
    ENUM  units,
    SINT32  index
    );

and oldschool simconnect. Which one is better just to access data from my driver?
Thanks for your help.

The SimConnect API is accessible from C++/WASM and from C#/C++ compiled .exe programs. Note that C++/WASM programs run in a virtual browser sandbox so those programs can interact with the Sim (via SimConnect) but otherwise have no access to the userā€™s PC so WASM is potentially suitable for in-aircraft gauges and modules. For more general use of SimConnect and the users PC then a Windows executable is likely to be more suitable.
I think C++/WASM has pretty much exclusively been used by people porting either their code or their skills from FSX, with HTML/JS being the more functional replacement for gauge code in MSFS.

HTML/JS is not good performance wise ā€¦

As far as I am understanding it:

You cannot access your hardware via wasm because it is runnibg in a sandbox. So you need to run your code outside and connect via simconnect interface.

If you need additional variables in gauges or want to display grafic in your gauges inside the sim you need to use wasm.
It is possible to exchange the variables via simconnect, so you may need both.

Drawback simconnect: you cannot use it for xbox.

If it is ā€œsimpleā€ hardware with buttons and siders you can make a USB-Gamepad or -Joystick device and simply map axis and buttons inside the sim.

I am building an XA41 cockpit using a pc. Since the original magnetoswitch is using two signals to set Off-L-R-Both (it is not like signal 1: left magneto, signal2: right magneto) I need external code and simconnect. For the future XPNDR I will need to display a kind of standby XPNDR Code that is not existing in the sim. So I need to create a custom variable in wasm to display it in my custom XPNDR gauge in the sim and be filled via simconnect from my external code witch is connected to my hardware transponder.

Hope this helped a bit. If I understand something wrong, please correct me. I am also on the search to find my way through the sim jungle. :slight_smile:

This is confused because Asobo added WASM/SimConnect to help migration of FSX C++ gauge code, so FSX devs (probably still the majority of MSFS devs) tend to concentrate on the WASM support even though it has significant limitations in MSFS.

There are three apiā€™s that work as intended on MSFS:

(1) The Windows compiled .exe simconnect programs. These can be written in C++ or C#, have full control over the usersā€™ PCā€™s, and interact with the sim across a protected inter-process boundary exchanging information via reading and writing simvars that either affect the sim engine directly or can also be read and written by gauge code. An error that crashes your Windows .exe simconnect program will typically have no effect on the sim at all. The excellent integration with the userā€™s PC comes with a trade-off of less integration with MSFS, i.e. you are limited to variable value exchanges via the simconnect API.

(2) Model Behavior XML - this uses an unusual proprietary programming language defined partly as a reverse-polish stack based language supporting variables with basic arithmetic, if-then-elseā€™s and simple math functions, and also a scripting language defined in XML itself, with special tags used for procedure calls, switch statements and argument passing. This code is closely tied to the sim update cycle and designed to be mostly linear (i.e. no loops) and so very fast. An error in the XML will typically cause MSFS to CTD as soon as the aircraft is loaded, but valid XML that loads ok is then very unlikely to crash the sim. For simple gauges than only move animated parts (e.g. an ASI) this API works fine.

(3) The HTML/JS gauge system. This runs in a separate thread but is closely tied to the sim with a comprehensive API allowing access to all simvars, user interactions including ā€˜touchā€™ and higher-level APIā€™s such as the map, flightplan and flight services at airports. The HTML is mostly optional (i.e. a module can be written in JS with no direct interaction with the pilot) but the HTML allows arbitrary digital content to be rendered onto texture surfaces in the aircraft and user interactions with that area can be passed back to the gauge code. The HTML is particularly suited to flat-panel instruments, and also the background dials of analog instruments so those can be adjusted according to user preferences (i.e. imperial/metric, or light/dark options). JS has very similar syntax to C++ but also has standardised ways of rendering digital data (i.e. svg/html/css) and asychronously receiving user events so there is widespread experience of those (i.e. web development).

Note that none of these options are C++/WASM, which allows you to take older C++ code that used the SimConnect interface, and compile it into a Javascript subset (WASM) that runs in the same protected enviroment as the HTML/JS gauge code and can write digital data to in-cockpit textures using a 2D/3D library, but has no access to the external PC or the various gauge APIā€™s making it a distant second choice for new gauge development in MSFS.

There is no relevant performance difference in MSFS between JS and WASM for normal cockpit content in a complex aircraft. The Volocity Volocopter developers DID write a complete replacement flight simulation engine in C++/WASM to replace the engine inside MSFS and that was definitely faster than JS, but that code has no UI/interaction. The canonical instrument which you would have performance concerns for would be the large modern PFD and MFD displays and these are being most successfully developed in HTML/JS. WASM doesnā€™t run at all on the XBox at the moment, and some developers are lobbying to get that implemented, but even then there is no chance those simconnect programs will have access to the userā€™s device (PC or XBox) so the simconnect programs are still a limited choice to the JS APIā€™s, unless youā€™re porting a whole load of existing Windows C++/simconnect code.

Unless you are porting an existing C++ XPNDR gauge from FSX then HTML/JS would be a far more mainstream choice for a new gauge in MSFS.

7 Likes

This is really insightful stuff especially as Iā€™m looking to build my first addon. What would be the best approach to building an addon that displays a pdf from the documents folder, similar to an EFB?

I was thinking of a .exe file linked via a local server but having read the above regarding HTML/JS Iā€™m now not sure.

Thank you for clarification :slight_smile: I will need to dig into the html/javascript stuff in this case.

Could you link any thread or documentation for (2) ? It is first time I hear about this. Do I get it correctly that using XML Behaviour Model I can create my own variables based on others and than get this custom variable via SimConnect ?

No this is incorrect - you can program the sim via RPN code in the model XML code, including creating many new variables which can be shared with the html/js code, but those variables will not be visible to simconnect via a .exe or C++/WASM.

This is almost correct :wink:

However it is my understanding that you can expose those ā€žlocal variablesā€œ via SimConnect as ā€žuser variablesā€œ (or events (?)).

There are threads here in the forum that describe this ā€žhow to access local variablesā€œ in great detail.

But yes, there are drawbacks: naturally your addon must be running inside MSFS (to ā€žserveā€œ those local variables via SimConnect), and most importantly your chosen ā€žuser data (event?) IDsā€œ may clash with other such addons that have chosen the same ā€žuser IDsā€œ.

Is it possible to read a file (e.g. text or values from a database) using WASM or does it have to be fully self contained and only get/set simvars with simconnect?

1 Like

Sorry, but I have no practical experience with compiling code as WASM. I guess from a WASM only standpoint there are no limitations, but I strongly assume that the ā€œsandboxā€ (e.g. webbrowser etc.) the WASM code runs in puts certain restrictions on it (e.g. ā€œno file accessā€ and what not).

UPDATE: depending on the ā€žsandboxā€œ in question it may provide APIs on its own to permanently store (and read) dara - within the ā€žsandbox boundariesā€œ for the app.

Random link:

Yes, thatā€˜s mostly related to ā€žweb appsā€œ and not necessarily related to WASM let alone the ā€žMSFS WASM runtimeā€œ. But it should be a good startā€¦

2 Likes