Products Support > GSX Support FSX/P3D

GSX turning 77W into 77F cockpit **SOLVED**

<< < (6/10) > >>

hammertime:

--- Quote from: virtuali on September 09, 2021, 11:14:15 pm ---...conflict with L: variables IDs...
--- End quote ---

Is there any way of telling what L: variables are being sent and when? - I have FSUIPC (paid), but I'm a bit of a rookie when it comes to stuff like this. Would this log/output what you need to confirm suspicions?


--- Quote from: virtuali on September 09, 2021, 11:14:15 pm ---Does it happen if you configure the airplane in GSX to use Belt Loaders instead of Cargo loaders ?

--- End quote ---

Interestingly it doesn't appear to happen if you use Belt Loaders


--- Quote from: virtuali on September 09, 2021, 11:14:15 pm ---- Load the airplane and WAIT until the countdown ends and the airplane is ready to fly.

- Choose "Restart Couatl" from the menu and start loading cargo.

--- End quote ---

It still happens if the Cargo doors are set to AKE/Pallets unfortunately

virtuali:

--- Quote from: hammertime on September 09, 2021, 11:52:55 pm ---Is there any way of telling what L: variables are being sent and when? - I have FSUIPC (paid), but I'm a bit of a rookie when it comes to stuff like this. Would this log/output what you need to confirm suspicions?
--- End quote ---

The issue is, this would be very difficult to troubleshoot with normal tools, because they always handle variables by name and you can be 100% we DO NOT use their name, the only variables we write to, are our own variables, which all starts with something like FSDT_xxxxxxx.

As I tried to explain, L: variables are never handled by their names, at least not when using the fastest and more native C++ methods ( you use their names in XML gauges instead ).  When C++ program tries to use a variable, it first should ASK the sim if the variable is available and if it is, call a function to register that variable in the sim, which will return with a numeric ID, which is just a number.  From that moment on, the name is not used anymore, to read or write to an L: variable, you give only the ID and the value.

When an airplane is unloaded from memory ( because you switched to another airplane ), all IDs used by L: variables created by that airplane are ( or should ) considered available again for other running modules to register. Since an airplane reload triggers a GSX complete restart, a conflict between IDs used by the airplane and those used by GSX should never happen, especially considering you are reporting something happening only when the cargo loaders start loading pallets, not during a GSX restart that happens while the airplane might still loading.

That was the reason for asking to *wait* for the airplane to finish loading and then restart GSX, but it didn't seem to make any difference, so it's not something that happens during a restart.

If the problem is really a conflict of variable IDs ( which again, should have been noticed years ago, and not just with a single airplane model ), and I don't see what else could be, perhaps some new undiscovered bug in the sim which is giving to us an ID that is already used by the airplane, it would be very difficult to troubleshoot with normal tools, which usually refers to variables by their names, unless you know of a tool which logs every possible ID continuously, to monitor of every change, so we might trace what's happening.

I guess that, if you try to troubleshoot this with a LUA script in FSUIPC, it might give you a misleading result of GSX trying to write to BOTH its own variable and the PMDG variable at the same time, when in fact what is *really* doing is writing only to its variable, because it trusted the sim the ID it was given back when it registered the variable was free to use.

Qantas747:
Hi Umberto,

I tried only with AKE containers and the issue still persists. I posted on the PMDG forums, and they said it themselves that GSX is causing the change.

EDIT: I did also try as you suggested, waiting for the aircraft to fully load and restart couatl and it still persists

virtuali:

--- Quote from: Qantas747 on September 10, 2021, 01:02:18 am ---I posted on the PMDG forums, and they said it themselves that GSX is causing the change.
--- End quote ---

I was quite sure that would said that but, the issue is, GSX is NOT writing to the variable they use to control the VC visibilities. GSX only writes to its own variables, that's for sure, and I never heard of that particular variable before. Not that it makes any difference since, the only time we need to know of custom L: variables is to READ them ( never write! ) to check the door status.

What I'm not fully understand is ( only them can know that ), where, exactly, their visibility variable is set and what's used for. As far as I understand, the same VC can switch between two variations of the plane depending on that variable but, who's setting the correct value and when ?

Is the airplane gauges when the airplane loads or some kind of support module ? Is the variable being set using the C++ gauge interface ? It is set using the PDK ? It is set by name using the execute_calculator_code ? Is it set through an XML code ?

Each one of these methods can have different results and, for example, not checking if the ID of a variable has changed or its available before registering it ( which GSX surely does, for the precise reason to prevent such conflicts ), would result in the ID originally assigned to your variable being taken by somebody else, because you assumed your ID would never changes.

But of course, even a bug in the sim could possibly cause this. Are you all testing with P3D 5 ? Do you have V4 as well ? Is this happening there too ?

And of course, saying "GSX is causing this" doesn't even begin to explain why it seems to happen only to a single variation of a single model, and it never happened before with any other plane, regardless who made it.

I GSX was really causing this, you should see all sort of crazy things happening when you start loading pallets, because every complex 3rd party airplane can use dozen or even hundreds of these so, if GSX randomly wrote other's L: variables assuming they are its own ( this would be a result of an ID conflict ), it should happen everywhere, any custom animation on any airplane could be potentially screwed up by GSX and this should have been noticed years ago, since GSX always used the same L: variables for animations in years, especially the cargo loaders, that hasn't been updated in a long while.

Qantas747:
I'm on V4.5 HF3 and VHEBM is on P3D V5.2 latest HF

Navigation

[0] Message Index

[#] Next page

[*] Previous page