GSX adds ice (!) to the 777 and 737

[Fiorentoni]

Now that might sound hilarious - but it's not a joke.

Context: MSFS 2024, in the 777 and 737 FMC -> Payload menu, there's a field call "icing". It shows the current "icing" value of the aircraft in percent.
I've noticed that very often after the pre flight departure I end up having an icing value in there between 15 and 30% - and that is with outside temperatures of e.g. 25 degrees Celsius.

I've started looking for a reason and also contacted the PMDG support. Now I think I have finally found out - it seems like this is caused by GSX doing inputs on the FMC (or directly on the aircraft variables, not sure).

To reproduce:
Prepare a flight normally, then request boarding via GSX. Now GSX starts navigating and entering something into the FMC pages (payload), and since I don't want that (already distributed all weights as I want it), I quickly change the page back in the FMC to where I want it (usually the ground services overview page). The same happens when I request departure / pushback.
Now it's either the request boarding or the request pushback that causes an icing value to appear afterwards on the payload page. So it seems like the inputs GSX does into the FMC/aircraft do add icing accidentally when I touch the FMC in the meantime. (Theory: it's the boarding request, because the icing percentage 15-30% correlates with typical passenger numbers on the 737 and 777).

Another important info: The actual things GSX tries to do (entering payload, or even fuel before that when requesting a fuel truck) does NOT work at all. Nothing changes on the fuel page or the payload page, even when I leave it alone. So I think PMDG changed / disabled the "API", because they don't want GSX to mess with their FMC.

What I want from GSX: Disable the complete FMC-intervention stuff in the PMDG aircraft, or at least give a setting to disable it.

I attached a log of a flight where it did add about 10-15% of icing (can't remember the exact value anymore) after I requested boarding.

[virtuali]

Prepare a flight normally, then request boarding via GSX. Now GSX starts navigating and entering something into the FMC pages (payload), and since I don't want that (already distributed all weights as I want it), I quickly change the page back in the FMC to where I want it (usually the ground services overview page).

Well, that's what really caused it. The commands sent to the FMC can't be stopped like that: they use a queue, so we are sure they are executed in the same order as they were inserted, but if you change the page ( no matter of quickly ), the queued commands will still execute, but on the wrong page.

It IS already possible to selectively disable various automation features, as explained in the manual at Page 117, the chapter named "Enabling or Disabling GSX own Automation", but it requires access to any utility/script that allows you set LVars (Mobiflight, Spad Next, AxesAndOhs, FSUIPC.), because we added this feature so that airplane developers can disable parts of GSX own automation to replace them with their own.

[Fiorentoni]

Thanks, yes I've read this in the manual and I think I will set it with mobiflight as I already use that for my MCP.

[Fiorentoni]

Quick follow up question regarding those:

"New LVars added to help 3rd party integration: FSDT_GSX_LOADER_EXIT_0, FSDT_GSX_LOADER_EXIT_1, FSDT_GSX_LOADER_EXIT_2. These LVars will be set to 1 if there's a GSX loader at Cargo1, Cargo2 and MainCargo doors. "

I'd like to disable the door automation for the 737F and 77F, but only for the main cargo door - I want to open that door myself (it's quite immersive doing this at the panel). How would I go about setting those in a mobiflight profile? Is the FSDT_GSX_LOAD_EXIT_2 always the one for the main cargo door? And do I have to set it to 0 or to 1 to DISable the door management by GSX?

[virtuali]

"New LVars added to help 3rd party integration: FSDT_GSX_LOADER_EXIT_0, FSDT_GSX_LOADER_EXIT_1, FSDT_GSX_LOADER_EXIT_2. These LVars will be set to 1 if there's a GSX loader at Cargo1, Cargo2 and MainCargo doors. "

Pay attention to the start of the Developers chapter ( Page 86 ):

If a variable is shown on a table with a RED background, it’s supposed to be readonly, if it’s on a GREEN background, it’s a variable add-ons can write to control GSX. Please don’t write values to read-only variables, because it will surely confuse GSX.

