11 hours ago, edpatino said:

I always have to turn off my antivirus, otherwise the FSDT Universal Updater doesn't work for me. The same happened to me when using P3D years ago.

You don't. And in fact, it would be best if you didn't but, instead, configure it to add the FSDT installation folder to the antivirus Exclusions. If you have Windows Defender, the exclusion is automatically added by the FSDT Installer, but if you have a 3rd party antivirus, you must do it manually.

I've been using GSX for over 10 years and own most of  FSDT's sceneries. My observations are these

- It can be finiky. Most of the time it works as it should, but then sometimes it just doesn't. I landed at iniBuilds EGLL last night, an airport I've flown in and out of dozens of times and for reasons I don't understand, the GSX menu opened and then closed 5 seconds later after simply showing the loading icon. Why? Who knows. But I'm sure had I asked for support on their website it would have been my fault.

-  Innovation seems to have stalled. Yes we got passengers. Great. They walk like zombies and I personally can't stand them. Outside of that, and the addition of new cargo loaders and companies doing ground services, how has the program fundamentally advanced in the past 5 years. To the OP's point - why do we not have timing improvements in loading? I feel that there's plenty of room for innovation. I'm sure Umberto will provide a list and tell me I'm wrong. 

- The ability for GSX to interact with other programs, or, more specifically, for other programs to interact with GSX seems fundamentally difficult. I'm not a developer, but observing conversations other developers have about trying to interact with GSX just seems antiquated. BATC has managed to get GSX gate selection working "most of the time" on arrival at an airport, but it essentially involves opening and operating the GSX menu automatically. Say Intentions have looked at doing similar and advised that they also can't see a way to achieve this without operating the GSX menu system. I know, I know, iniBuilds and others have intergrated the calling of GSX services..... but after so long I would have suspected the program was a little more robust and flexible.

- Lastly, and not related to GSX, I wish FSDreamTeam also continued doing airports. They made some fantastic sceneries for FSX and P3D, but since MSFS the focus seems entirely on updates to GSX that don't, IMHO, fundamentally change the user experience. Their scenarios are aging and there's no sign of life being brough into them.

 

Anyway, thats my view. As a paying and loyal customer I'm entitled to it. I'll now go put my flame suit on and wait for Umberto and some others to tell me how wrong my view is.

 

16 hours ago, MaximumN2 said:

 

Because GSX is pure garbage, it has barely improved over the years. So many things are missing or bugged, but when you report those issues, they always point the finger at others, they never admit to making mistakes.

I think GSX will always stay the way it currently is. It’s a shame, but we really need a new player here. Maybe the rumors are true and Fenix is developing its own counterpart for their Airbus lineup, because we really need one.

A very poor way to resolve a potential dispute with a developer, huh?
Umberto doesn't have a nanny mentality, and if you're looking for someone to tuck you into bed at night, he might not be the right person. But he's efficient, highly competent, and hardworking, and for that, he deserves respect.
Granted, he doesn't have much patience with some people who don't read the documentation or his forum replies, but who could blame him?
When you repeat the same things 1,000 times, it's perfectly human to get exasperated the 1,001st time.
And we all know that there are people among us who don't make much of an effort. They're usually the same ones who complain the most, so the exasperation is easy to understand.
GSX is one of my favorite addons, and I sincerely thank Umberto for his continued involvement over all these years.

Well, I just love GSX.

A lot of people experience issues with GSX because they don't understand how it works, which to be fair isn't their job. The software should never get into a situation where the user sits scratching their head wondering if it's working or not, but it is what it is. It's not poor software, it's really good - it just needs some understanding and *shock* reading of the manual to understand what is going on and why.

However, the attention span of some people nowadays is seriously bad. As an anecdote, I watched someone on a video/stream using my own software complaining about "too many options" and the software not doing what they wanted... what they failed to grasp was that the software actually did what they were wanting BY DEFAULT but them clicking aimlessly through options and not paying attention to what they were clicking on had changed the default behaviour 😂.  Then during the inevitable support ticket they swore blind they hadn't changed anything - despite me pointing to the video and timestamp in question showing them doing it. I would imagine Umberto deals with a lot of the same issues many times a day (and for many years now) so I understand the snark that comes across, especially when solutions have been documented in support articles. People can be... challenging.

