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: