I mean, programs need to be compatible with OS, not the other way around. Hopefully GSX devs can figure out something.
That's precisely the wrong approach to a problem: if a Windows update has a bug that caused problems to a program that worked fine before, it's Microsoft that should fix it, and in fact that what usually happens when a Windows update cause problems to any 3rd party program/games, and this happens.
We surely can't fix Windows updates, you might have had a point if Windows had major changes that would require ALL developers to fix or change something in their code, but if this happens (an intentional breaking change in Windows, not just a Windows update bug), they alert developers very well in advance, with clear instructions how to deal with this.
But that's not even the point: the "developers" Microsoft should alert about this, are Asobo, not even us, because as far as Simobjects movements are concerned, we only interact with the simulator through Simconnect, it's the simulator that will then eventually interact with Windows so, if because of a Windows KB update, Simconnect has become less responsive or it introduced some extra lag, IF this is not a KB update bug and it CAN be fixed, it can only be fixed by Asobo, if possible.
But that's not even the point too: I DO have KB5031904 installed in Windows 10, and all the multiple videos I posted to show I have no stuttering vehicles, were all made after October 26th, when the KB5031904 came out.
So no, it's not the Windows update that caused a problem per-se, at best it's system-dependent.
I'll try to explain it more clearly, so you should understand that there's not much we can do on our side we haven't done already to prevent this:
Simconnect is like a "metronome" for GSX: EVERY movement or animation that happens in GSX, is based on Simconnect CALLING GSX, not the opposite way around, if Simconnect "forgets" to call GSX for 1 second for any reason (os issue, too many addons, hardware issues, anything), you WILL see all GSX objects stopping for 1 seconds, that's it.
And no, before somebody would suggest "can't you run your own clock instead of relying on Simconnect calling back", this won't change much because, if we reversed the task of who's the "metronome", since in that case GSX would have to always call Simconnect back (to set the variables to animate/move things), even if GSX internal timing was 100% steady, if Simconnect is laggin on getting our data back, it will be exactly the same: if Simconnect is lagging for any reason, there's just nothing we can do to prevent that.
Because, again, it's the sim and Simconnect that are directly related to the relationship with Windows itself and the simulator's own engine. Other than sending commands to Simconnect, and trying not sending them too many at once, there's nothing else we can do, other than HOPING Simconnect is not lagging, and if the lag is caused by a Windows update, there's just nothing we can do, the only ones that can fix that are either Asobo (assuming they CAN), or the Windows team who made the update.
