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

[virtuali]

Well if it doesn't have anything to do with GSX, why does it occur after I've recently updated your program??? It was working fine and now its not

Nothing in the latest update changed anything in the handling of L: variables.

Sticking your head in the sand and saying no issues here, nothing needs to be fixed is really not the solution here

And what kind of comment is that ?

Nobody is "sticking the head" anywhere and you should really stop making this kind of comments, because they are offensive and not related in ANY way to my reply.

NOWHERE I said for sure there's nothing to be fixed in GSX, YOU are the one that is being drawing conclusions without getting all the facts first. You couldn't possibly know if GSX tried to write that variable, I can but, nowhere I said nothing can or should be fixed in GSX because, again, before being "clearly" sure of something, I need to check facts first.

Fact it never happened before, doesn't mean it could never happen because, it also depends on what the airplane own code does to be sure those variables IDs are still valid when they are used.

I already explained GSX does when registering a new variable for it own use, but it doesn't continuously before trying to write to it, because this might cause stuttering during the animations, and this always worked so far, because ID usually change only when the airplane is reloaded.

Has been the PMDG 777 recently updated ?

Maybe, we just got lucky there weren't any conflicts before because, if the issue is really a conflict of IDs ( that's the only thing I can think of, because WE DON'T USE THAT VARIABLE BY NAME!! ), it might have happened before as well, but perhaps a change in the number of custom L: variables in the airplane would expose a conflict that was always possible.

[Qantas747]

The 777 has NOT been recently updated. My guess the last update came out 4-5 months ago.

[Captain Kevin]

Has been the PMDG 777 recently updated ?

Last update was March 19th, 2021.

[virtuali]

Is this happening only with the ER version, or even the base LR version ?

[B777Capt]

I have the same issue. I have just tried three different scenarios including the base product as well as the extension both -200ER and -300ER. The issue has only persisted on the -300ER version of the aircraft.

[virtuali]

The issue has only persisted on the -300ER version of the aircraft.

Is the -300ER version the only one that has a VC that can "morph" between two versions ?

I'm asking because, the 777 is the only PMDG product I don't own in P3D, I bought the FSX version, but decided to pass on the P3D version, because it didn't feel having to purchase it again without even a small discount ( I guess we are the only fools that allowed users that bought GSX in 2012, to use still use it with the same license in P3D V5 and PBR, 9 years later ) so, if I need to buy the 777 just to check this problem, I wanted to know if it also happens with the Base product, or only with Expansion.

[B777Capt]

Indeed that seems to be the case. I have restarted the simulator for each scenario and only the -300ER version experiences the VC "morth" only in the overhead for the air conditioning and fire protection systems. I havent experianced any issues with the other versions, everything seems to run smoothly.

[Qantas747]

Hi Umberto,

It only happens with the 300ER. I tried with the 77L and 77F and they work perfectly

[hammertime]

I have the -300ER in v5, just tested, and yep sure enough as soon as the pallets start getting loaded into the plane the overhead and door changes, exactly as in the video.

Very strange!

[virtuali]

I have the -300ER in v5, just tested, and yep sure enough as soon as the pallets start getting loaded into the plane the overhead and door changes, exactly as in the video.

Yes, it's strange and, the only explanation I have, is a conflict with L: variables IDs, since I'm 100% sure there's nothing in the GSX code that ever tries to write on another airplane own L: variables.

Which is strange, since if this could happen, it should have happened years ago, with many other airplanes too, since lots of them use L: variables for everything that is not a standard animation, and PMDG sure always used many of them, so it's strange this is only happening now, with only a single variation of a model.

Does it happen if you configure the airplane in GSX to use Belt Loaders instead of Cargo loaders ?

Also, try this:

- 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.

[hammertime]

...conflict with L: variables IDs...

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?

Does it happen if you configure the airplane in GSX to use Belt Loaders instead of Cargo loaders ?

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

- 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.

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

[virtuali]

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?

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]

I posted on the PMDG forums, and they said it themselves that GSX is causing the change.

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