GSX Pushback LVAR

[LukeK]

The GSX documentation says that when pushing back, the LVAR FSDT_VAR_Frozen will be set to 1. I've tried a pushback in both P3Dv3 and P3Dv4, using an FSUIPC LUA macro that logs any changes to LVARs containing "FSDT". It doesn't look like it's being set in either P3Dv3 or P3Dv4.

Is this variable still supported? I'm using couatl build 4061.

Cheers!

Luke

[virtuali]

The variable is of course still fully supported, and it works correctly so, the only possible reason why you don't see it changing, is some kind of problem in configuring your monitoring system.

Of course, I checked before replying, and I can confirm the variable is set to 1 the moment the pushback guy says "start at will", and goes back to 0 when he says "set parking brakes" at the end of the pushback.

[LukeK]

The variable is of course still fully supported, and it works correctly so, the only possible reason why you don't see it changing, is some kind of problem in configuring your monitoring system. Of course, I checked before replying, and I can confirm the variable is set to 1 the moment the pushback guy says "start at will", and goes back to 0 when he says "set parking brakes" at the end of the pushback.

Thank you. I'll recheck again, but both FSUIPC and my own LVAR reading code (which works fine on other GSX LVARs) indicate nothing. I'll let you know what I find and post further logs.

Cheers!

Luke

[LukeK]

.... and so we can compare apples to apples, what are you using to determine the LVAR values and that they are being updated correctly?

Cheers!

Luke

[LukeK]

Here's the P3Dv3 log entry:

