I bought GSX as it was recommended by FSL for their A321. Its added more depth to the simulation like the sounds of passengers boarding while you carry out cockpit preparation, and there was obviously some decent collaboration to integrate GSX into the aircraft so you don't use the GSX menu. The FSL highlighted how poor PMDG's integration is with GSX.

I forgive the occasional GSX glitch as I understand that GSX is an add-on competing for resources with all my other add-ons. At least you don't get CTD's all the time, like you did with FSX.

10 hours ago, David Roch said:

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.

If all are like Umberto our life would be easier.....He get's to the point..but job is done

Many thanks to Umberto for taking the time to respond so comprehensively to the “issues” raised. Knowing how long it takes me to draft a simple email, I can appreciate the time it takes in responding as you did. Cheers. 

11 hours ago, virtuali said:

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.

 

Well okay, to answer your question, one quick example I can think of would be the BATC gate selection currently having to display the UI multiple times by automatically pressing "Next Page", "Next Page", etc to get to a specific gate selection on arrival.

If an API existed you could expose an endpoint like: GET "localhost:912/gsx/arrival/parking" which would broadcast the list of available parking spaces at the arrival airport:

Response: HTTP/GET 200 OK {
       parkings: {
             { id: 1, parkingName: "Stand 1" },
             { id: 2, parkingName: "Stand 2" },
             { id: 3, parkingName: "Stand 3" },
             { id: 4, parkingName: "Stand 4" },
             { id: 5, parkingName: "Stand 5" },
             { id: 6, parkingName: "Stand 6" },
             { id: 7, parkingName: "Gate 1" },
             { id: 8, parkingName: "Gate 2" },
             { id: 9, parkingName: "Gate 3" },
             { id: 10, parkingName: "Gate 4" },
       }
}

The BATC application could then select one of those gates via the relevant Id, eg: POST "localhost:912/gsx/arrival/parking/7", in the background and save the UI from needing to be visible at all (let alone displayed multiple times while different options are displayed). Then BATC could automatically adapt itself using information GSX provides back to it in a response to its request:

Response: HTTP/POST 200 OK {
      result: OK,
      selectedArrivalGateId: 7,
      parkingName: 'Gate 1',
      handler: 'British Airways',
      marshaller: true,
      vcgs: true
}

or

Response: HTTP/POST 200 OK {
    result: ERROR,
    reason: "Gate too small for user aircraft"
}

or

Response: HTTP/POST 200 OK {
    result: ERROR,
    reason: "Gate already occupied"
}

If BATC were to receive the latter messages, the ATC could use the errors to say:
"Negative, that space is too small for your aircraft - taxi to Gate 3".
or
"Proceed to holding point L7 and standby, gate currently in use".

Right now BATC can only proceed with "affirmative" to whatever you select whether its appropriate or not because GSX doesn't give any feedback.

I'm aware an API would certainly be a lot of work and it may not even be possible but you asked, and that's why I think having one could be a good thing: better integrations would be possible via third parties and smoother user experiences for those who enjoy the visual sides of your product and want to use it to its full potential.

 

 

 

2 hours ago, FPVSteve said:

If an API existed you could expose an endpoint like: GET "localhost:912/gsx/arrival/parking" which would broadcast the list of available parking spaces at the arrival airport:

That's not needed. The MSFS Navdata API already provides a list of available parking spots. And I'm sure BATC already use it. 

 

2 hours ago, FPVSteve said:

The BATC application could then select one of those gates via the relevant Id, eg: POST "localhost:912/gsx/arrival/parking/7", in the background

An application can already set a menu choice, in the background, by setting the L:FSDT_GSX_MENU_CHOICE through Simconnect.

 

Quote

and save the UI from needing to be visible at all (let alone displayed multiple times while different options are displayed)

The GSX menu won't be visible if the app sets GSX in Remote Control mode.

 

2 hours ago, FPVSteve said:

Then BATC could automatically adapt itself using information GSX provides back to it in a response to its request:

No need for an API call to do that either. Starting from the parking list it already got from the Navdata API, if the app needed to read GSX-specific extra informations about a gate, like the presence of a docking system, which operators are assigned, which custom pushback routes might be available, etc, it can read the GSX airport profile, which is a standard .INI file, where the section names match the names returned by the Navdata API.

 

