Nose high GSX pushback by others on VATSIM/vPilot

[rcarlson]

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?

I have an idea for a workaround that doesn't require sending anything over the network. More on that later.

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

I'm confused ... you have said several times that you don't want to use that solution because of the added SimConnect load. Are you saying you are okay with it if it works and properly solves the issue?

[rcarlson]

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.

I have a few concerns with this approach. First, it requires changes to the VATSIM network protocol. Second, the packet that you are referring to is only for aircraft appearance data, like gear/lights/engine states. (It is called the "Aircraft Configuration" or ACCONFIG packet.) It is not sent every frame with the positional/rotational values, rather it is only sent when the values change, and it is rate-limited to avoid spamming the server when the values are changing rapidly such as during flaps extension/retraction. So that means there will be timing problems since the configuration packet won't be received in time to prevent the pitch movement. Lastly, it requires changes to all pilot clients for all sims.

Also, to my knowledge, custom LVars are not accessible to external SimConnect clients like vPilot. We would have to use some other means of communicating GSX pushback such as custom SimConnect client events or a CDA (Client Data Area.)

I would like to find a way to work around the velocity issue in one place (within GSX) so that it is solved for any pilot client on any sim on any network. This is why I think that having GSX override the velocity during pushback is the right approach, assuming that testing reveals that this actually does solve the issue. Though I do understand the concern about adding SimConnect load, but in this case it will be just a single var, and only during pushback, and only if using a towbarless tug, and only if vPilot is running, if you want. If testing shows that this workaround does not solve the problem, I suggest the following alternate workaround:

When the user initiates a pushback in GSX using a towbarless tug, check if vPilot is running. If it is, then don't raise the nose, even if using a towbarless tug. That way, the sim won't try to push the nose back down to the ground during the pushback, because it will already be on the ground. The pitch velocity should remain at or near zero.

In order to detect if vPilot is running, you could check if a process named vPilot.exe is present in the process list, or if you don't have access to the process list, vPilot creates a SimConnect CDA (Client Data Area) which has a byte that contains a one or zero to indicate if vPilot is currently running. It contains another byte that indicates if vPilot is actually connected to VATSIM. You could use that second byte to determine if the nose should be raised or not. That way, if someone is running vPilot without being connected (because, for example, they launch it as part of a batch file every time they run the sim) then they still see the nose raise up.

This workaround has the benefit of only having to be done in one place (GSX) and not in multiple pilot clients, and obviously it doesn't require any network protocol or server changes on VATSIM or any other network. Obviously, you would need to detect other pilot clients as well, through a similar means. The only other VATSIM client that supports MSFS is Swift, but there could be more in the future. The vast majority of VATSIM MSFS pilots use vPilot, so just detecting vPilot would be more than enough I'd say. (Though if you do have access to the process list, it would be simple to also check for the Swift executable.)

The downside is that the GSX user won't see their nose raised up when being pushed with a towbarless tug while running vPilot and connected to the network.

What do you think?

[virtuali]

I'm confused ... you have said several times that you don't want to use that solution because of the added SimConnect load. Are you saying you are okay with it if it works and properly solves the issue?

You said you don't want to change vPilot.

I never said that I will "never" change GSX, but I like the other approach more, and I'm still convinced it is the best approach, not just for performance reasons, but also to eventually expand it further with better integrations. In addition to that, I even posted an *actual* file with the changes you suggested, and I'm awaiting some feedback from anyone using Vatsim to see if it works so, what else I'm supposed to do?

That doesn't mean we should stop investigating other solutions.

I have a few concerns with this approach. First, it requires changes to the VATSIM network protocol.

Which means the Vatsim protocol is forever frozen, with no chances to ever expand it?

It is not sent to every frame with the positional/rotational values, rather it is only sent when the values change, and it is rate-limited to avoid spamming the server when the values are changing rapidly such as during flaps extension/retraction.

Sounds about right for an event like that. I never suggested you should check it at every frame! Every second, for example, seems to be more reasonable.

So that means there will be timing problems since the configuration packet won't be received in time to prevent the pitch movement. Lastly, it requires changes to all pilot clients for all sims.

