Safe use of BUS LOOKUP INDEX in Js

Per the docs on electrical: This is a settable simvar meaning that it can both
be read and set. Some of the simvars in this list are using this to lookup a
value using two arguments (one argument in addition to the component index).
For example to check the state of the connection between a “circuit.45” and
the “bus.2” it would be written as follows: 2 (>A:BUS LOOKUP INDEX, Number)
(A:CIRCUIT CONNECTION ON:45, Bool) I would like to be confident that it is
safe to use SimVar.SetSimVarValue and subsequent GetSimVarValue and this not
run into any race conditions (with wasm, external simconnect, behaviors or
other Coherent contexts even). Is that true that this is safe, or is it not
recommended to attempt to use electrical vars outside of RPN?

Hello @davux3 It’s expected to be safe. If you encounter any issue, it means
there’s a bug on our side and you should report it. Regards, Sylvain

Hi @FlyingRaccoon. I have spent quite some time with the electrical system now
and I do believe there is some kind of problem. It is difficult because the
results are true/false, but it seems a bit like only one Set call is allowed
per-frame. In my case I am attempting to query a set of bus connections, first
3 against one bus then another 3 against the second bus. The results of one of
the groups would always be wrong (when compared with the in-sim electrical
debug). I replaced the logic with a snippet of RPN that saves to an L:Var and
everything worked correctly. I have setup a pretty extensive system with bus
ties and automatic logic and all is working really well once I went the RPN
route, so I do really think something is broken. The good news is that the
workaround is not making a mess and works well. Thanks again.

Hello @davux3 SetSimVarValue is asynchronous so you probably want to use
its return promise to encapsulate your GetSimVarValue call:

SimVar.SetSimVarValue("BUS LOOKUP INDEX", "Number", 2).then(() => { 
    let myValue = SimVar.GetSimVarValue("CIRCUIT CONNECTION ON:45", "Bool");

We have introduced a new syntax in RPN that lets you pass the lookup value
directly when reading the simvar (it’s being documented and was discussed
here: We will extend support
for this type of reading to other APIs in the future. Regards, Sylvain

Hello @davux3 I’ve edited my answer here. It turns out the writing is
asynchronous but calling then() should be enough to guarantee the writing is
finished. Also, if you have subsequent set calls, make sure they’re nested in
the then as well or the 2nd set could be called before the 1st Get is done.
Regards, Sylvain