Anyway - for me, GSX would improve 100x with two things:

1) have the capability to forget about its own logic flows and simply react to external triggers asking for boarding / loading / fueling. The current remote triggering system is not the best and heavily relies on scanning a file for available options whenever the UI changes. A proper API would be lovely.

2) the capability to separate boarding and loading into two entities so that they can be triggered individually would be excellent

Bonus #3) The ability to reduce fuel from the tanks. Right now If your aircraft starts with 20,000kg of fuel and you only need 5,000kg for your flight plan GSX will just hang during fueling. It should (at least) simply disconnect if it cannot complete the operation.

I've been using GSX in all it's forms now since it came out and has it been perfect?..no. but then I can't name one addon or even sim itself that hasn't had issues. I agree with FPVSteve a lot of the issues people have with GSX stem from the fact they haven't read the manual so aren't using it correctly or another addon is conflicting with it, but then some people can't be told that the issue is their end and not with the product and they need to put a bit of their own effort in to find the issue, because that's not what they want to hear.

 

11 minutes ago, FPVSteve said:

The ability to reduce fuel from the tanks. Right now If your aircraft starts with 20,000kg of fuel and you only need 5,000kg for your flight plan GSX will just hang during fueling. It should (at least) simply disconnect if it cannot complete the operation.

I have had defuelling happen, maybe it's aircraft specific
 

13 minutes ago, FPVSteve said:

Anyway - for me, GSX would improve 100x with two things:

1) have the capability to forget about its own logic flows and simply react to external triggers asking for boarding / loading / fueling. The current remote triggering system is not the best and heavily relies on scanning a file for available options whenever the UI changes. A proper API would be lovely.

 

This is a big one for me. I just wish that GSX was more flexible and had a more robust API (or way of interacting/triggering). That would allow more seamless interaction with other addons. Steve you've done a pretty good job having SLC interact with GSX...or at the very least monitor what GSX is doing. I just get the impression that it seems overly complex and could be made simpler if GSX allowed more interaction. 

2 hours ago, virtuali said:

You don't. And in fact, it would be best if you didn't but, instead, configure it to add the FSDT installation folder to the antivirus Exclusions. If you have Windows Defender, the exclusion is automatically added by the FSDT Installer, but if you have a 3rd party antivirus, you must do it manually.

Thanks Umberto, but the FSDT installation folder is already excluded on my A/V which is Windows Defender, which I manually did anyway, and the only way to make it work and update anything is to turn it off before running the Universal Installer.

3 hours ago, virtuali said:

I already replied to you about the same question you posted on the MSFS forum, but since others here might have missed that reply, I'll copy it here:

GSX already supports the concept of external power (and air) coming from a jetway. However, it only works with FSX/P3D, because there, the jetways were completely custom using SODE, and using the GSX airport profile editor, if you used GSX jetways, you could even customize a jetway to individually enable/disable Power or Air, and GSX even set some LVars so that 3rd party developers could read them and possibly react on their eventual custom electric/air simulations.

However, in MSFS GSX uses the standard Jetway system (because there’s no SODE for it), so what a jetway can or can’t do is very limited, but that’s not really the point.

The point is that MSFS already always automatically flags External Power to be available on a Gate, assuming the jetway would always supply it, even if it does it in a very crude way, by making the external power available even *before* the Jetway is connected, and even if the gate doesn’t have a jetway to begin with.

Take the default 737-Max by Asobo for example, opposite to the default A320 V2 made by iniBuilds, which has *its own* custom (not from GSX!) GPU, the 737 doesn’t have any ground vehicles, so it relies on the *default* ones, and when you spawn on any parking, you’ll see a *default* GPU that “looks” like the GSX one, but it’s not, it’s a default GPU that has its appearance replaced by GSX, but it’s still a default GPU and the airplane has the external Power light active even **before** you call the default GPU using the default ATC Ground Services menu, making not really meaningful to call the default GPU.