That might be solved from GSX side, if it set the pitch velocity to 0 constantly, but only for a bit of extra time *after* it froze the airplane (enough to be reasonably sure it the event has been received it), and then stopping, to stop the continuous data sending.

Lastly, it requires changes to all pilot clients for all sims.

Well, if they want their prediction algorithm to stop being confused by a frozen airplane...what if another add-on comes out and for some reason need to freeze the airplane as well?

You should try to see the big picture.

It's not "just" a matter of fixing this annoying but admittedly minor pitch issue. With all the various add-ons like AI packages doing their thing, don't you think seeing airplanes being pushed back by invisible tugs is something that would require at least some discussion? We could do so much more and add actual features to improve the experience on ground, by integrating better ground services with Vatsim.

In fact, it's when you are on ground that you have a chance to see the other user airplanes up close, and they would look so much better if they were serviced by proper ground vehicles, especially during pushback.

Also, to my knowledge, custom LVars are not accessible to external SimConnect clients like vPilot. We would have to use some other means of communicating GSX pushback such as custom SimConnect client events or a CDA (Client Data Area.)

There's a substantial difference here between MSFS and FSX/P3D. With MSFS, you can just add an L: variable to a standard data definition, just as if it were a regular SimVar, and read/write to it from an external Simconnect .EXE

Yes, with FSX/P3D it would require exchanging data with custom client areas, which is what we use to connect with SODE, and what we used in MSFS as well, before the ability to access L:  variables directly have been added to Simconnect, in a sim update. But yes, we could just use the same CDA method for all simulators, no problem.

If testing shows that this workaround does not solve the problem, I suggest the following alternate workaround:

Sure, that's Plan B (more like a Plan C) if all else fails. But precisely for this reason:

The downside is that the GSX user won't see their nose raised up when being pushed with a towbarless tug while running vPilot and connected to the network.

It's really the last resort, if there's no other way, because it's just not right to penalize GSX users because they use vPilot, when there IS a solution (the one I proposed), which will SURELY work regardless of any foreseeable test results, and it's acting on vPilot instead and letting it consider the pitch velocity to be 0, if it knows GSX is pushing.

To me, the only real obstacle here, is having to add something to the Vatsim protocol. What is required to at least make a proposal?

[rcarlson]

I never said that I will "never" change GSX

And I never said that you said you will "never" change GSX. Please don't jump to extremes and put words in my mouth. That is not helpful here.

Which means the Vatsim protocol is forever frozen, with no chances to ever expand it?

You are again jumping to extremes. Of course the protocol can be changed. All I said is that having to change the protocol is a downside to your proposed solution.

It is not sent to every frame with the positional/rotational values, rather it is only sent when the values change, and it is rate-limited to avoid spamming the server when the values are changing rapidly such as during flaps extension/retraction.

Sounds about right for an event like that. I never suggested you should check it at every frame! Every second, for example, seems to be more reasonable.

I think you are missing my point. The point is that the ACCONFIG packets are sent with different timing and different triggers as compared to the 5hz positional/rotational values. So by the time the new ACCONFIG packet (with the GSX flag set to true) is received, the invalid pitch velocity has already been received and caused the nose-down movement to begin. This will result in the pitch jittering/bouncing a bit.

Lastly, it requires changes to all pilot clients for all sims.

Well, if they want their prediction algorithm to stop being confused by a frozen airplane...what if another add-on comes out and for some reason need to freeze the airplane as well?

It's not that their prediction algorithm is being confused by a frozen airplane, it's that their prediction algorithm is acting appropriately on invalid pitch velocity data.

You should try to see the big picture.

By not wanting to have to implement a fix that requires changes to multiple applications and systems, and instead suggesting a much simpler fix at the source of the problem, "seeing the big picture" is exactly what I'm doing.

It's not "just" a matter of fixing this annoying but admittedly minor pitch issue. With all the various add-ons like AI packages doing their thing, don't you think seeing airplanes being pushed back by invisible tugs is something that would require at least some discussion? We could do so much more and add actual features to improve the experience on ground, by integrating better ground services with Vatsim.