2 hours ago, FPVSteve said:

Right now BATC can only proceed with "affirmative" to whatever you select whether its appropriate or not because GSX doesn't give any feedback.

GSX will give the same feedback it would have given to users (which won't be displayed in Remote Control), by sending a standard MSFS SDK event to let the app it has sent such feedback, and the exact content of it can be read by reading the "tooltip" file, in addition to the "menu" file that might have been also used to check if GSX considered the parking to be occupied even before it was selected.

That even without saying that if the goal was to know if the parking is occupied, it can be done directly with Simconnect (by checking AIs positions against the parking position) and I'm fairly sure BATC is already doing this, otherwise it couldn't possibly handle AIs, so that's basic information it already needs even before GSX.

So no, following your examples, I don't see how adding the extra weight on the system for having GSX having to run a local web server through FastAPI or something like that, would add any functionality which is not already available now.

Edited September 26, 2025Sep 26 by virtuali

I like Gsx and use it often. The thing I find funny is how the animated workers disconnect the baggage loaders, back away and park them, and then just sit on them there doing nothing. Same after hooking up the tug. Get back to work! Theres a plane arriving at the next gate over! 

@virtuali Any plans for more expansion?   Maybe have flight attendants do a beverage service etc?  

Speaking of GSX oddities tho..... I'm guessing the glue on the VDGS didn't quite hold...... 🙂 In All seriousness, it was actually in the right spot for the first 20 seconds of the sim session and then moved down to here.... odd. 

 

Edited September 26, 2025Sep 26 by KL Oo

3 hours ago, Tony P said:

@virtuali Any plans for more expansion?   Maybe have flight attendants do a beverage service etc?  

Why would you want that? It's called Ground Services X for a reason. it simulates the ground operations. Not operations while in the air... 🙂

5 hours ago, Tony P said:

@virtuali Any plans for more expansion?   Maybe have flight attendants do a beverage service etc?  

see Self Loading Cargo software for that !

3 hours ago, anden145 said:

Why would you want that? It's called Ground Services X for a reason. it simulates the ground operations. Not operations while in the air... 🙂

Because he does... That's enough for me.  Why do people constantly challenge other people's preferences here?

 It also simulates seated passengers in flight.  

 

7 hours ago, Tony P said:

Maybe have flight attendants do a beverage service etc?  

About that, apparently not many have noticed the FSDT_Airline_Trolley Simobject in the GSX package, which is currently inactive, because we are still hoping for a possible "Attach API" ( which I've been trying to push for for years ), that would make that way more easier to do, in addition to make the whole Seated Passengers so much easier to use, with no need to patch the airplane model, and the ability for users to add support for Seated Passengers themselves.

Basically, everything is planned, our list of future updates is so long that will keep up busy for years. There are a lot of new things that are ready to be added which we are testing and waiting for SDK improvement to make them in the best possible way.

On 9/25/2025 at 7:48 AM, bennyboy75 said:

 

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. 

 

You can easily change the method of pushback.  It's (I think, I don't have the app running right now) on the drop down, "Airport Customization" perhaps?   At the bottom, you can select tow bar or tug.   You can also select conveyor loaders or container loaders and the brands for tugs, catering trucks, etc.   It's pretty easy.   The only thing I'm not sure about is if the changes made are persistent or if you need to select them for each flight from that gate. 

My original post seems to have opened a big can of hate on GSX, which wasn't my intent.   This program provides a huge amount of realism for airline ops.    It's not perfect but simply uninstall it and see how you like operating in a very sterile environment.  

That said, still haven't seen an answer to my question on why loaders can't remain attached to the aircraft for the duration of PAX boarding instead of quickly loading all the bags and then driving away, leaving the cargo doors gaping open for the remainder of the loading process.   Seems like it would be a relatively quick fix to implement. 

4 hours ago, virtuali said:

Basically, everything is planned, our list of future updates is so long that will keep up busy for years

Be sure to add code to make ground crew STOP when the plane is stopped before it reaches the end of its 100' max pushback'.   It's silly to stop at 40' only to have to wait until crew goes all the way to 100'. 

Edited September 26, 2025Sep 26 by Noel