That’s the default airplane situation. 3rd party add-ons usually have their own custom GPU OR they can integrate with the GSX one, so they can model the availability of external power in any way they like, so if they decide to link the available of external power to a working jetway connection, they surely can do so, no matter if GSX is used or not, and since any jetway you can see in MSFS is standard, complaining GSX only has GPU vehicles doesn’t make much sense, since Jetways are not supplied by GSX, and if any airplane developer wanted to simulate the availability of External Power to depend on a Jetway instead of a vehicle, they have all the means to do so, usually when coupled with a custom Electrical system.

And what about the baggage conveyors immediately moving away after loading, instead of at least one remaining in place until PAX loading has been completed, as in RL? 

I have a love hate relationship with it, but I do think part of the reason GSX gets flamed so much is that it is one of the only programs that you have to interact with not just once, but twice in EVERY single flight. Most simmers will vary the aircraft they fly and the airports they fly to regularly, but GSX requires interaction from the initial load, through to the pushback and then through to parking up to quitting the sim. 

When it works perfectly, it's really good. Fenix for example managed to automate the whole process so you can just let it do its thing and if you use it with a well made airport profile then there's nothing to complain about. I appreciate the incremental steps over time such as walking passengers, additional voices (although they are definitely subpar now when you hear for example the premium voices from BATC), connecting the tug when boarding commences and the ability to choose airport operators etc.

As much as Umberto gets a lot of flack, I for one am grateful for the fact we have something like this in the sim. I know when I first fired up MSFS upon release the lack of GSX drove me nuts, with no satisfactory options to pushback. 

There are a few things I've always wanted to see to make it more easily customisable - such as being able to choose the pushback tug type (I seem to always get the lift-up type, even at tiny regional airports), maybe even select the type of steps (again I always get the drive up ones, even though I rarely see them in real life) and I'd love to be able to draw a pushback on a map upon load and have it remember it, a bit like better pushback, although I obviously have no idea how feasible it is to integrate into the main program. 

When it doesn't work, it has given me rage quit vibes on more than one occasion in my simming career.......🤣

Edited September 25, 2025Sep 25 by bennyboy75

2 hours ago, KL Oo said:

I landed at iniBuilds EGLL last night, an airport I've flown in and out of dozens of times and for reasons I don't understand, the GSX menu opened and then closed 5 seconds later after simply showing the loading icon. Why? Who knows

You landed at an extremely dense airport, where it's fairly easy to reach the in-famous Simobject limit.

