FSDreamTeam forum
Products Support => GSX Support MSFS => Topic started by: davidcherrie on April 27, 2025, 04:11:03 pm
-
On first load of the sim at a gate, the docking systems always spawn at the incorrect height than what is saved.
To fix, need to restart Couatl all the time.
-
Know issue with MSFS 2024: the correct ground altitude is not loaded until *after* a flight started (instead of slightly before, as it should be), which affects default ground vehicles too, which "jumps" when spawning.
-
Also get multiple docking systems spawn on load as well.
-
Also get multiple docking systems spawn on load as well.
That doesn't happen. It might be the profile though, setting two vgds from different parking in the same spot.
-
It's not the profiles, I create all my own profiles and this happens sometimes when spawning in. It's not duplicates.
Why not re-spawn the docks when you first click the menu to board/deboard/catering etc? That way they will ensure they aren't duplicates or in the wrong position.
-
Why not re-spawn the docks when you first click the menu to board/deboard/catering etc? That way they will ensure they aren't duplicates or in the wrong position.
That would be the a "solution", but it's the wrong one, because the whole point of VGDS, is they are supposed to spawn (in static version) as soon as you go to the airport. We might kind of "fix" it by setting again the ground altitude after the flight loaded, but they will still look bad "jumping" on you.
You can SORT OF simulate what you are asking, by disabling the option to create Static VGDS in the airport profile Details. This way, no VGDS will be created until after you select the gate.
-
Also get multiple docking systems spawn on load as well.
That doesn't happen. It might be the profile though, setting two vgds from different parking in the same spot.
Again, another double spawn so "it does happen". It isn't the profile either. Attached is the log.
-
Happened again. Am guessing its to do with the incorrect height loading, then when you trigger a service it spawns a new one.
-
Happened again. Am guessing its to do with the incorrect height loading, then when you trigger a service it spawns a new one.
And again, it doesn't. It's NOT spawning a new one, there are two different VGDS in your pictures:
1) the static one, which is just the casing with no text, which is created before you activate the service
2) the dynamic one, which is NORMALLY (that's what happens here, for sure) created at the same position of the static one and, after about 1 second or less (to prevent pop-ups), the static one is removed.
So no, the issue is not GSX is creating double VGDS but, instead, why in your simulator, the command GSX surely sends to removed the static version has been ignored.
-
The problem in my simulator? Really, you're blaming Asobo for your program not working? That's rich.
-
So no, the issue is not GSX is creating double VGDS but, instead, why in your simulator, the command GSX surely sends to removed the static version has been ignored.
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.
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?
-
The problem in my simulator? Really, you're blaming Asobo for your program not working? That's rich.
Because we all know MSFS 2024 is absolutely perfect and has no bugs whatsoever, right ? THAT'S "rich", in fact.
-
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.
-
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.
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.
Thank you Umberto, I really do appreciate your thorough explanations of things. I'm not here to blame GSX, but to identify and debug issues so they can be fixed. I never encountered this before SU3 beta so I'm very happy to blame Asobo for this one :)
-
The problem in my simulator? Really, you're blaming Asobo for your program not working? That's rich.
Because we all know MSFS 2024 is absolutely perfect and has no bugs whatsoever, right ? THAT'S "rich", in fact.
Please, you tell me "that doesn't happen". You've got great support etiquette that you blame the users and it can never be GSX's fault.
-
Please, you tell me "that doesn't happen". You've got great support etiquette that you blame the users and it can never be GSX's fault.
Of course it doesnì't happen here, but that doesn't auto-magically mean it's YOUR fault. Fact is not GSX fault (it clearly isn't, otherwise it would happen in MSFS 2020 as well), doesn't mean it's YOUR fault either. You just can't accept the simulator HAS issues?
-
The amount of times you tell users that "it can't happen", "no one else has reported it", "no that is not GSX fault" all when they are reporting a problem is severely condescending.
-
The 3.5.3 update now has the docking systems spawning on the ground in 2024... And no it is not the profile.
-
The 3.5.3 update now has the docking systems spawning on the ground in 2024... And no it is not the profile.
I can say the way it "doesn't happen here". In a way, it does happen, but surely not as severe as in your screenshot. Yes, I can replicate a very small difference in height in some airports (FSDT LSZH), the STATIC docking system is created a few centimeters below the normal height, but it gets immediately correct as soon you open the GSX menu.
When debugging this, to fix the problem with the fonts going up/down which is now fixed and you completely ignored, the real reason is that MSFS 2024 is reporting the ground height to be continuously changing for a few seconds *after* the flight loads. As in: if we read the ground altitude for 3-4 times in a row, we get different values each time.
With the font, the problem was fixed because we could just re-read the altitude again and clear the screen before drawing any text, but with the static is a bit more difficult, because the static is supposed to be there *before* you even start a flight so, even in the best possible case we might improve on that, you would STILL see the static docking jumping in place as the flight starts.
And guess what, that is exactly what default ground vehicles do (with no GSX involved) when you start a flight! They jump up/down but, because they have a physics and ground contact points, they jump and then settle down on ground. The static docking system is static, so it just stays there until is replaced by the dynamic one.
So again, we'll try to improve this because, I always saw very small differences so it looked tolerable, I never seen such big difference. And no, the 3.5.3 update hasn't changed ANYTHING in the way the STATIC docking system is created, the fix you decided to not noticed was JUST about the TEXT, this would have happened even before the update.
We'll obviously look into this separate issue, of course.
-
I hope you spend as much time looking into problems and fixing them than over explaining them. I don't care what you do, just make your program work properly and reliably.
-
I hope you spend as much time looking into problems and fixing them than over explaining them
It's really striking how many factually wrong information you have been able to put in a single sentence, not even including the always condescending and tone. This sounds even more wrong after working for a whole month releasing a massive update with tons of new features AND fixed.
And no, I'm not the one programming GSX, I'm PART of the team and I'm not even the main programmer, but something has to explain things, that's why I "waste" my time explaining things, which doesn't seem to be appreciated.
So, I'll issue the standard "I'll forward this to the programmer", because this is what will really happen. There goes the urban legend that GSX is just me.
-
Then you’re explaining things to the wrong person and explain it to the people who can actually do something about it. Don’t be like the Mathias Kok of FSDT.
-
Then you’re explaining things to the wrong person and explain it to the people who can actually do something about it.
If you think you don't need or even deserve an explanation, why you posted here, which is precisely the place where you are SUPPOSED to obtain one. Without even mentioning your unfunded assumption this is not already being discussed with the team, but that's not your concern.
Your concern should have been obtaining an explanation, you got one, and you complained. I guess you would have complained in any case.
-
I don't need an explanation, I'm not looking for an excuse. All I need is "Yep, we acknowledge the issue and will look into investigating it" as the same as any other bug I report anywhere else so that the issue can be fixed and the program works as intended.
Instead when reporting an issue here it feels like stepping into a boxing ring as if I'm touting some conspiracy theory and being gas lit.
-
I don't need an explanation, I'm not looking for an excuse. All I need is "Yep, we acknowledge the issue and will look into investigating it" as the same as any other bug I report anywhere else so that the issue can be fixed and the program works as intended.
You are now complaining of having received a much better service and carefully articulated reply, instead of something that might have been generated by an AI bot.
Instead when reporting an issue here it feels like stepping into a boxing ring as if I'm touting some conspiracy theory and being gas lit.
That's exactly how I feel when you post something using that kind of attitude. Trash-in->Trash-out.
-
Because you instantly dismiss it with ‘Doesn’t happen here. Must be something you’re doing wrong.’ It’s as if you’re taking a bug report as a critique to your work and then writing paragraphs explaining why it isn’t your fault or couldn’t happen when it has.
When anyone reports a bug, we just want it fixed and the acknowledgement you’re working on fixing it. If you’re not sure why it is happening then ask more questions. My experience in technical support is always assume something is broken for everyone then if it isn’t, triage why some users are experiencing it and some aren’t.
-
Because you instantly dismiss it with ‘Doesn’t happen here.
Wrong, again. I said exactly the opposite about THIS issue you are reporting now, I said it happens, but I never seen that much difference.
You are confusing with the OTHER issue you reported when you open this thread, which was TWO docking systems together. THAT I could never reproduce and I still can't, but the current update should have fix that, because instead of "just" sending the VGDS underground, we are now also moving it away entirely so, not only you are wrong about me saying "doesn't happen here" as a way to "dismiss" a report, but the current update should have proven to you that your issue HAS been taken care of.
Do you still have double VGDS now ?
-
I haven’t even completed my first flight yet after updating GSX and this is the first thing I saw with it sitting on the ground and the pink missing textures over every ground vehicle. I didn’t get to surveying the area to see if there was another several metres because I was more preoccupied with documenting it.
-
I didn’t get to surveying the area to see if there was another several metres because I was more preoccupied with documenting it.
So you are now hinting that when I said the double VGDS has been fixed, I'm not trustworthy because it can still happen and you just haven't checked ? Your rudeness (you even call me "liar" in the other thread) is beyond reproach.
-
So I'll ask again:
- Do you still have double VGDS ? Try WHEN YOU HAVE TIME
- Do you still have text out of place ? Try WHEN YOU HAVE TIME.
-
I called you a liar because you quoted me saying something as a justification for the reason you did something even though I said that quote after you did it.
-
I called you a liar because you quoted me saying something as a justification for the reason you did something even though I said that quote after you did it.
This sentence doesn't make any sense to me. I never called YOU a liar, instead, regardless of the amount of factually wrong informations you spread here.
-
There is a difference between different points of view having different experiences with software bugs to flat out lying by taking sequence of events such as posts as justification of your wrong assumptions when those posts hadn't been made yet.
A > B > C
A = You tested 2020
B = I brought up 2020
C = You said you tested 2020 because of what I said at time B.
You're saying: B happened before A which it didn't hence why I called you a liar.
-
There is a difference between different points of view having different experiences with software bugs to flat out lying by taking sequence of events such as posts as justification of your wrong assumptions when those posts hadn't been made yet
What you say not only doesn't make any sense, it's not related to this in any way. I'll make it simpler:
- You opened this thread reporting double VGDS, I was never able to replicate it.
- You came back with it, reporting a completely different issue, the wrong initial height.
I just asked:
- Do you have double VGDS NOW ? You replied you don't know, because of course you don't trust it was fixed, because it would then clash with your narrative that I ignore problems that I cannot replicate.
- About your new problem, me acknowledging that I CAN replicate this, albeit not as severe as in your case, also disparage your statement I always say I can't replicate something. I'm not, I always say exactly what is happening.
BOTH issues clearly show how wrong you were saying I don't acknowledge issues, the 1st because the problem I couldn't replicate HAS been "fixed in the blind", clearly proving that even things that cannot be replicate ARE taken into account and end up in actual fixes. The 2nd is undeniable: I literally said it does happen here, what else you want ?
-
Let's get somethings cleared up because again you're confused and mixing up the timeline of actual events.
- You opened this thread reporting double VGDS, I was never able to replicate it.
Actually I opened this thread on 27th April about the docking systems spawning at wrong height hence the title "Docking Systems Spawn at Wrong Height". You said "Know issue with MSFS 2024"
- You came back with it, reporting a completely different issue, the wrong initial height.
No, that's what I initially reported and created the thread. 2 days later on April 29th I then also reported that double docking systems were spawning and posted a screenshot and you said "That doesn't happen." I then posted more examples on May 15th and May 21st.
On May 22nd you then admitted rather weirdly there was a problem that it isn't 2 spawning, it is one spawning, then isn't de-spawning when the second one is spawned. Tomato tomatoe... essentially the Obi-Wan explaining to Luke how "Darth Vader betrayed and murdered his father" was true, from a certain point of view.
It took three screenshots from over 3 weeks for you to acknowledge the problem after saying "That doesn't happen." I don't yet know if the issue has been fixed until I do more flights with GSX. I didn't notice if there was a double one when I started the 6 hour flight I'm currently flying which shows the docking systems spawning at the wrong height hasn't been fixed which is what this thread is about.
-
Actually I opened this thread on 27th April about the docking systems spawning at wrong height hence the title "Docking Systems Spawn at Wrong Height". You said "Know issue with MSFS 2024"
Fact you chosen the wrong title for the issue doesn't change the fact your first issue WAS having TWO VGDS stacked on top of another, which is not the same of having only one of them at the wrong height.
Now you have a different issue. Or, maybe, half of the problem is gone (the 2nd VGDS), because opposite of what you keep saying, even things that cannot replicated, ARE taken seriously and fixed. I'm sure we'll fix this one as well.
Other users has thanked us for having fixed the 3rd problem with VGDS, which was probably the most annoying, the text corrupted which forced a GSX restart on every flight. Another FS2024-only problem, which nobody as "dismissed", but was taken care of when feasible in this update.
I'm closing this thread, will be opened again when there will be other news about this.