FSDreamTeam forum
Products Support => GSX Support FSX/P3D => Topic started by: LukeK on March 16, 2019, 03:05:12 pm
-
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
-
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.
-
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
-
.... 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
-
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
-
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.
-
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
-
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
-
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.
-
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
-
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.
-
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
-
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
-
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
-
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
-
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. :)
Since you surely must have read the previous message from Eisbahn, who confirmed the GSX Pushback variable works flawlessly, if you really don't believe me, at least believe your fellow user...
I'm not sure what else I could say, if you have tools that might have issues detecting what works correctly in the SIM itself ( if it weren't, the execute_calculator_code command would never work ), and I don't know what else should we do, other than posting a sample of a C++ snippet of code that surely works, and it's made in a way to prevent precisely the likely issue you are experiencing.
And yes, developers convinced they don't have a problem are very well known to me, since more than one contacted me about GSX variables that supposedly didn't work, only to realize they didn't follow the advice of always checking for the variable IDs before reading them, as explained in the GSX manual so, once they fixed this in their code, it started to work, with no changes required by GSX.
-
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.
That's explains why that tool won't work with GSX: it assumes an L: variable must be something related or created only by an aircraft, so it connects its scanning routine to the airplane loaded event. This means it won't work if the variable is created at a different time, which is the case of GSX variables, that might be created at any time, usually when they are needed.
While we could probably create the variable when GSX starts, it still won't be a foolproof solution, because it might not be always certain if the airplane or GSX would start first, since GSX starts in parallel with the sim under an entirely separate thread and process ( the Couatl interpreter ) and, there are additional timing issues, because it's not even Couatl or the GSX python code that *actually* declare the variable, since this cannot be done by an out-of-process ( = .EXE ) program, but only by an in-process .DLL, which can be a gauge or a .dll module. In GSX's case, it's the Addon Manager .DLL that *actually* creates the L: variable, following a communication request from Couatl that is running the GSX code.
In addition to that, Couatl automatically restarts itself when the airplane is switched, and that takes a couple of seconds so, even if we just re-created the L: variable at each restart, an utility that scans for all used L: variables by IDs, should do it each time after the airplane has loaded, but should ALSO wait for GSX to finish its startup, which would make it needlessly complex.
So, the only way a tool that checks L: variables would work with every product that creates L: variables which is not necessarily an airplane gauge, or might simply be an airplane gauge that initialize its L: variables *later*, not during startup, would be this tool could allow to check L: variables at any time, or allowing to monitor variables that are supposed to be used in the near future, if you already know their names in advance.
I have no idea why that that GIT tool consider an "error" a variable that doesn't exists. The way the simulator works, an L: variable is created by the first one registering, then everybody else has access to it so, if the code is done correctly and it always checks variables before using them, it's surely possible to monitor a variable *before* its created, because in that case, the monitor utility becomes the creator, and while I cannot speak for others, GSX won't be confused by a monitor utility that has created a GSX own L: variable before GSX (as long it doesn't WRITE anything to it!!), only for the purpose of monitoring it. When GSX will try to create the variable itself, when the Pushback starts in this case, it will see the variable already exists, and will just use it.