virtuali

At least somebody remembers what we did years ago (maybe 8, but still...), although 10 years ago we made a fully walkable control tower at KMEM, with walkable stairs, a working elevator (with elevator music) and the tower with full 3d interiors, 3d sound effects, etc. However, and this says it all: the most groundbreaking feature, never seen before, and still as of today still never seen on any airport, at KORD, were the working monitors in the terminal showing the actual AI airplanes with Departure/Arrivals complete with the airline logos, dynamically updated with zero cost on fps. This was an incredibly hard thing to do, since it used pure DirectX 11 c++ Render to Texture, only possible in P3D with an extremely advanced and ultra-fast rendering, which also had working panel info outside the gate. THIS was the true "10-years ahead" feature. And yet, the only thing that got remembered, was the fast food girl.

The update process is spread now between GitHub and Cloudflare in this way: Important files, those that might cause errors if you are not fully updated, the core of GSX code, it's entirely on GitHub, no Cloudflare. They are basically the same files included in the Offline Installer. The rest like models/textures is still on Cloudflare, since they are less critical and the worse it can happen if your local node is stale, you might see pink textures of new operators. We decided to make this change after we got evidence that some ISPs (a major ISP in Germany, one in the UK) were actively blocking Cloudflare, very likely for monetary reasons and/or don't wanting to join Cloudflare bandwidth alliance. In another case (another ISP in Germany), Cloudflare nodes stopped working because of an configuration error on that ISP part, which which would never discovered, if it wasn't for a smart user that instead of blaming us for the problem, really got to the bottom of this, collected evidence, reached out to his ISP support, and they finally found the problem on their side. We don't know if this was also an innocent mistake, but it's clear something was going on with some ISPs and Cloudflare, which is what likely prompted Cloudflare to develop their own free VPN, which disrupted the VPN market and, in turn, caused a stir by many Youtubers that gets lucrative sponsorship by commercial VPNs, but I'm getting political here so, let's stop... The point is, it was clear we couldn't fully rely on Cloudflare, no matter what we did, so we moved the important files, the ones that must be updated during an update, to GitHub. Why not moving everything to GitHub then ? Well, GitHub is still a CDN, just a different one, so it's not 100% guaranteed it's completely immune from replication delays and/or possible local problems on some nodes and, just like Cloudflare, the nodes replication is completely outside our control. However, the big difference is that GitHub doesn't work like Cloudflare, (which downloads fresh files from our server when somebody in some area requests them, triggering a refresh of that node). Instead, it requires us to push a release on it, which we do at the same time as we released it on our server, but they never talk with each other, it could even work without a server, which in this case it's just a backup, so a possible element of failure (local cloudflare node failing to contact our server when somebody ask a file), can't happen on GitHub, but still it's a system based on many nodes auto-replicating, because that's how CDNs work. So, while I'm sure GitHub should work better, we'll wait a bit before moving everything there, that would be also reckless and risky.

If you are using the Fenix, it's because you enabled Auto-select ground handling agent in the EFB

The new UI makes quickly seeing what you choose way easier instead: The classic menu only changed a text so, for example, if you called catering, it would change "Request Catering" to "Catering requested", so you had to spot a change in the text. The new menu, instead, in addition to show the same text, it will also change the service icon color, from white to green to show the service is being performed, and to yellow to show the service is waiting from some other service to complete so, not only you have the same information as before, but now you also know what is happening and why something is not arriving soon (waiting for something else to complete) And it's not just that: the classic menu was STATIC. If something changed in a service, you had to close->open the menu again to see a change. For example, the number of passengers boarding or the amount of fuel being loaded, none of these were updated in the menu in realtime, you had to close/open to refresh the values and the text saying what is happening. The new menu, instead, is DYNAMIC, you'll see service progress even with the menu option, which refreshes without any need to close/open it (you need yesterday update 4.0.1 for the dynamic refresh). That's why the new menu is way better than the old one, precisely to see what you selected and what is happening with the service.

So you know the going back to the old UI for which we were chastised for looking like an VAX terminal menu from the 70' is a downgrade...and yes, you CAN go back to it, it's called Classic Menu in the Settings.

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.