When this happens, first things might start to disappear, but also Simconnect *itself* stop responding. When the GSX menu shows "loading", GSX is waiting for MSFS to call it back through Simconnect, but if your Simconnect broke because of having reached the max Simobject limit (which accumulates over the flight, so it's more frequent at landing), the menu won't load, but that's really more a side effect, the real issue is the communication with Simconnect stalled. Sometimes it can be fixed by just restarting the Couatl engine (because a new connection sometimes triggers a Simconnect "clean up" in the sim), but in the worse cases, it requires restarting the simulator.

 

2 hours ago, KL Oo said:

-  Innovation seems to have stalled. Yes we got passengers. Great. They walk like zombies and I personally can't stand them. Outside of that, and the addition of new cargo loaders and companies doing ground services, how has the program fundamentally advanced in the past 5 years. To the OP's point - why do we not have timing improvements in loading? I feel that there's plenty of room for innovation. I'm sure Umberto will provide a list and tell me I'm wrong.

Well, I already posted a link which analyzed the ACTUAL Changelog in a scientific matter, not biased by perception about how frequently new features are added, but that's not really the point.

The point is, it has been explained so many times why passengers don't move or appear as naturally as they might, and it's a combination of many reasons, none of them having anything to do with "innovation", but all a result of clear design choices taking into account both performances AND flexibility, so let's start with my "usual list" of counterpoints:

- A walking cycle is made by two main components: the in-place animation of the body, and the translation over the world. If you want to have the best possible natural result, you can "just" motion capture the entire animation, and it will look very natural but, of course, it won't work for what we need to use humans for: that is the ability to have people walking everywhere, climbing stairs, making turns, following waypoints, all the flexibility we need to adapt to many different airplanes (not just stairs, but internal corridors as well), create custom walk-in path, etc. To have the flexibility we need, we need to trade the natural motion of motion-captured animations that would only work on a single area, with looped in-place animations for the body, and a procedural translation in the world, that results in a less natural walking appearance. However, it's just not true this hasn't been improved, because it surely has, we know have multiple variations of the walking cycle for each passenger that are randomly selected ever 2-3 steps, so they are not exactly identical, and it's passengers has its animations individually made in appearance, speed and and stride, so they won't look like an "army of robots" had they reused the same walking cycle, which is also a cheap way of "fixing" collisions (if all passengers walk at the same speed/stride, you "fix" collision by simply adding a delay between each one), but we decided that the big increase of workload on our side to make every animation different and the side effect of having passengers colliding into each other was worth to REDUCE the zombie-like effect or the robotic army effect, which would have been WAY worse if ever passengers used the same (or a limited set) of animations.

- Another part of the "zombie-like" appearance, is due to the complete lack of facial animations: passengers have a fixed expression, their eyes are not moving, they don't blink and they don't move any muscles, and this adds to impression of being zombie-like. This is clearly done for obvious performance reasons. The software we use to animate (Reallusion's iClone+Character Creator) supports both eye animation (move/blink) and full-blown facial animations but, eyes+eyelids animation increases the number of Bones in the skeleton, and they are fairly heavy on performances in MSFS (and not LOD-able, since the skeleton must be shared across LODs) and facial animations requires a feature called "Morph Targets" that is not supported in MSFS, but I guess even if it were, it would be fairly costly in performance, because if you load a 777ER with the full complement of 390 passengers, with each one having already 75 bones (minimum to do a believable skeleton: Unreal considers anything less than 72 to be "mobile quality", not PC level), all animated, it's almost a miracle the performance is still acceptable as it is, but we had to *remove* all these fancy features, which are clearly targeted for an character-oriented gaming engine, like Unreal.

 

2 hours ago, KL Oo said:

The ability for GSX to interact with other programs, or, more specifically, for other programs to interact with GSX seems fundamentally difficult. I'm not a developer, but observing conversations other developers have about trying to interact with GSX just seems antiquated. BATC has managed to get GSX gate selection working "most of the time" on arrival at an airport, but it essentially involves opening and operating the GSX menu

About BATC, they contacted me during development of their integration, and the main problem seemed to be they just had to take into account the inherent latency of the system. No, it doesn't involve operating the GSX menu. In fact, the GSX menu can be entirely closed. It's the opposite way around: if an application want to control GSX remotely, it must behave LIKE the GSX menu.

About SI, I can only say we spoke about GSX integration more than a year ago. Still in 2024, Brian told me he understood everything he had to do, and it seemed it could go on. Then I stop hearing from them, and I only learn from their users they first said our "API" is not up to task, and very recently it should be GSX that should call into their own API instead. That was completely news to me, since nobody from SI ever contacted me asking for any issues they had things they lack. I think there must have been a misunderstanding how I should be reached, which is by email, they seem to very Discord-oriented, so they might have assumed the GSX Creators channel is owned by FSDT so I'm always there, but it really isn't: it's Community owned channel in which I'm not even an admin there, and my presence is there only when I have spare time. I'll go there again to understand what issues they are having.

In any case, there are reasons why it works like this:

- MSFS deprecated (in a way that is just not available anymore) the native Simconnect way of creating menus. So we had to change GSX to be controlled remotely by some menu. This can be either the GSX menu itself, but also another app. Users and developers asked for years for the ability to remote-control GSX, but it was difficult with FSX/P3D, where the menu was created by GSX itself, so they were strongly coupled.

- If the application behaves like the GSX menu and acts in a generic way, it won't break if we update GSX with new options, intermediate in-between menus.

- Having to open a file with the menu entries is fairly simple to understand, so it opens the ability to interface with GSX even to non professional developers, using a variety of programming languages. Yes, there might be better alternatives we can use: Simconnect custom client data areas (the main issue here is that is not easy to share STRINGS via Simconnect) surely are a possibility, but they are far more complex to use. MSFS 2024 has introduced a new API called "Comms Bus" that might help, but it's 2024-only, and it's probably too early to add a fundamental change that would discard MSFS 2020.

Nonetheless, any future "API" wouldn't replace the existing one because, again, we don't want to break the code of anybody who took the time to integrate GSX.

Also, I would like to point out GSX integration is not JUST "having an API". There are many ways in which GSX can be integrated in other apps. Has anybody got to have a look at the recent VGDS SDK ? It's VERY extensive and flexible, and it can be customized with two different users in mind:

- End users have an easy to use external app ( the VGDS editor ) which can be used to create customized VGDS messages which can be localized, time-based, airplane-based, airline-based, etc. And it comes with a dedicated manual for the app.

- Developers can write directly to the VGDS .JSON file, and there's a separate developers manual for this where the format is fully documented. I could guess somebody working with Virtual ATC system might want to create an app that could create dynamic VGDS events, use real and dynamic TOBT to reflect delays, etc.

About the "timing improvements in loading", that seems to be like a very MINOR thing that might be changed very easily. I mean: all that discussion about big "innovation", and you are quoting something so minor as a problem ?

 

Edited September 25, 2025Sep 25 by virtuali

I'm baffled by most of these responses. I think GSX is one of the best addons I own. To me, it is absolutely worth the price I paid.

It can be complicated, but what in flight simulation isn't? Everything is complicated, from setting keyboard and joystick assignments to the actual flights.  

I wouldn't fly without it. 

Great work Umberto (and team - if there is one). . Thank you for the continued updates and improvements. 

 

15 minutes ago, bennyboy75 said:

such as being able to choose the pushback tug type (I seem to always get the lift-up type, even at tiny regional airports)

You can already do that: the choice between Towbar and Towbarless can be set in the airport profile, and it's individual for each gate.

Which answers the 2nd questions about Stairs. There's no such thing for stairs, because we don't have as many stairs variations as we have with Pushback  vehicles. Or, more precisely, we don't have enough variations of both types (vehicle or towed) that would cover ALL door's height ranges, so the main driving factor of the stairs choice is just the airplane doors height.

When we'll have enough Stairs models in both variations that could reasonably cover a wide enough range of heights (same as the different pushback styles cover different airplane weight ranges), we might add a similar option like the Towbar/Towbarless choice we already have, but for stairs.

I think I explained many times why the choice will always be generic, rather than being fixed on a specific model, and it's to prevent to have airport profiles that might have issues with future updates. Take the new Cargo loaders, for example, if we allowed airport profiles to include a reference to that specific model, when we RETIRED IT to replaced with a new better looking version, loading an airport profile that might have included a reference to the old model would cause an error due to the object now missing. Instead, by keeping things generic, all existing profiles will still work and will benefit for new models that will continue to be added.

3 hours ago, FPVSteve said:

Anyway - for me, GSX would improve 100x with two things:

1) have the capability to forget about its own logic flows and simply react to external triggers asking for boarding / loading / fueling. The current remote triggering system is not the best and heavily relies on scanning a file for available options whenever the UI changes. A proper API would be lovely.

Ok, your 100x hyperbole looks so prominent, that I really need to understand these better. "simply react to external triggers" is exactly what GSX is doing right now if it's under Remote Control.

The only issue here is the fact you cited  boarding/loading/fueling as 3 separate items, when in fact they are two (boarding and fueling), but they are surely separate and can be called independently so, how exactly an "API" would change that ? An API won't change they way GSX works so, what difference it made if, instead of getting the content of the GSX menu from a text file, you would got the same content, just formatted as .json as part of an API request so, the only possible benefit I could think of, you might have a bit less of latency for not being tied to an event on the filesystem, but it's not as if you would completely remove every latency and ignore it: GSX is still a standard Simconnect application that has some inherent latency in the way it process communication with the sim anyway, so you would still have to be careful not to send too many commands to it.

Not that this is any different than interfacing with other add-ons running in the sim: if we need to send commands to the PMDG FMC through the PMDG SDK that uses custom Events (like GSX), we still need to take into account the overall latency of the whole system, so we need to space keystrokes about 250-300 ms apart, otherwise the airplane (which is also affected by the sim latency) can't keep up with it.

Sure, as a developer, it would be nice if the PMDG SDK allowed me to simply set all data in the FMC automatically in a single call, with a blazing fast memory set, and instead it's forcing me to "use the FMC menu" (sounds familiar ?), but who am I to question why they did it that way ? I'm fairly sure they had sound motivations, the FMC might have been designed to reply to the user input and only works correctly that way, even if might not be the most efficient or "modern" way for a connecting application, but it would be wrong for me complaining about the PMDG SDK not allowing me to do things as I would like to do, because I can guess having an user-oriented interface and a completely different mode of operations for external app not only is quite complex, but it can raise all sort of difficult to find bugs that surely can't happen if the user and the app are both forced to go through the same code path.

 

3 hours ago, FPVSteve said:

2) the capability to separate boarding and loading into two entities so that they can be triggered individually would be excellent

