Nose high GSX pushback by others on VATSIM/vPilot

[Copper]

Copper, here is a build of vPilot that has this latest workaround idea implemented:

https://vpilot.rosscarlson.dev/Assets/Files/Installers/vPilot-Setup-3.7.0.1.exe

Please give it a go and let us know the results.

May I ask which variables you're now forcing to 0 if the freeze is active? Just out of curiosity

We did two tries both with the lifting kind of pushback, both looked great (while remote user still had the current release version of vPilot running). Thanks again Goose for helping on the tests!
The second one I recorded. When lifting the remote view shows the aircraft going up very briefly but then settles with a slight nose up attitude which I think is perfectly fine.
The pushback is slightly stuttery (maybe due to lack of velocity data) but it could also be the remote connection with all the video streaming etc.

I can't test with all the different pushback tugs etc, but I guess the critical behavior is the same for all of them.

Also Goose spotted this, has a fair bit of comedy in such a video

[Rick Maclure]

Let's focus on the solution instead...

Firstly, may I say I am delighted to see, at long last, some meaningful dialogue on this long-running issue. I have long campaigned for this issue to be addressed.

@rcarlson Sincere thanks to you for positively engaging in the analysis of the issue.

@virtuali You now have people engaged in helping you find a solution. In their efforts, they are supporting you and your product. I am glad you now recognise and welcome that support.

@Copper Where did you come from??? I thank you for the amount of time you have put into analysing the issue and professionaly publishing the results of a potential solution. You have, quite literally, graphically demonstrated what GSX Pro should look like in a multiplayer environment.

I look forward to the implememtation of the outlined solution.

Best regards

[Copper]

@Copper Where did you come from??? I thank you for the amount of time you have put into analysing the issue and professionaly publishing the results of a potential solution.

I didn't analyse much, just replicated what Umberto and rcarlson discussed since the very obvious issue is that Umberto isn't using vPilot/Vatsim and rcarlson isn't using GSX (or MSFS in general) - so they need assistance to verify that their theory on cause and fix actually is true.

Whenever we buy (or use) addons we can't expect the devs to make sure they work with any other addon as long as it isn't explicitly part of the product description.
Let's hope the fix doesn't have any side effect and that it indeed fixes all the cases of this issue.

Also if I understood correctly it's up to Asobo to properly fix this issue since whichever tool reads the faulty data generated by MSFS will continue to have issues with GSX pushback (or with basically any other addon that might want to use the "freeze" SDK feature that is).

[rcarlson]

May I ask which variables you're now forcing to 0 if the freeze is active? Just out of curiosity

If IS LATITUDE LONGITUDE FREEZE ON returns true, then these vars are zeroed:

VELOCITY WORLD X
VELOCITY WORLD Z

If IS ALTITUDE FREEZE ON returns true, then this var is zeroed:

VELOCITY WORLD Y

If IS ATTITUDE FREEZE ON returns true, then these vars are zeroed:

ROTATION VELOCITY BODY X
ROTATION VELOCITY BODY Y
ROTATION VELOCITY BODY Z

We did two tries both with the lifting kind of pushback, both looked great (while remote user still had the current release version of vPilot running). Thanks again Goose for helping on the tests!
The second one I recorded. When lifting the remote view shows the aircraft going up very briefly but then settles with a slight nose up attitude which I think is perfectly fine.
The pushback is slightly stuttery (maybe due to lack of velocity data) but it could also be the remote connection with all the video streaming etc.

The stuttering during push is likely due to the fact that the lat/lon are changing, but the velocities are zero, so vPilot is continually auto-correcting the mismatched lat/lon, 5 times per second, and that shows up as the stuttery movement. Not much we can do about that, other than trying to calculate realistic velocities for lat/lon, on the sending side. Seems like more trouble than it's worth.

I'd like to figure out why the aircraft raises up and then settles down. My best guess is that for some reason the PLANE ALTITUDE var is briefly reading a too-high value, then it goes back to normal. Would you be able to record a video showing that var? Also showing the three freeze vars, and the VELOCITY WORLD Y var, since that's the altitude velocity.

