virtuali

In almost 13 years, since it came out in 2013.

Are you using the Fenix ? If yes, disable the automatic jetway option in the EFB. A pushback that can be stopped from the MSFS ATC is NOT a GSX Pushback, so this issue is completely unrelated with GSX, that doesn't use or call anything from the standard Pushback system.

It was like this years ago!! And users begged to change it so the direction could always be decided at the very last moment, this way you could comply with an online controller giving you another direction after the tug was connected.

No, that's correct: Windows has *two* default audio devices: - the default "main" audio device, this is the one that it's used for normal windows audio. - the default "communication" audio device, this is the one used for microphone, headphones, etc. They might be or not the same, and changing the default windows main audio device won't automatically change the communication device, they are separate settings. By default, GSX assigns: 1) the Outside sounds to the default Windows MAIN audio device. 2) the Comms and UI sounds to the default Windows COMMS audio device. So, if you have configured speakers as the default main device in Windows, and headphones as the default comms device in Windows, you'll gear GSX vehicle/outside sounds through the speakers and the GSX spoken voices and other UI sounds through the headphones. But that's just the default assignment, which you can change, so you are not restricted to GSX having to use the same settings as in Windows, which might or might not be correct.

I understood you perfectly: I just used your post related to Vatsim as an "anchor" to explain what really happened with that in-famous issue that resulted in users pushing with GSX being seen with the airplane completely pitched up/down by other Vatsim users, which many assumed to be a GSX bug, when in fact was just a result of the combination of the sim not freezing the acceleration variables when the airplane is frozen, and the vPilot client relying on the acceleration data to predict the attitude of the local representation of other players.

"Bloated" ? Let's see: - Models ? Almost every GSX model is full optimized using up to the maximum number of 8-9 LOD levels allowed in the sim. Lots of well regarded airplanes out there don't even use *one* extra LOD: they are full loaded at the max detail no matter the distance. Most of the AI traffic packages out there (similar in modeling to GSX vehicles) use 3-4 LOD at most. This because adding extra LOD requires lots of extra work, and you must do it again every time you update the model, that's why they are not used as much as they should. But we don't mind the extra work, because performance is extremely important for us, even if 90% of the available memory is already taken by something else. - The thing that might affects fps more in GSX are Seated Passengers. That's precisely why they are not enabled by default, it's your choice to use them. Something like Pushback, for example, doesn't have any impact compared to the default Pushback. - Startup time ? Yes, GSX affect Startup time, exactly like any other large collection of AI models with many liveries and what affects startup time is the huge number of operators, almost 700, which multiplied for all vehicles results in ten of thousands of new objects added to the sim, which affect the startup time. However, you are not forced to install ALL 700 operators: there's an extra Livery Manager utility that comes with GSX that can be used to create customized sub-sets of operators for the areas you fly the most, and reducing operators has a big effect in reducing the startup time. - Code performance ? GSX runs completely outside the simulator, so its code cannot possibly slow down the sim in any way, because it runs as a separate process in a different thread so, any calculation in GSX regardless how heavy it is, cannot affect the sim own fps, this is enforced at the OS level, which will automatically assign GSX own separate threads to spare cores of the CPU. - Code safety ? Fact GSX runs completely outside the sim, makes it very safe compared to how it would have been if it was running in-process using WASM. And you don't have to take my word for it, making add-ons using external .exe is the suggested method in the MSFS 2024 SDK: https://docs.flightsimulator.com/msfs2024/html/6_Programming_APIs/SimConnect/SimConnect_SDK.htm As Microsoft/Asobo wrote: So no, GSX is not bloated, its modeling it's extremely optimized, its impact on fps is very low and can be easily controlled, its impact on startup time can be controlled, and it's coded using the best practices suggested in the latest MSFS 2024 SDK for both performance and safety. I can fully understand you might have a bad experience at start, because MSFS 2024 *itself* had lots of issues that affects GSX. At a certain point, it was found even the most basic Simconnect "Open" command (which every app must do to start connecting) was leaking memory at each call starting from a certain update of the SDK (this was discovered by the author of Air Manager), with SU4 a bug was introduced in the programmable Tooltips GSX use to write messages on screen resulting in truncated text (fixed in SU5 Beta), during the SU5 Beta, a couple of version had ALL wheels animations INOP (affecting GSX and things like FSLTL), but both the sim quite different compared to how it was a year ago, as @Noel witnessed so, while I understand you might have found issues, GSX itself today is also very different than it was a year ago.

