We haven't "dismissed" anything, it's just that, before being SURE of why something happens and what is the real cause, I want to first check all facts first because, even if disabling GSX "fixes" the problem, that doesn't automatically means GSX is the cause.
And no, if I say GSX is not the cause, doesn't mean:
- I'm "blaming users", this is just made up and wrong.
- I'm "dismissing" anything.
When any user reports a problem, it's obviously taken very seriously, so first thing is asking about the situation and trying to replicate it. Somebody reported pauses up to 30 seconds on landing at EGLL with the Fenix, so I tried doing that and, of course, I couldn't replicate it:
https://youtu.be/dLzpXSEuTP0This doesn't mean I don't
believe it's happening to that user. And it doesn't mean I'm "blaming" the user either. It simply means that: I cannot replicate it. Period. I would like to ask to take this information as VALUABLE information instead of being taken as a "dismissing" or (even more absurd") as a "blame". Because knowing it's not SUPPOSED to happen it's VALUABLE information to understand the real cause behind it and, to see if we can find a WORKAROUND.
So, for the last time, I ask to stop this nonsense that we "blame users" (never happen a single time), or "dismiss" stuff and instead, take the "I can't replicate it" as USEFUL info for you, and also understand why it might not be as easy to "fix" this from our side, without being able to replicate it.
We have been having doing several tests on the GSX community channel on Discord in the last couple of days, and it seemed the problem happened between 3.5.6 and 3.5.7. We made available an Offline installer for 3.5.6 and an Offline installer for 3.5.7, and one affected user confirmed it didn't happen with 3.5.6 but it does with 3.5.7. Remember, we CANNOT REPLICATE ANYTHING, with any version, so I can only rely on reports by affected users.
Somebody hinted it's the Couat64 .exe "because it goes away if I close it". Well, it's not. Because I asked the affected user to keep 3.5.6 installed, but manually replace the latest Couatl64_MSFS.exe from 3.5.8. NO PAUSES so no, it's NOT the .exe either.
It must have been something we did in the actual GSX code, and the only thing that could have possibly have an effect on this, was that in 3.5.7 GSX will automatically restart after takeoff. Which in fact, should be the very thing that should PREVENT this. By restarting on takeoff, we should have removed the risk that something still running or not terminated properly done at departure, could possibly affect the landing, because restarting cleans up everything with nothing from the previous session still running.
This is just a THEORY (because, again, we are proceeding "in the blind" because we CANNOT REPLICATE IT!!) but, if restarting GSX introduces this problem instead of improving, there might be something else going on which we don't know about the simulator, possibly an undiscovered bug or at least a behavior not consistent with how the sim normally behaves. Usually, when a Simconnect client disconnects and restart, everything from the previous session is thrown away: all Simobjects created by it are automatically removed, all data requests are thrown away, all input events are cleared, it's usually a total clean up.
One THEORY is this clean up might not apply to previous requests of airport data, which GSX normally does when flying to know which airports are nearby, so restarting after take off might not have clean up this request (like everything else normally done on restart) and when you land, all requests of airports nearby made during the flight might arrive all at the same time, because usually the only way to cause a pause in the sim is either creating a lot of objects in a very short time OR asking for a lot of data. We don't ask for lots of data, just the list of airport nearby and when you are close to the airport, the data for that single airport you are landing on. This hasn't changed since a very long time, but MAYBE if the issue is the sim doesn't clear up requests for airports in the same way as it clear *everything else* it's possible that a restart on takeoff might have caused this.
So, today there's an hotfix to try ( run CHECK to get it, the version won't change), which a change: now before automatically restarting, a request to remove the subscription to receive data about airports is made explicitly. We don't have any idea if this works because:
- Nowhere in the SDK they ever said you must do that, so we just assumed the standard behavior that every data request is always automatically cleared when a client disconnects.
- We cannot replicate it! So it's really a shot in the dark.
But since the automatic restart on takeoff is the only thing that changed from 3.5.6 to 3.5.7, that's the only thing we can work with.
However, I want to add that things are not THAT SIMPLE, because if you read here on MSFS forum, a user who spent its time to make a PROPER test, with and without GSX, didn't found much difference, but he surely noticed that in ALL cases (even those without GSX!), there are some stuttering on touchdown:
https://forums.flightsimulator.com/t/touch-down-stutters-su16/727324/27And what about THIS user instead ?
https://forums.flightsimulator.com/t/touch-down-stutters-su16/727324/28He has freezes on landing, and he use an XBOX so, clearly, not a chance to have GSX there!
As I've said, the issue is way more complex than just saying "it's caused by GSX", I think there are other things going on at the same time, which for some reasons are triggered by GSX, but without being able to replicate it, we can only TRY different solutions and rely on reports by affected users.
So, try the todays' hotfix now, and see if you see any improvement.
