Jump to content
The simFlight Network Forums

FSUIPC7/LUA and SimConnect indexed variable


Recommended Posts

Hi all,

I have a few technical questions before buying FSUIPC7 because I'm not sure about what I can acheive from FSUIPC7/LUA scripts regarding the SimConnect Indexed variables.

As example, I take the Asobo Airbus A320 .
Someone has already reported that Offset 07D4 [AP ALTITUDE VALUE] is not working. He gave up thinking it was a bug.
I found that Offset 281C or 3102 [Master Battery Switch] are not working neither.

After having looked into Microsoft SDK and SimConnect, I found that the A320 FCU AP Altitude is linked to an indexed SimVar  [AUTOPILOT ALTITUDE LOCK VAR:3]
It seems that FSUIPC7 is not natively looking at this SimVar.

Both A320 Battery Push Buttons are a bit more tricky:

For the left battery Push button:
First, set SimVar BUS LOOKUP INDEX to value 10
Then the state of the left battery can be read at indexed SimVar BUS CONNECTION ON:6

For the right battery Push button:
First, set SimVar BUS LOOKUP INDEX to value 11
Then the state of the right battery can be read at indexed SimVar BUS CONNECTION ON:6

So here are my questions :

Q1. Is it possible from FSUIPC7 (I guess with Lua Scripts) to access the Indexed SimVars and map them to a free FSUIPC7 offset ?


I know it *was* possible to access Local SimVars with Lua scripts, but I want to be sure that we can query the indexed variables, for instance like this :

ipc.writeXXX("A:BUS LOOKUP INDEX", 10)
LeftBattery = ipc.readXXX("A:BUS CONNECTION ON:6")

ipc.writeXXX("A:BUS LOOKUP INDEX", 11)
RightBattery = ipc.readXXX("A:BUS CONNECTION ON:6")

Q2. Is it possible from FSUIPC7 to log all SimVars and Indexed SimVars ? (in order to identify which one is changing after a few clicks in the virtual cockpit)

Oh god, the BUS LOOKUP UP thing is not going to help with this kind of feature...

---
Regarding the Local SimVar, I understand that FSUIPC7 has no way to access them. And in fact, Microsoft SimConnect SDK does not provide a way to do this.
The only workaround for now is to create a fake gauge and put the local SimVar in the Client Data Area. Then FSUIPC7 would be able to
read/write the Local SimVar through the SimConnect SDK.

Link to post
Share on other sites
16 minutes ago, Pliskin said:

regarding the SimConnect Indexed variables

If by 'indexed variables' you mean standard simconnect variables that are indexed (i.e. in an array), then I don't understand your worries as they are no different from standard un-indexed sim variables.

18 minutes ago, Pliskin said:

As example, I take the Asobo Airbus A320 .

The A320Neo is known to function quite differently than  most other aircraft, with many controls/events and sim variables currently not functioning for that aircraft.

20 minutes ago, Pliskin said:

Someone has already reported that Offset 07D4 [AP ALTITUDE VALUE] is not working. He gave up thinking it was a bug.

Reported here? Reference would be useful.
Many AP variables (and controls) are currently not working, especially for the G1000.

21 minutes ago, Pliskin said:

I found that Offset 281C or 3102 [Master Battery Switch] are not working neither.

Maybe. But using offsets is tied to a specific control (or simvar) that may not be working for that particular aircraft. You have to choose a method that works for the controls provided for each aircraft. If they do not respond to the 'generic' controls, then other mechanisms should be used.

27 minutes ago, Pliskin said:

After having looked into Microsoft SDK and SimConnect, I found that the A320 FCU AP Altitude is linked to an indexed SimVar  [AUTOPILOT ALTITUDE LOCK VAR:3]
It seems that FSUIPC7 is not natively looking at this SimVar.

If available, any simvar can be added to the offset area on request.

28 minutes ago, Pliskin said:

Q1. Is it possible from FSUIPC7 (I guess with Lua Scripts) to access the Indexed SimVars and map them to a free FSUIPC7 offset ?

No. Only simvars known to FSUIPC and published in the offset area can be accessed. If there are simvars not currently requested by FSUIPC that you require, then I can add these upon request.

30 minutes ago, Pliskin said:

I know it *was* possible to access Local SimVars with Lua scripts, but I want to be sure that we can query the indexed variables, for instance like this :

Thats local variables, or lvars, not simvars. There is currently no access to lvars in FSUIPC7, pending facilities to be provided.

31 minutes ago, Pliskin said:

Q2. Is it possible from FSUIPC7 to log all SimVars and Indexed SimVars ? (in order to identify which one is changing after a few clicks in the virtual cockpit)

A simvar is a simvar, indexed or not does not make a difference. The included offsetStatus spreadsheet contains the simvars used for each offset (where applicable), together with a list of available simvars not currently held in the offset area (at the end of the document, after the offset list). Please take a look at these.