In fact, it's when you are on ground that you have a chance to see the other user airplanes up close, and they would look so much better if they were serviced by proper ground vehicles, especially during pushback.

Any discussion about adding functionality to display pushback tugs on VATSIM is a separate (and much larger) conversation that I'm happy to have some other time.

Also, to my knowledge, custom LVars are not accessible to external SimConnect clients like vPilot. We would have to use some other means of communicating GSX pushback such as custom SimConnect client events or a CDA (Client Data Area.)

There's a substantial difference here between MSFS and FSX/P3D. With MSFS, you can just add an L: variable to a standard data definition, just as if it were a regular SimVar, and read/write to it from an external Simconnect .EXE

Ahh, that's good news. So that at least solves that one problem with the solution.

It's really the last resort, if there's no other way, because it's just not right to penalize GSX users because they use vPilot, when there IS a solution (the one I proposed), which will SURELY work regardless of any foreseeable test results, and it's acting on vPilot instead and letting it consider the pitch velocity to be 0, if it knows GSX is pushing.

I disagree that it will "SURELY" work, for the reasons I stated above about timing.

I'm still unclear on whether or not you are willing to try the solution where you set the pitch velocity to zero each frame during pushback. In my opinion, that is the best solution on offer currently, since it requires no changes to any client applications and no changes to the VATSIM protocol. It "fixes" the problem at the source, rather than having to fix the symptoms everywhere those symptoms arise, and it doesn't cause degraded experience for the GSX user. So let me ask directly: If that solution works during testing, are you willing to implement that solution or no?

[MrRoper]

I know you guys are working through a solution, so dont want to get in the way. I just wanted to point out that it is NOT just the pitch velocity vector that is erroneous but all 3 velocity vectors. So all 3 vectors would need to be zeroed out during the push procedure.

Good luck in finding a suitable solution.

[virtuali]

And I never said that you said you will "never" change GSX. Please don't jump to extremes and put words in my mouth. That is not helpful here

I HAVE changed GSX, does it mean I lost the right to express my opinion that I would prefer a better solution instead?

You are again jumping to extremes. Of course the protocol can be changed. All I said is that having to change the protocol is a downside to your proposed solution.

It could allow us to fix the problem in a cleaner way. On the GSX user side, we'll reduce the Simconnect traffic, and we won't have to "fight" against a simulator variable. On vPilot side, an extremely simple assumption of the pitch velocity to be 0 during that time, would make it work with the existing system.

I think you are missing my point. The point is that the ACCONFIG packets are sent with different timing and different triggers as compared to the 5hz positional/rotational values. So by the time the new ACCONFIG packet (with the GSX flag set to true) is received, the invalid pitch velocity has already been received and caused the nose-down movement to begin. This will result in the pitch jittering/bouncing a bit.

Which would be fixed in the way I suggested, with GSX setting the pitch velocity to 0 for a bit more, when it can be sure the package has been received.

But now you are saying something interesting: the ACCONFIG are sent with different triggers. Which are they, exactly? Could GSX possibly use similar triggers as well? In that case, it wouldn't even have a need to add hysteresis to the pitch velocity zeroing: it would simply have to send this packet (or possibly a custom one) and not freeze the airplane until it can be sure it has been received.

It's not that their prediction algorithm is being confused by a frozen airplane, it's that their prediction algorithm is acting appropriately on invalid pitch velocity data.

In an ideal world, if the airplane is frozen, the pitch velocity shouldn't be calculated, so at the real root is an issue in the sim itself, that if it was fixed wouldn't have caused this problem in the first place and nobody would have to do anything: it will just work.

But we now KNOW the pitch velocity can't be relied to if the airplane is frozen, and since I highly doubt Asobo will consider changing this (I can try asking, it won't hurt), it might be a good idea to have the prediction algorithm changed to consider this. Again: what if another product comes out and will need to freeze the airplane for any reason?

By not wanting to have to implement a fix that requires changes to multiple applications and systems, and instead suggesting a much simpler fix at the source of the problem, "seeing the big picture" is exactly what I'm doing.

