Idea

You can write A: variables using Simconnect, check the SimConnect_SetDataOnSimObject in the docs.

Well, it's a good point. If WASM module has read access to variables, why can't it have write as well - like a stack that pushes edited user aircraft values on each frame.

You can, simply use execute_calculator_code instead.

I still don't think adding the ability to write A: variables without using Simconnect is really worth Asobo dev's time, when other things far more pressing are still lacking.

This, because you already CAN read/write to A: variables using Simconnect, and there are extra features too, like being able to read and write *multiple* variables at once and targeting Simobjects other than the user airplane.

So, the feature IS there. What would be way more useful, instead, would be adding reading/write of other (L:, H:, etc. ) variable kinds through Simconnect without the absurdity that right now, there are already dozen of WASM stand-alone modules that don't do anything other than serve those to an external connected client using Simconnect as transport.

And, since WASM is not multi-threaded, each of these modules ( which won't be needed if those variables could be used directly through Simconnect ) will weight on the CPU and, even if WASM modules would eventually become threaded, they would still generate traffic on the pipes channels.

@Simbol, I don't know if you realized it but, you are just making my point: I was saying it would be best to allow Simconnect for things we can't do right now ( L: vars, for example ) EXCEPT with a WASM module, for the precise reason they are limited, difficult to debug and bad for performances, because everybody (and his dog too ) is reinventing the same wheel, that is serving out access to the Gauge api to an external .EXE client through Simconnect, since we don't know if and when each WASM module would eventually run in a different thread, assuming it's even possible without facing thread safety issues we might not be aware of.

That's precisely why it's best to improve Simconnect with what is lacking, since it would both benefit those who need to use WASM but also those who don't want or can't, because their application simply can't work within the limitations of sandboxing.