Reading SimVars aka A:vars (and Z:vars) by name instead of offsets?

[joeherwig]

Dear John,

I'm currently integrating the A320 Korry-Annunciators of FBW A32nx into my home cockpit.

Of course i found in the Advanced Users guide you provided the Manual for "Adding Simulator variables (simvars) to FSUIPC offsets" on Page 34. And you already implemented plenty of mappings of the easy to work with variable-names to the offsets. So it seems, that FSUIPC is accessing the vars within the sym by name which is great.

For us as users, it is really painfull to first search for the variable then add the variable into the myOffsets.txt, search for the next free offset within an allowed range (respecting the sizes of the previously assigned offsets etc. and then accessing the var via the hard to remember offset instead of the easy to remember and usually documented variable name...

Do you see any chance to implement something to read (and set) MSFS A:Vars (and Z:Vars as they behave identical) by name instead of the offsets somehow? It would be a huge leap ahead regarding the use of FSUIPC for home cockpits. Probably it would make it a lot easier for you as well instead of implementing completely everything listed as simvars on request.

Thanks a lot and best regards,

       Joe

[John Dowson]

1 hour ago, joeherwig said:

Do you see any chance to implement something to read (and set) MSFS A:Vars (and Z:Vars as they behave identical) by name instead of the offsets somehow?

Not really as I don't see how this can work. How would you read/set them if not from offsets? Or are you talking about using lua? But even with that, you would need to read them from somewhere...
Currently I am reading lvars using simconnect. It is not a straightforward process - you don't just ask for the value of a simvar, you have to add it to a data definition and then request that data definition on some sort of interval (basically, although it is more complicated than that). You then receive the values asynchronously. these then need to be put somewhere so that they can be accessed somehow.

It is now possible to access a:vars via calculator code in a WASM, but accessing this way would also present the same issues - if not  more.... It would be a request/response (again, asynchronous), and allowing this via WASM communication (which is via Client Data Areas, again using SimConnect) would mean that you would basically have to implement a simconnect-style a:var access system using CDAs, and do this in a way to make the interface easy to use/understandable to a non-programmer. I really can't see how this can be done.

1 hour ago, joeherwig said:

Probably it would make it a lot easier for you as well instead of implementing completely everything listed as simvars on request.

It is a lot more work for me (if even possible - would be a lot of work to even think about how this could be implemented) for minimal benefit (if any) for a small user subset. You would still need to know the names, sizes and units of the simvars - or do you expect me to make these all available somehow and continually update these as well?
And currently there is no work for me, as I am  no longer adding simvars to offsets on request - this is why I have provided the current mechanism for (advanced) users to be able to add any simvar to an offset, so that I no longer have to do this.

I could possibly add a UI instead of using the myOffsets.txt file, but if this UI was to present all available a:vars with there default units/size and the possible conversions available 9and maybe a descriptive text, this would basically mean that I would have to incorporate the MSFS simvar documentation into FSUIPC7 and keep this updated...again, a lot of work for little benefit  - and no real cost benefit as I don't think this would improve my sales, which I also have to consider. My time is actually quite limited for updates/improvements, as most (if not all) of my time is taken up on support issues and keeping up with MSFS/P3D and SDK updates. 

Regards,

John

[joeherwig]

Hi John, 

Thanks... So i see... 

Main issue is the way how simconnect makes AVars hardly available compared to LVars. So the latter are much simpler to access? 

The easier approach seems to reach out to the Addon vendors to provide the values to be readable via LVars instead of AVars. 🙈

Joe

[John Dowson]

1 minute ago, joeherwig said:

Main issue is the way how simconnect makes AVars hardly available compared to LVars. So the latter are much simpler to access? 

There is no access to lvars via simconnect - they are only accessible via the gauges API and are handled by the FSUIPC WASM module. And in the WASM I can scan for lvars programmatically, and so can get the names of all the ones available. There is no such method to scan for a:vars (or hvars, or any other variable type). And all lvars are a fixed size, so there is no added complication determining their size - they are all treated as doubles.

5 minutes ago, joeherwig said:

The easier approach seems to reach out to the Addon vendors to provide the values to be readable via LVars instead of AVars.

That seems to be the way most add-ons are going anyway,  and a:vars cannot be added by an add-on, only used. All a:vars are provided by the FS and documented in the SDK.

John