These variables are in red, meaning they can be used to read something GSX is doing, opposite to the ones about disabling the automation, which are green, so you are supposed to write to them and control some GSX behavior.

It's not possible to selectively disable door automation for *some* doors. It's either all of them or nothing.

[Fiorentoni]

So it turns out, GSX does add ice even with the payload and fuel interaction and ground service LVARs disabled. (By the way the groundservice LVAR is still active, even if set to 0; it will still try to do ground service stuff in the FMC, so that LVAR doesn't even work correctly in the first place).  In addition I did not touch the FMC 2 at all. Still I got 16% icing added to the aircraft the moment I "request boarding" with GSX.

[Fiorentoni]

Additional info: The icing gets written directly into the aircraft variable, not via the MSFS icing variable. MSFS structural icing still shows 0. It's therefore also not fixable by using engine-anti ice or turning icing off in MSFS.

So as this is clearly caused by GSX (it does not happen when GSX is disabled) and there's no way to prevent it, not even using LVARs, I hereby request to remove *all* write operations into the PMDG aircraft's variables.

[virtuali]

Additional info: The icing gets written directly into the aircraft variable, not via the MSFS icing variable. MSFS structural icing still shows 0. It's therefore also not fixable by using engine-anti ice or turning icing off in MSFS.

What is the "aircraft variable", opposed to the "MSFS icing variable" ? Note that, GSX doesn't write on ANY icing variable. That is, even if it tried (it doesn't), it won't work, since the default MSFS icing variable is not writable in the first place.

So as this is clearly caused by GSX (it does not happen when GSX is disabled) and there's no way to prevent it, not even using LVARs, I hereby request to remove *all* write operations into the PMDG aircraft's variables.

Of course is not "clearly" caused by GSX. The airplane code might write to it because it's reacting to something done by GSX. GSX DOES NOT write into ANY PMDG variables. GSX only sends EVENTS using the PMDG SDK, which the airplane code will then use to do something we have no control over.

And, there's a known bug in the PMDG SDK, which I reported to PMDG as soon some users found it, that when sending the PMDG SDK custom event to open one of the cargo door, the equipment door opens instead. This has been acknowledged by PMDG and they said it will be fixed with an update.

I have no idea if maybe opening the equipment door resulted in ice formation, but you can be sure GSX is NOT writing into any PMDG variable or any variable related to icing in general.

[Fiorentoni]

I don't know the aircraft internal variable, but I can say that the MSFS structural icing LVAR remains at 0, even though the icing value in the FMC is 20% or so. This means the "icing" has not been effectuated via the MSFS icing, in other words, the icing is not caused by "icing" (which explains why this also happens at 25 degrees OAT).

Could it be that the event or offsets changed between the MSFS 2020 and MSFS 2024 versions of the PMDG aircraft (because that only happens on MSFS 2024) and GSX is now accidentally accessing something else in the aircraft? It must be some event being used during "request boarding", because 1 or 2 minutes after I click on request boarding, I always have an icing value in there. Since during boarding most doors are opened, your theory could indeed be true that one of the door event codes changed and now an unusual door gets opened which creates a knock on effect internally that leads to the icing value changing.

I will ask them, but at the moment it's a bit difficult regards GSX at PMDG's...

Can you list the PMDG SDK events GSX is using during "request boarding"?

[virtuali]

I don't know the aircraft internal variable, but I can say that the MSFS structural icing LVAR remains at 0, even though the icing value in the FMC is 20% or so. This means the "icing" has not been effectuated via the MSFS icing, in other words, the icing is not caused by "icing" (which explains why this also happens at 25 degrees OAT).

