Nose high GSX pushback by others on VATSIM/vPilot

[virtuali]

The Rotation velocity doesn't even change

That's not what I ever observed. I suggest sticking to the SimVarWatcher utility in the SDK to monitor variables, just to be sure we are not introducing issues caused by the monitoring app.

For example, it's also strange the PLANE ALTITUDE at Zurich would be 0 feet, since PLANE ALTITUDE is an absolute value above Sea Level. In fact, SDK SimVarWatcher correctly reports PLANE ALTITUDE to be 1395 feet at LSZH A07.

[rcarlson]

Here's a whole pushback with Rotation and World Velocities and Altitude shown:

The Rotation velocity doesn't even change, but the world velocity acts really weirdly, I can't particularly say what is happening. After pushback was done I let it sit for a while before pulling the parking brake to see what happens, the variables keep on going even though nothing is happening...

I could be wrong, but the reason you aren't seeing the rotation value change may be because you have the wrong units. It should be in radians per second, not feet per second.

No idea why the altitude velocity is rising whenever the nose is off the ground. Maybe the sim thinks the airplane is flying/climbing because the nose is off the ground? Doesn't make much sense, but it's hard to speculate about what's happening because these velocity vars are so obviously buggy when the plane is frozen.

This is new and unexpected and if it's really the case, this indicates we haven't fully understood the issue because, as I've said in one of my previous posts, I noticed the pitch velocity assumed the following values:

- If the airplane is completely at rest, it's 0

- While GSX raises the airplane, it's about 0.04 m/sec. This seems about right: the raising animation lasts about 10-12 seconds, which would translate into 40/45 cm, which sounds reasonable so, during this step, it should show the airplane in the correct attitude, with the wheel reaching about 40 cm above ground when the raising stops.

- After raising ended, but before pushback starts, the pitch velocity started to raise, from 0.04 to 0.25 and this is clearly wrong, because the airplane pitch variable is instead perfectly steady (the airplane attitude is still frozen), so the velocity should have been 0, but it's not and I expected this should have caused the airplane CONTINUING to raise, now with a faster rate.

GSX has already stopped raising the airplane now, but , because vPilot is now interpolating the pitch with a 5x larger velocity, it "looks" like the GSX raising is happening now, but in fact it has already ended (with the smaller and correct amount), and what you are seeing now is just the result of the increase in the pitch velocity that gets picked up by vPilot.

If I remember correctly, a positive pitch velocity means the nose is pitching down, not up. So those values fit our theory that the sim is trying to push the nose back to the ground (due to gravity) once GSX lifts it up.

This is resets ROTATION VELOCITY BODY X and VELOCITY WORLD Y to 0 for as long the plane is frozen, at every Visual Frame.
https://youtu.be/klzLQWC-6VM

You can see why I still consider this solution messy and an ugly hack because, even when setting the values at every frame, we are still struggling to keep the variables at bay, because the simulator is fighting us, the values are still jittering.

What if you zero out the velocity every sim frame, instead of every visual frame? I assume the velocity is being calculated every sim frame. Maybe that will make the override more effective?

[Copper]

I could be wrong, but the reason you aren't seeing the rotation value change may be because you have the wrong units. It should be in radians per second, not feet per second.

You are right, I took the default AaO gave me which is obviously wrong.
Disregard my video then.

[virtuali]

What if you zero out the velocity every sim frame, instead of every visual frame? I assume the velocity is being calculated every sim frame. Maybe that will make the override more effective?

Two reasons:

- Sim Frame is not a System Event you can subscribe to, like VisualFrame, it's a period interval when you need to read data so, while it might be useful when you need to read data anyway, it's not when you only need to write it, like in this case, because not only we would double the Simconnect traffic again with an extra packet we are not interested in reading, but we are adding more lag, because of the bi-directional communication: one call to receive the data, another one to write it, so it would likely be worse.

- It has been recently reported to have issues, in some cases the subscription seems to stop for quite a while, then it restarts so, before consider trying it, I want to be sure it's bug-free:

https://devsupport.flightsimulator.com/t/requestdataonsimobject-with-sim-frame-sometimes-stops-working/4357/2

Asobo seems to have flagged the bug.

[MrRoper]

