Currently, only double data types are officially supported in local simvars
(Lvars). There needs to be a more efficient way to relay data between WASM
gauges as well as to/from WASM and JS gauges. Supporting string and custom
defined struct datatypes as lvars would be a huge plus. Also, being able to
read/write lvars and trigger h-events from external SimConnect clients would
be helpful.
Agreed, this is very important, and might prevent the unneeded proliferation
of dozen of almost identical WASM modules, all doing the same thing: calling
the Gauge api and use Simconnect client areas to extract data for external
.EXE clients.
Yeah - this is definitely what’s happening at the moment (I’ve had to write
custom modules for hardware to interface with the A32NX), and the last thing
we want to happen is for these multiple modules to affect performance for the
end user. I believe I brought this up to Asobo some months ago, and they
mentioned that the challenge on their end lies with specifying the simobject
that’s being talked to for LVars, but when it comes to standalone WASM
modules, specifying the simobject isn’t necessary… so perhaps this isn’t as
much of a barrier to implementation as previously thought?
I have created the MobiFlight WASM module for MobiFlight to be able to access
the A-Vars, L-Vars and trigger all kinds of events and code. I was probably
the first who published it, including its sources
(https://github.com/Mobiflight/MobiFlight-WASM-Module). I would propose to
consider rebuilding the SimConnect API for data access and allow for a more
modern and stable way to interact with the Sims Data. This could be so
powerful! I understand there is a myriad of tools that have grown over the
past decades that can interface with SimConnect. This definitely explains why
we would want to have SimConnect for these legacy tools. in my opinion, it
took way too much effort to be able to read and write all the data and it is a
HACK for sure. It’s 2021 and the home cockpit builder and also tools community
deserves to get an API that looks like it is from this decade (REST,
Websockets, or so). I am happy to help you with it.
I love your WASM module and agree with everything you put here. I really hope
MS/Asobo will step up SimConnect, but for the meantime thank you very much for
giving us this workaround.
I’m using the wonderful MobiFlight WASM module and a Python extension to read
and write L:vars in MSFS Mobile Companion
App. You can have a
look at the source code on the GitHub project page here:
https://github.com/mracko/MSFS-Mobile-Companion-App I hope this helps - at
least until it’s natively supported by SimConnect.
I’m using the wonderful MobiFlight WASM module and a Python Extension to read
and write L:Vars in MSFS Mobile Companion
App. You can have a
look at the source code on the GitHub project page here:
https://github.com/mracko/MSFS-Mobile-Companion-App I hope this helps, at
least for now until it’s natively supported by Simconnect.
Hello, While at the moment there is no plan to support string & custom structs
for vars, we definitely have a task in the roadmap to provide a better
documentation & to standardize the behaviour of our different variable types.
I believe this will be a good start to improve their usage.
The problem of not having an official way to access those variables and events
through Simconnect, is thear has been already a proliferation of stand-alon
WASM modules (not gauges) all reinventing the wheel and doing exactly the same
thing: using Simconnect client data areas to pass those variables to external
.EXE modules, which is what developers need to create, becasuse of the
extremely limited sandboxing when using just WASM. These being stand-alone
modules are of course causing performance problems and useless traffic over
Simconnect, without even discussing possible bugs which, being stand-alone,
will affect the simulator for the entire session, not just the loadede
airplane as they were gauges. What’s the current status of WASM multithreading
? Not necessarily allowing thread creation in a single module but, at least,
will separate modules be assigned each one to its own thread, instead of all
of them running on the main thread ? This at least might mitigate the problem
of multiple modules running all at the same time, all doing the same thing.