@FlyingRaccoon, your comment about the GaugeAPI not working in a stand-alone
module is worrisome. Maybe parts of it might not make much sense without a
Gauge but, the only reason why people has been using Stand-Alone WASM modules
until today, is to keep reinventing the wheel of using the GaugeAPI to pull L:
variables on the outside, using Simconnect as a communication layer. It seems
the OP is doing that as well, and while I never used the
set_named_variable_typed_value, I assure the most of the calls related to L:
variables, including the ubiquitous execute_calculator_code, not only works
just fine, but they are part of many products that has been already released
and rely on those calls. There are many of identical stand-alone WASM modules
that all do exactly the same thing, basically, which is almost the only thing
for which a Stand-alone WASM module is useful. They are used to help various
add-ons, handle hardware interfaces, and the only reason why everybody has
wrote the same module, over and over, is just one: We can’t access L:
Variables or execute XML expressions using Simconnect We have been asking
for this feature for a long while, and it’s currently the 3rd most voted idea:
https://devsupport.flightsimulator.com/t/3082 Because of this, since
products needs to be done, and developers do whatever they need to do to
achieve their goals, we are already with dozen of modules doing exactly the
same thing, all spamming Simconnect with by-directional communication to use
WASM in a client-server way to read/write those variables, all affecting the
Main thread, and let’s assume none of them has bugs. Please, consider adding
native support to read/write ALL kind of variables with Simconnect, both in
and out of process. That would make disappear 90% of the stand-alone WASM
modules out there, and performances, reliability and sim startup time will
benefit all.