I`m happy to help test this. if there is anyone else that can log into vatsim and monitor the push remotely?

[rcarlson]

What if you zero out the velocity every sim frame, instead of every visual frame? I assume the velocity is being calculated every sim frame. Maybe that will make the override more effective?

Two reasons:

- Sim Frame is not a System Event you can subscribe to, like VisualFrame, it's a period interval when you need to read data so, while it might be useful when you need to read data anyway, it's not when you only need to write it, like in this case, because not only we would double the Simconnect traffic again with an extra packet we are not interested in reading, but we are adding more lag, because of the bi-directional communication: one call to receive the data, another one to write it, so it would likely be worse.

- It has been recently reported to have issues, in some cases the subscription seems to stop for quite a while, then it restarts so, before consider trying it, I want to be sure it's bug-free:

https://devsupport.flightsimulator.com/t/requestdataonsimobject-with-sim-frame-sometimes-stops-working/4357/2

Asobo seems to have flagged the bug.

Ahh, okay, makes sense.

In that case, I don't think we should continue with this solution any further. Even if we can get it to "mostly" work on one system, it might not work as well on other systems where the visual frame rate is significantly lower than the sim rate. vPilot reads the velocity values 5 times per second, and if GSX is only overriding the velocity values every sim frame, there is a high likelihood that it will read a non-zero value if several sim frames have passed since the last visual frame. That likelihood increases as the visual frame rate decreases.

Instead, I have an idea that might work more reliably. At the same time that I read the six velocity values, I'll also read these vars:

Code: [Select]

IS LATITUDE LONGITUDE FREEZE ON
IS ALTITUDE FREEZE ON
IS ATTITUDE FREEZE ON

If any of those vars is set to true, then I'll ignore the associated velocity values and send zeroes to the network instead. This would essentially be "faking" the fix that we would ask Asobo to make, as far as other pilots on the network are concerned. This approach has the advantages of not adding any SimConnect message traffic, not fighting with the sim over the velocity values, and it works around the problem on the sending side, not the receiving side. The only disadvantages I can think of is that this change must be done in multiple places (any existing or future pilot client that supports FSX/P3D/MSFS) and it's a bit of a shotgun approach. The zeroing of the velocities will occur for any app that freezes the user's plane, not just GSX. I think that's probably okay, since it seems unlikely that any other app would be freezing the user's plane and trying to set realistic velocity values at the same time, due to the problems with that approach that we've encountered here.

If I do find that this approach causes problems with other apps, we could revisit this and make it happen only for GSX, using custom SimConnect client events that GSX would raise when it starts/stops the pushback procedure.

Thoughts?

[Copper]

Instead, I have an idea that might work more reliably. At the same time that I read the six velocity values, I'll also read these vars:

Code: [Select]

IS LATITUDE LONGITUDE FREEZE ON
IS ALTITUDE FREEZE ON
IS ATTITUDE FREEZE ON

If any of those vars is set to true, then I'll ignore the associated velocity values and send zeroes to the network instead. This would essentially be "faking" the fix that we would ask Asobo to make, as far as other pilots on the network are concerned. This approach has the advantages of not adding any SimConnect message traffic, not fighting with the sim over the velocity values, and it works around the problem on the sending side, not the receiving side. The only disadvantages I can think of is that this change must be done in multiple places (any existing or future pilot client that supports FSX/P3D/MSFS) and it's a bit of a shotgun approach. The zeroing of the velocities will occur for any app that freezes the user's plane, not just GSX. I think that's probably okay, since it seems unlikely that any other app would be freezing the user's plane and trying to set realistic velocity values at the same time, due to the problems with that approach that we've encountered here.

If I do find that this approach causes problems with other apps, we could revisit this and make it happen only for GSX, using custom SimConnect client events that GSX would raise when it starts/stops the pushback procedure.

Thoughts?

Sounds absolutely good and I think that's the cleanest approach we would have.

In the meantime I did the following test with the two relevant simvars AND the view of a Vatsim user (thanks, Goose!!!) in one:
- Pushback normally to verify that the issue persists in my setup (I stopped recording after the aircraft was lifted because there's no point for the full sequence)
- Pushback but with a script that on every frame sets the two simvars to 0:
-- A:VELOCITY WORLD Y
-- A:ROTATION VELOCITY BODY X

I let the results speak for themselves, one can see the simvars briefly jump back up and the motion on vatsim isn't 100% smooth but it's FAR better than without the fix.
The resetting of the variables I did with a Flow Pro script because it has a direct access to simvars and an easy way to set them every frame.
Note that the resetting needs to happen throughout the sequence including lifting/releasing by the tug, not just the push!
The test was with the release version of GSX, so no modifications of the scripts installed.

Hope that piece of information helps to at least get certainty that the cause of the issues are in fact these two simvars. The rest seems to be fine.

Default:

With resetting the two simvars:

[rcarlson]

Yeah, that does look much better, but it might look better or worse on different systems with different visual frame rates.

[Copper]

Yeah, that does look much better, but it might look better or worse on different systems with different visual frame rates.

I agree, so filtering the issue in vPilot when receiving the data from the sim based on the FREEZE variables is the best way to get them smooth.
But at least we know that these two variables are indeed what causes the issue.

Also I noticed that if the velocity is 0, the aircraft's position/orientation jumps back to the correct one, so even if the velocity is temporarily not 0 due to the frame/polling gap it fixes itself once it's at 0 again.
And one can even now see on vatsim that the nose is actually lifted because the pitch is no longer overridden by the velocity

If you have a beta version of vPilot to test with before rollout, I can offer trying it out.

[rcarlson]

Also I noticed that if the velocity is 0, the aircraft's position/orientation jumps back to the correct one, so even if the velocity is temporarily not 0 due to the frame/polling gap it fixes itself once it's at 0 again.

I think what you are seeing there is vPilot is correcting the position/orientation when it receives the actual values (not the velocities). vPilot is constantly applying it's own calculated "error correction velocities" to bring the predicted position/orientation (predicted from the velocities) back in line with the actual values received over the network.

[virtuali]

Instead, I have an idea that might work more reliably. At the same time that I read the six velocity values, I'll also read these vars:

Code: [Select]

IS LATITUDE LONGITUDE FREEZE ON
IS ALTITUDE FREEZE ON
IS ATTITUDE FREEZE ON

Thoughts?

But this was one of the first things I though, see my post in this thread, back in October:

https://www.fsdreamteam.com/forum/index.php/topic,30060.msg196743.html#msg196743

Yes, of course this happens when GSX is pushing, but "happening" doesn't mean "causing", considering it doesn't happen unless you use vPilot, that what it meant "vPilot would need to account for that", it means using the variables that signal the freeze, to KNOW GSX is pushing and do something about it.

That's because the normal documented LVariables GSX publish for developers to know GSX is pushing are not transmitted through Simconnect over a network, they are only valid for the user airplane (LVariable really means "Local"), so the only way to know when GSX is pushing is checking the freeze variables themselves, which should be transmitted via Simconnect, although I must say I never tested this.

I also suggested it to you, after you registered to this forum and entered in this thread:

https://www.fsdreamteam.com/forum/index.php/topic,30060.msg199117.html#msg199117

Basically, I think it should be enough if you just Disabled the simulation of all remote airplanes that have any of their "Freeze" variables set (indicating GSX is pushing).

But you replied, "There is no way for user B to know that user A's aircraft is frozen, since there is no support in the network protocol for that Boolean". There I suggested Disabling the simulation altogether, which is not really a good idea (we'd lost flaps/wheels turning and such) but, since you said there's no way to know if airplane has been frozen remotely, I just dropped it the whole concept.

Yes, of course disabling the prediction on frozen airplane would be PERFECT, if it works. No more extra Simconnect traffic, no fighting with the sim, no risk of having the variable being read precisely when it's not rewritten because of the out-of sync updates, and if any other product would ever need to freeze the airplane for some reason, it would already work.

[Copper]

But this was one of the first things I though, see my post in this thread, back in October

I think most of the messages you listed imply that handling the issue in vPilot on the *receiving* side of the network would be a solution (hence sending a GSX pushback status over the network as you suggested). That's far more complex and requires changes in multiple clients (xPilot, vPilot, Swift,...).

But the fact that zeroing specific variables on the *sending* side (on the side of the user of GSX where the Freezing can be detected) in vPilot is the clean approach and that's only possible after knowing which variables are causing that.
So referring to a "told ya" in October doesn't really matter.
Let's focus on the solution instead...

[rcarlson]

Copper is exactly correct. There's a big difference with what I'm suggesting. With this suggestion, the remote aircraft don't need to know that your aircraft is frozen. Nothing needs to be done on the remote (receiving) side at all. And no protocol changes. With this suggestion, the GSX user's vPilot will not send the bad velocity data to begin with.

[virtuali]

Copper is exactly correct. There's a big difference with what I'm suggesting. With this suggestion, the remote aircraft don't need to know that your aircraft is frozen. Nothing needs to be done on the remote (receiving) side at all. And no protocol changes. With this suggestion, the GSX user's vPilot will not send the bad velocity data to begin with.

Well, now you explained this way, it's clear. Doing it on the sending site is even better than on the receiving site. I'm not fully aware exactly how vPilot works, if it relies by the default Multiplayer and which variables are sent, or if it's in charge of the whole communication entirely on both sides. Now it's clearer.

[rcarlson]

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.