This reached new levels of crazy for me yesterday. The amount of smoke that gets generated from the crazy pitch dropped my framerate to single digits until the other guys pushback finished!
2 Likes
What would be great is if there was some way to flag this in VPilot or XPilot, so they could take a look at the data from a log file and figure out what was happening. Do the VATSIM clients need to be updated to better understand what GSX is doing? Or does GSX need to change how their pushback is being transmitted?
1 Like
There’s a good explanation (or theory) on the GSX forum link posted above. It seems MSFS changed the way certain variables work versus how they worked in FSX, P3D etc and unless the relevant client takes account of this you could get erroneous data and therefore incorrect pitch values being assigned to AI traffic models. I think we need the vPilot Dev to give a view.
1 Like
I wonder if this is something that might see some attention now that CRC is released
1 Like
I Just wanna bump this thread since the issue is still present and i was wondering if theres anything that can be done on vpilots side.
also could i ask if FSDT reached out to @887155 about this issue.
i wish to know this as currently on the above mentioned forum post the dev of GSX suggests that its on vpilots side to resolve this issue right now.
also to be clear incase my message comes across rudely, i just hope to help find the cause of this issue so everyone on vatsim no longer sees planes behaving in this manner constantly.
I posted this in the other thread a while ago:
I think it is possible to fix via VPilot but they would need to ignore velocity vectors whilst on the ground and calculate the aircraft movement using another mechanism.
I just registered on the FSDT forums so that I can join the thread there and provide more information about how vPilot works.
1 Like
The vPilot rendering code was developed after many iterations of testing and fine tuning. (And the same algorithms are used in xPilot.) I definitely will not be rewriting how vPilot handles aircraft movement just because of this issue. The root cause of the issue must be identified and fixed by the responsible party. I will do what I can to figure out what and who that is, whether it be FSDT, Asobo, or myself.
Understood,
In that case the problem is likely one for Asobo to fix. GSX sets the 3 freeze simconnect variables during the push and it seems that the velocity vectors are being incorrectly calculated during this freeze. its possible that the GSX application is setting these but im sure I saw the same result when setting aircraft pitch etc manually via simocnnect when frozen.
Thank you very much, Ross.
I will do what I can to figure out what and who that is, whether it be FSDT, Asobo, or myself.
This is exactly the attitude i was hoping for. As i have already stated in the FSDT forum thread, we as users really don’t care where the problem lies, as long as it get fixed in some way.
thank you very much!
apologies for my late response im not super active on this forum and didn’t get a notification on my mail that i got a reply.
Hello,
I’m quite sure we found the real cause for this issue, which is in fact the unexpected behavior of the various velocity variables which are still being calculated, even if the airplane is frozen, and confuses vPilot, which uses those velocities to predict the airplane movements, since the networks is updated at a much lower frequency than the visual frame rate.
This thanks to @1582549, who took the time to continue my tests and recognize the problem exactly.
While the real root of the problem is this strange behavior of the velocity’s variables, that don’t seem to honor the “freeze” variables, so it should be “ideally” fixed by Asobo (if they did, neither GSX or vPilot would need any changes), I highly doubt they’ll consider worthwhile working on it so, it’s going back to us.
So yes, this can be fixed from both sides:
-
From GSX, by constantly rewriting the pitch velocity to be 0 at every frame for as long the plane is kept frozen
-
From vPilot, if there was a way for it to know the airplane has been frozen by GSX, so it could momentarily ignore the pitch velocity (just consider it to be 0) in the prediction calculation.
I already posted a slightly modified GSX Pushback code that everybody on our forum can try, which adds this change. The link is below, in that post on our forum.
It’s not final, because the pitch velocity is only set while the airplane is moving (it’s like this to make it very quick to change), a better way would be continuing rewriting the variable for the whole procedure instead. But it would be useful to know if it fixes the issue for you. Of course, you must try a Towbarless tug, because with a Towbar, I guess the problem wouldn’t happen, since the plane is not pitched up.
However, the GSX approach will put extra strain on the user local system, because the pitch velocity must be constantly rewritten at every visual frame, so I would rather not be doing it, unless strictly necessary, because we are already facing issues caused by too much traffic on Simconnect (by the combination of all Simconnect clients used) right now, so we’d rather not add something that will increase it further.
Another approach might be a way of signaling GSX is pushing, so vPilot could know that, and just consider the pitch velocity to be 0 during that time, no reason to extrapolate with a value that’s surely won’t change, because the airplane is frozen.
I made a proposal how this might work:
But it’s based on very sparse and quick research about how the Vatsim protocol works, so I have no idea if this makes any sense.
But if it does, it might open to new possibilities.
Other than “just” fixing this pitch issue, I guess we might send more data about GSX over the network: for example, we might send the name of the Pushback tug used and, if you have GSX installed, you might see other pilots being pushed by the actual Pushback tug used by them, instead of just going backwards.
1 Like
For those not following the thread on the FSDT forums, Umberto’s fix for overriding the pitch velocity value during pushback worked a little bit, in that the pitch changes are much better now, but it’s not ideal since the movement is still a little jittery, and it also greatly increases SimConnect message traffic. So I instead have made a change in vPilot so that it ignores the invalid velocity values during pushback and doesn’t send them to the VATSIM server … it instead sends a velocity of zero.
This technique is a compromise because it doesn’t fix the true problem, and it requires changes to all MSFS/P3D/FSX pilot clients, but it also doesn’t require any changes to the VATSIM network protocol or any xPlane client to deal with the bad velocity values on the remote end, since they aren’t sent to begin with.
This vPilot change is currently being tested and if it works, it will be in the next public release of vPilot which will be on March 1st.
2 Likes
Awesome thanks so much guys.
This is awesome news, will be so good not having to see this anymore when flying online on Vatsim.
Fantastic job Ross. Thank goodness we will no longer be subject to those awful GSX Pro pushback animations!
Thank you so much both Ross and Umberto working to solve that problem!
And what a wonderful idea:
Blockquote Other than “just” fixing this pitch issue, I guess we might send more data about GSX over the network: for example, we might send the name of the Pushback tug used and, if you have GSX installed, you might see other pilots being pushed by the actual Pushback tug used by them, instead of just going backwards
Now that vPilot 3.8 is out, please let me know if you are still seeing this issue. Note that it may take some time for the swift developers to make the same change, so if you still see this happening, it’s possible that the pilot is using swift.
This is superb news Ross, thank you so much!
Haven’t had much time flying lately but very much looking forward to trying this new version out!