Nose high GSX pushback by others on VATSIM/vPilot

[HeicoH]

Of course, it would be easier if the vPilot developer adapted their code - easier for the GSX Pro developers because then they wouldn't have to deal with this problem. Again: no other tool other than GSX Pro causes any problems in combination with vPilot. From the user's perspective, and from the perspective of the vPilot developer, it is therefore absolutely understandable if the solution is expected from the GSX Pro developers.

[rcarlson]

Hi all, vPilot developer here ... I have read through this thread and I'm going to help figure out what's going on and what can be done about it.

as I already confirmed in a previous post, we have been in contact with vPilot author, and he's aware of the issue, so I would expect a vPilot update should eventually arrive.

Umberto, I'm embarrassed to say that I cannot find this previous correspondence. I'm struggling to remember where it happened ... was it via email, or discord somewhere, or maybe in the VATSIM or MSFS forums? Can you refresh my memory so that I can go back and review the discussion and see where we left off? I don't want to ask you a bunch of questions that you likely already answered when we discussed this issue previously. As I'm sure you can relate, I have a lot of conversations with other flight sim devs and I can't retain them all in memory as the months go by. 

Once I've had a chance to review our previous discussion, I'll see if I can figure out some options for fixing or working around the issue.

-Ross

[Rick Maclure]

Hi all, vPilot developer here ... I have read through this thread and I'm going to help figure out what's going on and what can be done about it.

Ross! Delighted to read this.  GSX Pro pushbacks are simply destoying immersion in the VATSIM network.

I hope you can assist Umberto in finding a resolution. I've found that if a non-lifting towbar is used, then the nose/tail high animations are not present. Perhaps Umberto can change his software to detect the vPilot client is running and force a non-lifting pushback?

Its now 2024 and we are seeing even more of this https://i.imgur.com/H25uc4m.jpg

[virtuali]

Once I've had a chance to review our previous discussion, I'll see if I can figure out some options for fixing or working around the issue.

I emailed you last November, and we had several email exchanges. I checked your email and it's the same as the one you used to register to this forum so, I'll resend the last emails again, with all my latest findings.

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).

[rcarlson]

Thanks Umberto. I don't have those emails anymore, so forgive me if I repeat myself here.

vPilot uses the following variables to read the pitch/bank/heading of the user's aircraft, and the rate of change of those three attitude variables:

Code: [Select]

PLANE PITCH DEGREES
PLANE HEADING DEGREES TRUE
PLANE BANK DEGREES
ROTATION VELOCITY BODY X
ROTATION VELOCITY BODY Y
ROTATION VELOCITY BODY Z
These values are sent over the network (5 times per second) and other user's vPilot uses the velocities every frame to predict the current rotation and then rotates the model that they are using to represent your aircraft accordingly. It also uses the actual reported pitch/bank/heading to error-correct the predicted rotation, so that the prediction doesn't get too far off from reality due to error accumulation.

An earlier post in this thread said that the aircraft is still reporting a non-zero pitch velocity during pushback. If that's the case, that would explain why the pitch is wrong when viewed from another user's perspective (no matter which pilot client they are using, vPilot, xPilot, or swift ... they all use the same technique.)

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).

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. Also, I already freeze the location, altitude, and attitude of all remote aircraft and I manually set their lat/lon/alt/pitch/bank/heading every frame. I can't disable the simulation because then engines wouldn't turn, flaps wouldn't extend/retract smoothly and at the right speed, same with landing gear, and other control surfaces.

Sounds like we need to focus on fixing the invalid pitch velocity being sent. According to the docs, that is a settable var, so maybe you could just zero it out continuously during pushback? (Other than when the pitch is actually changing, of course, during lifting and lowering of the nose.)

Lastly, early in this thread, you said that the pitch variables are handled differently in MSFS as compared to P3D and FSX. Can you elaborate on that? I haven't seen any differences. Indeed, vPilot works fine on all three sims with no special handling of pitch for MSFS.

[virtuali]

An earlier post in this thread said that the aircraft is still reporting a non-zero pitch velocity during pushback. If that's the case, that would explain why the pitch is wrong when viewed from another user's perspective (no matter which pilot client they are using, vPilot, xPilot, or swift ... they all use the same technique.)