Yes, for this specific pitch problem, which I ALREADY POSTED A FIX (to be improved, sure). When I say you are failing to see the big picture, it's the bigger one outside this specific case. Maybe I'm wrong but, isn't as immersion breaking seeing airplanes being pushed by ghosts? Because that's the next thing users will ask, after this is fixed.

They'll wonder why they can't have a better experience overall, with Vatsim and Ground services at large. THIS is the "big picture" I'm referring to.

Any discussion about adding functionality to display pushback tugs on VATSIM is a separate (and much larger) conversation that I'm happy to have some other time.

Exactly, "much larger" is just another way to say "big picture"

I'm still unclear on whether or not you are willing to try the solution where you set the pitch velocity to zero each frame during pushback.

This is starting to get unreal. I said multiple times I already done that!!!

The file I posted, which you said you can't test because you don't have MSFS, and I replied it's valid for P3D too, does exactly that, even if it's not final, in the sense that the pitch velocity is set to 0 only while the airplane moves, but it would be useful as a test, because it might even be easier to see the effects, because if it works as expected, it should result in the wrong pitch happening when the airplane is not moving, but still frozen, so it's a useful visual cue for those trying it to visually see the fix in effect.

Clearly, a "final" version would keep rewriting the variable for the entire procedure, for as long the airplane is frozen.

In my opinion, that is the best solution on offer currently, since it requires no changes to any client applications and no changes to the VATSIM protocol. It "fixes" the problem at the source, rather than having to fix the symptoms everywhere those symptoms arise, and it doesn't cause degraded experience for the GSX user. So let me ask directly: If that solution works during testing, are you willing to implement that solution or no?

Of course, but I'll keep saying it's the 2nd best solution in MY opinion, because it adds extra traffic on Simconnect, it's messy in the fact it rewrites a variable that is constantly calculated by the sim. But of course, if you are not willing to do it in any other way, a 2nd best solution is better than no solution.

[virtuali]

I just wanted to point out that it is NOT just the pitch velocity vector that is erroneous but all 3 velocity vectors. So all 3 vectors would need to be zeroed out during the push procedure.

Have you tried the file I posted? Because, as far as I know, the only issue was the pitch so, if zeroing the pitch velocity at every frame is enough, I'd rather keep it that way.

I know I might seem paranoid in my quest to not contribute to Simconnect traffic any more than strictly required, but it's a serious issue and I suspect if more developers took this matter at heart, we wouldn't have to contend with the problem as much as we are already.

If you are seeing issues in the other axes as well, it's really a quick fix for me to add those as well (triplicating the length of the Simconnect packet sent every frame), so just try it, and let me know if it's enough, at least during the time the airplane is actually pushed back. I still need to add the constant zeroing for the whole duration of the procedure, when the plane is already frozen but not moving yet.

[Copper]

Because, as far as I know, the only issue was the pitch so, if zeroing the pitch velocity at every frame is enough, I'd rather keep it that way.

I can add on this note, I've seen traffic being elevated by around 5-10m high (standing at the gate) but still being level to the ground when GSX connected the tug.
Could this be an indication that the vertical axis velocity is also an issue sometimes?
Doesn't happen all the time, maybe depends on the tug that is used and whether it's lifing the aircraft or not.

But would be already a big improvement if the pitch issue is fixed and then to see if more axes might need the handling too.

Really appreciate you two finally talking to each other on the problem even though the tone might be a bit harsh.

[rcarlson]

I HAVE changed GSX, does it mean I lost the right to express my opinion that I would prefer a better solution instead?

Of course not ... I never suggested or even implied such a thing.

It could allow us to fix the problem in a cleaner way.

It is not cleaner. We agree that the root cause of this issue is invalid velocity data being generated by the sim. It is an ugly hack to try to fix this on the other side of the network connection. The cleanest fix is to not send the bad data to begin with. I believe this to be objectively true, and not a matter of opinion. As the saying goes, "treat the disease, not the symptoms".

As such, I will not further entertain any solution that requires protocol changes or that tries to address the issue on the receiving side. I have seen that sort of ugly hack implemented several times over the three decades that I've been developing for VATSIM and other networked gaming/simulation systems, and it always results in an unmaintainable mess that accumulates technical debt that other developers have to deal with far into the future.