There's no such thing as MSFS LVars, the only variables defined by MSFS are A: variables, and L: Variables are defined by add-ons. The only ones related to icing in MSFS are A: variables and as I've said, they are read-only. GSX will never try to write to them but, even if it tried doing that  (it doesn't), it won't cause anything other than a Simconnect exception, because those variables are not writable.

Could it be that the event or offsets changed between the MSFS 2020 and MSFS 2024 versions of the PMDG aircraft (because that only happens on MSFS 2024) and GSX is now accidentally accessing something else in the aircraft?

GSX uses the event codes as defined by the PMDG SDK. As I've said, at least one of them has an error, but I have no idea if there might be others.

Can you list the PMDG SDK events GSX is using during "request boarding"?

At the time boarding is requested, it will use events related to doors and, if it's required to send away the PMDG own vehicles, event related to FMC buttons. During the boarding process, further events will be sent to the FMC to set the Payload from Simbrief.

And, GSX is ONLY sending EVENTS, never writes to any to airplane-owned LVars, it only reads them, and if the relevant GSX LVars to disable the door/payload/fuel automation are set to 1, is not even sending any Events.

[Fiorentoni]

Alright thank you, I will see what PMDG responds.

[FlyingScaresMe]

I have had this issue as well. I can confirm GSX was the issue for me. I completely uninstalled everything and their associated files related to anything flight simulator. I then did a vanilla install of MSFS 2024, and PMDG 777 only, I disable icing effects in the sim as well to be safe and I have not had any issues. However, I then proceeded to install GSX and low and behold, the icing in the FMS Payload Summary page came back. It most certainly is GSX. I have had this issue occur in the sim when I was getting ready in a warm and sunny Dubai and it behaved as if I was in Anchorage in the dead of winter. Just like the original poster, I have also went and reference the long GSX manual and set LVars values to 0 for the PMDG aircraft just to limit as much as I could between GSX and the PMDG 777 and that still did not solve the issue.

I am curious whether or not this is something FSDT and PMDG can closely collaborate more on in the future for updates to make the end user experience seamless and not require any manipulation on the users part? From the perspective of the consumer, I pay for a product I expect to work upon install, I shouldn't have to "code" anything. Call it consumer ignorance but it has been frustrating and as a result I can't reliably fly any PMDG aircraft with accuracy due to this weight and balance anomaly with GSX adding icing to PMDG aircraft. I have tried matching my real world takeoff data on a 777 and the PMDG 777 won't come anywhere close to the performance I expect due to this icing anomaly.

I have even opened a support ticket with PMDG and ran through their troubleshooting tasks and it didn't solve the issue. I am at a dead end and can only hope FSDT and PMDG can potentially collaborate more closely for future updates.

As of this writing to simulate real world procedures without any adverse affects I no longer use GSX for this reason and I advise others to do the same unfortunately.

[virtuali]

It most certainly is GSX.

If you read my previous explanation, you would understand why this is not "most certainly GSX", which has no access to anything related to icing.

[FlyingScaresMe]

Any idea then because the various tests with PMDG support and reinstalls say otherwise. A little bit of accountability of your own product would be much appreciated along with a type of solution rather than a remark like that to a customer... I'm curious if you will be working closely with PMDG to figure out why this anomaly occurs.

[virtuali]

A little bit of accountability of your own product would be much appreciated along with

Why you said "Your product" ? Have you even read my explanation ?

There was a confirmed BUG in at least one of the PMDG SDK Event codes we are using, which PMDG has confirmed to be a problem that must be fixed on their side, since we cannot have any control over ice formation in any airplane, let alone the PMDG.

As I've said already, I don't know if the wrong door (equipement instead of cargo) being opened when calling the correct event from PMDG SDK resulted in a side effect that causes icing formation, that's something only PMDG can possibly know. I can only repeat and confirm:

- we call the correct events as documented in the PMDG SDK, and they confirmed to me at least one (the one I found) was wrong in their SDK

- we DO NOT write to ANY icing variable. Not custom LVars (we never write to *any* custom LVars on *any* airplane), and neither the standard MSFS icing variable, which cannot be written to, since it's read-only.