Disconnecting problem

[IanHarr]

I have a problem with the interaction between the pushback vehicle and my PMDG 747.
All appears to go well, right up to the wing walker waving "have a good trip".
I disengage the brakes but the aircraft will not move.
If I reload the plane, it cures the problem.
Having read the manual, I see there is a notification that is read by the plane telling it that the tow tug has disconnected.
It also says that resetting couatl will reset the code from1 to 0.
Is there any way for a user, with no programming skills to set this manually, as I suspect that the code is not being received correctly by the 747.?

I am asking here as I know that a programmer who knows what is going on, will answer.(Umberto) whereas I am not so sure about P3D forum.

[virtuali]

GSX sends two commands to the airplane when disconnecting the truck:

- A standard "unfreeze" command, resetting the standard variable that freezes the flight model to its default value. Every airplane should respond to that automatically with no extra coding from the airplane developer, but it's possible some 3rd party airplanes with a custom flight model might not react to it automatically. Never heard this would happen on the PMDG 747 though.

- An additional custom L: variable documented in the GSX manual, which airplane developers can also check, so they might do something to react to the tow truck disconnection, and this was made to help airplane developers to do additional things that might not be standard which should be done when a pushback is connected, for example temporarily disabling any custom simulation of hydraulics that might prevent turning the front gear ( a sort of "virtual bypass pin" ). However, this requires extra coding by the airplane developer, since we cannot obviously know which kind of system might require attention during pushback, and several developers have used it successfully, like FS Labs, Aerosoft and Leonardo SH, however PMDG never done that, but of course all the information they need is fully documented in the GSX manual, should they decide to do so.

[IanHarr]

Thanks for your reply. It seems to me that FSDT and PMDG are not talking nicely to each other
I requested an answer from them, having posted the same query and got a reply telling me that they can do nothing and it is FSDT's job to fix it.
I then sent them your very clear explanation and got this:

"As I wrote nothing we can do from our side. None of us have GSX on our systems due to issues that their license tool is using with our products. "

Very disappointing when the one major developer gives a clear unambiguous answer and the other says in effect "get lost".
So this problem looks as if it will never be solved.

[virtuali]

I'm afraid PMDG is just trying to offer you some kind of explanation of their policy, but unfortunately that doesn't have any technical merit.

I'll tell you exactly why they are saying our "license tool" is causing issue using their products, something that every PMDG *users* knows very well it's not the case, since everybody happily uses our software together with PMDG products for years.

When P3D4 initially came out, after a while it was found there's a bug in the sim in some undocumented features carried over from FSX, that resulted in a crash when flying over remote areas, like Northern Canada or Siberia if an add-on tried to call one of these features, to obtain a list of nearby airports. GSX required this, in order to present users with a list of nearby airports, so they could pre-select a gate before landing, which is a feature many asked for.

This call was made by the Addon Manager but, what really caused the crash was the FACILITIES.DLL, it wasn't "our code" that crashed, it was the sim itself that crashed, and only when flying over remote areas. PMDG IS full aware the crash happened in FACILITIES.DLL, because I've got a couple of emails from users at that time, which quoted a reply they got from PMDG, showing they knew where the crash *really* happened.

So yes, in a way, we could say GSX indirectly caused that crash, because with the help of the Addon Manager ( and yes, calling the Addon Manager a "licensing tool" is a neat trick to make it automatically hated by users ), it called this function, exactly in the same way it could have if it used, let's say, FSUIPC, the sim would have crashed just the same, because the thing that really crashed wasn't our "licensing tool", was the relevant function of the sim in FACILITIES.DLL, which seems to have trouble being called when there's nothing in the area.

Of course, as soon we could find what the problem really was, we disable every query of that function when you are flying over 10k feet and/or faster than 250k, which was the only way to still have the gate pre-select feature for nearby airports, considered you don't usually need it when cruising over remote areas.

This, to give you some background about the "licensing tool" issue I believe they are referring to.


The problem is, all of this ( both the crash AND the resolution ) happened LONG AFTER PMDG already decided not do anything to recognize GSX so they could do something in their code to temporarily stop their custom simulations while GSX is pushing, or refueling.

PMDG promised us long before P3D4 came out they would have a look at it, "as soon the 747 for P3D completed" so, when they did, I got in contact with them explaining what to do, and offering some suggestions to make even a better integration, like adding proper support for GSX refueling so that it could integrate better with the custom progressive refueling of the PMDG, etc.

The reply I've got was along the lines we cannot possibly know how different systems might be involved on their side, how potentially dangerous is GSX interfering with their simulation, like touching the fuel quantities, and they know better, and I should keep my suggestions for myself.

This seemed to indicate some kind of misunderstanding of the whole point of integrating GSX:

- It's precisely because GSX doesn't try to touch any of the airplane system that we ask for airplane developers to do something on their own!

- It's precisely because we know how many issues there might be if we *tried* to affect the airplane systems directly that we don't do that.

- It's precisely because we know nobody better than the original airplane developer can possibly know what can be affected, that we asked them doing what only them can possibly know, to be sure pushing back or refueling with GSX won't do any harm to the plane.

PMDG was completely unaware, for example, that GSX always flagged all their products has having a custom fuel system and a custom electrical system, so it won't ever try to change fuel quantities or recharge the batteries, which are the only things GSX does on a default airplane ( or a 3rd party that use standard systems ) that affects the status of the simulation. We don't even try to open doors automatically...

I tried to explain all of this, but never got any further reply, complete radio silence.

THEN, after all of this happened, P3D4 came out, and the FACILITIES.DLL incident happened, and it took a bit longer than it should have to find what really was, and we fixed it by circumventing the issue ( we couldn't really "fix it", since it wasn't our code that was crashing, it was the sim, so we could only stop calling it when it wasn't required ). We fixed this years ago but, I guess PMDG got a good excuse to continue to ignore GSX integration, which of is only hurting their customers, because:

- FS Labs customers enjoy an incredibly deep integration with GSX, which increase the value of both products

- Leonardo SH customers and Aerosoft ( both the Airbus and the CRJ supports GSX ) customers also enjoy GSX integration.

So, it's not that we can't work together with other developers, even those making the highest-end possible airplanes which, I'm afraid to say, are starting to get better and better with GSX's help.

An interesting twist might come in the future, consider the following two projects:

- The A32NX from FlyByWire

- The Working-title CJ4

Those are one of the most promising projects for MSFS, which MIGHT end up to be really "study level", maybe in a year or so. And they are OPEN SOURCE, which means we could do any required GSX integration OURSELVES, and just contribute with it so it can be part of the airplane or, at least, have a look at the code and do things on our end we know are safe to do.

So yes, times are changing and, regardless what's going to be the best airplane out there, you can be sure GSX will be there too...