about Vatsim, I would like to clarify the problem with GSX been fixed a long while ago by Ross Carlson, author of vPilot, with a vPilot update. The real cause of the problem was: - GSX must freeze the airplane when using a towbarless tug that raises the front gear. It wouldn't work otherwise. - When the airplane is frozen, the simulator doesn't freeze the airplane body velocity variables. One might say this could be a design flaw in the sim, since I don't see what's the point to keep updating the acceleration variables after the airplane is frozen, but that's how the sim works. - vPilot used a common network optimization method used by online games: instead of sending only the airplane positions, it uses the body acceleration variables to locally interpolate and predict the position for all connected planes, including pitch/bank/heading and since those variables didn't stop and kept their values, the last pitch acceleration caused by GSX raising the gear kept its previous value long after GSX stopped raising the gear, so vPilot was fooled thinking the airplane continued to being pitched up, but it wasn't, since it was now frozen. - After a long troubleshooting process and having tried a fix from GSX side, by constantly rewriting all the acceleration variables to 0 at each frame, which improved a bit but was still constantly fighting against MSFS that also wanted to rewrite the variables, we found the best solution was a fix from vPilot, which was easy enough: if the airplane is frozen, it would stop to use the acceleration variables to predict the plane attitude, and that fixed of planes pitched up on Vatsim when pushed back by GSX using a Towbarless tug.

That's a specific thing that happens only with the PMDG, which has a custom parking brake variable that is not set until *after* the airplane has completely loaded. The issue is, the airplane is *not* completely loaded when MSFS is read to fly (so that GSX could detect that), I think as a PMDG user, you surely have noticed the PMDG has a few seconds of pause *after* the sim is ready, and during this pause, it's initializing all its custom variables, including the parking brakes. That's why, during this period where the sim is ready but the airplane is not, GSX can't tell if the parking brake is on, because it's not On until all the custom variables complete their initialization, taking a variable amount of time, which is the "pause" were you can see the yoke turned and the sim almost stopping for a few seconds.

Another thing that both an aircraft handler or an airport handler can do, based on any conceivable logic, is to temporarily disable certain doors without requiring to update the aircraft profile.

Your request has been granted, exactly 2 hours after you posted it. Check version 3.8.4, out now: Well, in fact we were always aware this was a missing feature, it's just that we had so many other things to do, that is had to be put in the backburner, but now it's finally there.

It's as "aware" as far the SDK provides, with extra data added with an airplane profile.

Yes, this is correct, and the only reason why the aircraft doesn't disappear, it's because you are still not close enough OR the same AI got injected again, so you might not see much difference. Note that, opposite to FSX/P3D, is NOT possible in MSFS to "remove" AIs not created by you ( "you" meaning the app in question ). Or, to be more accurate, no app that doesn't don't any in-memory hacking is capable of removing objects created by simconnect clients other than itself. GSX being 100% SDK compliant and not doing anything potentially dangerous in memory (you can recognize these app when they require an updated *every* single MSFS update), is bound by this limitation. What GSX really does, is "just" *moving* the selected AIs out of the way, which is the only thing it can do, but the AI is still well alive and possibly under control of the creating app. If you are using an AI injector that updates the position of its own created AI at every frame, what is really happening is that GSX will move it away, and the injector will be then put it back in place where the injector assumed it should have been, so you are mislead assuming GSX AI removal "doesn't work", without understanding what is *really* happening.

That's because if you call it when you are not close to the gate, MSFS will automatically refill the same gate with another AI which would steal the gate for you. It wasn't always like this, it's a "feature" that has been added in MSFS in some update, that's why you might assume the GSX feature stopped working. It we tried to outsmart it and keep removing the new AI over and over, not only we would create unnecessary traffic on Simconnect, but by the time you arrive at the gate (but not close enough for MSFS to stop respawning new AIs), you would see AIs constantly being removed/recreated in a loop so we are not obviously doing that. The chance of this happening, of course, depends how many *other* spots are free, how dense is your traffic, you location when you asked for AI removal (affecting how long the taxi will last ) but the main issue is: MSFS will consider the gate "free" to use because it obviously cannot possibly know that you requested it in GSX. It would work only if you used the default ATC, got a gate assigned to you, and then select the same gate in GSX, so MSFS reserves it for you for the whole time.

Nothing PMDG does can possibly hamper how GSX will work with it. In fact, if they had a problematic automation, removing it would only make GSX work better, since the only automation at play would be GSX's one, considering all those weird things happening with doors opening/closing were caused by both automations at play. We even added documented variables that developers can use to *stop* our internal automation, on the assumption PMDG would have a wonderfully perfect automation themselves, so they might have wanted to shut down ours, but they decided to remove it instead. Or, at least, to tell users they removed it, since I can still see several GSX LVars inside their .WASM code for all 737 and 777, but of course I cannot possibly tell for sure it's they have been left there as dead code not running, or they are still doing something. If they remove the GSX profile, it's also better, since we would be sure that, barring any user customization, the profile used is our internal one, that works and well tested.

Give it time, but you'll see lots of incredible stuff being added. This is really next level compared to what was possible with a simple .INI profile or with the extremely limited .PY addition which were just naming decoration.