********* FSUIPC4, Version 4.974b (14th March 2018) by Pete Dowson *********
Windows 10 Enterprise 64 Bit reported as Build 17763, Release ID: 1809 (OS 10.0)
Prepar3D.exe version = 3.4.22.19868
Reading options from "D:\Program Files\Prepar3Dv3\Modules\fsuipc4.ini"
Running inside Prepar3D v3 on Windows 10
Module base=5E6D0000
FSUIPC4 Key is provided
WIDEFS7 not user registered, or expired
        0 System time = 16/03/2019 10:14:00
        0 FLT path = "C:\Users\Luke\Documents\Prepar3D v3 Files\"
        0 ------ Module Version Check ------
        0        acontain.dll: 3.4.22.19868
        0             api.dll: 3.4.22.19868
        0        controls.dll: 3.4.22.19868
        0      fs-traffic.dll: 3.4.22.19868
        0             G3D.dll: 3.4.22.19868
        0        language.dll: 3.4.22.19868
        0            sim1.dll: 3.4.22.19868
        0        visualfx.dll: 3.4.22.19868
        0         weather.dll: 3.4.22.19868
        0          window.dll: 3.4.22.19868
        0 ----------------------------------
        0 Trying D:\Program Files\Prepar3Dv3\Modules\SimConnectP3D3.dll
        0 Found it: trying to connect
        0 FS path = "D:\Program Files\Prepar3Dv3\"
       94 ---------------------- Joystick Device Scan -----------------------
       94 Product= CH PRO THROTTLE USB
       94    Manufacturer= CH PRODUCTS
       94    Vendor=068E, Product=00F1 (Version 0.0)
       94    GUIDs returned for product: VID_068E&PID_00F1:
       94       GUID= {8AE67BE0-FD72-11E8-8001-444553540000}
       94       Details: Btns=19, POVs=(0, 0, 0, 0), Cal=x00000000, Max=R0,U0,V0,X248,Y245,Z228
       94 Product= CH PRO PEDALS USB
       94    Manufacturer= CH PRODUCTS
       94    Vendor=068E, Product=00F2 (Version 0.0)
       94    GUIDs returned for product: VID_068E&PID_00F2:
       94       GUID= {8AE67BE0-FD72-11E8-8002-444553540000}
       94       Details: Btns=0, POVs=(0, 0, 0, 0), Cal=x00000000, Max=R0,U0,V0,X255,Y255,Z254
       94 Product= CH FLIGHT SIM YOKE USB
       94    Manufacturer= CH PRODUCTS
       94    Vendor=068E, Product=00FF (Version 0.0)
       94    GUIDs returned for product: VID_068E&PID_00FF:
       94       GUID= {D3D9B770-FD97-11E8-8001-444553540000}
       94       Details: Btns=12, POVs=(0, 0, 0, 0), Cal=x00000000, Max=R0,U255,V255,X255,Y255,Z255
       94 -------------------------------------------------------------------
      110 Device acquired for use:
      110    Joystick ID = 2 (Registry okay)
      110    2=CH PRO THROTTLE USB
      110    2.GUID={8AE67BE0-FD72-11E8-8001-444553540000}
      110 Device acquired for use:
      110    Joystick ID = 1 (Registry okay)
      110    1=CH PRO PEDALS USB
      110    1.GUID={8AE67BE0-FD72-11E8-8002-444553540000}
      110 Device acquired for use:
      110    Joystick ID = 0 (Registry okay)
      110    0=CH FLIGHT SIM YOKE USB
      110    0.GUID={D3D9B770-FD97-11E8-8001-444553540000}
      110 -------------------------------------------------------------------
      125 LogOptions=00000000 00000001
      125 -------------------------------------------------------------------
      125 ------ Setting the hooks and direct calls into the simulator ------
      125 --- CONTROLS timer memory location obtained ok
      125 --- SIM1 Frictions access gained
      125 --- FS Controls Table located ok
      125 --- Installed Mouse Macro hooks ok.
      125 --- Wind smoothing fix is installed
      125 --- SimConnect intercept for texts and menus option is off
      125 --- All links okay (except older global weather setting method)
      125 -------------------------------------------------------------------
      125 SimConnect_Open succeeded: waiting to check version okay
      125 Trying to use SimConnect Prepar3D
      125 Opened separate AI Traffic client okay
     4954 Running in "Lockheed Martin® Prepar3D® v3", Version: 3.4.22.19868 (SimConnect: 3.4.0.0)
     4954 Initialising SimConnect data requests now
     4954 FSUIPC Menu entry added
     4954 ... Using Prepar3D with Academic License
     4969 C:\Users\Luke\AppData\Local\Lockheed Martin\Prepar3D v3\Prepar3D_Default.fxml
     4969 D:\Program Files\Prepar3Dv3\SimObjects\Airplanes\IRIS Raptor Driver\Raptor.air
    33985 D:\Program Files\Prepar3Dv3\SimObjects\Airplanes\TFDi_Design_717\Aerodynamics.air
    55704 Aircraft loaded: running normally now ...
    55704 User Aircraft ID 2 supplied, now being used
    56672 System time = 16/03/2019 10:14:56, Simulator time = 10:14:05 (15:14Z)
    56688 Aircraft="TFDi Design 717 Delta Air Lines"
    59594 Starting everything now ...
    59625 ASN active function link set
    59625 Ready for ActiveSky WX radar with additional data
    63094 Advanced Weather Interface Enabled
    87891 Sim stopped: average frame rate for last 32 secs = 24.6 fps
    87891    Max AI traffic was 3 aircraft (Deleted 0)
    87891 Average weather filter write interval in that time = 16093.5 msecs

    97782 LUA.0: L:FSDT_GSX_NUMPASSENGERS=0
    97797 LUA.0: L:FSDT_GSX_DEBOARDING_STATE=1
    97797 LUA.0: L:FSDT_GSX_CATERING_STATE=1
    97797 LUA.0: L:FSDT_GSX_REFUELING_STATE=1
    97797 LUA.0: L:FSDT_GSX_BOARDING_STATE=1
    97797 LUA.0: L:FSDT_GSX_DEPARTURE_STATE=1
    97797 LUA.0: L:FSDT_GSX_OPERATEJETWAYS_STATE=1
    97797 LUA.0: L:FSDT_GSX_DEICING_STATE=0
    97797 LUA.0: L:FSDT_GSX_DEICING_TYPE=0
    97813 LUA.0: L:FSDT_VAR_EnginesStopped=1
    97813 LUA.0: L:FSDT_GSX_JETWAY_POWER=0
    97813 LUA.0: L:FSDT_GSX_BATTERY_VOLTAGE=0
    97813 LUA.0: L:FSDT_GSX_FUEL_PRICE=0
    97813 LUA.0: L:FSDT_GSX_JETWAY_AIR=0
   105641 LUA.0: L:FSDT_GSX_DEPARTURE_STATE=4
   105688 LUA.0: L:FSDT_GSX_DEBOARDING_STATE=3
   105735 LUA.0: L:FSDT_GSX_BOARDING_STATE=3
   105782 LUA.0: L:FSDT_GSX_CATERING_STATE=3
   105829 LUA.0: L:FSDT_GSX_REFUELING_STATE=3
   105907 LUA.0: L:FSDT_GSX_OPERATEJETWAYS_STATE=3
   106047 LUA.0: L:FSDT_GSX_JETWAY_POWER=2
   106094 LUA.0: L:FSDT_GSX_JETWAY_AIR=2
   112891 LUA.0: L:FSDT_GSX_DEPARTURE_STATE=5
   327704 Sim stopped: average frame rate for last 233 secs = 25.3 fps
   327704    Max AI traffic was 5 aircraft (Deleted 0)
   327704 Average weather filter write interval in that time = 25906.2 msecs

   328469 === Closing session: waiting for DLLStop to be called ...
   353532 === DLLStop called ...
   353532 === Closing external processes we started ...
   354532 === About to kill any Lua plug-ins still running ...
   354688 Lua threads being terminated:
   354688       0 = "D:\Program Files\Prepar3Dv3\Modules\FSDTLogLVars.lua"
   354860 LUA: "D:\Program Files\Prepar3Dv3\Modules\FSDTLogLVars.lua": killed
   354860 === Closing global Lua thread
   355860 === About to kill my timers ...
   356063 === Restoring window procs ...
   356063 === Unloading libraries ...
   356063 === stopping other threads ...
   356063 === ... Memory checking ...
   356063 === ... Button scanning ...
   356172 === ... Axis scanning ...
   356266 === Releasing joystick devices ...
   356266 === Freeing macro memory
   356266 === Removing any offset overrides
   356266 === Clearing any displays left
   356266 === Calling SimConnect_Close ...
   356875 === SimConnect_Close done!
   356875 === AI slots deleted!
   356875 === Freeing button memory ...
   356875 === Closing my Windows ...
   356875 === Freeing FS libraries ...
   357875 === Closing devices ...
   357875 === Closing the Log ... Bye Bye! ...
   357875 System time = 16/03/2019 10:19:57, Simulator time = 10:18:30 (15:18Z)
   357875 *** FSUIPC log file being closed