Fine, but non-zero doesn't mean much, it would be best to make a proper test, to see exactly what is being transmitted, which is clearly not the same of what GSX is setting locally, otherwise we should have the wrong nose-up altitude on the user airplane, wouldn't we?

So, for example, when GSX sets the plane to be 1 degree pitch up, what are you receiving from the network instead?

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. Also, I already freeze the location, altitude, and attitude of all remote aircraft and I manually set their lat/lon/alt/pitch/bank/heading every frame. I can't disable the simulation because then engines wouldn't turn, flaps wouldn't extend/retract smoothly and at the right speed, same with landing gear, and other control surfaces.

All right, if you can't know if the remote plane is frozen, disabling the simulation no matter what wouldn't work, my suggestion assumed you would do that only during the time the airplane is pushed and raised, so it would be a minor distraction not seeing moving surfaces or engines running, at least compared to what they see now.

Sounds like we need to focus on fixing the invalid pitch velocity being sent. According to the docs, which is a settable var, so maybe you could just zero it out continuously during pushback? (Other than when the pitch is actually changing, of course, during lifting and lowering of the nose.)

No, I can't do that because, a pushback with a raised pitch must keep that pitch during all the pushback, if I set it to 0 when the airplane starts to move, it would jump back to level just as soon it completed being raised.

Lastly, early in this thread, you said that the pitch variables are handled differently in MSFS as compared to P3D and FSX. Can you elaborate on that? I haven't seen any differences. Indeed, vPilot works fine on all three sims with no special handling of pitch for MSFS.

I suspect it might be related to a bug in the unit of measure used, have you tried reading the pitch as degrees, radians or even number, and verified they are all coherent?

[rcarlson]

Fine, but non-zero doesn't mean much

I'm not talking about pitch, I'm talking about pitch velocity, which is reported in the ROTATION VELOCITY BODY X simvar. See this earlier reply from MrRoper:

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

You can see that ROTATION VELOCITY BODY X has a non-zero positive value, which means the pitch is rotating nose-down.

Sounds like we need to focus on fixing the invalid pitch velocity being sent. According to the docs, which is a settable var, so maybe you could just zero it out continuously during pushback? (Other than when the pitch is actually changing, of course, during lifting and lowering of the nose.)

No, I can't do that because, a pushback with a raised pitch must keep that pitch during all the pushback, if I set it to 0 when the airplane starts to move, it would jump back to level just as soon it completed being raised.

See above ... I'm not suggesting you set the pitch to zero ... I'm suggesting you set the pitch velocity to zero, when the pitch is not changing.

I suspect it might be related to a bug in the unit of measure used, have you tried reading the pitch as degrees, radians or even number, and verified they are all coherent?

I don't have any problems with pitch. It works fine across all three sims. I'm just asking what you were referring to earlier in this thread when you said that pitch vars are handled differently in MSFS as compared to P3D and FSX.

[virtuali]

See above ... I'm not suggesting you set the pitch to zero ... I'm suggesting you set the pitch velocity to zero, when the pitch is not changing.

I can try this but,  it's not as if I ever set this value, ever, it's the sim own physic that is doing this and, if you checked my previous long post, in where I tried just freezing the airplane manually over a network WITHOUT GSX and WITHOUT VPILOT, just using the default Multiplayer, the local airplane I was setting the pitch to, and the remote airplane on the networked session behaved differently: the remote one jumped high, because its own flight model is not the same as the local one, which is an airplane, it's the "Fakesim" reduced model and, since we don't set the Pitch Velocity from GSX, just the Pitch, the Pitch velocity has been set automatically by the sim because the pitch has changed and it seems the two different flight models are not reacting to the change in pitch in the same way.

So yes, I can try setting the pitch velocity constantly to 0 as soon as the raising is complete but, I fear I'll end up fighting against the sim on inertia system.

I don't have any problems with pitch. It works fine across all three sims. I'm just asking what you were referring to earlier in this thread when you said that pitch vars are handled differently in MSFS as compared to P3D and FSX.

