MSFS 2024 - at LFPO airport, GSX jetways don't work.

[ObiTwo]

Hello,
With MSFS 2024, at LFPO airport, GSX jetways don't work.

LFPG Asobo: OK
EGLL iniScene 1.3.4: OK
LFPO JetStream Designs 1.4.0: doesn't work

Note: With GSX loaded (couatl.exe), jetways work if requested via MSFS 2024 ATC.

Voloport is not present in the MSFS 2024 library.

Thanks in advance.

[virtuali]

This has been explained so many times: GSX has NO CONTROL over jetways if they work or not, nothing in GSX has any control over how good (or bad, or not at all), Jetways will work.

Fact they work with the default ATC doesn't change this, GSX still has no control over jetways, it simply send a JETWAY TOGGLE key event, the rest is up to the sim, so maybe the known problem with Jetways happening at Paris airports is not affecting the default ATC, but it affects the key toggle, which of course is the only possible way for GSX to ask the sim to move the jetway ITSELF ( GSX doesn't move jetways ).

[ObiTwo]

I understand your irritation at repeating the same things. But you can understand that for a customer using the A320 Fenix, with which GSX is fully integrated, this customer might be surprised by this non-functioning in 2024, when it works in 2020.

Moreover, in 2024, when I call the jetway via GSX, it doesn't move, and when I call it via ATC, the jetway disappears.

It might be advisable to consult with Asobo to establish a single process.

Note: I sent a message to JetStream Designs.

Sincerely,

[Ankh]

I have the same issue on PacSim RKSI addon scenery. Already contacted the dev and he said that they do not use anything special, just default jetway system. However, today, when exiting into the main menue, a error window popped up telling me "the addon jetwayOperations.py is causing the Couatl Scripting Engine to restart" and then an error file was created, those are the contents:

couatl v5.0 (build 5621)
panic log started on Tue Apr 22 21:18:31 2025

problem raised by engine or unspecified addon
{'Airport': 'RKSI', 'Requested assistance services at': 'Gate 15', 'User Pos': (37.45315559249982, 126.45219955289792, 11.6737 m, 4.5817 m, 253.30981005374102, -0.0001315834630399998, -0.0, -4.853571491773111e-06, 4.8768, 1.0)}
icao_airline CPA
flight_number 1982
route BOPT2Y BOPTA Z51 BEDES Y711 MUGUS Y742 SALMI Q11 DRAKE A1 ELATO V522 ABBEY ABEY2G
passengers (315/315)
airplane A359
originICAO RKSI
Runway 34R
destinationICAO VHHH
est_time_enroute 186.000000
sched_time_enroute 167.000000
sched_out Tue Apr 22 23:15:00 2025
sched_off Tue Apr 22 23:35:00 2025
plan_ramp 56057
units lbs
OEW 312567
ZFW 385017
Max TOW 493609
pax_weight = 175.000000
Cargo 17325
emulateMenu_MSFS CHOICE 0
channel.balance =  -1
22.9469 m 24.5318 m
22.9469 m 24.5318 m
22.9469 m 24.5318 m
22.9469 m 24.5318 m
Error: exception UNRECOGNIZED_ID in call RemoveClientEvent param #2 '1111310416'
{'Airport': 'RKSI', 'Requested assistance services at': 'Gate 15', 'User Pos': (37.453155592496195, 126.45219955289959, 11.6737 m, 4.5817 m, 253.30981002306103, -0.00013158410996306303, -0.0, -4.760425436249009e-06, 4.8768, 1.0)}
FSDT_GSX_NUMPASSENGERS is 315
Number of passengers provided by addon is 315
FSDT_GSX_NUMPASSENGERS is 315

bypassPinSystem: steerVar=INI_NOSEWHEEL_STEERING_POSITION, degPerFrame=1.190476, zeroFrame=0.000000
22.9469 m 24.5318 m
AssistanceServices.showMessage() Handling by Asiana Airlines WHITE
AssistanceServices.showMessage() This gate has a default jetway WHITE
AssistanceServices.showMessage() Jetway operating WHITE
emulateText_MSFS [GSX] Handling by Asiana Airlines WHITE 2.0
setNumVagons()
FSDT_GSX_NUMPASSENGERS = 315.0
FSDT_GSX_MAX_NUMPASSENGERS = 315.0
FSDT_GSX_SIMBRIEF_CARGO = 17325.0
FSDT_GSX_SIMBRIEF_UNITS = 0
FSDT_GSX_SIMBRIEF_FUEL = 56057.0
FSDT_GSX_SIMBRIEF_MAX_TOW = 493609.0
EMPTY WEIGHT = 308647, FUEL TOTAL QUANTITY WEIGHT = 52910, TOTAL WEIGHT = 361558.03125, MAX GROSS WEIGHT = 623908.0
Payload:-3146/128904 lbs.
Set Wagons according to Pax number of 315/315
Set 4/4 wagons, according to loading ratio of 100.00%
22.9469 m 24.5318 m
setNumVagons()
FSDT_GSX_NUMPASSENGERS = 315.0
FSDT_GSX_MAX_NUMPASSENGERS = 315.0
FSDT_GSX_SIMBRIEF_CARGO = 17325.0
FSDT_GSX_SIMBRIEF_UNITS = 0
FSDT_GSX_SIMBRIEF_FUEL = 56057.0
FSDT_GSX_SIMBRIEF_MAX_TOW = 493609.0
EMPTY WEIGHT = 308647, FUEL TOTAL QUANTITY WEIGHT = 52910, TOTAL WEIGHT = 361558.03125, MAX GROSS WEIGHT = 623908.0
Payload:-3146/128904 lbs.
Set Wagons according to Pax number of 315/315
Set 4/4 wagons, according to loading ratio of 100.00%
22.9469 m 24.5318 m
emulateText_MSFS [GSX] This gate has a default jetway WHITE 3.0
emulateText_MSFS [GSX] Jetway operating WHITE 3.0
Traceback (most recent call last):
  File ".\GSX\assistanceServices\jetwayOperations.py", line 447, in _trigger
