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.