I fully agree about this. I would like to have those separated as well but, it's a HUGE change, and it's also one that would break all existing integration, because they would all be updated to consider Loading to be a separate Service, instead being part ot the Boarding/Deboarding process. Note that, it was designed this way long before we had visible (let alone Seated) Passengers, so cargo/luggage USED to take longer than Boarding, now it's usually the opposite. I won't say it can't be changed but, somebody must be very convincing it's really something that will provide a real benefit.

We drive new features based on a very simple metric, which is daily/monthly sales.

In the 13+ years GSX has been out in its first version, we noticed an undeniable fact, and it's that what drives sales are VISIBLE STUFF. New "things" you can see, like new Vehicles, Seated Passengers, new Services (like Water/Lavatory), the PIGS system has also been a big hit (and hard core users don't believe that). The simulation-based features and the logic-based features are only secondary, up to a point we can't even measure their impact on sales, while new graphic/models/textures/operators and all things YOU CAN SEE, are clearly affecting sales, in real time.

Which is funny because, I'm more of a simulation guy, and I cannot even tell which one looks best between Fenix vs FsLabs, they all look equally good to me, but then I see a 2 hours long video on Youtube showing all the differences, which I would have never noticed myself. However, it would be a mistake (from a commercial point of view) if I let MY own ideas drives the development of GSX: if sales raise when we add new models to look at, I'm not there to question, so we'll keep add new models and operators, most likely until we'll have each and every ground operator in the world.

Which was the reason why we added a separate Livery Manager app to manage the number of installed operators: to allow GSX to grow and at the same time allowing users to install a sub-set of their most used operators to not affect the simulator start up time too much.

 

Quote

Bonus #3) The ability to reduce fuel from the tanks. Right now If your aircraft starts with 20,000kg of fuel and you only need 5,000kg for your flight plan GSX will just hang during fueling. It should (at least) simply disconnect if it cannot complete the operation.

This is not supposed to be happening. When you already have more fuel than you need for the flight, if you call the GSX Truck, it will depart immediately as it arrives. But this might be possibly related to the airplane integration and how its fuel system works, so it would be best if you contact me on the FSDT forum and/or by email, to provide with replication steps.

But yes, a proper and fully recognized Defueling procedure is planned.

Edited September 25, 2025Sep 25 by virtuali

@virtuali Thank you for taking the time to post your above responses to mine, and the points of others. Whilst, as I said above, there are things I wish GSX did better, I cannot fault your passion and commitment to your product. 

As somebody who uses GSX on every flight, I get frustrated with it sometimes. But the fact I use it on every flight is a credit to you and the team who've clearly made a product that keeps me coming back.