I know this issue is well known as I see on flight simmer streams and I think it’s just an MSFS issue, and maybe specifically GSX users, but is there any fix on the horizon for these wonky pushbacks where the other users have their nose or tail at 45 degrees in the air, or even vertical?
I don’t remember ever seeing this in P3D with GSX. If it’s some kind of data issue couldn’t some code be added to block erroneous pitch data during Ground manoeuvres say under 100kts?
Thanks
David
I also see this very often. Would love a fix for this!
I came here to ask the same thing. Here’s Spirit pushing back at KBOS the other day. Kinda ruins the immersion lol.
Yep it’s a shame it doesn’t seem to be getting any attention as it’s been an issue for months. I had two aircraft pushing back in front of me the other day and one 767 was perfectly on the ground, and a 737 in front of him had his nosewheel 10ft off the ground.
I would suggest that, if you don’t like the behavior exhibited due to the failure of a developer’s software, you contact the developer to investigate, find the root cause of the problem and solve the problem. You can get sympathy here, but you should push for the root cause to be solved with the developer.
That was precisely the reason for posting, I was hoping vPilot could be coded to solve the problem, maybe some kind of rule which won’t change pitch of AI models under 30kts ground speed for example. But maybe an expert on the forum knows the root cause (something to do with the traffic models? Or is a GSX issue?)
Others may know better – I’m only going off what I vaguely remember – but I think it’s a GSX issue. Anyone can feel free to correct me if that’s not right.
Hi,
The GSX developer has given thoughts here, and believes it to be an issue that needs to be resolved in vpilot:
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!
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?
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.
I wonder if this is something that might see some attention now that CRC is released
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.
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.
