Has this issue been identified and logged? This happened to me too with MK Studios EFHK, which does not have any of its own VDGS and the profile I've used has always worked before.
Yes, of course it has, as I already explained, there's an issue with MSFS 2024 loading the correct ground altitude later, when the flight already started, instead during the loading progress bar.
This can be easily noticed that even default ground vehicles "jump" up/down quickly as soon the flight starts because of this, but since they have some limited physic, they just "jump", but the VGDS is frozen so, if it's created when the ground altitude is not final, it will stay at the wrong altitude until replaced.
The REAL issue is: until now, there's no way to check exactly when the flight starts, because the CAMERA STATE variable doesn't differentiate between the small cinematics before pressing the button and the actual flight start.
This of course has been discussed so many times on MS Devs forum, because it's causing problems with SEVERAL other add-ons, but of course it's easy to always "blame GSX" because you *visually* see a problem with it caused by this, which in turn is caused by the late loading of the ground altitude.
In SU3 BETA, a NEW API has been added to the SDK, called "Flow API", which should report exactly the various stages of the flight, without having to rely on the Camera variables, and this should improve things, because we can now wait until the last moment, when the ground altitude should be finally correct, to create the VGDS, so it should fix this. But first we need to test this, and we'll have to wait until SU3 comes out of beta to eventually release it, because if we rebuild the Couatl engine with the very latest SU3 SDK, it won't work on non-beta versions.
I restarted couatl from the Windows traybar but that did not help, but then when I restarted couatl from GSX menu the duplicate (static?) VDGS disappeared. Not sure if couatl restart from traybar or from the GSX menu are any different, so is it just the sim (I'm on SU3 beta) ignoring the command and it just took two tries to get the command through?
They are exactly the same call, the only difference might be you just caught a moment where Simconnect was less congested by traffic, so the command GSX surel sends to remove the object, wasn't ignored.
Note that, the static object is not really "removed", because removing/creating objects can create a small stuttering, and once the VGDS goes back to Inactive, we'll need the static one again, so instead of removing it, it's temporarily moved 1000 meters under ground, so there's zero stuttering involved in the object removal/creation, so it's possible THIS is the call that is not working, so it's possible we might find a different workaround.