Maybe I'm wrong but, isn't as immersion breaking seeing airplanes being pushed by ghosts? Because that's the next thing users will ask, after this is fixed.

VATSIM users have been seeing planes push back without tugs for over 20 years, and I don't recall ever being asked to add such a feature. It is most certainly not as immersion-breaking as seeing an airliner with its nose buried in the ground or high in the air.

I understand that you see this feature (displaying tugs on VATSIM) as a way to justify NOT fixing the bad velocity data at the source, and instead making it a problem for all pilot client developers to solve. For the reasons I stated above, that is not going to happen.

Furthermore, if we implement displaying tugs on VATSIM, it will be done in a generic way that works for all sims and all pushback systems, not just GSX. To include any special handling for GSX to deal with the bad velocity data is still just an ugly hack hidden within a larger feature.

I'm still unclear on whether or not you are willing to try the solution where you set the pitch velocity to zero each frame during pushback.

This is starting to get unreal. I said multiple times I already done that!!!

I see that I worded that poorly. What I meant to ask (and what I asked explicitly further down in my post) is whether or not you are willing to try it in actual practice ... i.e. actually implement the full solution in the release version of GSX, assuming testing reveals that the source code change you made actually does remedy the issue. I see from below that you have answered that question with "of course".

So let me ask directly: If that solution works during testing, are you willing to implement that solution or no?

Of course, but I'll keep saying it's the 2nd best solution in MY opinion, because it adds extra traffic on Simconnect, it's messy in the fact it rewrites a variable that is constantly calculated by the sim. But of course, if you are not willing to do it in any other way, a 2nd best solution is better than no solution.

I understand and agree that it is messy. And I sympathize with not wanting to increase SimConnect message traffic, even just during pushback. Where we probably disagree is on which of the proposed solutions is the "least messy". Which is the lesser of two evils? Naturally, you want to keep the mess out of GSX, and naturally, I want to keep the mess out of vPilot, xPilot, Swift, all future pilot clients, and the VATSIM network protocol. (And yes, I know that you don't think it's messy to work around the bad data on the receiving side, and we'll just have to agree to disagree on that point.)

I propose we move forward with testing your fix and see if it actually works. For all we know, it won't even solve the issue and we'll have to keep thinking.

[virtuali]

The cleanest fix is to not send the bad data to begin with. I believe this to be objectively true, and not a matter of opinion. As the saying goes, "treat the disease, not the symptoms".

It IS a matter of opinion. There's another saying: "All Input data is considered to be Evil, until proven otherwise", which is even more true when it's coming from a network. A very well-known programming practice, which means your app should try its best not to be fooled by external data.

We must agree to disagree here.

VATSIM users have been seeing planes push back without tugs for over 20 years, and I don't recall ever being asked to add such a feature. It is most certainly not as immersion-breaking as seeing an airliner with its nose buried in the ground or high in the air.

It surely is, especially after the pitch issue will be gone. People will wonder why, since we DO have started some kind of coordination to be sure GSX works on Vatsim, why nothing is done to make it even better.

And frankly, saying that people have seeing planes being pushback by invisible tugs for 20 years, is really a weak justification, and it's not even true that users are not asking for more features like that:

https://forums.vatsim.net/topic/33735-feature-request-include-the-n1-and-n2-variables-from-the-user-planes-in-vpilot/

This post was about specific things used AI planes, but another user on that thread was specifically suggesting some integration with GSX vehicles, and you dismissed it. Clearly there some demand to see more interesting things when flying online, PC and networks today are not the same as 20 years ago and, the better the sims become locally, the more people will notice things that are lacking when they are online.

I understand that you see this feature (displaying tugs on VATSIM) as a way to justify NOT fixing the bad velocity data at the source, and instead making it a problem for all pilot client developers to solve. For the reasons I stated above, that is not going to happen.

This is as wrong as it can be, and even a bit offending, and it's proven wrong by the fact that, not only I already worked to do it as you like, but I even confirmed that, it will be like that, if you don't want to consider what for me was a better solution. I was genuinely suggesting some improvements.

But if you are sure that fixing the pitch is the only thing Vatsim users wants from GSX, then fixing the pitch will be all they'll get.

Furthermore, if we implement displaying tugs on VATSIM, it will be done in a generic way that works for all sims and all pushback systems, not just GSX.

I understand, and I can agree it would be better to keep the *protocol* generic.

Assuming such system would ever appear, it might be possible to find a way that, normally, a generic tug will appear, using some default that comes with the simulator, as if doing AI model matching, just with ground vehicles.  And if the user has GSX, find a way to coordinate between GSX and vPilot to delegate the model matching.

]I propose we move forward with testing your fix and see if it actually works. For all we know, it won't even solve the issue and we'll have to keep thinking.

We were already moving forward the moment I posted the changed file. If that doesn't work, we'll proceed from that.

[rcarlson]

There's another saying: "All Input data is considered to be Evil, until proven otherwise", which is even more true when it's coming from a network. A very well-known programming practice, which means your app should try its best not to be fooled by external data.

The concept of not trusting input data does not apply here. In this case, we already know the incoming data is bad, and it is within our power to fix that since we control both sides of the connection.

And frankly, saying that people have seeing planes being pushback by invisible tugs for 20 years, is really a weak justification, and it's not even true that users are not asking for more features like that:

https://forums.vatsim.net/topic/33735-feature-request-include-the-n1-and-n2-variables-from-the-user-planes-in-vpilot/

I didn't say no one ever wanted that feature ... I only said that I don't recall anyone asking for it. And that's true ... I did not recall that one instance. I would not be surprised if there have been a few other instances of people asking for it. However, if lots of people were asking for it, I would surely recall at least one such request. The fact is, it's not something a lot of people are asking for. Certainly not as many as are asking for this pitch issue to be rectified. And this pitch issue has only existed since we started using velocity data on the network. The lack of pushback tugs has been an "issue" on VATSIM for all of its history, and all of SATCO's history before that.

And as I said before, even if VATSIM did add support for displaying tugs, that wouldn't change the fact that we need to find a solution to stop sending the bad velocity data in the first place ... working around the issue everywhere that bad data is received (in ALL pilot clients) is the wrong approach. I know you don't agree, and I won't keep beating the dead horse, so this is the last time I'll say it: I will not consider a solution that tries to work around the problem on the receiving side.

I understand that you see this feature (displaying tugs on VATSIM) as a way to justify NOT fixing the bad velocity data at the source, and instead making it a problem for all pilot client developers to solve. For the reasons I stated above, that is not going to happen.

This is as wrong as it can be, and even a bit offending, and it's proven wrong by the fact that, not only I already worked to do it as you like, but I even confirmed that, it will be like that, if you don't want to consider what for me was a better solution. I was genuinely suggesting some improvements.

I don't understand what you mean here. You have been pushing for a receive-side solution from the start of this thread.

But if you are sure that fixing the pitch is the only thing Vatsim users wants from GSX, then fixing the pitch will be all they'll get.

No, I'm not sure that's all they want, and I never said so. On the contrary, in a previous post, I said that adding display of tugs on VATSIM is a separate topic that I'd be happy to discuss. It's irrelevant anyway, for reasons already stated.

I propose we move forward with testing your fix and see if it actually works. For all we know, it won't even solve the issue and we'll have to keep thinking.

We were already moving forward the moment I posted the changed file. If that doesn't work, we'll proceed from that.

Great. I'll stay subscribed to this thread and hopefully a couple of your users can test your code change.

[Copper]

Umberto, could you please provide a pushBack.pye file where the velocity is reset not just during the push itself but during the connection/disconnection of the tug?

On Vatsim the aircraft usually gets into the wrong attitude when the tug is connected, not while being pushed. So trying to freeze the pitch velocity during push does little to nothing to solve the issue.

Also as I mentioned the pitch wont be enough, probably the vertical axis needs to be frozen too since currently the aircraft not only lifts its tail (for other vatsim users) but also is elevated a few meters into the air while the tug grabs the nose wheel (for those tugs that do that).

I'll be glad to test, but with the file you provided I saw no change due to that.

See below an example how the issue looks like - the user did not start pushback yet, they just connected the tug and were sitting at the gate for some time waiting for a pushback clearance. During the pushback the attitude did not change, so freezing it only then doesn't help.
The critical phases are lifting/releasing the aircraft, not the pushback itself from my observations.

[rcarlson]

Thanks for the testing and information, Cipher. It seems to make sense to me that the nose would pitch down after connecting the lifting tug and before actually pushing back, since I assume the sim is trying to push the nose back down to the ground (it's trying to essentially apply gravity) and that would happen as soon as GSX lifts the nose up.

What I don't yet understand is why you see the plane climb into the air. It would be helpful if someone could monitor the vertical velocity (simvar is "VELOCITY WORLD Y") and the actual altitude (simvar is "PLANE ALTITUDE") to see how and when they are changing during the full procedure.

[Copper]

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

Maybe that helps.
And ignore the weird ground textures, if the PC is under load reading the simvars and recording apparently DX12 is acting up far more than usual...

Oh and that video is with the pushBack.pye that was posted here, if that matters.

[virtuali]

Umberto, could you please provide a pushBack.pye file where the velocity is reset not just during the push itself but during the connection/disconnection of the tug?

That will come, if this solution proves to be working.

This was supposed to be a quick fix for the sole reason of testing, to see if there's a difference.

Resetting the pitch velocity constantly from the moment the plane is frozen until it gets "thawed" again will require a less quick fix, because we need to initiate a new "every-frame" update routine we'd normally do only when the airplane is moving.

Every single place where there's a connection in GSX, we are always extremely careful not to produce any extra traffic so, in this case, the "by frame" update is enabled only when it was really required, so only when GSX moves the airplane, since there shouldn't be any need to keep sending data for no reason, we are realizing we need to do so, just to correct the sim not honoring the freeze flags entirely.

On Vatsim the aircraft usually gets into the wrong attitude when the tug is connected, not while being pushed. So trying to freeze the pitch velocity during push does little to nothing to solve the issue.

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.

- Are you sure the pitch up didn't happen while the airplane was moving, and it happened on the same airplane which was raised before (just to be sure you weren't observing another airplane, one using a Towbar tug for example)? Without resetting the variable constantly during the push, the pitch velocity was still higher than expected, like 0.25/0.28, the only way to keep it around 0 is to reset it at every frame so, I would expect there would have been problems even during pushback?


In any case, I made 3 test session, under the following conditions:

This shows GSX in its last normal release, with no changes:
https://youtu.be/PEiqP1wTkb4

This is resets ROTATION VELOCITY BODY X and VELOCITY WORLD Y to 0 for as long the plane is frozen, 6 times per second.
https://youtu.be/XDzQq4kn9pQ

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.

And that's why I still think that finding some way to signal about this to vPilot (ONE signal when freezing, ONE when thawing) so it can just IGNORE those velocity vectors during that time, would have been the best solution, with the only exception for a "white knight" (more like unicorn) solution coming from Asobo.

But that's beside the point: as I've said, I want to fix this in some way, so here's I've attached the latest Pushback code, with the above changes:

- The reset to 0 of the two variables now happens as soon the airplane gets frozen by GSX, and stops after it's thawed. The velocity reset routine starts 1 second before the airplane is frozen.

- You can configure it, by editing the %APPDATA%\Virtuali\Couatladdons.ini file and adding this line to the [GSX] section:

pushback_vpfix_freq = Frame

This will enable the fix, with a frequency set at every Visual Frame. You can set it to be 6 times per second instead, this way:

pushback_vpfix_freq = 6Hz

One time every second is also possible, although I don't think it would be very effective:

pushback_vpfix_freq = 1sec

If you remove the line, the whole fix will be DISABLED, so it will be identical to the current GSX release.

Please let me know your feedback by trying with all different values. The file should be placed here:

\Addon Manager\couatl\GSX\AssistanceServices

It's only meaningful for Towbarless tugs AND if the airplane has the "Pushback Raise" option Enabled in the profile, and you can try different settings by Restarting GSX/Couatl with no need to restart the sim. And yes, it's the same code for FSX, P3D and MSFS.