That's what I meant with:

"I suspect it might be related to a bug in the unit of measure used, have you tried reading the pitch as degrees, radians or even number, and verified they are all coherent?".

I noticed the pitch was being reported wrong when using certain units of measure (not sure which one it was), so the difference might have been just a bug in that particular unit of measure in MSFS for this variable (which you might have not noticed if didn't used it), and it was a while ago, it's possible it might have been even fixed with an update. In fact, we are not setting the pitch any differently in MSFS or P3D right now.

[rcarlson]

See above ... I'm not suggesting you set the pitch to zero ... I'm suggesting you set the pitch velocity to zero, when the pitch is not changing.

I can try this but,  it's not as if I ever set this value, ever, it's the sim own physic that is doing this and, if you checked my previous long post, in where I tried just freezing the airplane manually over a network WITHOUT GSX and WITHOUT VPILOT, just using the default Multiplayer, the local airplane I was setting the pitch to, and the remote airplane on the networked session behaved differently: the remote one jumped high, because its own flight model is not the same as the local one, which is an airplane, it's the "Fakesim" reduced model and, since we don't set the Pitch Velocity from GSX, just the Pitch, the Pitch velocity has been set automatically by the sim because the pitch has changed and it seems the two different flight models are not reacting to the change in pitch in the same way.

So yes, I can try setting the pitch velocity constantly to 0 as soon as the raising is complete but, I fear I'll end up fighting against the sim on inertia system.

Yeah, you might have to continuously set it, every sim frame. Though it might be worth running a test to see when exactly the pitch velocity changes, relative to when you freeze the plane and set the pitch. Maybe if you freeze the plane, set the pitch, then zero out the pitch velocity, since the plane is frozen, and the pitch is no longer changing, maybe the sim won't try to calculate a pitch velocity.

The way I see it, the bottom line is if the pitch isn't changing, the pitch velocity should be zero. Otherwise there's a bug somewhere that's causing the invalid velocity value.

[virtuali]

The way I see it, the bottom line is if the pitch isn't changing, the pitch velocity should be zero. Otherwise there's a bug somewhere that's causing the invalid velocity value.

I just did a test right now and yes, it's not behaving logically, which suggests a bug or a weird behavior at least. I'm monitoring the variables with the standard SimvarWatcher from the SDK.

Taking the PMDG 737 as an example, which defaults to a pitch down attitude of about 0.8 degrees when it's at rest on ground. The GSX towbarless tug will raise to -1.2 degrees (which really means up, of course) and during the raise animation, which goes from 0.8 to -1.2 controlled by GSX at every frame, the ROTATION VELOCITY BODY X is floating around 0.04/0.05 m/s while the pitch is slowly going up.

However, and this is the interesting (and worrying) part.

As soon GSX stops the raise animation, I can see the pitch ("PLANE PITCH DEGREES") is perfectly steady at the last value reached, not changing by even the tiniest decimal (which is to be expected, since the ATTITUDE has been frozen before starting to raise the gear), but the ROTATION VELOCITY BODY X starts to INCREASE, from the 0.04/0.05 it was while the pitch changed during the raise, to about 0.25 m/s.

This seems to indicate, while the PLANE PITCH DEGREES surely honors the ATTITUDE FREEZE, and doesn't move at all, the ROTATION VELOCITY BODY X is still being calculated, with no visible effect on the airplane locally, but if that gets transmitted over the network, and you use it to compensate for the lower update rate, it explains why locally everything is fine, but not on the network.

Now, if I add the code to constantly set ROTATION VELOCITY BODY X to 0 during pushback, I can see I'm fighting with the sim, because now the value wobbles between 0.0000 and 0.0003, which is very low, and should be enough to not mess up your prediction calculation but, as soon the airplane stops, so GSX is not constantly resetting the pitch velocity anymore (airplane is still frozen, pitch never changed during the entire time), the ROTATION VELOCITY BODY X starts to go up again, settling to around 0.25 m/s, and it finally settles down to 0 after the airplane has been put back on ground AND Unfrozen.

Find attached the modified code which sets the pitch velocity to 0 at every frame while the airplane is pushed, if this works (at least during the push), we might do this for the entire procedure, for as long the airplane is kept frozen.

Is still not an ideal solution because, I always try to be as economical as possible with Simconnect calls so, while we clearly need to set the airplane position at every frame during the pushback, we stop doing it as soon is not strictly required, to be sure we are not spamming the sim any more data than really required.

Maybe a better way might be finding some way to "signal" (sending a single bit of data) GSX is controlling that airplane and just one another signal when it's done, so you might just disable the use of the Pitch Velocity to derive the pitch value from the low network frame rate. The pitch is surely not changing while the airplane is raised so, it's not a problem if you are updating only 5 times per second something that is known not to change. This will spare GSX from having to set the pitch velocity constantly, at every frame, reducing traffic over Simconnect locally.

In fact, thinking about it, do you even need a signal to begin with? Isn't it simpler and more efficient on your side as well, to NOT apply any lag compensation to the pitch (that is, disregarding the pitch velocity in that case), if the new pitch read from the network hasn't changed between calls?

In any case, let me know if you see some difference with attached file, to be placed in:

\Addon Manager\couatl\GSX\assistanceServices

[rcarlson]

I just did a test right now and yes, it's not behaving logically, which suggests a bug or a weird behavior at least. I'm monitoring the variables with the standard SimvarWatcher from the SDK.

Taking the PMDG 737 as an example, which defaults to a pitch down attitude of about 0.8 degrees when it's at rest on ground. The GSX towbarless tug will raise to -1.2 degrees (which really means up, of course) and during the raise animation, which goes from 0.8 to -1.2 controlled by GSX at every frame, the ROTATION VELOCITY BODY X is floating around 0.04/0.05 m/s while the pitch is slowly going up.

However, and this is the interesting (and worrying) part.

As soon GSX stops the raise animation, I can see the pitch ("PLANE PITCH DEGREES") is perfectly steady at the last value reached, not changing by even the tiniest decimal (which is to be expected, since the ATTITUDE has been frozen before starting to raise the gear), but the ROTATION VELOCITY BODY X starts to INCREASE, from the 0.04/0.05 it was while the pitch changed during the raise, to about 0.25 m/s.

This seems to indicate, while the PLANE PITCH DEGREES surely honors the ATTITUDE FREEZE, and doesn't move at all, the ROTATION VELOCITY BODY X is still being calculated, with no visible effect on the airplane locally, but if that gets transmitted over the network, and you use it to compensate for the lower update rate, it explains why locally everything is fine, but not on the network.

Now, if I add the code to constantly set ROTATION VELOCITY BODY X to 0 during pushback, I can see I'm fighting with the sim, because now the value wobbles between 0.0000 and 0.0003, which is very low, and should be enough to not mess up your prediction calculation but, as soon the airplane stops, so GSX is not constantly resetting the pitch velocity anymore (airplane is still frozen, pitch never changed during the entire time), the ROTATION VELOCITY BODY X starts to go up again, settling to around 0.25 m/s, and it finally settles down to 0 after the airplane has been put back on ground AND Unfrozen.

Thanks for the test ... that's good info. My guess is that the sim is applying a positive velocity (nose down movement) to try to settle the plane back down to where it thinks it should be (nose wheel on the ground) so it's essentially fighting against your manual pitch setting. And since you have frozen the attitude, the velocity value isn't actually having any effect. Does that sound right to you?

Find attached the modified code which sets the pitch velocity to 0 at every frame while the airplane is pushed, if this works (at least during the push), we might do this for the entire procedure, for as long the airplane is kept frozen

Is still not an ideal solution because, I always try to be as economical as possible with Simconnect calls so, while we clearly need to set the airplane position at every frame during the pushback, we stop doing it as soon is not strictly required, to be sure we are not spamming the sim any more data than really required.

Maybe a better way might be finding some way to "signal" (sending a single bit of data) GSX is controlling that airplane and just one another signal when it's done, so you might just disable the use of the Pitch Velocity to derive the pitch value from the low network frame rate. The pitch is surely not changing while the airplane is raised so, it's not a problem if you are updating only 5 times per second something that is known not to change. This will spare GSX from having to set the pitch velocity constantly, at every frame, reducing traffic over Simconnect locally.

In fact, thinking about it, do you even need a signal to begin with? Isn't it simpler and more efficient on your side as well, to NOT apply any lag compensation to the pitch (that is, disregarding the pitch velocity in that case), if the new pitch read from the network hasn't changed between calls?

The velocity values are not used for lag compensation, they are used to predict (extrapolate) the aircraft's position and attitude. Then the actual values are used to apply error correction to the predicted values. This is a common technique used in multiplayer games and I spent a lot of time fine-tuning it for VATSIM. I don't want to introduce conditional code that disables the prediction algorithm when it sees that values are not changing from one update to the next. To me, that's a hacky workaround, when instead we need to fix the root cause, which is the invalid velocity values. Also, any such workaround would need to be implemented by all VATSIM pilot clients, not just vPilot.

In any case, let me know if you see some difference with attached file, to be placed in:

\Addon Manager\couatl\GSX\assistanceServices

Thanks for sending the code, but I don't have GSX installed, and I don't even have a copy of MSFS installed right now. (I use P3D myself because MSFS is not yet suitable for multi-screen home cockpits.) I normally have MSFS installed on my development computer, but I recently rebuilt it and haven't needed to install MSFS yet since I haven't been making any changes to vPilot recently. Maybe a GSX user here in this thread could test it out?

[virtuali]

Thanks for the test ... that's good info. My guess is that the sim is applying a positive velocity (nose down movement) to try to settle the plane back down to where it thinks it should be (nose wheel on the ground) so it's essentially fighting against your manual pitch setting. And since you have frozen the attitude, the velocity value isn't actually having any effect. Does that sound right to you?

Yes, that's what I think is happening.

The velocity values are not used for lag compensation, they are used to predict (extrapolate) the aircraft's position and attitude. Then the actual values are used to apply error correction to the predicted values.

Sure, you are limited by the lower datarate over the network, so you need to extrapolate where the airplane should be before the next update comes, so you can update it locally with a higher frequency.

I called it "lag", not just the fact the network might be even slower or unpredictable (which still can happen, and this would help with that as well), but also under ideal network conditions, just because you are getting data 5 times per second, so it's the lag between this limited frequency and the visual frame rate.

I don't want to introduce conditional code that disables the prediction algorithm when it sees that values are not changing from one update to the next.

That's ok, just let agree that, if you are extrapolating over a fixed value that you know hasn't changed, you are doing extra calculations you could have spared.

To me, that's a hacky workaround

To me, it's more an optimization, but of course it's your program.

when instead we need to fix the root cause, which is the invalid velocity values

Sure, if this could be done without causing any other effects because, while I haven't noticed any visual difference when I'm constantly setting the pitch velocity at every frame, it's because I don't have any other add-ons loaded that use Simconnect, so it might not be always the case on every user system, especially when they are running multiple Simconnect clients that sent lots of data, that's why I'm worried about being as tidy as possible and don't send data if it's not strictly required.

Thanks for sending the code, but I don't have GSX installed, and I don't even have a copy of MSFS installed right now. (I use P3D myself because MSFS is not yet suitable for multi-screen home cockpits.) I normally have MSFS installed on my development computer, but I recently rebuilt it and haven't needed to install MSFS yet since I haven't been making any changes to vPilot recently. Maybe a GSX user here in this thread could test it out?

The code I sent you is platform independent, so you can test it under P3D (just be sure you use a towbarless tug), with no need to activate it, just download the latest version, even in Trial mode, and replace the file with the one attached.

But yes, of course anybody can try it.

[rcarlson]

I don't want to introduce conditional code that disables the prediction algorithm when it sees that values are not changing from one update to the next.

That's ok, just let agree that, if you are extrapolating over a fixed value that you know hasn't changed, you are doing extra calculations you could have spared.

I don't know that the value hasn't changed until I receive the second one, so that's a bit cart-before-the-horse. I would have to retroactively undo the predictions that I have been doing since the last position update was received. And then when the value starts changing again, I'm one update behind. This is why I call it hacky. And it's a workaround because it is working around the true problem, which is invalid velocity data.

when instead we need to fix the root cause, which is the invalid velocity values

Sure, if this could be done without causing any other effects because, while I haven't noticed any visual difference when I'm constantly setting the pitch velocity at every frame, it's because I don't have any other add-ons loaded that use Simconnect, so it might not be always the case on every user system, especially when they are running multiple Simconnect clients that sent lots of data, that's why I'm worried about being as tidy as possible and don't send data if it's not strictly required.

I guess we're at an impasse, then. I don't want to add ugly workaround code to my client, and require that the authors of the other pilot clients do the same (as well as any future pilot clients) and you don't want to add the SimConnect load.

Perhaps the only option we have left is to ask Asobo to disable rotational velocity calculation when the attitude is frozen. Although I can only guess at what negative impacts that could have elsewhere, so I wouldn't be surprised if they declined to do so.

[virtuali]

I don't know that the value hasn't changed until I receive the second one, so that's a bit cart-before-the-horse.

That could be easily solved if we find a way to communicate (once, not constantly) when GSX starts freezing the airplane, and once after it releases the airplane. With these two signals, you would KNOW the pitch won't change and instead of constantly sending data, I would send just two messages.

Couldn't this be included somehow in the VATSIM protocol, like an extra command?

We might use it in many more useful ways to make GSX and VATSIM work better together, and not just for this issue that might be annoying but is not even the main issue. People don't like to see the airplane in a weird attitude, which of course is bad but, even if we fix this, you are still seeing airplanes being pushed by ghosts, which is distracting and immersion breaking as well.

What if we communicate over VATSIM other things related to GSX, like the name of the Pushback tug used, so all users would see the airplane being pushed by the same vehicle, instead of just moving backwards? Of course, if GSX is not installed remotely, you can just ignore these messages. This could be extended for other vehicles as well, so users with GSX installed might also see their local GSX vehicles servicing the airplanes of other users. It would make the simulation way more immersive, with all the different ground vehicles with their real liveries.

I guess we're at an impasse, then. I don't want to add ugly workaround code to my client, and require that the authors of the other pilot clients do the same (as well as any future pilot clients) and you don't want to add the SimConnect load.

That's not what's happening. I have already DONE what you suggested, at least partially (the complete solution should be constantly rewriting the pitch velocity at ever frame for the *entire* duration of the procedure, not just when the airplane moves), but I think it's not the best solution, because it puts needless strain on the already limited Simconnect pipe, when there might be a more efficient way to do it, using some kind of messaging.

Perhaps the only option we have left is to ask Asobo to disable rotational velocity calculation when the attitude is frozen. Although I can only guess at what negative impacts that could have elsewhere, so I wouldn't be surprised if they declined to do so.

I'm quite sure they won't do this, even it would appear to be the logical choice (if the plane attitude is frozen, I don't see why the sim still calculates the related velocities), but it's just too marginal use for them to justify spending time on it.

[virtuali]

What about doing something like this:

- vPilot on GSX user system detects when GSX freezes the airplane (very easy, just check L:FSDT_VAR_Frozen)

- if the variable is non-zero (if it's 0, it means GSX is not pushing or is not running), you send this modified packet:


{
    "config":{
        "is_full_data":true,
        "lights":{
            "strobe_on":false,
            "landing_on":false,
            "taxi_on":true,
            "beacon_on":true,
            "nav_on":true,
            "logo_on":false
        },
        "engines":{
            "1":{
                "on": true
            },
            "2":{
                "on": true
            }
        },
        "gear_down":false,
        "flaps_pct":0,
        "spoilers_out":false,
        "on_ground":true,
        "gsx_pushback":true
    }
}


- the remote vPilot checks the packet and if gsx_pushback is True, it will consider the Pitch Velocity to be 0, because it can be sure pitch won't change for as long GSX is pushing, because the plane attitude is frozen.

So, the real question is: is there a problem sending a packet containing an extra field? If not, would it be feasible to have a new kind of package that contains specific GSX data that would only be sent by users running vPilot and GSX?

I understand other Vatsim clients won't have this feature but, if we documented it, they could add it as well.