For the definitive list of available simulator variables, please see the MSFS SDK documentation. Note also that they are documented in two sections, one is the complete list of simvars, and the other is the list available via SimConnect. FSUIPC7 obviously (?) uses the latter, although I have had some success requesting variables in the former not in the latter, i.e. simvars not yet documented as being available via SimConnect.

 

Link to post
Share on other sites

Thank you for your answer.
 

Quote

Reported here? Reference would be useful.


The issue regarding the AP Altitude on A320 is here

Some other topics are refering to the same issue

We can find a few discussions like this on other forums:
https://forums.flightsimulator.com/t/a320-fcu-variable-autopilot-altitude-lock-var-vs-displayed-altitude/307093/3

In fact, the A320 FCU altitude 7-segment display is mapped to [AUTOPILOT ALTITUDE LOCK VAR:3] and not to [AUTOPILOT ALTITUDE LOCK VAR]

I guess when we push or pull the altitude knob, then the value is copied from [AUTOPILOT ALTITUDE LOCK VAR:3] to [AUTOPILOT ALTITUDE LOCK VAR]
 

Quote

You have to choose a method that works for the controls provided for each aircraft. If they do not respond to the 'generic' controls, then other mechanisms should be used.
[...]
No. Only simvars known to FSUIPC and published in the offset area can be accessed.

I understand a FSUIPC Lua script will not solve the issue by itself. A new offset has to be published in any case.

I feel a bit a bad to ask to implement new offsets just because this plane is not working like the others.
Is it not too "dirty" to add "official" offsets just for this plane ? I mean, this is not a bug from FSUIPC. The issue is on the A320 by design (and I think there is a legit reason for Asobo to have implemented things like this).

Perhaps a better solution would be to add new functions to the lua API in order to allow it to query SimVar by their name directly.
Or better, perhaps FSUIPC could give us the possibilitity to publish our own custom offset by providing the name of the SimVar (and mandatory parameters).
The case of the battery push button requires a macro, because it depends on 2 SimVars.

Anyway, thank you for your answer.
 

Link to post
Share on other sites
8 hours ago, Pliskin said:

Regarding the Local SimVar, I understand that FSUIPC7 has no way to access them. And in fact, Microsoft SimConnect SDK does not provide a way to do this.
The only workaround for now is to create a fake gauge and put the local SimVar in the Client Data Area. Then FSUIPC7 would be able to
read/write the Local SimVar through the SimConnect SDK.

On the last Dev update, they mention enabling a facility called standalone wasm module, I suppose to make this more straightforward. Are you saying it is possible to make a generic control that can "proxy" between local variables and events and the SimConnect world?

Link to post
Share on other sites
13 hours ago, Pliskin said:

The issue regarding the AP Altitude on A320 is here

Ok. That has been reported to Asobo.

13 hours ago, Pliskin said:

In fact, the A320 FCU altitude 7-segment display is mapped to [AUTOPILOT ALTITUDE LOCK VAR:3] and not to [AUTOPILOT ALTITUDE LOCK VAR]

Ok. I can add  [AUTOPILOT ALTITUDE LOCK VAR:3] if required. What about  [AUTOPILOT ALTITUDE LOCK VAR:2] ?

13 hours ago, Pliskin said:

Is it not too "dirty" to add "official" offsets just for this plane ? I mean, this is not a bug from FSUIPC. The issue is on the A320 by design (and I think there is a legit reason for Asobo to have implemented things like this).

Its not an issue to add new offsets which can then be used for specific aircraft. However, I can't change the behavior of existing offsets if they are still functioning for other aircraft.

13 hours ago, Pliskin said:

Perhaps a better solution would be to add new functions to the lua API in order to allow it to query SimVar by their name directly.
Or better, perhaps FSUIPC could give us the possibilitity to publish our own custom offset by providing the name of the SimVar (and mandatory parameters).
The case of the battery push button requires a macro, because it depends on 2 SimVars.

I don't like the idea of allowing any simvar to be requested via lua - it would be very problematic. Its far clearer to identify any needed simvar and add it to the offset area.

16 hours ago, Pliskin said:

Regarding the Local SimVar, I understand that FSUIPC7 has no way to access them. And in fact, Microsoft SimConnect SDK does not provide a way to do this.
The only workaround for now is to create a fake gauge and put the local SimVar in the Client Data Area. Then FSUIPC7 would be able to
read/write the Local SimVar through the SimConnect SDK.

The long term plan is to provided access to lvars via an internal WASM module, and have an inter-process communication mechanism between the WASM module and the FSUIPC7 application. Whether this i done via a SimConnect client data area or using standard windows communication protocols is still to be decided, and depends on what facilities are provided on the WASM side.  This is one of the larger development areas still to be addressed.

John

 

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.