virtuali

GSX reads the only thing that can read: the sim official variables for the engines. Some airplanes use a custom engine simulation that normally is supposed to sync their internal variables with the standard ones and sometimes they might fail to do that, or take longer than usual, especially when starting from a specific state (like cold and dark) so when you call GSX the standard variable (which is the only thing GSX can read) is still reporting the engines running but you might just open the menu again later and it would work, assuming the airplane completed its job properly in time.

Yes, this is in fact a bug, it doesn't work on first spawn but if you press shift+c twice, it works. Will be fixed in the next update, of course.

That's one method, but it's not the normal one and it's a side effect of the still unknown reason why on your system the direction menu doesn't auto-popup, which normally does if the toolbar menu is not completely closed.

You can't do it from the installer anymore, it's done only from the menu, by double-click on the hotkey in the menu, left of the gsx logo in the black band.

I checked again, with the Fenix, and it works as expected: If the GSX menu toolbar is closed (dark icon), the pushback direction won't pop-up, which is normal and is as it always was If the GSX menu toolbar is only hidden (light icon), the pushback direction pops-out automatically, exactly as it always was. I'll see if we can use the same method to make the hotfix work with the menu closed, to pop-up menus, but I can't say right now if it's possible.

It's installed automatically, you must have the current GSX update. Of course, if you use an airplane with a custom EFB, you must open the 2d version of the EFB and it won't show in the airplane 3d EFB like it does with planes using the standard EFB. However, integrating the GSX menu in a custom EFB is so criminally easy (as in a couple of lines of code, since all the work is done by the GSX remote web server), that I expect every developer using a custom EFB would add a GSX page shortly.

You can say it "over and over" but, it doesn't change the fact: GSX opens pop-up menus automatically when the toolbar menu is hidden (not closed) GSX won't open pop-up menus automatically when the toolbar is closed (not just hidden) This is exactly as before. The ONLY major change from previous version is that now, the hotkey would always work, even if it's fully closed but pop-up menus would still require the menu to be just hidden, not closed. Of course I re-checked it again and again just to be 100% sure, because before posting anything, especially in reply to someone reported a possible bug, I always verify first. So yes, I can confirm that, if the menu is only hidden (not closed), the Pushback direction pop-up comes out automatically, exactly like it always did. Now, why it doesn't for you (and from your description it seems "random") ? No idea, I doubt it's another add-on. If GSX crashed that might happen, but I guess you would realize if it crashed. Note that, if you open the GSX EFB app, the toolbar menu WILL be closed (completely) from GSX itself, this is of course normal and intentional, so you won't have the normal menu pop-up together with the same menu in the EFB each time you act on the EFB version of the menu so yes, in this case, it's GSX that would auto-close entirely its menu, for good reason.

It will always open automatically if you didn't closed it from the Toolbar. Nothing changed from before. It will still open automatically if you didn't close from the Toolbar, and it won't open automatically if you closed it from the Toolbar, there's nothing "random" about it. If your airplane uses the standard EFB, I suggest using the menu from that, it's completely removes any of these doubts caused by not remembering how you closed it last time. That's not correct either. If you close the direction menu before the timeout expires, you would always get the Continue option when you opened it again.

Maybe I should clarify menu usage better: ALL menus have an automatic TIMEOUT, which changes depending on context, longer for normal commands (default 30s) and much shorter for things that you might also want to skip without confirmation, like the operator selection. This means, if you open the menu and don't do anything for more than the timeout time, the menu will hide and you'll have to open it again and, in case of the Pushback, you'll use the Continue pushback option, to continue where you left. What changes is HOW you re-open it: with PREVIOUS version, before the EFB update came out, IF you closed the menu from the Toolbar instead of the Hotkey, you had to open it again from the Toolbar, because the hotkey didn't work after the menu was closed from the Toolbar. AFTER the EFB update, the hotkey works even if the menu is closed, that's the main difference but, if you let the timeout expire you would still have to open the menu to CONTINUE.

I suggest you look at the native flightsim.to integration in GSX, in the Additional Services: It comes with an integrated browser for flightsim.to and downloads, uncompress and installs a profile Before a profile is installed, it will check all its parking spots against the data GSX has loaded from the actual airport, and offer a reports about the profile, with how many parking spots are matching. Based on the matching report, you can decide to install it or not. If it's reported as a Perfect match, you can be sure the profile is good to be used for that airport. If you see lots of parking spots not matching, it's possible the profile might not be good for the airport, either because the scenery has been updated (common when the airport has a 2020 version and a 2024 version), or because it might have been made for a completely different version of the same airport. If you accept to install it, the profile will be loaded by GSX automatically without even a restart of GSX All of these inside the simulator, without interrupting a session, no restarts required at any time.

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.