Title says it all. The new SDK spec says, that L:1: scoped LVars is what developers want, to make sure that they don’t interfere with other objects of the same model. But TMBK SimConnect can’t work with “scopes”. But it does query variables for specific object IDs anyway, which should be kind of the same thing?
How do we access L:1: scoped variables with SimConnect?
I’ve been trying to do that all day. But since my simobject in my case is a staticObject not an aircraft it didn’t work.
It worked for me only via execute_calculator_code(‘(L:1:scopedvar)’) in a standalone WASM module
NOT via SimConnect or WASM legacy get_named_variable_value(id) as one cannot get an ID with an “1:scopedVar” name, also not with the new VarApi fsVarsNamedVarGet() - you don’t get an ID for this name either.
I used a standalone WASM module - but I would not know if the “scope” of this module is always the user aircraft instance?
Scoped vars are intended to be specific to the instance of the creator (at least that is how I read it…)
It would be very helpful to read a bit more about this topic.
SimConnect_AddToDataDefinition takes L:FOO and works okay. Does it not take L:1:FOO?
For the gauge API there is fsVarsCustomSimdVarGet and friends.
simconnect doesn’t throw an exception when adding a data definition with an L:1 var, but requesting data on the simobject that created that L:1 var still not works.
L-Vars cannot be directly accessed via SimConnect (at least, not “in general”). This is not special to MSFS, same goes for FSX and P3D. Suggest you take a look at the Dowson’s MSFS solution they use with FSUIPC: https://www.fsuipc.com/
The FSUIPC WASM module lives in the MSFS Community package directory, and you link to the WASM API library on the client side. I’ve used this with my products, works great! Last I checked, there are still a few issues that are being worked out for MSFS 2024.
FYI, the FSUIPC WASM module and the WASM API is free to use for everybody.
L vars have been accessible via SimConnect since a few FS 20 / SDK versions ago.
https://docs.flightsimulator.com/html/Programming_Tools/SimConnect/API_Reference/Events_And_Data/SimConnect_AddToDataDefinition.htm#lvars
My question is not about LVars in general. LVars can be accessed in MSFS 2020 and MSFS 2024 using the standard SimConnect methods that you would use for AVars.
This question is about the new variant, called “scoped variables”, appearing as (L:1:varname, unit).
Interesting, thanks for the info Max!
However, L-vars are just one thing that can be done with the Gauge API. In order to use other parts of the Gauge API, a solution like the FSUIPC WASM module is required, as the Gauge API cannot be used outside of WASM.
Lorby, yeah sorry my bad for not reading carefully enough. Unfortunately, it’s probably yet another case of “oops we forgot about that”… suggest you enter a bug report.
Same here, that is the route that I took as well.
The “intellectual” question here is, why LVars would have to be scoped in SimConnect, because we are already querying data using a specific object ID. This already works for AVars obviously, since you can query them for each individual simobject. So the L:1: syntax seems kind of superflous, and I would like to know more about the reasoning behind it.
It’s not really a bug, it is just bugging me…
I have a solution for the problem, that is not the issue here. The whole concept seems messed up though. On the one hand we’ve always had the AVars local to the Simobject we query. But apparently that wasn’t true for LVars? So if you were using, say the the same LVar name for the animation of the ailerons in an AI model as you were using in the user aircraft, then both would move?? I never noticed that.
So the question about what is “scoped” and what isn’t seems kind of important, at least to me.
OT
Indeed… check the WASimCommander link in my profile here… 
Reading from the SDK:
https://docs.flightsimulator.com/msfs2024/html/6_Programming_APIs/Reverse_Polish_Notation.htm
Section L and L:1 it tells us that
L … This variable is shared between aircraft if multiple instances of the aircraft are spawned using the variable. In general this is not what you want and you should use the scoped L:1 variable type instead.
and L:1 … This variable is scoped to each instance of the aircraft that uses it, so each instance will have a unique version of the local variable
Theoretically it makes sense regarding aircraft instances - only I don’t know how to spawn multiple instances of the same aircraft as a single pilot in the current Sim 
Anyway it seems that it was forgotton to update SimConnect and the WASM APIs to support this feature so far.
Anyway it seems that it was forgotton to update SimConnect and the WASM APIs to support this feature so far.
The WASM gauge API has explicit support for them in the new fsVars API as I mentioned previously. It’s just SimConnect in question.
As AI aircraft or static objects with the respective SimConnect methods. Nothing to it. Besides, as noted above, nothing is stopping an AI aircraft developer from using the very same LVar names for his own animations. Either LVars have always been scoped - or not, that is why they are bolting that functionality on “from the side” now. It seems strange though, that nobody noticed that before.
which one in the fsVars API - I have missed it (sorry)
The gauge api is deprecated in WASM 2024 (see compiler messages) and no replacement for the execute_calculator_code is provided …
there is no such support - officially
Yes one can still do it but for how long?
You can have a standalone module that will run execute_calculator_code.
I tried retrieving L:1 vars with it but had no success.
If you have multiple instances of a simobject, I don’t really understand how to tell execute_calculator_code which instance to fetch the data from.
I share this confusion. Never even considered that a “Local” variable is actually “global.” Who thought up these names?
I found this expanded description/explanation in the MSFS Avionics docs which spells it out and has a useful example to build on:
For example, let’s say that a particular type of airplane uses the
Door_OpenL var to control whether the airplane’s door is open. If a scoped L var is used (L:1:Door_Open), then multiple instances of the airplane in the sim can each have its own independent door state. Opening the door for one airplane instance (setting the value ofL:1:Door_Opento 1) will open the door only for that instance, and other instances of the airplane will remain unaffected. On the other hand, if a global L var is used (L:Door_Open), then opening the door for any airplane instance (setting the value ofL:Door_Opento 1) will open the door for all instances of the airplane.NOTE: When using
SimVarto access scoped L vars, the scope that is used is that of the player airplane.
OK so from, say, a standalone module or other code that expects to only operate on user object/aircraft, I guess using “scoped” L vars would prevent the door (from the example) from being affected on any other instances of the same model. Indeed, it would be silly if AI controlled models are flying around with doors open or what-have-you. I don’t understand how this was handled in previous sim versions or if it was even an issue, or what.
And what about multiplayer scenarios? Would toggling a door on your model also affect everyone else? 
The “intellectual” question here is, why LVars would have to be scoped in SimConnect, because we are already querying data using a specific object ID.
Indeed, seems redundant with the docs/explanations we currently have available. So in FS20 SimConnect using L vars was affecting objects globally… and no one noticed, or was it just not an issue for some other reason? Very strange.
One could argue (or even expect) that via SimConnect any L var should already be scoped to the specified object (once actually used via Request/SetDataOnSimObject()). Isn’t the ObjectID parameter supposed to define the scope already? Granted if one actually did want to manipulate these “global local vars” for all instances then SimConnect may need a new flag like SIMCONNECT_OBJECT_ID_GLOBAL to signal that.
PS. How often would one even want to change var values on all instances of a particular object? Typically in such a case a programmer would just loop over the available objects and modify them individually.