Nose high GSX pushback by others on VATSIM/vPilot

[Rick Maclure]

@HeicoH,

I appreciate your contribution in sharing your test results - thank you. Can I ask if you tested pushbacks using tow-bars and tugs? I recall there was a suggestion that the towbar (which didn't lift the nose) did not give rise to the issue? If the type of tug was outside of your scope, then it would be good to have that tested.


The key insight from your findings is the persistent nose-high pushback behaviour identified in MSFS Multiplayer. This discovery holds particular significance given that vPilot, IVAO's Altitude client, and MSFS Multiplayer all rely on the SimConnect architecture.

But it can ONLY be fixed from vPilot, is this now clear to you ?

In light of your results, I suggest that Umberto's assertion - that the only remedy lies in vPilot recognising a GSX Pro user - appears misguided. In fact, his statement that vPilot would need to handle a GSX client differently from everyone else only underlines that something exceptional is happening when GSX maneouvres the aircraft. Umberto has already confirmed that GSX uses bespoke coding to 'freeze' the aircraft until the pushback is completed.

- It's not vPilot "fault"

- It's not GSX "fault

I agree with Umberto in that the use of pejorative terms such as 'fault' and 'blame' are not helpful. However, I think there is a growing likelihood that GSX Pro is the cause of this pushback issue. Yes, we all understand that GSX is unaware of the existence of any network (MSFS Multiplayer, VATSIM, IVAO etc.) but GSX is solely responsible for positioning the aircraft throughout the manoeuvre. And the position and attitude of that aircraft is picked up by network clients through SimConnect.

Each network client interrogates SimConnect to establish, amongst many other attributes, the aircraft's heading, roll, pitch and elevation. From my own observations, it is interesting to note that GSX Pro accurately positions the aircraft in terms of heading and roll throughout pushback. It is primarily pitch which is the issue (although there are come examples where elevation has been problematic and the aircraft appears to hover with a nose down/up attitude).

So, could it be a bug in SimConnect? It is possible, although it must be considered that an aircraft manipulated by PMDG's inbuilt pushback or Toolbar Pushback etc., will also be communicated through SimConnect to the network. So given that several other pushback methods are correctly depicted across  the network through SimConnect and those managed by GSX Pro are not, does strongly suggest that the practice of 'freezing' the aircraft during a pushback is the issue and merits closer examination.

Without further investigation I do not know if Simconnect maintains state of the the aircraft position discretely from the core values in MSFS. It would certainly make sense as a form of abstraction layer. In other words, when the network client requests aircraft positional data, it is retrieved from a SimConnect state array rather than from the core values within MSFS itself. If GSX 'freezes' the aircraft during pushback does that imply, and this is pure speculation, that positional values are not passed, or not correctly passed, to SimConnect?


I strongly suspect that GSX was conceived with the single, non-networked, flight simmer in mind. And in that context, I'm sure GSX provides value to that user. However, with the growing popularity of networks such as VATSIM, a GSX pushback is now very much in scope. I note that @Captain Kevin has responded and I would ask him, as a beta tester, if he is at liberty to outline the scope of network testing undertaken in the development of GSX Pro.

I wish to emphasis that this is not an assault on Umberto or FSDT. If you ask yourself what is the most valuable attribute that a flight sim must offer, I am sure the word 'immersion' would be prevalent. Poor frame rates, stutters, scenery glitches, AI traffic seemingly intent on disabling your aircraft all fall into that category. A GSX Pro pushback is simply another example to add to that list. I think I can safely say we are all keen to resolve this issue. On a personal note, I am more than happy to offer any assistance.

Respectfully,

[virtuali]

The key insight from your findings is the persistent nose-high pushback behaviour identified in MSFS Multiplayer. This discovery holds particular significance given that vPilot, IVAO's Altitude client, and MSFS Multiplayer all rely on the SimConnect architecture.

Which confirms precisely what I'm suspecting: it might be a Simconnect bug! We are setting some variables that obviously work locally, but when another Simconnect CLIENT reads them, to replicate the remote airplane position, it doesn't receive the SAME values we set.

In light of your results, I suggest that Umberto's assertion - that the only remedy lies in vPilot recognising a GSX Pro user - appears misguided. In fact, his statement that vPilot would need to handle a GSX client differently from everyone else only underlines that something exceptional is happening when GSX maneouvres the aircraft. Umberto has already confirmed that GSX uses bespoke coding to 'freeze' the aircraft until the pushback is completed.

If the real issue lies in Simconnect itself, which changes some variables when they are transmitted, taking this approach from vPilot would be the only reasonable solution.

Since GSX Pushback is completely custom, the airplane must be frozen during pushback, otherwise the airplane's own physic would "fight" against GSX custom pushback calculations, since they would both controlling the airplane inertia at the same time, and this will cause jittering so, we surely cannot disable freezing but, this can be used by vPilot as a "signal" GSX is pushing, so it might act on the variables it receives differently, to WORK AROUND the issue.

What would be the alternative? This is the one thing we might do on our side, and it would still require changes to vPilot anyway:

- Detect if vPilot is connected, this will add lots of potentially buggy code to do this, since we would need to know if it's connected to something, requiring some communication with it, which means both coordination and changes to BOTH sides with testing, just to be sure the communication with vPilot works.

- Disabled freezing entirely if vPilot is used. Assuming this will fix the issue, which is not a given, it would mean all vPilot users would experience exactly what you labeled a detrimental to "immersion": that is stuttering/jittering, and that's JUST to prevent their airplane to be seen in the wrong attitude by OTHER users on the network.

Do you really think this would be best solution, compared to:

- Have vPilot checking those few *standard* Simconect variables to KNOW the airplane is frozen, meaning GSX must be pushing, and interpret the airplane attitude differently.

This second solution is clearly much better, because it involves 100% standard coding, it can be done entirely within vPilot with no need to agree on some special communication protocol, it doesn't require changes on both sides and, most importantly, it won't condemn users to suffer jittering locally, just to have their attitude correctly transmitted over the network!

[HeicoH]

As I understand it, the main reason for the way GSX handles pushback ("freezing") is to avoid stuttering.

But this doesn't seem to work:

http://www.fsdreamteam.com/forum/index.php/topic,30676.msg197409.html#msg197409

[virtuali]

As I understand it, the main reason for the way GSX handles pushback ("freezing") is to avoid stuttering. But this doesn't seem to work:

http://www.fsdreamteam.com/forum/inde

Because that thread doesn't have ANYTHING to do with the jittering that is prevented by freezing the airplane. The problem reported in the thread is NOT about jitters due to GSX Pushback competing against the default flight/ground model to control the airplane DURING PUSHBACK.

According to the users that are reporting it, it affects every GSX vehicle, and not just during Pushback, but always, so it's clearly something like Simconnect or the simulator itself being affected by too many add-ons using it. And as you can see, I posted a video showing it doesn't normally happen.

The jitter that is prevented by freezing the airplane it's a completely different matter, if would affect JUST the user airplane (not the other vehicles) and would happen only during Pushback so no, you are confusing two completely unrelated matters.

[TorbenJA]

Apparently this issue is related to the push back method GSX Pro is using ("freezing"). Other pushback tools doesn't seem to use this method, e.g. UGCX, as only GSX Pro sets variable that makes things go wrong. I have no idea how e.g. UGCX's pushback engine differs from GSX's, but asking vPilot developers to change their code, when it apparently is the setting of Simconnect variables from GSX, that makes things go wrong, is, well, wrong. Perhaps it would be more prudent if the developers of GSX found another way of making a pushback engine, that like UGCX doesn't make thing screw up.

[Rhett]

Hi Umberto. I'm delighted to hear that you have made contact with Mr Ross Carlson and are looking to resolve this troublesome issue. VATSIM (using the vPilot client) is one of the best, if not the ultimate, flight simulation immersion contributors and I long to see this issue resolved. I've just landed at Gatwick and found several aircraft with their noses ditched into the ground and tails in the air while pushing back. I have attached the screenshot as I am not sure how to embed it into the message.

[virtuali]

asking vPilot developers to change their code, when it apparently is the setting of Simconnect variables from GSX, that makes things go wrong, is, well, wrong.

Asking to change the whole Pushback method in GSX, which is clearly more flexible than all the others and has a background of thousands of user profiles made with it (and changing the "pushback engine" will result in throwing away all of them) when it clearly works perfectly fine when used locally, and the problems happens only when using vPilot, is wrong.

I think it's likely some variables are not translated correctly by Simconnect, possibly because a Simconnect bug or an undocumented change but AGAIN, since we don't control the transmission, there's just nothing we can do on our side if they WORK locally.

Instead, since vPilot is receiving them and it can verify GSX is pushing, it can fix this in a way simpler way we could ever do, which would, as you correctly guessed, require to change the pushback engine completely, not only losing features, but making all the existing custom pushback useless.

[TorbenJA]

the problems happens only when using vPilot

This statement troubles me, as HeicoH has test results indicating that the weird behaviour during pushback also is found, when vPilot is not being used. So even having Carlson change the code of vPilot, will not "save" the GSX pushback. Only change in your code OR making Microsoft/Asobo change the apparently faulty Simconnect code into a code, which doesn't make the planes having strange pitch, can save the situation. Understandably you ask Carlson to change the code as Microsoft is not likely to chage the simconnect code, but that won't change the behavior when vPilot is not used.

[virtuali]

This statement troubles me, as HeicoH has test results indicating that the weird behaviour during pushback also is found, when vPilot is not being used.

The statement is correct in the context of what is being discussed here, that is Vatsim, meaning vPilot is required.

So even having Carlson change the code of vPilot, will not "save" the GSX pushback.

Yes, of course it can, and easier than we could ever do, without rewriting the whole pushback method. As I've said, several times by now, since vPilot is tasked to recreate the remote airplane and it's likely getting bad data from Simconnect when GSX is acting on the "bad" variables that for some reasons are being transmitted wrong even if they are correct locally, it would be enough detecting GSX pushing, and process the bad data in some way.

My suspicion is that it has something to do with units of measure transmitted or received incorrectly (again, by Simconnect itself during the transmission, it GSX used them incorrectly, it would show up locally as well and GSX has no control over transmission), so it might just be a matter of converting them.

[TorbenJA]

If HeicoH test results are correct, showing the weird behavior when Multiplayer - not VATSIM connection via vPilot - are being used, I fail to see how having Carlson changing the vPilot code can affect the weird behavior in Multiplayer. I take it, you haven't been able to reproduce the pitch problem using Multiplayer, so it would be nice to know, how exactly HeicoH tested and found these results and see, if you can reproduce them.

In case this is correct - will you change the gsx push back, or will we have to live with them?

[virtuali]

I fail to see how having Carlson changing the vPilot code can affect the weird behavior in Multiplayer.

That only means we might have it fixed in vPilot only.

[HeicoH]

@TorbenJA: ("it would be nice to know, how exactly HeicoH tested and found these results")

There is nothing easier than verifying that the phenomenon also occurs in multiplayer. You don't have to set up a scientific test series to do this. You look for an airport where you know that there is a lot going on at a certain time, for example because of a Vatsim event, and where you know that, for example, a certain streamer is encouraging not only Vatsim users, but also a lot of Multiplayer users, to fly together with them. (Torben, you'll know who I mean, I won't "out" them here). Now you don't log into Vatsim, but into Multiplayer and - voila - you can just watch it.

[HeicoH]

@Umberto: ("The statement is correct in the context of what is being discussed here, that is Vatsim, meaning vPilot is required.")

Do you suggest starting a new thread, for the same phenomenon in Multiplayer?

[virtuali]

Do you suggest starting a new thread, for the same phenomenon in Multiplayer?

What would be the point?

I did some tests and, from what I can see, it confirms my suspects the problem is somewhere in the sim, which I'll explain in a proper way now that I have more hard evidence.

Now, I understand my method of testing might be a bit complex for a normal user but, if you want to REALLY find the REAL underlying cause of things, you need to test properly, no matter how complex it might be.

Let's put vPilot out of the picture for the time being, because understanding what is really happening in Multiplayer is the key to really understanding this.

First, it's not entirely true it happens with standard Multiplayer; it happens ONLY when using a Towbarless Tug. When using a Towbar tug, with GSX, in Standard Multiplayer, there are no issues whatsoever.

This suggests there's something related to the airplane pitch variable, which is only set when using a Towbarless tug that raises the front gear,  which doesn't get transmitted properly.

To prove this, I'm not using GSX, I just setup up a multiplayer session between my PC and my Notebook, which I can do because I bought two copies of MSFS to make these kinds of tests, so I can see my airplane in Multiplayer sitting on a gate. I'll repeat it again: there's NO GSX involved now, the airplane is just sitting on a gate without doing anything. I'm using the default Asobo A320.

In this resting state, the airplane has a pitch of 0.65 degrees (so it's a slight pitch down attitude, because the sign is inverted), now I need something other than GSX to set any variables on the airplane, and that's the SimVarWatcher program from the SDK, which can be used to set variables on the user airplane and other objects too.

First test: let's just set the pitch to -2 degrees (nose up), by setting the "PLANE PITCH DEGREES" SimVar to -2.

The airplane, not being frozen, jumps up and then down immediately, because its attitude is not frozen. The visual effect in this case is simular both locally and on the other networked PC, however it not entirely identical: the networked airplane jumps a bit on the main gears as well, while the local plane kept the main gears on ground and only raised the front gear momentarily. This suggests the two airplane representations (local and networked) are not reacting in the same way, and this will be even more apparent in the next test.

Second test: let's freeze the airplane and set the pitch up to -2 again. Here things start to get interesting, because, while the local airplane is perfectly pitched up and doesn't move at all, the networked one jumps up 4-5 meters in the air, then it stays frozen, up in the air, with the requested pitch.

This means, these two tests proved that setting the airplane pitch variable locally, has a DIFFERENT effect on the local airplane compared to its remote representation in Multiplayer.

The difference between the two tests, where the frozen airplane stayed up in the air, are showing the same issue in different ways: the frozen status is only helping to see the effect more easily but, in BOTH cases, the real issue is that, setting the airplane pitch locally, for some reason affects the airplane ALTITUDE as well, since even when it's not frozen, it's doing a (smaller) jump on the main gears, but it's clear the whole airplane was raised, even if I never touched the altitude, just the pitch.

Could this be a bug?

Not necessarily, they might "just" use different physic handling, so I checked the kind of SimObject on the networked PC, which can be done using the SimObject Debug in DevMode and of course, it seems to become more clear what the issue might be: while the local airplane is clearly an airplane, with a full blown flight model that reacts in a certain way, it's networked representation is NOT an airplane. In the list of SimObjects it can be found under the "FAKESIM" Category, with a sub-category of "NPC!Netplane".

This explains the underlying problem: in multiplayer, the remote airplanes are not using the same flight model as the local airplane, likely for performances reasons, the remote airplanes use a simplified flight model, which reacts differently to the airplane pitch, perhaps is not fully capable to calculate where the main gears should be when the nose is pitched up by taking into account the complete contact points/compression simulation of the local airplane.

To verify the theory, I set another variable ("SIM DISABLED" to 1), to DISABLE the simulation completely on the local airplane and, guess what, this SOLVED the problem: now setting some pitch locally, will result in the networked airplane mimic the local airplane attitude entirely, no jumps up in the air, nothing, they are exactly the same because, apparently, the simulator transmits the "Disable" state as well so, the networked version will completely shut down its "dumb" flight model, and will just follow whatever attitude is set by the local airplane.

So, the solution from GSX would "just" be disabling the simulation during pushback? Well, no. That wouldn't work because, when the simulation is Disabled, you can't do anything on the airplane, it's completely dead so, for example, you wouldn't be able to start the engines during pushback and everything will be shut down, no rudders, no elevators, nothing.

So no, we can't Disable the simulation locally "just" to prevent our networked representation from using its reduced flight model, which goes bonkers when touching the pitch.

So, I tried this: what if we Disabled the simulation (during pushback with a raised airplane only) from the networked PC instead, so the networked representation would shut down its own flight model, without affecting the user doing the pushback? If this worked, it might be a very simple solution for vPilot as well. Remember, we can't access variables on other user's systems, that's why any fix can only come from the receiving side, not from GSX.

But this idea crashed into the hard reality of Simconnect limitations: when trying to set SIM DISABLED to 1 on the networked PC on the "FAKESIM" object that represents the local airplane of the other PC, I was greeted with the sad "DATA ERROR" error from Simconnect. This is a very well-known issue: the variables you are allowed to write depends on the SimObject type: the one with the most writable ones are standard Airplanes, the GroundVehicles have less, the SimpleObjects even less.

The error means the "FAKESIM" SimObject category used to represent networked airplanes in Multiplayer, doesn't allow to write to the "SIM DISABLED" variable, which is inconvenient, since it's usually possible on many non-Airplane object types, but not this one. And there's just nothing we can do about this, other than begging Asobo to make this change.

However, there might be a way out because, even if we might never be able to fix the Multiplayer mode when the airplane is raised, it's not sure that, when vPilot is used, the airplane models generated by vPilot have the same limitation of those "FAKESIM" that MSFS Standard Multiplier mode use. If vPilot generates proper AI airplanes, like an AI Injector, it should have the ability to Disable their simulator, at least while GSX is pushing, which can be recognized by checking the variables that control the freeze.

That is in theory, but I will surely suggest this approach to Ross Carlson, see what he thinks of this.

[TorbenJA]

Thank you, Umberto for this very interesting post. I hope, Asobo will fix this (unfortunately rather pessimistic on my part), or that Ross can edit the vPilot code to fix it for vPilot/VATSIM users. However, if neither can fix it, one has to ask oneself: What would you prefer: Seeing planes at strange pitch or limit the use of towbarless pushback.  Perhaps as simply as having a checkbox, which can be set, so the full gsx can be chosen, when flying offline and a limited gsx push, where you don't change the pitch for the push, when you're online. I know the immersion of having a push from a towbarless truck without being pitched up a lilttle, isn't as good as being pitched, but to my mind looking out of the cockpit window and seeing a bunch of planes at odd attitudes is even less immersive.

Could that be an idea for FSDT to follow?

But it could be even simpler - don't use a towbarless pushback truck, when flying online?



regards