Pursuant to the comment above me… I’ve always wished for there to be an option to cancel a requested service in GSX, because a lot of third party integrations get mixed up easily and leave you hanging with an uncompleted service that’s blocking pushback. Something simple and straightforward, like selecting the request line in the menu again will cancel the request in process.
I don’t know how difficult that is from a coding standpoint, though, and I honestly wouldn’t blame Umberto if he didn’t want to waste time on it. You can always fix the issue by restarting couatl, and the only real downside is that you lose your seated passengers unless you go through the reboarding process again (which for planes like the A380 and 777 can take a while…). Not really a problem big enough to justify a lot of effort. Still, if it were easy to do, it would be useful.
Confirmed multiple times a general “Cancel service” option is planned.
It’s not there (yet), because opposite of what might seem, it IS fairly complex because “Cancel” might mean either an immediate cancel (= Abort) or a graceful cancel.
While an Abort might look easy (just kill all vehicles and end the service), is still not the same depending on the service performed and a “real” abort is already there: just restart GSX so, clearly, even an “Abort” should be done with some logic.
How to perform a graceful cancel is completely different depending on the service. During boarding we might stop generating new passengers, for example, but allow the existing ones to reach their seats. Which means a very variable time before the service would be canceled. Same for luggage, should we load the current bag and end the service, or complete the current loader ?
So no, it’s not “easy” as it sounds, because each service has different ways to be canceled or aborted. The Pushback, of course, can be canceled or aborted, but only after it started pushing, with very different outcomes.
So yes, we know exactly what is required, it just takes time, because we have a long list of planned updates that will go on for years to come.
quick question about GSX Pro and cabin crew visibility, because I’m not sure if this is expected behavior or something that changed recently.
Back in MSFS 2020 with an older GSX version, I clearly remember that cabin crew (flight attendants) were not only visible during boarding and deboarding, but also stayed inside the aircraft during the flight (usually standing or hanging out in the galley). At least this was the case when flying the Fenix.
Now with MSFS 2024 SU4 and the latest GSX version, I still see the cabin crew during boarding and deboarding, but once the flight is underway, they’re gone.
Passengers are working perfectly for me and remain seated as expected, it’s only the cabin crew that disappears during cruise.
So my question is:
Is this an intentional change in GSX or a limitation of MSFS 2024 / SU4? Or did I maybe miss a setting or option somewhere?
Just want to understand whether this is by design now, or if cabin crew visibility during flight might come back in a future update. This isn’t a big issue for me, I’m just curious.
Have used the progressive taxi after landing a few times after BATC assigned me a gate and gave me a taxi sequence. GSX doesn’t follow that sequence and seems to go very far out of the way to get to the assigned gate. I just had the longest taxi of my life at Madrid airport. Could have driven from Porto in less time.
Yes, it’s due to the completely different way we use in MSFS 2024 to attach passengers.
While in MSFS 2020 we patch every exterior .xml model in all liveries, so we could use different crew uniforms for different liveries (assuming the airplane has the correct icao airline code), in MSFS 2024 we add passengers to the attached_objects.cfg file, which is the “native” way to attach objects according to the new modular aircraft structure.
This has huge advantages in the installer reliability to support all kind of liveries and makes patching way easier, since we don’t have to deal with different ways developers use to create the model .xml files.
However, the attached_objects.cfg file is shared between all liveries so, the advantage of having to deal with just one file to patch and use the “proper” method to attach things to the airplane, means we no longer have a different set of crew (and a different textures fallback as well) for each livery so, between having to show a crew that would change uniform and characters when switching from dynamic to static, we decided to just not have the static crew (the one standing for the whole flight).
I think what you might be running into is that GSX now deactivates itself during flight, and also will not draw characters in during flight if active unless the cockpit door is open. But I haven’t gone looking for the attendants recently, so maybe there is an issue I don’t know about.
First, you must understand there’s not such thing as a “GSX Discord”, if by that you mean Discord as a GSX support place. That channel you probably used it’s a Community channel, not owned by FSDT where everybody there are just users. We don’t have any official presence on Discord, the one and only places where you are supposed to get support from FSDT, are the FSDT support email, or the FSDT support forum. I might sometime appear on Discord, as a normal user, but that’s only when I have free time.
About your issue, you don’t say which simulator you use but, assuming you are using MSFS 2020, then yes, there is a problem with the weather detection there, which will be of course fixed in the next update.
GSX doesn’t use the same routing as BATC, it has its own pathfinding method, that is not just “the shortest path”, but it takes into consideration:
the taxiway type. it won’t try to use vehicle type taxi, even if that would result in a longer path, unless there’s no other route
It will try to not force you to make a too sharp ( > 120 deg ) turn.
It will read AI planes ahead of you, and reroute if there’s a chance of a collision, if it can (of course)
This means, all these realistic constraints might result in a longer path than just the shortest one.
The next update will have an option to NOT try to re-route because of AI planes in the way, so it might re-route way less, but of course it will be your responsibility then to not run into AIs.
