virtuali

I should clarify this: there's nothing special in SU5 that made this possible, just tiny details that are allowing to work in a less messy way, but that's not the real bulk of it. In fact, we could make it work in MSFS 2020 as well, but we decided not to, because It would force us to maintain two set of models, two separate build processes, extra tools working in different ways depending on the sim, with the likely increased chance of bugs caused by having to do that, and MSFS 2024 user which are now the majority, rightly complaining they deserve a native product, because we are not even saving or even converting the not-so-old set of jetways we already had in MSFS 2020. Everything will be redone from scratch, from modeling to texturing, clean slate, no leftovers, no conversion, nothing. Going MSFS 2024 only it's only logical, because it makes many things easier for us. So no, multiple jetways are not coming because some new magic in SDK, those small changes we nice to have, but they are not the main thing. I would rather say it was an inspiration that came up discussing between FSDT how we could fix the main problem that, if we had a new custom system that would force developers to learn some kind of SDK and have to remodel or just re-export their existing jetways, it would never caught on. No airport developer would want spend any time working at something that 1) requires a payware product to work 2) might be useless if one day MS/Asobo would finally decide to support this natively. That's why we didn't do that 2 years ago and why I always said this was the main reason for not doing, not a technical one, it was the "no developers will follow us" issue. Instead, we found a way that, not only doesn't require developers to do any extra work to support it, but it's very likely that, if a real native system would ever arrive from Asobo, we would likely be able to enhance that one too, since I wouldn't expect a total change in the system, but rather an extension to support more than a jetway per-gate and, if anything, it they ever did that some day, it would make our work even easier.

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.

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.

I'm not exactly sure what sounds you are referring to, exactly. It seems you are referring *just* to the pilot good engine start confirmation, that seems like a very little and nitpicky thing to put in 1st position, those are the only voices for which a variation exist (accents and variations within the same accent) and the reason why is not there, it's because we want to do it properly, since that's *your* pilot voice, so it shouldn't be simply a part of the regional voice system driven by the ICAO, but it should have some kind of global setting where you can set your own preferred voice and accent, unrelated to the airport you are flying it. The "Continue Pushback" is there precisely for those that keep close the menu with the toolbar, so they won't lose the pushback in the middle. If you are sure you didn't do that, it must happen for some kind of accident (maybe it restarted automatically), but it's NOT how GSX normally works. If you have the menu active and just hidden, the pushback direction WILL pop-up automatically. Well, unless you let the 30 seconds timeout expire: if you see didn't notice the pop-up, it would have disappeared after 30 seconds, requiring reopening the menu to "Continue". I can't believe I need to explain this. The message ("garish" or not, it's obviously subjective), it's NOT preventing GSX from working!!! It's just a text, you can ignore it or not, but your current session will continue *exactly* as before, just with the older version. No need to shut down MSFS, at all. And I'm sure you noticed the different level of quality, because most of its animations are "in place", so they are not combining manual animation + procedural movement, at least not while the guy is idling. Add-on don't have the same options available to the SubtleTaxiRibbon: we can only create Simobjects through Simconnect, with great attention to their number, in order to be sure we not only create too many of them, but also because of the extra latency due to having to individually set their position, heading *and* altitude over a possibly sloped terrain. So, less objects, which must be larger in order to be seen. The simulator internal functions, not accessible to us, don't have to call Simconnect, don't generate extra traffic on it, so they can do things we can't.

It's not that I don't "believe" anybody, is that before saying it insert the payload wrong, and being sure it's GSX that is doing that, one should provide so kind of proper report. In this case, just a log might not be enough because a log would only indicate if GSX read the data wrong from Simbrief or possibly sent the wrong data to the FMC. But it won't tell if the issue was instead caused by too much lag so the delay that normally works might not be enough in some situation, of you just had already characters on the scratchpad, which is not something we can really fix automatically, since there's no way with the PMDG SDK to automatically clear the scratchpad. To find if you fell into those TWO last issues, I would probably need a video, or at least a description of what you saw. That is, of course, assuming there isn't a problem in reading the data to begin with, like getting the wrong flightplan, getting the wrong values or sending the wrong values, which is the 1st part of my answer that could be diagnosed with a GSX log.

I'm not exactly sure what we could do more, considering how passengers must work. We already have each passengers animated separately, no two passengers have the same animation (already a huge effort) and that can't be said about any other similar system, both in the default (MSFS 2024) passengers system, but also in other system we've seen in other simulators, where it's clear the same animation has been used for all passengers, resulting in a very unnatural "army of clones" effect when they walk together. The main problem is: passengers needs to be versatile, go everywhere, climb steps, turn over waypoints. This means their animation is PART manually animated and PART procedural, namely the translation/rotation part is made procedurally, since a passenger can possibly walk around the whole airport. While is reasonably easy to make a convincing animation that works "in place" (like the dancing marshaller or the various poses "at rest" of the recent manual stairs operator), when you combine the mandatory procedural part with the manually animated part, there always be some kind of disconnection, since (for example) real people don't make turns in the same way (it changes depending on the turning radius), there's the missing "gait" effect (the translation speed is not uniform across the whole step cycle) because doing this would increase traffic over simconnect quite a bit (having to adjust the speed of each passenger at each frame). As always in GSX, there's always reasons why things are done in a certain way and not as they might be, if it ran under a character-oriented game engine (Unreal, Unity), instead of a flight simulator. Unfortunately, the new procedural character system added in MSFS 2024, is completely not documented, and there are no tools provided to create these new kind of passengers (and if you fill up the default 737 with 180 pax, you'll see how your fps will go down compared to GSX), we think because the character system has been supplied by a 3rd party that hasn't licensed their tools to be included in the SDK.

I don't see why not, the method would change depending how you are getting that data. If you are obtaining historical weather data from an online service, you make an web API call to get it. If the data is coming from an application into the sim, you can call Simconnect directly in an handler to get data from the sim.