Minimum frame rate was 18.9 fps, Maximum was 37.1 fps
Minimum available memory recorded was 1238Mb
Average frame rate for running time of 265 secs = 25.2 fps
Average weather filter write interval in that time = 24122.1 msecs
Maximum AI traffic for session was 5 aircraft
Memory managed: 68 Allocs, 67 Freed
********* FSUIPC Log file closed ***********

Cheers!

Luke

[virtuali]

Here's the P3Dv3 log entry:

The log doesn't tell much, other than the program seemed unable to detect a change in that variable. However, I don't use FSUIPC, so I have no idea how you setup monitoring for variables, but I can only repeat and confirm the FSDT_VAR_Frozen is correctly set to 1 the moment the pushback guy says "start at will", and goes back to 0 when he says "set parking brakes" at the end of the pushback.

A common issue with reading L variables, which is explained on Page 59 of the manual, is they sometimes change their ID during a session, usually after switching the airplane so, if your code is storing the initial ID, it might no longer valid by the time you read the variable, so you must be sure the ID is current before using the variable.

[LukeK]

I can only repeat and confirm the FSDT_VAR_Frozen is correctly set to 1 the moment the pushback guy says "start at will", and goes back to 0 when he says "set parking brakes" at the end of the pushback.

What tool are you using to confirm this? I'd at least like to duplicate your results.

Given that log, are there any other LVARs that should be set that it's not reading, or just this specific one?

Cheers!

Luke

[LukeK]

I can only repeat and confirm the FSDT_VAR_Frozen is correctly set to 1 the moment the pushback guy says "start at will", and goes back to 0 when he says "set parking brakes" at the end of the pushback.

What tool are you using to confirm this? I'd at least like to duplicate your results.

Given that log, are there any other LVARs that should be set that it's not reading, or just this specific one?

Any update on what you are using to read the LVAR? It's odd that FSUIPC and my software can both read and write every other LVAR correctly....

Cheers!

Luke

[virtuali]

Any update on what you are using to read the LVAR? It's odd that FSUIPC and my software can both read and write every other LVAR correctly....