And thanks very much for taking the time to make the videos ... very helpful.

[Copper]

I'd like to figure out why the aircraft raises up and then settles down. My best guess is that for some reason the PLANE ALTITUDE var is briefly reading a too-high value, then it goes back to normal. Would you be able to record a video showing that var? Also showing the three freeze vars, and the VELOCITY WORLD Y var, since that's the altitude velocity.

We did not see this plane jump on the first try, only on the second one.
I did not record the first try entirely but the lifting was in there too and there was no jump:

And here's a recording of the requested simvars (I added altitude over ground). I tried this two times, in both cases I do not see the altitude change at all, but it of course could be a matter of a polling interval (it seems like AxisAndOhs polls in 1Hz or 2Hz I think). I have no way to record higher frequency on my side.
Could there be some sort of race condition that a velocity that is set to 0 manages to "leak" through before it's reset? Not sure.

Not in the video, the altitude vars do change during the pushback movement (probably due to ground elevation changes), but that's not an issue for vPilot I think since it happens gradually.

But since the weird attitude and lifting (before the fix) only happen during the tug connection, having that brief "glitch" is certainly acceptable.

[rcarlson]

Could there be some sort of race condition that a velocity that is set to 0 manages to "leak" through before it's reset? Not sure.

I don't think so, because the altitude is frozen from the very beginning of the procedure, so vPilot will be sending zero for the altitude velocity the whole time.

I suspect it's the actual altitude itself that is jumping. It could also be a glitch in the ground clamping algorithm that vPilot uses to keep aircraft on the ground when the sending side has different scenery and terrain elevation data. That algorithm involves continually sampling the terrain height below the aircraft, and using the reported AGL altitude to render the aircraft at the right altitude. Maybe there's a glitch in that code caused by bad terrain elevation data or something like that.

I suppose it's not worth worrying about, especially if it only happens intermittently. I'd say we can put this one to bed for now. This workaround will be in the public release of vPilot scheduled for March 1st. I'll let the devs of the other SimConnect pilot clients (of which there is currently only one, Swift) know so they can implement this workaround as well if they want.

Thanks for all the help!

[Copper]

I suspect it's the actual altitude itself that is jumping. It could also be a glitch in the ground clamping algorithm that vPilot uses to keep aircraft on the ground when the sending side has different scenery and terrain elevation data. That algorithm involves continually sampling the terrain height below the aircraft, and using the reported AGL altitude to render the aircraft at the right altitude. Maybe there's a glitch in that code caused by bad terrain elevation data or something like that

Could totally be it, yes.
I now, as suggested by a Community member Chaoz, tried using SimVarWatcher with highest frequency but there is no change to the PLANE ALTITUDE nor the above ground whatsoever either.

I just noticed that on my today's videos I had a typo in the simvar "IS LATITUDE LONGITUDE FREEZE ON" which shows as 0 all the time in my video (I added one bracket too many) but in fact, GSX also set this simvar to 1 as soon as the tug starts being connected with the other two FREEZE variables.
Just in case you happen to rewatch it and get confused by this difference.

Anyhow, yeah I think with the limited options to debug everything it's probably as good as it gets for now and to be honest more than good enough from those few tests I was able to do. It's hard to repeat them since you always need someone else's time to see what actually shows up on the other side.

For completeness sake:

[Copper]

And as a last datapoint, thanks to Ashley we could test the fix with xPilot on the remote side too, all good. Smooth, no jumping, accurate representation of position and attitude on the remote side

[Rick Maclure]

This workaround will be in the public release of vPilot scheduled for March 1st. I'll let the devs of the other SimConnect pilot clients (of which there is currently only one, Swift) know so they can implement this workaround as well if they want.

@rcarlson I cannot wait for March the 1st when these crazy pushbacks are no more! I would like to thank both yourself Ross and Copper for this diligent analysis, and resolution, of the issue.