plane icon Welcome to Microsoft Flight Simulator’s SDK Q&A Platform!

You have questions regarding the SDK? DevMode Tools? SimConnect? You would like to submit an idea for future improvements, seek help or exchange knowledge? You’re in the right place.

In the upcoming flighting, we've changed the behaviour of the content.xml file. If your addon uses this file, please read this article!

Please take a moment to read the platform’s guidelines before you get started!


question

RipPipPip avatar image
RipPipPip asked virtuali commented

How to create own SimVar for use by SimConnect (to change its value from outside MSFS)

Hi,

two days of studying this forum and all of the Google and I am still stuck - my question is:
how to create own SimVar for use by SimConnect (to change its value from outside MSFS) ?

Is it possible already? I do not like to mess with existing variables...

BTW: I have read and even generated a sample SimvarWatcher application.


Regards,
Rysiek


simconnect
10 |10000

Up to 5 attachments (including images) can be used with a maximum of 4.8 MiB each and 23.8 MiB total.

virtuali avatar image
virtuali answered

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.

10 |10000

Up to 5 attachments (including images) can be used with a maximum of 4.8 MiB each and 23.8 MiB total.

RipPipPip avatar image
RipPipPip answered

OK, understood :/

10 |10000

Up to 5 attachments (including images) can be used with a maximum of 4.8 MiB each and 23.8 MiB total.

RipPipPip avatar image
RipPipPip answered RipPipPip edited

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??


10 |10000

Up to 5 attachments (including images) can be used with a maximum of 4.8 MiB each and 23.8 MiB total.

RipPipPip avatar image
RipPipPip answered virtuali edited

So I've made two attempts:


CODE_A:

<?xml version="1.0" encoding="utf-8"?>

<ModelInfo guid="{dde7e4d0-dc1c-4ff4-8fcf-11490e798479}" version="1.1">

<LODS>

<LOD ModelFile="poi_00603_LOD00.gltf"/>

</LODS>

<Behaviors>

<Include ModelBehaviorFile="Asobo\Generic\FX.xml"/>

<Component ID="component_poi_00603" Node="node_poi_00603">

<UseTemplate Name="ASOBO_GT_Visibility_Code">

<VISIBILITY_CODE>(A:TAILHOOK POSITION, number) flr 128 & 0 &eq;</VISIBILITY_CODE>

</UseTemplate>

</Component>

</Behaviors>

</ModelInfo>

RESULT_A: CTD of MSFS, when trying to spawn at the scenery.


CODE_B:

<?xml version="1.0" encoding="utf-8"?>

<ModelInfo guid="{dde7e4d0-dc1c-4ff4-8fcf-11490e798479}" version="1.1">

<LODS>

<LOD ModelFile="poi_00603_LOD00.gltf"/>

</LODS>

<Visibility>

<Parameter>

<Code>

(A:TAILHOOK POSITION, number) flr 128 & 0 &eq;

</Code>

</Parameter>

</Visibility>

</ModelInfo>

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.

3 comments
10 |10000

Up to 5 attachments (including images) can be used with a maximum of 4.8 MiB each and 23.8 MiB total.

virtuali avatar image virtuali commented ·

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

0 Likes 0 ·
RipPipPip avatar image RipPipPip virtuali commented ·

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/

0 Likes 0 ·
virtuali avatar image virtuali RipPipPip commented ·

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.

1 Like 1 ·
redouane avatar image
redouane answered

you got any clue how to control visibility conditions through simconnect ? (without wasm modules)

10 |10000

Up to 5 attachments (including images) can be used with a maximum of 4.8 MiB each and 23.8 MiB total.

bert.laverman avatar image
bert.laverman answered virtuali commented

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

1 comment
10 |10000

Up to 5 attachments (including images) can be used with a maximum of 4.8 MiB each and 23.8 MiB total.

virtuali avatar image virtuali commented ·

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.

0 Likes 0 ·

Write an Answer

Hint: Notify or tag a user in this post by typing @username.

Up to 5 attachments (including images) can be used with a maximum of 19.1 MiB each and 23.8 MiB total.