FSDreamTeam forum
Products Support => GSX Support MSFS => Topic started by: Buggsy44 on June 13, 2023, 09:31:52 am
-
Hello,
Over on the vatsim forums, the vPilot developer seems to suggest it might be GSX that causes in nose-high attitudes on other users' aircraft while they use GSX on VATSIM. Is that true, and is this solvable in a future update? Is the GSX pushback sending some "nose up" attitude that is being displayed over the network this way?
https://forum.vatsim.net/t/strange-ai-pushback-behaviour-pitch/1842/3
-
I often see this attitude and i believe this is happening when the other aircraft is using GSX for pushback. When someone i know uses GSX for pushback there's nose high attitude. I hope this can get fixed. Definitely immersion breaking especially in VR.
-
The first obvious question would be: does it happen with standard MSFS multiplayer too ?
I usually notice difference in ground altitude when seeing other players in MSFS with nothing other than standard multiplayer functions, but they might be due to users using different airports. However, I never seen somebody with a wrong pitch attitude like that, it seems it only happens when vPilot enters into play.
My guess would be that, since the variable that holds the airplane pitch has *changed* its behavior from FSX/P3D to MSFS ( we noticed it, because we need to use completely different units of measure in MSFS when pitching up the airplane from GSX with the Towbarless trucks, compared to FSX/P3D ), this might be intentional or just a bug of that variable, but if vPilot uses the same code for FSX/P3D and MSFS, it will likely translate the pitch wrong.
-
I've seen this a lot also with anyone that uses GSX pushback. Whether it's vpilot or gsx as the root cause I'm not sure, but definitely looks ridiculous.
-
I've seen this a lot also with anyone that uses GSX pushback. Whether it's vpilot or gsx as the root cause I'm not sure, but definitely looks ridiculous.
The correct sentence would be: "I've seen this a lot also with anyone that uses GSX and VPILOT", because the problem doesn't happen when using GSX with the standard MSFS multiplayer.
-
I've seen this a lot also with anyone that uses GSX pushback. Whether it's vpilot or gsx as the root cause I'm not sure, but definitely looks ridiculous.
The correct sentence would be: "I've seen this a lot also with anyone that uses GSX and VPILOT", because the problem doesn't happen when using GSX with the standard MSFS multiplayer.
On a thread titled 'Nose high GSX pushback by others on VATSIM/vPilot' really? I'll spell it in bold letters next time
-
On a thread titled 'Nose high GSX pushback by others on VATSIM/vPilot' really? I'll spell it in bold letters next time
I only wanted to make it clear the problem is not caused by GSX, without sounding to "blame vPilot", because that's how my posts are usually misunderstood. I already explained what's the likely issue in my previous post:
I usually notice difference in ground altitude when seeing other players in MSFS with nothing other than standard multiplayer functions, but they might be due to users using different airports. However, I never seen somebody with a wrong pitch attitude like that, it seems it only happens when vPilot enters into play.
My guess would be that, since the variable that holds the airplane pitch has *changed* its behavior from FSX/P3D to MSFS ( we noticed it, because we need to use completely different units of measure in MSFS when pitching up the airplane from GSX with the Towbarless trucks, compared to FSX/P3D ), this might be intentional or just a bug of that variable, but if vPilot uses the same code for FSX/P3D and MSFS, it will likely translate the pitch wrong.
This posts included several useful information:
- That it doesn't happen with standard Multiplayer. It only happens with vPilot.
- WHY it might have happened. This is a guess (that's why I used that term), because I cannot possibly know much about vPilot code, but since I KNOW we have different code when dealing with the standard Pitch variable through Simconnect, which is handled differently in MSFS compared to FSX/P3D, I think a possible reason for this is that vPilot uses the same handling in FSX/P3D/MSFS without accounting for the differences in MSFS (the standard multiplayer mode clearly does), and if this is the case, it's normal that reading that variable from vPilot and using it as in FSX/P3D would surely cause the pitch to be completely wrong.
With the following information, it should be clear there's nothing we can do from our side to fix this. We are not transmitting anything over the network, we are just setting a variable that is clearly correct locally, how it's transmitted and received (standard Multiplayer or vPilot), is completely outside our control.
-
Thanks for your input. I've added a comment on the Vatsim forum thread linking back here so hopefully it can be looked into.
https://forum.vatsim.net/t/strange-ai-pushback-behaviour-pitch/1842/8
-
I came here to check on this as well... I could never tell if this was a GSX issue, or Vpilot issue. Recently I bought XP12 and loaded XPilot for it, same exact issue. So it seems it's more something GSX needs to fix. No other pushback utility does this on VATSIM. Maybe GSX could code it so that if it detects VATSIM then no pitch data it sent? Very simplistic I know, but just a thought.
-
I came here to check on this as well... I could never tell if this was a GSX issue, or Vpilot issue. Recently I bought XP12 and loaded XPilot for it, same exact issue. So it seems it's more something GSX needs to fix. No other pushback utility does this on VATSIM. Maybe GSX could code it so that if it detects VATSIM then no pitch data it sent? Very simplistic I know, but just a thought.
I'm befuddled. You loaded XPilot in X-Plane 12 and had the exact same issue, so you believe it's a GSX issue? As far as I know, GSX doesn't even exist in X-Plane. In fact, I don't think FSDreamteam even has any X-Plane products at all. Given the above, how would GSX cause an issue in a simulator that it was never even designed for.
-
I'm befuddled. You loaded XPilot in X-Plane 12 and had the exact same issue, so you believe it's a GSX issue?
Maybe he wanted to say he's looking from X-Plane to other users that are instead flying MSFS using GSX ? That would be the only case where he might think it's a GSX issue, but I don't even know if this vPilot program allows multiplayer sessions between MSFS and XP12 players at the same time. Does it ?
-
Maybe he wanted to say he's looking from X-Plane to other users that are instead flying MSFS using GSX ? That would be the only case where he might think it's a GSX issue, but I don't even know if this vPilot program allows multiplayer sessions between MSFS and XP12 players at the same time. Does it ?
The only thing VPilot does is connects the user to VATSIM and displays the VATSIM traffic as AI traffic regardless of which simulator the other traffic is using. You wouldn't use it for your typical multiplayer session.
-
Sorry, I hadn't been on here in a while...
Firstly, I don't own GSX. These are my observations while flying on VATSIM in both MSFS2020 (using vpilot) and XP12 (using XPilot) When I would see someone pushback doing a ridiculous nose-high wheelie, I'd query them about it and yep, always GSX. The reason this has to be something going on inside GSX code, is because no matter which VATSIM client is used, the same result is displayed on screen. GSX is the common denominator. I could understand if this only happened when connected to say Vpilot and not Xpilot, then I'd blame Vpilot. But since it's both, GSX is the bad guy here.
All I'm saying is that it can't be THAT difficult for the devs to figure out what exactly they're doing that translates into pushback wheelies with regards to VATSIM, and fix it.
-
Sorry, I hadn't been on here in a while...
Firstly, I don't own GSX. These are my observations while flying on VATSIM in both MSFS2020 (using vpilot) and XP12 (using XPilot) When I would see someone pushback doing a ridiculous nose-high wheelie, I'd query them about it and yep, always GSX. The reason this has to be something going on inside GSX code, is because no matter which VATSIM client is used, the same result is displayed on screen. GSX is the common denominator. I could understand if this only happened when connected to say Vpilot and not Xpilot, then I'd blame Vpilot. But since it's both, GSX is the bad guy here.
All I'm saying is that it can't be THAT difficult for the devs to figure out what exactly they're doing that translates into pushback wheelies with regards to VATSIM, and fix it.
I just want to clarify what you are trying to say. You yourself aren't using GSX, but the other airplanes that push back with their nose up are using GSX?
-
That's exactly it. I've never used GSX before, I just started noticing this happening seemingly randomly on VATSIM, some airliners push back normally, some have their nose up in the air. I queried the VATSIM subreddit and forum, as well as various MSFS forums, and most people pointed at it being "someone using GSX for their pushback". I started asking directly via VATSIM message whether they used GSX, and the answer was always yes. Then switching over to try X-Plane (and of course an entirely different VATSIM client), the exact same thing was happening.
I feel that somehow when GSX loads the nose wheel onto the tug, the height of the nosewheel is being translated as feet and not inches. It's no huge deal, but when you have these photo realistic airports and liveries, seeing these silly pushbacks kind of throws cold water on the immersion factor. So whatever the cause, it would be awesome if it was fixed.
-
Kind of wish that information was made clear from the start since that part wasn't clear in the initial post. The only thing I can think of is that there are towbarless tugs that GSX uses for pushback that lifts the nose wheel off the ground. Even then, it shouldn't be that dramatic. Next time that happens and you ask them, ask them if they have the towbarless tug or not. The tugs with the towbar don't lift the nose.
-
Ahh good idea. Could very well be the specific tug. And who knows, the fix could be on the VATSIM clients side to "learn" how GSX does its thing. But narrowing it down will definitely be helpful.
-
Just a quick clip here, but you can see the tug dropping the nose after pushback.
https://www.twitch.tv/videos/1875930023?t=16m54s
-
Kind of wish that information was made clear from the start since that part wasn't clear in the initial post. The only thing I can think of is that there are towbarless tugs that GSX uses for pushback that lifts the nose wheel off the ground. Even then, it shouldn't be that dramatic. Next time that happens and you ask them, ask them if they have the towbarless tug or not. The tugs with the towbar don't lift the nose.
This will happen with every tug but the effect will vary depending on tug and/or aircraft.
- A320s will do a stoppie on the nose wheel and sometimes just float in the air
- 737s will do a wheelie on the rear wheels
- A310 will stand on its nose
This has been happening on VATSIM when connected via vPilot (MSFS + P3D) and xPilot (XP11/12). Only people pushing back with GSX do these aerobatics. All other pushback apps keep the aircraft flat, despite them also lifting the nosewheel.
GSX Pro for MSFS is basically a meme on VATSIM because of this.
Please find a solution, thanks.
-
Please find a solution, thanks.
Unfortunately, I'm just a customer, not a developer. I can't do anything to solve the issue.
-
Please find a solution, thanks.
Unfortunately, I'm just a customer, not a developer. I can't do anything to solve the issue.
I was hoping the message would be picked up by Mr. Umberto and a quick solution would be deployed promptly, for the sanity of all people on VATSIM.
-
I was hoping the message would be picked up by Mr. Umberto and a quick solution would be deployed promptly, for the sanity of all people on VATSIM.
WEL, I mean, you did quote me, which led me to believe you were responding to me.
-
I feel that somehow when GSX loads the nose wheel onto the tug, the height of the nosewheel is being translated as feet and not inches. It's no huge deal, but when you have these photo realistic airports and liveries, seeing these silly pushbacks kind of throws cold water on the immersion factor. So whatever the cause, it would be awesome if it was fixed.
If you read my previous posts here, but also here:
https://www.fsdreamteam.com/forum/index.php/topic,30182.msg194858.html#msg194858
You would have noticed this couldn't possibly caused by GSX because it doesn't happen with standard MSFS Multiplayer, clearly indicating GSX is setting correct data.
Maybe it's not entirely clear how this works but, when setting variables on airplanes, Multiplayer or not is not even a thing to consider: we JUST set the variables required to the user airplane, and that's it, we don't need to know if there's a Multiplayer session running, it's all handled by the simulator internally so, if our values were "wrong", they would be wrong in all situations:
- When there's no multiplayer at all
- When the standard Multiplayer is used.
In BOTH these cases, the airplane pushed by GSX is clearly in the correct state. The ONLY case where the pitch is wrong, is when there's vPilot in between, and I already offered some guess WHY this happens, something changed in how Simconnect handles the pitch and, since standard Multiplayer doesn't use Simconnect to receive data, only vPilot does, something along the translation might not take into account this fact.
For some reason, it only happens with GSX, because the difference comparing to other pushback method, is that GSX freezes the airplane, so maybe vPilot would need to account for that.
-
I often see this attitude and i believe this is happening when the other aircraft is using GSX for pushback. When someone i know uses GSX for pushback there's nose high attitude. I hope this can get fixed. Definitely immersion breaking especially in VR.
Sadly, I am seeing more and more of this online (VATSIM). Whilst I am certain GSX Pro increases immersion for the user, it utterly destroys it for everyone else who has the misfortune of witnessing an Airbus attempting to bury itself in the ground.
I've read some intelligent commentary on the issue and it appears that a solution, if one exists, may only be achieved through collaboration with the developers of SimConnect and/or vPilot. So has anyone from FSDT approached the authors of those network components?
The add-on looks rich in functionality but as someone who only flies online, I will not buy GSX Pro until a solution is found. I do not want to be party to the ugliness of an online GSX Pro pushback. I am sure there are others of the same opinion.
Perhaps there is no solution. But, for the benefit of the online community would it not be the right and proper thing to collaborate and seek an answer?
Respectfully
-
I highly doubt the fault is completely with vpilot as these issues only started on vatsim with the release of GSX for MSFS.
Also worthy to note, on pushback without lift it also happens (the old 737 pusback with the towbar).
And not to forget toolbar pushback also lifts the nose and this issue was not present with that addon.
it seems a bit to easy to just blame it on vpilot when all other pushback addons dont show the same behaviour so i hope this bug can be looked at from the GSX side.
-
Also worthy to note, on pushback without lift it also happens (the old 737 pusback with the towbar).
Which seems to indicate what is confusing vPilot it's either the fact the airplane is frozen (and only partially when a Towbar is used) or it's moved by Lat/Lon not under its own flight model, rather than the raise itself.
And not to forget toolbar pushback also lifts the nose and this issue was not present with that addon.
That's not really relevant. If that add-on doesn't freeze or moves the airplane in the same way as GSX does, it might not confuse vPilot, misleading you the problem lies in GSX, when it's not.
it seems a bit to easy to just blame it on vpilot when all other pushback addons dont show the same behaviour so i hope this bug can be looked at from the GSX side.
And again, if you are still saying it can be looked at "from GSX side", it means you either haven't read my previous explanation, or you decided to ignore it. We can't do anything "from our side" because:
- We are not doing anything other than setting some variables and move the airplane which works just fine on the user system
- We don't have any idea or means to check if this data is local or it's being transmitted over a network.
- The problem doesn't exist with Standard multiplayer. It only happens with vPilot. If the problem WAS on "GSX's side" it should have happened with standard Multiplayer as well.
I'll repeat it again: there's nothing in the sim that tells us the data we set on the airplane is being transmitted or not on the network.
-
We can't do anything "from our side" because...
I understand your logic, but you can do something. You could initiate a conversation with the vPilot dev(s)? Is it beyond the wit of man to jointly investigate the matter?
GSX Pro continues to destroy immersion in the VATSIM environment.
Respectfully
-
Hi Virtuali,
Thank you for an outstanding product (GSX) that has brought much joy and increased the immersion factor for many thousands of flight simmers over the years.
As GSX Pro is one of the most successful addon products that the majority of flight simmers purchase and use, please could you try to resolve this immersion killing issue with the developer of vPilot. I have tried to find the "forum" for vPilot and there does not appear to be one or perhaps I have not looked in all the possible places. The developer is Ross Alan Carlson as indicated on the vPilot home page.
VATSIM is continually growing in popularity and seeing the unrealistic (ridiculous) behaviour of aircraft during pushback continue for so long in vPilot is truly beyond belief.
As you are a professional developer in every sense of the word with world class products, your customers would really appreciate your assistance on this issue. I understand that GSX is not the problem as you have explained above and that vPilot and/or simconnect is. I am sure that if Mr Carlson was informed of exactly what GSX is doing to the aircraft in MSFS during pushback, he would be in a fairly good position to try to solve the issue.
Many thanks in advance.
-
I am sure that if Mr Carlson was informed of exactly what GSX is doing to the aircraft in MSFS during pushback, he would be in a fairly good position to try to solve the issue.
Of course he has.
-
Hi Virtuali,
I was intrigued by the following:
I am sure that if Mr Carlson was informed of exactly what GSX is doing to the aircraft in MSFS during pushback, he would be in a fairly good position to try to solve the issue.
Of course he has.
From the above, it appears you have been in contact with Mr Carlson. I would be interested to know how extensive or fruitful your correspondence with Mr Carlson has been. Did you propose any form of 'interface' testing?
Earlier, you yourself hinted that GSX could be responsible for the appalling pushback animations we see on Vatsim:
For some reason, it only happens with GSX, because the difference comparing to other pushback method, is that GSX freezes the airplane, so maybe vPilot would need to account for that.
[My emphasis on your quote] Your use of the word 'maybe' concerns me in that it suggests you have not undertaken any testing whatsoever with vPilot. Please correct me if I am wrong.
Further, can you explain what 'freezing' the airplane means? To me this is critical to understand since any other of method I have tested (Toolbar Pushback, PMDG and FBW inbuilt push back, and even simply slewing) does not result in the gymnastics we see from online users of GSX Pro. What, precisely, is 'frozen' during the pushback?
I appreciate that many of your clients will fly offline and therefore cannot adversely affect the simming experience of others. However, several, through no fault of their own, do ruin the immersion of other VATSIM users. Consequently, I think this is a growing issue which will not go away.
I do not represent VATSIM other than being a user, but it should be noted that a GSX Pro pushback is establishing itself as something of a meme in the community. Which is a shame. GSX Pro appears to have its benefits but, and from a personal perspective, since most flights I undertake are online, I will not be party to wrecking someone else's immersion by using it.
Umberto, in closing, I refuse to believe that this cannot be readily resolved by a short collaborative effort between yourself and Mr Carlson.
Respectfully
-
From the above, it appears you have been in contact with Mr Carlson. I would be interested to know how extensive or fruitful your correspondence with Mr Carlson has been
Only very recently, so it doesn't imply in the slightest that we *tried* some coordination a while ago, and it failed for some reason. If this were the case, I would have clearly said so.
Earlier, you yourself hinted that GSX could be responsible for the appalling pushback animations we see on Vatsim:
I don't know how you could understand that, by saying "maybe vPilot would need to account for that", that would mean GSX is "responsible" for causing this problem, as if you never read or understood all my previous repeated explanations about GSX **ONLY** setting some variables that clearly works correctly in local and standard multiplayer.
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.
Your use of the word 'maybe' concerns me in that it suggests you have not undertaken any testing whatsoever with vPilot. Please correct me if I am wrong.
I never said I made any test with vPilot myself, and why should I? Since vPilot is not Open Source, the only thing I could do would be *confirm* what users are reporting, and I have no doubts about this happening, also because I saw it in some videos of online sessions. It's not as if I could check the code and have some ideas about how to make vPilot aware of GSX.
To me this is critical to understand since any other method I have tested (Toolbar Pushback, PMDG and FBW inbuilt push back, and even simply slewing) does not result in the gymnastics we see from online users of GSX Pro. What, precisely, is 'frozen' during the pushback?
Freezing means temporarily disabling the plane's own ground physic, to prevent visual stuttering due to both the simulator's own physic simulation and GSX trying to do the same thing at the same time, which is moving the airplane in certain axes, this because it's a completely custom method with its own custom physics, which is why it does what other methods can't do, like supporting the very different Towbar kinematics, for example, since they still use in some form the default pushback method, which likely solves the in-fighting of two physic simulations automatically because it's part of the sim.
Umberto, in closing, I refuse to believe that this cannot be readily resolved by a short collaborative effort between yourself and Mr Carlson.
That's what I've been saying for a long time: it can only be fixed from vPilot's side so, clearly, it should be easier with some coordination which, again, has just started.
-
That's what I've been saying for a long time: it can only be fixed from vPilot's side so, clearly, it should be easier with some coordination which, again, has just started.
[My emphasis] That's encouraging news! It would be great to be kept abreast of any findings.
Respectfully
-
Since the last GSX Update ... "nose up" isnt anymore .... it reminds me to a floating Dschinn when tug is beeing connected... planes start to float
-
Since the last GSX Update ... "nose up" isnt anymore .... it reminds me to a floating Dschinn when tug is beeing connected... planes start to float
There's nothing in the latest update that could possibly fix any issues you are having on Vatsim because, as explained so many times, we can't fix it from our side, there must be something vPilot should do to detect GSX is pushing and do something differently in that case.
Impossible to say exactly *what* vPilot needs to change to fix that but, 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.
-
Time to get this fixed ... its so weird .... :)
https://youtu.be/tDMjCCPUVcI (https://youtu.be/tDMjCCPUVcI)
-
Time to get this fixed ... its so weird ...
Why you keep posting here about this, after all the repeated explanations there's just nothing we can do on our side, because the airplane is clearly NOT pitched up on the local machine, we are just setting some standard variables that are clearly correct locally, and we don't have ANY control over what is being transmitted and, most importantly, how it gets interpreted by vPilot?
I already confirmed I have contacted vPilot author about this, exchanged some ideas, but he's the only one that can do something to fix it on his side, the only thing I can do, is clearly explaining what we do from GSX (done already), so he can write whatever code he needs to write to at least detect it's *gsx* pushing and do whatever is required to do to prevent this from happening.
-
If this phenomenon was a vPilot issue, how do you explain that it is also observed in X-Plane? Note that there is no vPilot in X-Plane, the respective app is called xPilot. vPilot and xPilot are not coded by the same people.
-
I already confirmed I have contacted vPilot author about this, exchanged some ideas, but he's the only one that can do something to fix it on his side, the only thing I can do, is clearly explaining what we do from GSX (done already), so he can write whatever code he needs to write to at least detect it's *gsx* pushing and do whatever is required to do to prevent this from happening.
Umberto, I'm delighted that you have exstablished contact with Ross Carlson. I would be grateful if you could keep us informed with regards progress. By now I'm sure you are already aware that this is a major issue for those flying on a Vatsim network.
Respectfully
-
If this phenomenon was a vPilot issue, how do you explain that it is also observed in X-Plane? Note that there is no vPilot in X-Plane, the respective app is called xPilot. vPilot and xPilot are not coded by the same people.
If you are using xPilot and you see these awful pushback 'animations' then you need to consider that that user will be using vPilot. As far as I am aware FSDT do not make a GSX add-on for X-Plane.
Umberto has already emphasised that these immersion breaking pushback animations we see on VATSIM do not occur in an MSFS multiplayer environment. Perhaps that illustrates the scope of FSDT's pushback testing; I suspect GSX Pro was not tested in an open network such as VATSIM.
vPilot interprets the client's aircraft altitude, heading, pitch and roll (amongst other attributes) and sends that telemetry data to the VATSIM network so the client's aircraft is depicted correctly to other network users. Umberto has suspected that since GSX Pro 'freezes' the aircraft during pushback (I understand this to mean that GSX Pro itself specifies the aircraft waypoints to be followed during pushback) then vPilot is misinterpreting telemetry data during this time. Why this results in the grossly inaccurate representation of aircraft pitch, no-one can say. I'm sure a solution is achievable and I'm pleased to see that Umberto has reach out to vPilot's author to work collaboratively.
I suspect GSX Pro was originally conceived as a single user add-on - and in that case it appears to work satisfactorily. However, with more and more simmers enjoying flying on open networks like VATSIM, the pushback process is now a significant issue.
I'd like to know if the GSX pushback issue is seen on the IVAO network which uses a separate client (Altitude).
-
@Rick Maclure:
"Umberto has already emphasised that these immersion breaking pushback animations we see on VATSIM do not occur in an MSFS multiplayer environment."
Well, Umborto may have emphasised that, but this does not make it true.
We formed a group of experienced MSFS and X-Plane users to investigate this "phenomenon".
The truth is: it happens in multiplayer too.
On the other hand, no other pushback tool causes this phenomenon.
Why it should be vPilot's fault remains unclear.
-
We formed a group of experienced MSFS and X-Plane users to investigate this "phenomenon".
I appreciate you and your fellow testers (you don't specify how many contributed) taking the effort to conduct an independent assessment of the problem. I think the community would value an understanding of the scope of your testing. Can you share you test plans/test scenarios? Was any testing undertaken on the IVAO network and their Altitude client?
Why it should be vPilot's fault remains unclear.
I don't think it is vPilot's fault. I think the issue sits between the way GSX Pro 'freezes' the aircraft during pushback and how vPilot interprets the telemetry during this time.
-
I will be happy to publish the test scenarios if the other members of the group agree. There were 10 users in total.
No testing was carried out on the IVAO network.
-
If this phenomenon was a vPilot issue, how do you explain that it is also observed in X-Plane? Note that there is no vPilot in X-Plane, the respective app is called xPilot. vPilot and xPilot are not coded by the same people.
It might just be a SIMCONNECT BUG.
If we were setting the variable "wrong", it would be wrong also on the local machine and, as I've said so many times, the existence of a network connection (or not), is completely unknown to GSX, we are not transmitting anything over the network.
That's why there's just nothing we can do from our side, the only thing that can be done, by those authors, is to DETECT the way GSX does a push back and do something do prevent it, which doesn't mean it's THEIR FAULT!!!, it simply means:
if there's a problem with some specific variables in Simconnect, possibly related to units of measure used by some variables, since THOSE apps are tasked with INTERPRETING what is coming from Simconnect, the "fix" can only come from them, by detecting GSX and do something.
Keep saying "it doesn't happen with other pushback tools" and just because of this, assuming it's "GSX's fault" or something that we could fix in GSX, it's plain wrong, because if those "other tools" use DIFFERENT variables which might not be affected by a possible Simconnect bug (Simconnect has lots of unsolved bugs, more serious than this), it's easily explain why it doesn't happen with other pushback methods.
So, AGAIN:
- It's not vPilot "fault"
- It's not GSX "fault
But it can ONLY be fixed from vPilot, is this now clear to you ?
-
@Rick Maclure:
The following pushback cases were tested and observed:
1. MSFS / FBW A320 / MSFS-internal pushback (ATC menu) / on Vatsim
2. MSFS / FBW A320 / Pushback Helper / on Vatsim
3. MSFS / FBW A320 / Toolbar Pushback / on Vatsim
4. MSFS / FBW A320 / pushback by GSX / on Vatsim
5. MSFS / FBW A320 / MSFS-internal pushback (ATC menu) / Multiplayer
6. MSFS / FBW A320 / Pushback Helper / Multiplayer
7. MSFS / FBW A320 / Toolbar Pushback / Multiplayer
8. MSFS / FBW A320 / pushback by GSX / Multiplayer
9. MSFS / Fenix A320 / MSFS-internal pushback (ATC menu) / on Vatsim
10. MSFS / Fenix A320 / Pushback Helper / on Vatsim
11. MSFS / Fenix A320 / Toolbar Pushback (*) / on Vatsim
12. MSFS / Fenix A320 / Fenix-internal pushback (EFB) / on Vatsim
13. MSFS / Fenix A320 / pushback by GSX / on Vatsim
14. MSFS / Fenix A320 / MSFS-internal pushback (ATC menu) / Multiplayer
15. MSFS / Fenix A320 / Pushback Helper / Multiplayer
16. MSFS / Fenix A320 / Toolbar Pushback (*) / Multiplayer
17. MSFS / Fenix A320 / Fenix-internal pushback (EFB) / Multiplayer
18. MSFS / Fenix A320 / pushback by GSX / Multiplayer
19. X-Plane / Toliss A320 / Toliss-internal pushback / on Vatsim
20. X-Plane / Toliss A320 / Better Pushback / on Vatsim
(*) When starting, the Fenix app warns that Toolbar Pushback is not compatible with the Fenix. However, no incompatibilities were found during the tests.
The result:
The "Nose High phenomenon" was observed in cases no.4, no.8, no.13 (even if observed in X-Plane) and no.18
The "Nose High phenomenon" was not observed in any other cases.
The conclusion:
The "Nose High phenomenon" is caused by GSX.
Note:
None of the testers can understand that FSDT is demanding a change to the vPilot code instead of changing the GSX code. This is all the more true because the phenomenon can also be observed in multiplayer, which the developers of vPilot of course have no influence on.
-
This is all the more true because the phenomenon can also be observed in multiplayer, which the developers of vPilot of course have no influence on.
So the problem here is that your post is the first post I'm seeing where it did impact multiplayer. Up until this point, nobody had ever mentioned anything about seeing it in multiplayer, and Umberto had reported that he was NOT seeing this issue in multiplayer. This could have been looked into a lot better had that information been known.
-
@HeicoH,
I appreciate your contribution in sharing your test results - thank you. Can I ask if you tested pushbacks using tow-bars and tugs? I recall there was a suggestion that the towbar (which didn't lift the nose) did not give rise to the issue? If the type of tug was outside of your scope, then it would be good to have that tested.
The key insight from your findings is the persistent nose-high pushback behaviour identified in MSFS Multiplayer. This discovery holds particular significance given that vPilot, IVAO's Altitude client, and MSFS Multiplayer all rely on the SimConnect architecture.
But it can ONLY be fixed from vPilot, is this now clear to you ?
In light of your results, I suggest that Umberto's assertion - that the only remedy lies in vPilot recognising a GSX Pro user - appears misguided. In fact, his statement that vPilot would need to handle a GSX client differently from everyone else only underlines that something exceptional is happening when GSX maneouvres the aircraft. Umberto has already confirmed that GSX uses bespoke coding to 'freeze' the aircraft until the pushback is completed.
- It's not vPilot "fault"
- It's not GSX "fault
I agree with Umberto in that the use of pejorative terms such as 'fault' and 'blame' are not helpful. However, I think there is a growing likelihood that GSX Pro is the cause of this pushback issue. Yes, we all understand that GSX is unaware of the existence of any network (MSFS Multiplayer, VATSIM, IVAO etc.) but GSX is solely responsible for positioning the aircraft throughout the manoeuvre. And the position and attitude of that aircraft is picked up by network clients through SimConnect.
Each network client interrogates SimConnect to establish, amongst many other attributes, the aircraft's heading, roll, pitch and elevation. From my own observations, it is interesting to note that GSX Pro accurately positions the aircraft in terms of heading and roll throughout pushback. It is primarily pitch which is the issue (although there are come examples where elevation has been problematic and the aircraft appears to hover with a nose down/up attitude).
So, could it be a bug in SimConnect? It is possible, although it must be considered that an aircraft manipulated by PMDG's inbuilt pushback or Toolbar Pushback etc., will also be communicated through SimConnect to the network. So given that several other pushback methods are correctly depicted across the network through SimConnect and those managed by GSX Pro are not, does strongly suggest that the practice of 'freezing' the aircraft during a pushback is the issue and merits closer examination.
Without further investigation I do not know if Simconnect maintains state of the the aircraft position discretely from the core values in MSFS. It would certainly make sense as a form of abstraction layer. In other words, when the network client requests aircraft positional data, it is retrieved from a SimConnect state array rather than from the core values within MSFS itself. If GSX 'freezes' the aircraft during pushback does that imply, and this is pure speculation, that positional values are not passed, or not correctly passed, to SimConnect?
I strongly suspect that GSX was conceived with the single, non-networked, flight simmer in mind. And in that context, I'm sure GSX provides value to that user. However, with the growing popularity of networks such as VATSIM, a GSX pushback is now very much in scope. I note that @Captain Kevin has responded and I would ask him, as a beta tester, if he is at liberty to outline the scope of network testing undertaken in the development of GSX Pro.
I wish to emphasis that this is not an assault on Umberto or FSDT. If you ask yourself what is the most valuable attribute that a flight sim must offer, I am sure the word 'immersion' would be prevalent. Poor frame rates, stutters, scenery glitches, AI traffic seemingly intent on disabling your aircraft all fall into that category. A GSX Pro pushback is simply another example to add to that list. I think I can safely say we are all keen to resolve this issue. On a personal note, I am more than happy to offer any assistance.
Respectfully,
-
The key insight from your findings is the persistent nose-high pushback behaviour identified in MSFS Multiplayer. This discovery holds particular significance given that vPilot, IVAO's Altitude client, and MSFS Multiplayer all rely on the SimConnect architecture.
Which confirms precisely what I'm suspecting: it might be a Simconnect bug! We are setting some variables that obviously work locally, but when another Simconnect CLIENT reads them, to replicate the remote airplane position, it doesn't receive the SAME values we set.
In light of your results, I suggest that Umberto's assertion - that the only remedy lies in vPilot recognising a GSX Pro user - appears misguided. In fact, his statement that vPilot would need to handle a GSX client differently from everyone else only underlines that something exceptional is happening when GSX maneouvres the aircraft. Umberto has already confirmed that GSX uses bespoke coding to 'freeze' the aircraft until the pushback is completed.
If the real issue lies in Simconnect itself, which changes some variables when they are transmitted, taking this approach from vPilot would be the only reasonable solution.
Since GSX Pushback is completely custom, the airplane must be frozen during pushback, otherwise the airplane's own physic would "fight" against GSX custom pushback calculations, since they would both controlling the airplane inertia at the same time, and this will cause jittering so, we surely cannot disable freezing but, this can be used by vPilot as a "signal" GSX is pushing, so it might act on the variables it receives differently, to WORK AROUND the issue.
What would be the alternative? This is the one thing we might do on our side, and it would still require changes to vPilot anyway:
- Detect if vPilot is connected, this will add lots of potentially buggy code to do this, since we would need to know if it's connected to something, requiring some communication with it, which means both coordination and changes to BOTH sides with testing, just to be sure the communication with vPilot works.
- Disabled freezing entirely if vPilot is used. Assuming this will fix the issue, which is not a given, it would mean all vPilot users would experience exactly what you labeled a detrimental to "immersion": that is stuttering/jittering, and that's JUST to prevent their airplane to be seen in the wrong attitude by OTHER users on the network.
Do you really think this would be best solution, compared to:
- Have vPilot checking those few *standard* Simconect variables to KNOW the airplane is frozen, meaning GSX must be pushing, and interpret the airplane attitude differently.
This second solution is clearly much better, because it involves 100% standard coding, it can be done entirely within vPilot with no need to agree on some special communication protocol, it doesn't require changes on both sides and, most importantly, it won't condemn users to suffer jittering locally, just to have their attitude correctly transmitted over the network!
-
As I understand it, the main reason for the way GSX handles pushback ("freezing") is to avoid stuttering.
But this doesn't seem to work:
http://www.fsdreamteam.com/forum/index.php/topic,30676.msg197409.html#msg197409
-
As I understand it, the main reason for the way GSX handles pushback ("freezing") is to avoid stuttering. But this doesn't seem to work:
http://www.fsdreamteam.com/forum/inde
Because that thread doesn't have ANYTHING to do with the jittering that is prevented by freezing the airplane. The problem reported in the thread is NOT about jitters due to GSX Pushback competing against the default flight/ground model to control the airplane DURING PUSHBACK.
According to the users that are reporting it, it affects every GSX vehicle, and not just during Pushback, but always, so it's clearly something like Simconnect or the simulator itself being affected by too many add-ons using it. And as you can see, I posted a video showing it doesn't normally happen.
The jitter that is prevented by freezing the airplane it's a completely different matter, if would affect JUST the user airplane (not the other vehicles) and would happen only during Pushback so no, you are confusing two completely unrelated matters.
-
Apparently this issue is related to the push back method GSX Pro is using ("freezing"). Other pushback tools doesn't seem to use this method, e.g. UGCX, as only GSX Pro sets variable that makes things go wrong. I have no idea how e.g. UGCX's pushback engine differs from GSX's, but asking vPilot developers to change their code, when it apparently is the setting of Simconnect variables from GSX, that makes things go wrong, is, well, wrong. Perhaps it would be more prudent if the developers of GSX found another way of making a pushback engine, that like UGCX doesn't make thing screw up.
-
Hi Umberto. I'm delighted to hear that you have made contact with Mr Ross Carlson and are looking to resolve this troublesome issue. VATSIM (using the vPilot client) is one of the best, if not the ultimate, flight simulation immersion contributors and I long to see this issue resolved. I've just landed at Gatwick and found several aircraft with their noses ditched into the ground and tails in the air while pushing back. I have attached the screenshot as I am not sure how to embed it into the message.
-
asking vPilot developers to change their code, when it apparently is the setting of Simconnect variables from GSX, that makes things go wrong, is, well, wrong.
Asking to change the whole Pushback method in GSX, which is clearly more flexible than all the others and has a background of thousands of user profiles made with it (and changing the "pushback engine" will result in throwing away all of them) when it clearly works perfectly fine when used locally, and the problems happens only when using vPilot, is wrong.
I think it's likely some variables are not translated correctly by Simconnect, possibly because a Simconnect bug or an undocumented change but AGAIN, since we don't control the transmission, there's just nothing we can do on our side if they WORK locally.
Instead, since vPilot is receiving them and it can verify GSX is pushing, it can fix this in a way simpler way we could ever do, which would, as you correctly guessed, require to change the pushback engine completely, not only losing features, but making all the existing custom pushback useless.
-
the problems happens only when using vPilot
This statement troubles me, as HeicoH has test results indicating that the weird behaviour during pushback also is found, when vPilot is not being used. So even having Carlson change the code of vPilot, will not "save" the GSX pushback. Only change in your code OR making Microsoft/Asobo change the apparently faulty Simconnect code into a code, which doesn't make the planes having strange pitch, can save the situation. Understandably you ask Carlson to change the code as Microsoft is not likely to chage the simconnect code, but that won't change the behavior when vPilot is not used.
-
This statement troubles me, as HeicoH has test results indicating that the weird behaviour during pushback also is found, when vPilot is not being used.
The statement is correct in the context of what is being discussed here, that is Vatsim, meaning vPilot is required.
So even having Carlson change the code of vPilot, will not "save" the GSX pushback.
Yes, of course it can, and easier than we could ever do, without rewriting the whole pushback method. As I've said, several times by now, since vPilot is tasked to recreate the remote airplane and it's likely getting bad data from Simconnect when GSX is acting on the "bad" variables that for some reasons are being transmitted wrong even if they are correct locally, it would be enough detecting GSX pushing, and process the bad data in some way.
My suspicion is that it has something to do with units of measure transmitted or received incorrectly (again, by Simconnect itself during the transmission, it GSX used them incorrectly, it would show up locally as well and GSX has no control over transmission), so it might just be a matter of converting them.
-
If HeicoH test results are correct, showing the weird behavior when Multiplayer - not VATSIM connection via vPilot - are being used, I fail to see how having Carlson changing the vPilot code can affect the weird behavior in Multiplayer. I take it, you haven't been able to reproduce the pitch problem using Multiplayer, so it would be nice to know, how exactly HeicoH tested and found these results and see, if you can reproduce them.
In case this is correct - will you change the gsx push back, or will we have to live with them?
-
I fail to see how having Carlson changing the vPilot code can affect the weird behavior in Multiplayer.
That only means we might have it fixed in vPilot only.
-
@TorbenJA: ("it would be nice to know, how exactly HeicoH tested and found these results")
There is nothing easier than verifying that the phenomenon also occurs in multiplayer. You don't have to set up a scientific test series to do this. You look for an airport where you know that there is a lot going on at a certain time, for example because of a Vatsim event, and where you know that, for example, a certain streamer is encouraging not only Vatsim users, but also a lot of Multiplayer users, to fly together with them. (Torben, you'll know who I mean, I won't "out" them here). Now you don't log into Vatsim, but into Multiplayer and - voila - you can just watch it.
-
@Umberto: ("The statement is correct in the context of what is being discussed here, that is Vatsim, meaning vPilot is required.")
Do you suggest starting a new thread, for the same phenomenon in Multiplayer?
-
Do you suggest starting a new thread, for the same phenomenon in Multiplayer?
What would be the point?
I did some tests and, from what I can see, it confirms my suspects the problem is somewhere in the sim, which I'll explain in a proper way now that I have more hard evidence.
Now, I understand my method of testing might be a bit complex for a normal user but, if you want to REALLY find the REAL underlying cause of things, you need to test properly, no matter how complex it might be.
Let's put vPilot out of the picture for the time being, because understanding what is really happening in Multiplayer is the key to really understanding this.
First, it's not entirely true it happens with standard Multiplayer; it happens ONLY when using a Towbarless Tug. When using a Towbar tug, with GSX, in Standard Multiplayer, there are no issues whatsoever.
This suggests there's something related to the airplane pitch variable, which is only set when using a Towbarless tug that raises the front gear, which doesn't get transmitted properly.
To prove this, I'm not using GSX, I just setup up a multiplayer session between my PC and my Notebook, which I can do because I bought two copies of MSFS to make these kinds of tests, so I can see my airplane in Multiplayer sitting on a gate. I'll repeat it again: there's NO GSX involved now, the airplane is just sitting on a gate without doing anything. I'm using the default Asobo A320.
In this resting state, the airplane has a pitch of 0.65 degrees (so it's a slight pitch down attitude, because the sign is inverted), now I need something other than GSX to set any variables on the airplane, and that's the SimVarWatcher program from the SDK, which can be used to set variables on the user airplane and other objects too.
First test: let's just set the pitch to -2 degrees (nose up), by setting the "PLANE PITCH DEGREES" SimVar to -2.
The airplane, not being frozen, jumps up and then down immediately, because its attitude is not frozen. The visual effect in this case is simular both locally and on the other networked PC, however it not entirely identical: the networked airplane jumps a bit on the main gears as well, while the local plane kept the main gears on ground and only raised the front gear momentarily. This suggests the two airplane representations (local and networked) are not reacting in the same way, and this will be even more apparent in the next test.
Second test: let's freeze the airplane and set the pitch up to -2 again. Here things start to get interesting, because, while the local airplane is perfectly pitched up and doesn't move at all, the networked one jumps up 4-5 meters in the air, then it stays frozen, up in the air, with the requested pitch.
This means, these two tests proved that setting the airplane pitch variable locally, has a DIFFERENT effect on the local airplane compared to its remote representation in Multiplayer.
The difference between the two tests, where the frozen airplane stayed up in the air, are showing the same issue in different ways: the frozen status is only helping to see the effect more easily but, in BOTH cases, the real issue is that, setting the airplane pitch locally, for some reason affects the airplane ALTITUDE as well, since even when it's not frozen, it's doing a (smaller) jump on the main gears, but it's clear the whole airplane was raised, even if I never touched the altitude, just the pitch.
Could this be a bug?
Not necessarily, they might "just" use different physic handling, so I checked the kind of SimObject on the networked PC, which can be done using the SimObject Debug in DevMode and of course, it seems to become more clear what the issue might be: while the local airplane is clearly an airplane, with a full blown flight model that reacts in a certain way, it's networked representation is NOT an airplane. In the list of SimObjects it can be found under the "FAKESIM" Category, with a sub-category of "NPC!Netplane".
This explains the underlying problem: in multiplayer, the remote airplanes are not using the same flight model as the local airplane, likely for performances reasons, the remote airplanes use a simplified flight model, which reacts differently to the airplane pitch, perhaps is not fully capable to calculate where the main gears should be when the nose is pitched up by taking into account the complete contact points/compression simulation of the local airplane.
To verify the theory, I set another variable ("SIM DISABLED" to 1), to DISABLE the simulation completely on the local airplane and, guess what, this SOLVED the problem: now setting some pitch locally, will result in the networked airplane mimic the local airplane attitude entirely, no jumps up in the air, nothing, they are exactly the same because, apparently, the simulator transmits the "Disable" state as well so, the networked version will completely shut down its "dumb" flight model, and will just follow whatever attitude is set by the local airplane.
So, the solution from GSX would "just" be disabling the simulation during pushback? Well, no. That wouldn't work because, when the simulation is Disabled, you can't do anything on the airplane, it's completely dead so, for example, you wouldn't be able to start the engines during pushback and everything will be shut down, no rudders, no elevators, nothing.
So no, we can't Disable the simulation locally "just" to prevent our networked representation from using its reduced flight model, which goes bonkers when touching the pitch.
So, I tried this: what if we Disabled the simulation (during pushback with a raised airplane only) from the networked PC instead, so the networked representation would shut down its own flight model, without affecting the user doing the pushback? If this worked, it might be a very simple solution for vPilot as well. Remember, we can't access variables on other user's systems, that's why any fix can only come from the receiving side, not from GSX.
But this idea crashed into the hard reality of Simconnect limitations: when trying to set SIM DISABLED to 1 on the networked PC on the "FAKESIM" object that represents the local airplane of the other PC, I was greeted with the sad "DATA ERROR" error from Simconnect. This is a very well-known issue: the variables you are allowed to write depends on the SimObject type: the one with the most writable ones are standard Airplanes, the GroundVehicles have less, the SimpleObjects even less.
The error means the "FAKESIM" SimObject category used to represent networked airplanes in Multiplayer, doesn't allow to write to the "SIM DISABLED" variable, which is inconvenient, since it's usually possible on many non-Airplane object types, but not this one. And there's just nothing we can do about this, other than begging Asobo to make this change.
However, there might be a way out because, even if we might never be able to fix the Multiplayer mode when the airplane is raised, it's not sure that, when vPilot is used, the airplane models generated by vPilot have the same limitation of those "FAKESIM" that MSFS Standard Multiplier mode use. If vPilot generates proper AI airplanes, like an AI Injector, it should have the ability to Disable their simulator, at least while GSX is pushing, which can be recognized by checking the variables that control the freeze.
That is in theory, but I will surely suggest this approach to Ross Carlson, see what he thinks of this.
-
Thank you, Umberto for this very interesting post. I hope, Asobo will fix this (unfortunately rather pessimistic on my part), or that Ross can edit the vPilot code to fix it for vPilot/VATSIM users. However, if neither can fix it, one has to ask oneself: What would you prefer: Seeing planes at strange pitch or limit the use of towbarless pushback. Perhaps as simply as having a checkbox, which can be set, so the full gsx can be chosen, when flying offline and a limited gsx push, where you don't change the pitch for the push, when you're online. I know the immersion of having a push from a towbarless truck without being pitched up a lilttle, isn't as good as being pitched, but to my mind looking out of the cockpit window and seeing a bunch of planes at odd attitudes is even less immersive.
Could that be an idea for FSDT to follow?
But it could be even simpler - don't use a towbarless pushback truck, when flying online?
regards
-
But it could be even simpler - don't use a towbarless pushback truck, when flying online?
Or disable the "Pushback Raise" in the airplane profile.
But yes, I guess we might detect Multiplayer (or vPilot), and "cheat" on the Pushback preference and always select Towbar in that case.
-
Umberto,
Some interesting investigation there and I thank you for investing time in some analysis. I have a much better understanding of what is going on.
Firstly, are we confident that using the towbar does not result in the nose high/low behaviour on vPilot? Similarly with disabling Pushback Raise? If this is true, then we have a workaround and I would ask that, for the benefit of the VATSIM community, you strongly advise GSX Pro users to limit themselves to the towbar when pushing back online.
If you are able to detect the use of vPilot on the client and enforce a 'non-raise' pushback, that would be a stronger solution.
We are desperately keen to avoid witnessing this behaviour...
-
Firstly, are we confident that using the towbar does not result in the nose high/low behaviour on vPilot? Similarly with disabling Pushback Raise? If this is true, then we have a workaround and I would ask that, for the benefit of the VATSIM community, you strongly advise GSX Pro users to limit themselves to the towbar when pushing back online.
I haven't tested with vPilot but, another user said it happens "the same" with standard Multiplayer so, I verified that and while it's not exactly "the same" (the airplane jumps in the air, and it's pitched up more or less correctly, so it's different to what's in your screenshot), I definitely can see that, WITHOUT GSX, setting some variables on a plane that has been frozen DOES create issues with Standard Multiplayer and, USING GSX with Standard Multiplayer with a TOWBAR tug, worked perfectly fine, so I'm confident that, even if it's not exactly the same on vPilot, the underlying reason might be similar.
If you are able to detect the use of vPilot on the client and enforce a 'non-raise' pushback, that would be a stronger solution.
From my last post, it should be clear that, from GSX side, we only have TWO options to fix this, both being less than ideal:
- Disable the simulation while pushing with a Towbarless tug. This is way worse than "less than ideal", it's basically unacceptable because, during that time, you wouldn't be able to do anything on the airplane, engines wouldn't start, controls wouldn't move, the airplane will be as dead for the whole pushback duration. So, we can scratch that.
- Enforce the use of a Towbar when using vPilot. A bit annoying, but at least it won't affect the simulation.
On the other hand (assuming it will work), there's the 3rd option, which can be done only from vPilot's side, and it's disabling the simulation of the object it created to represent the remote airplane, for as long it's pushed by GSX, which can be known by checking its frozen status. Sure, you might notice minor things, like if the remote guy lowers the flaps or test controls, you won't see it, but at least it won't be something so obvious like the whole airplane turned down.
-
And of course there is a third option. This one would be ideal for the users, but less than ideal for FSDT.
The developers of GSX could re-write the code of the pushback part of the app so it isn't necessary anymore to use the respective variables that seem to be the reason for the whole phenomen.
-
And of course there is a third option. This one would be ideal for the users, but less than ideal for FSDT.
The developers of GSX could re-write the code of the pushback part of the app so it isn't necessary anymore to use the respective variables that seem to be the reason for the whole phenomen.
But would it. Because in one of his previous posts, he said this:
Instead, since vPilot is receiving them and it can verify GSX is pushing, it can fix this in a way simpler way we could ever do, which would, as you correctly guessed, require to change the pushback engine completely, not only losing features, but making all the existing custom pushback useless.
If all the customized GSX profiles become useless, that would be far from ideal for users if you consider the amount of time it takes to create one for one airport, let alone many airports.
-
@Captain Kevin. ("If all the customized GSX profiles become useless...")
I think there is a misunderstanding. I understand Umberto's statement to mean that by "custom pushback" he doesn't mean "customized GSX [airport] profile". Umberto should clarify this.
-
@Captain Kevin. ("If all the customized GSX profiles become useless...")
I think there is a misunderstanding. I understand Umberto's statement to mean that by "custom pushback" he doesn't mean "customized GSX [airport] profile". Umberto should clarify this.
The custom pushbacks would still be part of the GSX airport profile anyway, so my point still stands. Unless you've done it before, you have no idea how long it can take to get the custom pushbacks just right for one spot, let alone for an entire airport and multiple airports.
-
I haven't tested with vPilot...
Firstly, thank you for confirming the scope of your network testing to date.
I do not have access to GSX Pro so I cannot conduct extensive testing on multiplayer networks. However, I did spent around an hour observing pushbacks on VATSIM.
For each pushback I witnessed, I privately contacted the pilot and asked them what pushback method they were using. Out of the 18 pushbacks I observed, the majority reported that they were using methods other than GSX: Better Pushback (X-Plane), Toolbar Pushback, and integral pushbacks - namely the FBW A320Neo and the Fenix A320.
There were five pilots who replied stating that they were using GSX. One was using GSX with P3D, and the remaining four were using GSX Pro with MSFS.
If the pilot replied confirming his/her use of GSX, I made a further enquiry asking whether they were using a tow-bar or a tug. Every pushback I witnessed looked normal except two pilots who confirmed they were using the tug in GSX Pro.
Not, I admit, conclusive evidence, but sufficient to suggest that the lifting tug method causes the problem and the tow-bar does not.
Enforce the use of a Towbar when using vPilot. A bit annoying, but at least it won't affect the simulation.
My emphasis. I would suggest it is far more annoying witnessing aircraft burrowing their noses into the tarmac!
The developers of GSX could re-write the code of the pushback part of the app so it isn't necessary anymore to use the respective variables that seem to be the reason for the whole phenomen.
I agree with @HeicoH here. This would be the industrial strength solution. However, I strongly suspect that GSX was developed with the single, non-networked user in mind. I further suspect that absolutely no network testing was undertaken by FSDT around the behaviour of pushbacks.
That said, I understand the cost in completely rewriting the bespoke pushback method and so, I suggest the most effective, and cheapest, method is to restrict the pushback method the tow-bar when on a network (at least the VATSIM network). It would also eliminate the need for third parties (such as the vPilot network client) to make changes at their end.
Respectfully
-
Still, it could be difficult to have this method working.
What if I activated GSX before launching VPilot, the tug would already be there, I can’t imagine GSX being able to swap it with a different one as soon as I launch VPilot.
In the meantime a « VATSIM » setting in GSX global settings, forcing the towbar tug, could help, but it will require good will from everyone, and being aware of this issue.I bet a lot of VATSIM/GSX users don’t even have a clue about GSX being the reason of this behavior.
I won’t lie I always laugh when I see other aircraft’s diving in the ground, I’m used to it now :D
-
And of course there is a third option. This one would be ideal for the users, but less than ideal for FSDT.
The developers of GSX could re-write the code of the pushback part of the app so it isn't necessary anymore to use the respective variables that seem to be the reason for the whole phenomen.
And what makes you think this option is "ideal for users"?
Not using the standard limited pushback system, like other apps do, will dumb down GSX pushback to the level of the other system which, incidentally, is one of the reasons users say they bought GSX in the first place. While I think GSX offers a lot more than just the best Pushback possible, it's a fact many users use it for Pushback only, and why do you think that is?
And what about all those hundreds of custom airport profiles, many containing lots of custom pushback routes, do you think it would be "ideal" for users and creators to tell them that, because Vatsim users can't stand seeing *other* user airplanes in the wrong attitude, they would have to trash all that work away?
Are you trying to suggest we should cripple the features which make GSX stand out (custom pushback and a large community of creators), just because there are issues with Multiplayer?
While I don't think the ones with Standard Multiplayer can be fixed, I'm cautiously optimistic it might be possible to fix the ones with vPilot, because if the program works as I think it does (creating its own airplanes independently), the fix might be as simple as disabling the flight model on remote airplane models. It might even have some beneficial effect on performance, since the sim won't have to do any physics calculations for those.
So no, your "third option" is out of the question.
We'd rather consider the "fourth option" before doing that: which is writing a replacement for vPilot ourselves! I'm not kidding: a GSX-aware client might offer extra things, for example being able to see the remote GSX Tug (assuming both users have GSX installed), instead of just the airplane moving by magic...
-
What if I activated GSX before launching VPilot, the tug would already be there, I can’t imagine GSX being able to swap it with a different one as soon as I launch VPilot.
No, but it might easily disable the Pushback Raise function in that case. The only issue might be if you started vPilot in the middle of the pushback, when the airplane is already raised, but why would you do that?
-
We'd rather consider the "fourth option" before doing that: which is writing a replacement for vPilot ourselves! I'm not kidding: a GSX-aware client might offer extra things, for example being able to see the remote GSX Tug (assuming both users have GSX installed), instead of just the airplane moving by magic...
If you pair that with an Auto-Gain for the Mic, you would even be able to sell such a Client to non GSX Users (cause everybody likes their Eardrums not being busted) ;D
-
I have been investigating this over the past few days as I was intrigued to see if we could set the sim state on the aircraft as Umberto suggested. Unfortunately its bad news, whilst you can set this flag on the aircraft it does not fix the issue.
It would seem that this is an underlying simulator issue where the velocity vectors are being continually calculated when the aircraft is frozen by GSX. These values are what vatsim / multiplayer are using to create the smooth animation we see between each update.
Here is a picture of the CRJ resting on the tug whilst there is no movement, notice the velocity vectors and also reported speed.
Not sure where the fix lies, probably with Asobo but its possible that the vPilot guys could change how they predict motion when aircraft are on the ground.
-
I have been investigating this over the past few days as I was intrigued to see if we could set the sim state on the aircraft as Umberto suggested. Unfortunately its bad news, whilst you can set this flag on the aircraft it does not fix the issue.
It would seem that this is an underlying simulator issue where the velocity vectors are being continually calculated when the aircraft is frozen by GSX. These values are what vatsim / multiplayer are using to create the smooth animation we see between each update.
Here is a picture of the CRJ resting on the tug whilst there is no movement, notice the velocity vectors and also reported speed.
Not sure where the fix lies, probably with Asobo but its possible that the vPilot guys could change how they predict motion when aircraft are on the ground.
Thank you for looking into this. We as players really don't care where the problem lies. My hope is that the developers of GSX and vPilot/xPilot can talk together and figure out a fix. Sitting on different ends of the problem and blaming each other really does not contribute to the issue.
If not already done, i challenge Umberto and the team to reach out to the vPilot developer(s) and start an initial discussion on the matter to find a common solution. In case you agree that this is something Asobo needs to fix, you are the best people to make a report for them as well with relevant data.
Appreciate any response and attention to this post.
-
If not already done, i challenge Umberto and the team to reach out to the vPilot developer(s) and start an initial discussion on the matter to find a common solution.
If you followed my replies, you would have known this already happened, and mr. Carlson has been informed with my latest post, which confirmed the underlying issue is inherent in the way the sim works, and a solution.
However, I don't think it is correct from my side, continuing to update users about any progress, or the eventual lack of it: if mr. Carlson decides to act on this or not, it's his own prerogative, in his own time, and it's not up to me to constantly report this publicly, or even soliciting him in any way.
I guess there MIGHT be a possible solution on our side, in case vPilot won't be updated for some reason, but the solution would be very cumbersome, bad for performance (Simconnect traffic) and unnecessarily complex, worse for everybody compared to a much cleaner solution from vPilot because it would require the following:
- A separate Simconnect app, that we would have to write from scratch, that must be run in parallel to vPilot. We couldn't done it from GSX, since it would force to install GSX even for those that don't use it, so it must be a separate app.
- This separate app, will need to *constantly* monitor ALL AI planes created by vPilot, check when they become frozen by GSX, and Disable their simulation, so it won't interfere with GSX movement.
This MIGHT work (in theory at least), but it's so much worse than a vPilot solution, because we would need to constantly scan all created airplanes, increasing traffic over Simconnect and putting extra strain on the sim, with the added annoyance of another app to start.
Clearly, vPilot could make it much better, since it already has a list of airplane it has created, so it can do it way more efficiently and reliably, without any need for a separate app to start.
-
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.
-
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
-
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 (https://i.imgur.com/H25uc4m.jpg)
-
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).
-
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:
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.
-
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?
-
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.
-
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.
-
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.
-
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
-
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?
-
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.
-
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.
-
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.
-
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.
-
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?
-
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?
-
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?
-
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?
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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 (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 (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 (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.
-
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.
-
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 (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?
-
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.
-
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.
-
I`m happy to help test this. if there is anyone else that can log into vatsim and monitor the push remotely?
-
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:
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?
-
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:
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:
-
Yeah, that does look much better, but it might look better or worse on different systems with different visual frame rates.
-
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.
-
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.
-
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:
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.
-
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...
-
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.
-
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.
-
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.
-
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.
May I ask which variables you're now forcing to 0 if the freeze is active? Just out of curiosity :)
We did two tries both with the lifting kind of pushback, both looked great (while remote user still had the current release version of vPilot running). Thanks again Goose for helping on the tests!
The second one I recorded. When lifting the remote view shows the aircraft going up very briefly but then settles with a slight nose up attitude which I think is perfectly fine.
The pushback is slightly stuttery (maybe due to lack of velocity data) but it could also be the remote connection with all the video streaming etc.
I can't test with all the different pushback tugs etc, but I guess the critical behavior is the same for all of them.
Also Goose spotted this, has a fair bit of comedy in such a video :D
-
Let's focus on the solution instead...
Firstly, may I say I am delighted to see, at long last, some meaningful dialogue on this long-running issue. I have long campaigned for this issue to be addressed.
@rcarlson Sincere thanks to you for positively engaging in the analysis of the issue.
@virtuali You now have people engaged in helping you find a solution. In their efforts, they are supporting you and your product. I am glad you now recognise and welcome that support.
@Copper Where did you come from??? I thank you for the amount of time you have put into analysing the issue and professionaly publishing the results of a potential solution. You have, quite literally, graphically demonstrated what GSX Pro should look like in a multiplayer environment.
I look forward to the implememtation of the outlined solution.
Best regards
-
@Copper Where did you come from??? I thank you for the amount of time you have put into analysing the issue and professionaly publishing the results of a potential solution.
I didn't analyse much, just replicated what Umberto and rcarlson discussed since the very obvious issue is that Umberto isn't using vPilot/Vatsim and rcarlson isn't using GSX (or MSFS in general) - so they need assistance to verify that their theory on cause and fix actually is true.
Whenever we buy (or use) addons we can't expect the devs to make sure they work with any other addon as long as it isn't explicitly part of the product description.
Let's hope the fix doesn't have any side effect and that it indeed fixes all the cases of this issue.
Also if I understood correctly it's up to Asobo to properly fix this issue since whichever tool reads the faulty data generated by MSFS will continue to have issues with GSX pushback (or with basically any other addon that might want to use the "freeze" SDK feature that is).
-
May I ask which variables you're now forcing to 0 if the freeze is active? Just out of curiosity :)
If IS LATITUDE LONGITUDE FREEZE ON returns true, then these vars are zeroed:
VELOCITY WORLD X
VELOCITY WORLD Z
If IS ALTITUDE FREEZE ON returns true, then this var is zeroed:
VELOCITY WORLD Y
If IS ATTITUDE FREEZE ON returns true, then these vars are zeroed:
ROTATION VELOCITY BODY X
ROTATION VELOCITY BODY Y
ROTATION VELOCITY BODY Z
We did two tries both with the lifting kind of pushback, both looked great (while remote user still had the current release version of vPilot running). Thanks again Goose for helping on the tests!
The second one I recorded. When lifting the remote view shows the aircraft going up very briefly but then settles with a slight nose up attitude which I think is perfectly fine.
The pushback is slightly stuttery (maybe due to lack of velocity data) but it could also be the remote connection with all the video streaming etc.
The stuttering during push is likely due to the fact that the lat/lon are changing, but the velocities are zero, so vPilot is continually auto-correcting the mismatched lat/lon, 5 times per second, and that shows up as the stuttery movement. Not much we can do about that, other than trying to calculate realistic velocities for lat/lon, on the sending side. Seems like more trouble than it's worth.
I'd like to figure out why the aircraft raises up and then settles down. My best guess is that for some reason the PLANE ALTITUDE var is briefly reading a too-high value, then it goes back to normal. Would you be able to record a video showing that var? Also showing the three freeze vars, and the VELOCITY WORLD Y var, since that's the altitude velocity.
And thanks very much for taking the time to make the videos ... very helpful.
-
I'd like to figure out why the aircraft raises up and then settles down. My best guess is that for some reason the PLANE ALTITUDE var is briefly reading a too-high value, then it goes back to normal. Would you be able to record a video showing that var? Also showing the three freeze vars, and the VELOCITY WORLD Y var, since that's the altitude velocity.
We did not see this plane jump on the first try, only on the second one.
I did not record the first try entirely but the lifting was in there too and there was no jump:
And here's a recording of the requested simvars (I added altitude over ground). I tried this two times, in both cases I do not see the altitude change at all, but it of course could be a matter of a polling interval (it seems like AxisAndOhs polls in 1Hz or 2Hz I think). I have no way to record higher frequency on my side.
Could there be some sort of race condition that a velocity that is set to 0 manages to "leak" through before it's reset? Not sure.
Not in the video, the altitude vars do change during the pushback movement (probably due to ground elevation changes), but that's not an issue for vPilot I think since it happens gradually.
But since the weird attitude and lifting (before the fix) only happen during the tug connection, having that brief "glitch" is certainly acceptable.
-
Could there be some sort of race condition that a velocity that is set to 0 manages to "leak" through before it's reset? Not sure.
I don't think so, because the altitude is frozen from the very beginning of the procedure, so vPilot will be sending zero for the altitude velocity the whole time.
I suspect it's the actual altitude itself that is jumping. It could also be a glitch in the ground clamping algorithm that vPilot uses to keep aircraft on the ground when the sending side has different scenery and terrain elevation data. That algorithm involves continually sampling the terrain height below the aircraft, and using the reported AGL altitude to render the aircraft at the right altitude. Maybe there's a glitch in that code caused by bad terrain elevation data or something like that.
I suppose it's not worth worrying about, especially if it only happens intermittently. I'd say we can put this one to bed for now. This workaround will be in the public release of vPilot scheduled for March 1st. I'll let the devs of the other SimConnect pilot clients (of which there is currently only one, Swift) know so they can implement this workaround as well if they want.
Thanks for all the help!
-
I suspect it's the actual altitude itself that is jumping. It could also be a glitch in the ground clamping algorithm that vPilot uses to keep aircraft on the ground when the sending side has different scenery and terrain elevation data. That algorithm involves continually sampling the terrain height below the aircraft, and using the reported AGL altitude to render the aircraft at the right altitude. Maybe there's a glitch in that code caused by bad terrain elevation data or something like that
Could totally be it, yes.
I now, as suggested by a Community member Chaoz, tried using SimVarWatcher with highest frequency but there is no change to the PLANE ALTITUDE nor the above ground whatsoever either.
I just noticed that on my today's videos I had a typo in the simvar "IS LATITUDE LONGITUDE FREEZE ON" which shows as 0 all the time in my video (I added one bracket too many) but in fact, GSX also set this simvar to 1 as soon as the tug starts being connected with the other two FREEZE variables.
Just in case you happen to rewatch it and get confused by this difference.
Anyhow, yeah I think with the limited options to debug everything it's probably as good as it gets for now and to be honest more than good enough from those few tests I was able to do. It's hard to repeat them since you always need someone else's time to see what actually shows up on the other side.
For completeness sake:
-
And as a last datapoint, thanks to Ashley we could test the fix with xPilot on the remote side too, all good. Smooth, no jumping, accurate representation of position and attitude on the remote side :)
-
This workaround will be in the public release of vPilot scheduled for March 1st. I'll let the devs of the other SimConnect pilot clients (of which there is currently only one, Swift) know so they can implement this workaround as well if they want.
@rcarlson I cannot wait for March the 1st when these crazy pushbacks are no more! I would like to thank both yourself Ross and Copper for this diligent analysis, and resolution, of the issue.