Exception: requestJetwayData Internal error (dwIndex == 99)
{'Airport': 'RKSI', 'Requested assistance services at': 'Gate 15', 'User Pos': (37.453155592511244, 126.4521995528936, 11.6737 m, 4.5817 m, 253.30981012798662, -0.00013157296117461358, -0.0, -5.140771034935372e-06, 4.8768, 1.0)}

Does this give any information? Also in my case, I could easily get along with asking for the jetways the default way, but then the jetway simply disappears.

[Ankh]

Ok, I did some digging in the net and found interesting things.

For you, @ObiTwo, it seems that the nearby Voloport is causing the issue, you might get rid of it by deleting this. Thread: https://forums.flightsimulator.com/t/jetstreams-orly-airport-lfpo-ground-services-no-longer-work/583347

Regarding the jetway dissappearing when using the default ATC command AFTER already having tried GSX, it seems that if you directly use the default ATC command, the jetways do not disappear: https://www.fsdreamteam.com/forum/index.php?topic=32910.0

Interesting, no? I am now in contact with the dev of the airport where I do get the issue (RKSI from PacSim) to see if there is also a Voloport nearby and I will test later today if using the default ATC command first also prevents the dissappearance of the jetway at RKSI.

[ObiTwo]

Many thanks, @Ankh
I contacted JetStream Designs and it's Voloport that's still blocking the system (already on MSFS 2020). 




I disabled Voloport and everything works fine. 

NB : I hope you find a solution for RKSI.

[virtuali]

Exception: requestJetwayData Internal error (dwIndex == 99)

This error code is a panic message from Simconnect, saying there's an unknown problem with jetways, whatever the cause.

[Ankh]

This error code is a panic message from Simconnect, saying there's an unknown problem with jetways, whatever the cause.

No idea what it could be? Because if I call the default ATC to connect the jetways, it always works. Also the jetway detachment via GSX works. The issue is really only the "operate jetway" function by GSX. If this is executed first, it messes things up and only on this airport. Strange...

[Ankh]

Ok, the just released FlyTampa YSSY update (for MSFS2024) has the same issue. Giving the command via GSX menue to operate jetways results in no jetway movement, yet the GSX indications tell that operation started and also note that operation finished. Again, as in RKSI, jetway movement works when requested via default ATC command for boarding. I already got in contact with the dev over at avsim, wonder if he can find any potential cause (because PacSim dev did not so far).

As mentioned, not a biggie as long as I can use default ATC command, but still not perfect like this.

Interesting observation: when GSX completed the ghost operation of the jetway, default ATC offers me the option to "stop the boarding process". If I do this, the jetway instantly jumps into position (attached to the aircraft) and then disconnects and moves to the parking position. So, somehow the sim and GSX think that the operation worked, but the graphics engine is not replicating it correctly.

[Ankh]

Ok, add Flightbeams NZAA on the list...

[virtuali]

Ok, add Flightbeams NZAA on the list...

To the list of airports which, like RKSI, have some issues with jetways, and they cause the same error ?

Exception: requestJetwayData Internal error (dwIndex == 99)

This indicates either an error in the scenery OR jetways from another scenery in conflict, no questions about it, it's not as if GSX makes up Simconnect errors for no reasons, and if that error comes, the whole part of the Navdata API which GSX REQUIRE to know if a jetway is connected, where it is, and its geometry, won't work either because, as far as the Simconnect is concerned, that jetway doesn't exist.

[Ankh]

Just as an update: it is now entirely clear and sure that nearby heliports can cause jetways not to be able to be moved by GSX anymore (however, the default ATC command still works, which remains a mistery to me). RKSI was long time ago fixed by a nice guy over at avsim, now another user has taken up this issue and already released a bunch of small fixes over at flightsim.to for various airports with nearby heliports causing the same problem. I have now all my affected airports fixed and no longer need the workaround via default ATC command.

[virtuali]

Just as an update: it is now entirely clear and sure that nearby heliports can cause jetways not to be able to be moved by GSX anymore (however, the default ATC command still works, which remains a mistery to me).

That has been clear and sure for a long time. Which is why we released a patch to our KORD scenery which was affected by this bug. It has been reported to Asobo a long time ago, nobody knows why it doesn't work by sending the standard TOGGLE JETWAY key event (which is all what GSX does), but it works from the ATC menu, I can only guess the ATC menu must use a different internal non-documented way to trigger the jetway.

Of course, if GSX also got the error discussed above:

Exception: requestJetwayData Internal error (dwIndex == 99)

It won't even try to trigger a jetway because, as far GSX is concerned, no jetway exists there. But that's a separate issue related to that Simconnect Navdata issue, it's not really related to the "nearby helipad" problem, which seems to happen regardless of the above error or not.