We use our own software, which is 100% confirmed to works correctly (if we had a bug in using LVariables, the whole GSX wouldn't work, since most animations are based on them) and, in addition to that, we even included a small sample of C++ code how to read/write LVars on the last page of the GSX manual, which suggests what's the most common pitfall when reading variables, which is the sometimes changing IDs between sessions or airplane change.

I can only confirm our code is always correct and it's not being fooled by changing IDs. Most of 3rd party airplane developers don't realize it, since as long as they care about their own airplane only and their own gauge code, it's unlikely they'll ever run into this issue, since it usually requires switching the airplane, so it's possible the tool you are using might have the same problem, but we knew about this for years, and it couldn't be otherwise, since GSX is running across a session were multiple airplane and gauge might have been loaded/unloaded from memory.

[LukeK]

We use our own software, which is 100% confirmed to works correctly (if we had a bug in using LVariables, the whole GSX wouldn't work, since most animations are based on them)

I'm not suggesting your code doesn't work in general, I'm suggesting that specific LVAR isn't being set.

it's possible the tool you are using might have the same problem, but we knew about this for years, and it couldn't be otherwise, since GSX is running across a session were multiple airplane and gauge might have been loaded/unloaded from memory.

I'm using FSUIPC, so I've asked Pete Dowson for support and hopefully we can track this down. Pete is quite responsive and is quick to fix things if he determines a flaw in his code, and since you are the same I'm confident it will get resolved quickly.

Luke

[virtuali]

I'm not suggesting your code doesn't work in general, I'm suggesting that specific LVAR isn't being set.

And why you are doing that, after I already said I TESTED IT, and indicated precisely the moment it goes to 1 and to 0 ?

I'm using FSUIPC, so I've asked Pete Dowson for support and hopefully we can track this down. Pete is quite responsive and is quick to fix things if he determines a flaw in his code, and since you are the same I'm confident it will get resolved quickly.

I'm sure if FSUIPC need a fix, it will be fixed.

Note that, I have TWO ways of testing the variable, one by reading the value using the get_named_variable_value() from the gauge API, and another one using the XML expression evaluator ( execute_calculator_code ) so, we are only passing an XML STRING to the sim, which will evaluate the LVar on its own. This is similar as making an XML gauge.

Both methods confirm the FSDT_VAR_Frozen is correctly set to 1 and 0 when I said it should, using this expression:

(L:FSDT_VAR_Frozen, number)

Defaults to 0, returns 1 when the pushback starts and 0 when it stops.

[Eisbahn]

I can confirm that (L:FSDT_VAR_Frozen, number) works flawlessly. I have written my own gauge to initiate cabin announcements.
I use this LVAR (among others from GSX) to trigger certain events and have never experienced any problems. However, I use XML code and not Lua (FSUIPC).
Eisbahn

[LukeK]

And why you are doing that, after I already said I TESTED IT, and indicated precisely the moment it goes to 1 and to 0 ?

Umberto, I don't mean to be rude - but when you say you tested using your tools that means I cannot duplicate your results (and therefore narrow down what is wrong with my method) and to be frank I deal with many developers who are convinced they don't have a problem. From time to time I am one of them.

Note that, I have TWO ways of testing the variable, one by reading the value using the get_named_variable_value() from the gauge API, and another one using the XML expression evaluator ( execute_calculator_code ) so, we are only passing an XML STRING to the sim, which will evaluate the LVar on its own. This is similar as making an XML gauge.

Both methods confirm the FSDT_VAR_Frozen is correctly set to 1 and 0 when I said it should, using this expression:

(L:FSDT_VAR_Frozen, number)

Defaults to 0, returns 1 when the pushback starts and 0 when it stops.

Thank you. I appreciate it. I'll go track down what's not happening correctly on the FSUIPC side.

Cheers!

Luke

[Pete Dowson]

Didn't you come back and report to me that it seems not to actually exist until the pushback has been requested, or something along those lines? So simply logging changes to it won't work. You'd need to keep polling it by name and ignoring the nil ("non-existent") responses, until you get a proper response.

The assignable FSUIPC control to list L:Vars just lists those extant at that time.

The Lua plug-in I think you are using ("log lvars.lua") only polls for the ones it knows about.  When it first runs it scans for L:Vars with IDs from 0 to 65535 building the array of names to keep watching. However, it stops doing that when it reaches the last valid ID in that scan. It does this for efficiency and with most add-ons this is quite sufficient.

In this case, though, you would want it to repeat the complete scan, or at least continue from where it failed to retrieve a name before. I can help you modify the Lua code to do this, but please come to the FSUIPC Support Forum for this.

Pete

[c912039]

Ive experienced similar issues that Pete was referring to in his last update.

I use a hardware interface utility called GIT. Whenever a new aircraft is selected in P3Dv4, it scans for any advertised LVARs.
Ive written some code in GIT to interact with GSX LVARs, but more often than not, these LVARs have not been detected by GIT after an aircraft load/initialize.

The way GIT works is that, if it cant detect an LVAR that is referenced in the user configured code, it disables and removes the user code, so not to cause errors.  Obviously, this causes a loss of my code, and is a GIT specific problem.

However, it does seem to be triggered by the fact that GSX LVARs dont seem to have been initialized/advertised when GIT does its one and only scan after the aircraft is flyable after loading.

Regards
David