FSUIPC7/LUA and SimConnect indexed variable

[Pliskin]

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.

[John Dowson]

  On 11/19/2020 at 6:02 PM, Pliskin said:

regarding the SimConnect Indexed variables

Expand  

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.

  On 11/19/2020 at 6:02 PM, Pliskin said:

As example, I take the Asobo Airbus A320 .

Expand  

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.

  On 11/19/2020 at 6:02 PM, Pliskin said:

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

Expand  

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

  On 11/19/2020 at 6:02 PM, Pliskin said:

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

Expand  

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.

  On 11/19/2020 at 6:02 PM, 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.

Expand  

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

  On 11/19/2020 at 6:02 PM, 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 ?

Expand  

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.

  On 11/19/2020 at 6:02 PM, 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 :

Expand  

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

  On 11/19/2020 at 6:02 PM, 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)

Expand  

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.

 

[Pliskin]

Thank you for your answer.
 

  Quote

Reported here? Reference would be useful.

Expand  

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.

Expand  

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.
 

[Diego Vasquez]

  On 11/19/2020 at 6:02 PM, 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.

Expand  

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?

[John Dowson]

  On 11/19/2020 at 9:08 PM, Pliskin said:

The issue regarding the AP Altitude on A320 is here

Expand  

Ok. That has been reported to Asobo.

  On 11/19/2020 at 9:08 PM, 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]

Expand  

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

  On 11/19/2020 at 9:08 PM, 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).

Expand  

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.

  On 11/19/2020 at 9:08 PM, 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.

Expand  

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.

  On 11/19/2020 at 6:02 PM, 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.

Expand  

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

 

[Petrer]

Hello,

I try to set BUS LOOKUP INDEX to Value 10 but it does not want to set and stay with value 11.

I am doing something wrong ?

Thanks for the help.

[John Dowson]

  On 7/29/2021 at 10:31 AM, Petrer said:

I try to set BUS LOOKUP INDEX to Value 10 but it does not want to set and stay with value 11.

Expand  

BUS LOOKUP INDEX is read-only. This value changes when other controls are used, e.g. ELECTRICAL_BUS_TO_BUS_CONNECTION_TOGGLE.
I added this to see if it could be used to control the batteries in the A320 as described in this post:
   

However, it seems that these simvars are read-only
Presumably you are trying to control the batteries in the FBW A320, no? If so, you can try the calculator code specified in the MF spreadsheet for
    A32NX_OH_ELEC_BAT1_TOG
    10 6 (>K:2:ELECTRICAL_BUS_TO_BUS_CONNECTION_TOGGLE) 10 (>A:BUS LOOKUP INDEX, Number) (A:BUS CONNECTION ON:6, Bool) ! if{ 0 } els{ 1 } (>L:A32NX_OVHD_ELEC_BAT_10_PB_IS_AUTO) (L:XMLVAR_Momentary_PUSH_OVHD_ELEC_BAT1_Pressed) ! (>L:XMLVAR_Momentary_PUSH_OVHD_ELEC_BAT1_Pressed)

    A32NX_OH_ELEC_BAT2_TOG
    11 6 (>K:2:ELECTRICAL_BUS_TO_BUS_CONNECTION_TOGGLE) 11 (>A:BUS LOOKUP INDEX, Number) (A:BUS CONNECTION ON:6, Bool) ! if{ 0 } els{ 1 } (>L:A32NX_OVHD_ELEC_BAT_11_PB_IS_AUTO) (L:XMLVAR_Momentary_PUSH_OVHD_ELEC_BAT2_Pressed) ! (>L:XMLVAR_Momentary_PUSH_OVHD_ELEC_BAT2_Pressed)

(see https://docs.google.com/spreadsheets/d/1jTXlcHaJWx0B7TB63Pmma7bKwpxsxXJO6EJ3ECt7zpc/edit#gid=172455454)

My MSFS is updating at the moment (and still 30GB to go....) so can't test this, will check it later.

John

[Petrer]

Yes i try to interact the master battery 1 and 2 from the A320. I already update mine so i will try the calculator.

Thanks

[Petrer]

It's working fine. Thanks a lot

  On 7/29/2021 at 10:49 AM, John Dowson said:

BUS LOOKUP INDEX is read-only. This value changes when other controls are used, e.g. ELECTRICAL_BUS_TO_BUS_CONNECTION_TOGGLE.
I added this to see if it could be used to control the batteries in the A320 as described in this post:
   

However, it seems that these simvars are read-only
Presumably you are trying to control the batteries in the FBW A320, no? If so, you can try the calculator code specified in the MF spreadsheet for
    A32NX_OH_ELEC_BAT1_TOG
    10 6 (>K:2:ELECTRICAL_BUS_TO_BUS_CONNECTION_TOGGLE) 10 (>A:BUS LOOKUP INDEX, Number) (A:BUS CONNECTION ON:6, Bool) ! if{ 0 } els{ 1 } (>L:A32NX_OVHD_ELEC_BAT_10_PB_IS_AUTO) (L:XMLVAR_Momentary_PUSH_OVHD_ELEC_BAT1_Pressed) ! (>L:XMLVAR_Momentary_PUSH_OVHD_ELEC_BAT1_Pressed)

    A32NX_OH_ELEC_BAT2_TOG
    11 6 (>K:2:ELECTRICAL_BUS_TO_BUS_CONNECTION_TOGGLE) 11 (>A:BUS LOOKUP INDEX, Number) (A:BUS CONNECTION ON:6, Bool) ! if{ 0 } els{ 1 } (>L:A32NX_OVHD_ELEC_BAT_11_PB_IS_AUTO) (L:XMLVAR_Momentary_PUSH_OVHD_ELEC_BAT2_Pressed) ! (>L:XMLVAR_Momentary_PUSH_OVHD_ELEC_BAT2_Pressed)

(see https://docs.google.com/spreadsheets/d/1jTXlcHaJWx0B7TB63Pmma7bKwpxsxXJO6EJ3ECt7zpc/edit#gid=172455454)

My MSFS is updating at the moment (and still 30GB to go....) so can't test this, will check it later.

John

Expand