Hi, two days of studying this forum and all of the Google and I am still stuck
SimVars such as A: variables, which are independent for each SimObject cannot
be created. The list of available variables changes depending by the kind of
SimObject, with the User airplane having the largest set, AI planes a bit less
( but some extra specific to AI ), ground vehicles less, and Static objects
even less. These are read/written using Simconnect, either from external .EXE
or from WASM modules. You can create any number of L: variables, which are
instead “global”, not tied to a specific SimObject. You cannot read or write
these from SimConnect ( one of the most voted suggestions here asked for the
ability to do so ), so the easiest way to use them is to create a WASM module,
either as a Gauge or as a stand-alone module, which can access to the Gauges
API that provides a series of functions to register, read and write these
“user” variables, without Simconnect. The only way to give access to these
variables to an external .EXE, is to write a WASM module that can use L:
variables, and use Simconnect custom client data functions to transmit these
variables and their values to an external Simconnect .EXE client. There are
several modules doing this, but we are trying to convince Asobo to add direct
support for L: ( and H: ) variables from Simconnect, in order not to have
dozen of WASM modules all doing the same thing, needlessly increase traffic
over Simconnect.
OK, understood 
So… I still not clearly understand that: may I use any chosen (by me)
existing variable/variables, associated for example with: “Services Specific
Variables”: for example - CATERINGTRUCK ELEVATION CURRENT and attach this
variable in XML code of my own static object? If I will change the value of
the variable from outside by SimConnect, will it work “for me” or will it
crash all of MSFS catering trucks as well??
So I’ve made two attempts: CODE_A:
(A:TAILHOOK POSITION, number) flr 128 & 0 &eq;
RESULT_A: CTD of MSFS, when trying to spawn at the scenery. CODE_B:
`
(A:TAILHOOK POSITION, number) flr 128 & 0 &eq;
`
RESULT_B: Airplane is flying there , I see my object but changes by
SimConnect to “TAILHOOK POSITION” SimVar made no difference in visibility -
the object was still visible. PS. Today SDKv13 was released but I was not
able to find “Behaviors” nor “Visibility” description.
Code A should work. However, you included the wrong file, since the FX.XML
file doesn’t include that template definition, which is in
Asobo\Generic\Visibility.xml instead. And, your visibility code could probably
be streamlined like this:
(A:TAILHOOK POSITION, number)
This will make the object appear if the variable as any value other than zero
If you want the opposite effect:
(A:TAILHOOK POSITION, number) 0 ==
This will make the object appear only if the variable is zero And:
(A:TAILHOOK POSITION, number) 128 ==
This will make the object appear only if the variable is 128
Thanks! Actully the code I tried to design was meant to be like that: every
bit of the number will switch ON/OFF different group od POIs 
Anyway:
objects should be SimObjects and not scenery objects (ArtProj), everything is
explained in detail here - MSFS - Visibility | FSDeveloper:
https://www.fsdeveloper.com/forum/threads/visibility.449781/
Yes, for behaviours to work, the object must be a Simobject. Animations should
work even in objects part of a library .BGL but, at the moment, the current
Beta 1.18.9.0 is bugged, and animations in .BGL stopped to work, which has
been reported in other threads, so I hope it will be fixed before release.
you got any clue how to control visibility conditions through simconnect ?
(without wasm modules)
I’d like to chip in here, especially concerning the suggestion that you need
to write a WASM module to be able to exchange data that is not covered by the
predefined SimVars. Yes, L-Vars are the only Simulation Variables that are
“uncontrolled” in the sense that you can add your own, but the reason they are
also locked tight into the simulator stems from their origin: they were meant
to be used in panels and gauges, persisting beyond the single gauge they are
created in so they can be read or controlled in another gauge. (or part of the
panel) Also, because they persist, they still hold their value the next time
the panel (or gauge) needs to be generated, which allows for quite complex
components. The first version of Aerosoft’s Airbus Extended (as it was called
then) had the MCDU implemented with a large amount of (XML-based) stack-
machine code. At the same time brilliant and frighteningly complex. Given this
persistence, it was quickly the go-to method for exchanging custom data
between add-ons, provided both lived inside the simulator. So next
everyone started making DLLs that implemented some other way of exposing those
L-vars to the outside world, which works but is definitely not what they were
intended for. I think FSUIPC is a perfect example of this, as it provides a
LUA platform where you can access everything in a much more consistent way,
including those L-vars, at the cost of now having to integrate with a new
environment, increasing your dependencies with one more (versioned) module. I
love FSUIPC, but not the reason why it was needed. The other way , which
is what was actually intended to be the “official” SimConnect-compatible way
of exchanging data, is to use Client Data. SimConnect allows you to
define a block of data, give it a name, and then distribute that data to any
subscribers. This data will be sent to any SimConnect client app that
knows the name of that block and asks for it. No need for WASM or L-var
trickery. The only “disadvantage” is that the Client Data blocks are just
unstructured blocks of bytes, which you can easily solve in C, C++, or C# by
mapping a struct on top of it with any fields you want. With Aerosoft being a
big fan of L-vars, PMDG is using Client Data. So, if you want to interface
with Aerosoft aircraft, you need to solve the L-var conundrum. If you target
PMDG aircraft instead, you need to tell their aircraft’s runtime they should
send the data to the simulator using an option in an INI file and include the
header file they provide to get the struct definition. Ah yes, there is
actually a third way: you can define custom events and send numeric data with
them, but this is much riskier because there is no registry for them. So, if
you write an add-on that wants to use events to send data around, you need to
choose an event number and hope no other add-on is alive that uses that same
number. Cheers, Bert
Simconnect Client data and L: variables are not alternatives. They both have
their uses, depending what you need to do. Sure, “just” to exchange data,
there’s no need to use L: variables but, if you need to do something like
driving an animation part or use visibility conditions on objects, and you
need to do that from an external application ( ex. not from Javascript, which
can access more variables types ), you either use the object own A: variables,
assuming they can be written to, sometimes repurposing them, or you use some
L: variable, if you don’t need it instanced across multiple objects. That’s
because those are the only ones you can tie a XML behavior to AND control them
through WASM/Simconnect or external .EXE/Simconnect. You can’t code an XML
behavior based on custom data areas, and you can’t access variables other than
A: with Simconnect alone and you need WASM to access the other kinds, with
several kinds only available trough Javascript. So, the real issue here, is
the lack of integration between Simconnect and the new HTML/JS subsystem,
which if it was there, it would make WASM so much more useful for external
modules than how it has been used so far, acting like a server for external
applications requiring access to the Gauges API.
Hi, does anyone know what the “Z - Custom SimVar” variable type is all about?
It is listed in the RPN
reference,
but I never see anything else about it. Some old throwback to previous FS
versions? (I’m not a designer, my primary interest is interfacing with the sim
externally.) From what I can tell, the variable access issue could be solved
by aircraft designers being able to specify custom SimVars which SimConnect
could then access just like any of the built-in ones (and presumably they
could be settable or not, maybe even have Unit specifiers). “Just” like we can
do now for registering custom events from C code (with a “.” in the name).
Thanks, -Max
You can find descriptions of each type at
https://docs.flightsimulator.com/html/Additional_Information/Reverse_Polish_Notation.htm