virtuali

Could be you are using the menu in the wrong way ( closing it from the toolbar instead with the hotkey ), so the menu is disabled, and you don't see what GSX is trying to tell you, which would be the confirmation for a good engine start, that normally comes out as a menu after pushback, but if you closed the menu, you'll lose all the subsequent pop-up and text messages, so you don't know what GSX is waiting for. A complete explanation of this, with all the reasons and suggested workflow, starts a Page 113 of the Manual, the chapter named The GSX Toolbar Menu

But you still have either FSX or P3D installed (or at least their keys still in the registry) , and the installer can't possibly decide if you are still using any of these, it only checks that, if you have either FSX or P3D still installed, you must install SODE or update it if it's too old. When you got that message, the installer used to open the SODE website, but this function has been removed because the SODE website has been down for a while so, it's up to you find a downloaded version, which you had.

Of course it was installed. Or, more likely: you had very old version which you haven't uninstalled correctly, so the SODE registry key was still in your registry, so the Installer that checks everything that can possibly cause issues, as alerted you to either remove it or upgrade it.

Of course the new installer asks for a code as well. NOTHING changed. The activation with the license.xml is an EXTRA option that has been added recently which can be used by either those that don't want to type the key, or those that perform an offline activation using a different PC, or a phone. So you can either type a key or use a license.xml file, it's your choice so yes, it can't be easier.

Clarification: although obtained with different methods, the end result was the same in MSFS 2020 and FSX/P3D: automatically, you would only get the default jetway at default airport. The only difference was the jetway in FSX/P3D was handled by SODE, so it worked better. In MSFS 2020, they would "just" look better (better modeling, more styles and many operator logos), but they would still work like standard jetways, with all their issues. If you wanted to replace jetways in 3rd party airports in FSX/P3D, you had to create an airport profile so you could replace them with alternative jetways provided by GSX. This new system doesn't have anything in common with the previous two, but it combines many things at once and new things never done before, and it's the result of years of experience working with jetways: It will automatically replace all single jetways at default airports, that's the easiest thing. These will not just look better, they will work better, because they would be controlled completely by GSX. It will automatically replace all single jetways at ALL 3rd party airports. These will look exactly like they were before and they will work better, also completely controlled by GSX. There's ZERO work required on the developer's side and ZERO work on our side, so it's not like Seated Passengers where we have to manually create individual seating definitions for each airplane. This is all automatic and require no user intervention other than clicking a Refresh button in the installer, when you install a new airport. It will automatically replace the 2nd and 3rd jetway (I don't think 4 jetways per gate exists, but we are ready....) at ALL 3rd party airports that have modeled them as a separate Simobjects. Again, zero dev involvement is required, zero support from us is required. For those airport that modeled 2nd and 3rd jetways as Library objects, so they are not registered as proper SimObjects in the sim, in this case only there will a need for a GSX airport profile, which will define exclusions for the static jetways and a replacement, which can be EITHER the original dynamic Jetway that was supplied with the airport OR one of the many models that will be included with GSX. This is the only case where it's not automatic and requires some configuration. Everything will be of course completely integrated in the whole GSX system: Passengers will walk through them, all existing airport profiles that defined custom pre-jetway walking points or even more complex stairs+jetway mixed boarding systems will still work, even the invoicing system will be aware that yes, if you decided to use 2 or 3 jetways, you will be billed at 2x or 3x the normal rate for a single jetway, and yes there will be a menu asking which jetway you want to dock to which door, with a anti-crossing prevention system, but also an auto-dock option that will chose automatically. The jetway hood animation, while still working following the SDK rules, will also work better, because not only we have a default solving method that already gives better results than the standard in adapting to the airplane shape, but we'll have the ability in the GSX Aircraft Configuration page, to edit the individual bending points for each door, so you can tweak those and make the hood adapt perfectly to every individual airplane shape at every door point, and this will just be saved in the normal GSX airplane profile.

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.