Hello, Would it be possible to allow WASM to write settable A:VARS? we can
currenlty only read them but not write them, and instead we have to create an
internal Simconnect module to write A:VARS values. We can currently write
L:VARS already, which is great… but It would be great is WASM could be keep
in pure gauge code and avoid to have to use Simconnect for such purpose. Best,
Simbol
You can write A: variables using Simconnect, check the
SimConnect_SetDataOnSimObject in the docs.
Hi Umberto, I know this, what I want is to avoid having to code Simconnect
modules and dispatchers, etc. inside WASM just to write A vars. I want direct
access to write all variables from WASM without having to use Simconnect at
all. Regards, S.
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.
Exaclty… and you can already write L:VARS… even exchange L:VARS between
other WASM (gauges) modules and write on those… All we missing is the
capability to write A:VARS directly from WASM… in fact any variables why
limiting it… if it is a WASM module for my own aircraft, I should be able to
work with any variables interacting with it :). S.
You can, simply use execute_calculator_code instead.
I really don’t want to use this, it makes the C++ code a real mess with
Reverse Polish Language. The request is to support C++ natively and in the
same way as we work already with L: vars… Without using these unnecessary
work arounds.
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.
Having to rely on SimConnect just to write a variable is just crazy. I have
been using WASM for several projects with SimConnect and simply put it is
unstable, SimConnect gets disconnected due to external issues in the sim and
then refuses to re-connect from WASM causing the module to fail unless the
entire Msfs is re-started, try to explain that to a customer. The entire
objective of WASM is to allow us to be able to create gauges for our aircraft
and interact natively with the Sim. Having to use SimConnect or reverse polish
to complement such simple task defeats the purpose. If I wanted to use
SimConnect to talk to the sim, I can create a SimConnect application for this
purpose, or an in game panel with Html / JavaScript which already allows to
set A vars without any extra hooks. In addition look what happened to Pmdg on
Xbox, WASM modules failing to operate properly, who knows why… But clearly
having to add such way arounds inside of WASM to achieve a simple goal like
set a setable variable is just not the right approach since it can cause many
unstable results. I am not asking the end of the world surely, I am asking
WASM to be expanded to be used as it is supposed to be used. S.
@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.