Error when requesting Jetway **SOLVED in 2.4.1**

[fgiraudo]

Hello! I'm facing this error since updating MSFS to SU12 and GSX to latest version 2.4.0:

couatl v4.8 (build 5140)
panic log started on Tue Mar 21 20:44:18 2023

problem raised by addon <unknown>
Traceback (most recent call last):
  File ".\GSX\assistanceServices\jetwayOperations.py", line 416, in _trigger
AttributeError: 'Jetway' object has no attribute 'status'
{'Airport': 'SBGR', 'Requested assistance services at': 'Gate 18', 'User Pos': (-23.427222877770394, -46.479539064149044, 747.916 m, 2.47507 m, 270.38001216957946, 0.017816925421357155, 0.024434609338641167, -0.00014109277227990102, 2.553919111633301, 1.0)}

Already tried both airports which I have custom scenery or default airports, none seem to work. Anyone else facing the same issue?

[teofilo]

Hi after the new update I can't use GSX anymore. It crashes saying that the process <unknown> caused the Couatl scripting engine to crash. It was working perfectly before today's update.
How can I fix it? please see screenshot attached.

Here are the logs:


couatl v4.8 (build 5140)
panic log started on Tue Mar 21 16:11:30 2023

problem raised by addon <unknown>
Traceback (most recent call last):
  File ".\GSX\assistanceServices\jetwayOperations.py", line 416, in _trigger
AttributeError: 'Jetway' object has no attribute 'status'
{'Airport': 'KPIT', 'Requested assistance services at': 'Gate A 8', 'User Pos': (40.49670448383512, -80.24382550987647, 357.269 m, 2.47093 m, 316.9810863124241, 0.003920546267181635, 0.024434609338641167, 0.014042231141808784, 2.553919111633301, 1.0)}
emulateText_MSFS [GSX] Handling by OneJet 2.0


Teo

[teofilo]

I am having the exact same issue... it was working perfectly before..

[AirbusCaptain]

Same. Ive run the live updater. Getting an error when trying to connect the jetway. I was flying just fine yesterday. This is why I wish we could elect to not do these MSFS updates. I never want to be a beta tester

[SN737]

same

[mridout]

Same here. One workaround I figured in the PMDG that works, until there is a fix, is to use the FMC to attach the jetway / detach the jetway then GSX will board etc as per usual. Seems to be something in the new logic that is interrupting it locating the jetway to attach to the aircraft

[virtuali]

As explained so many times, when reporting a problem, you should always include as many details as possible, so it can be tested and possibly reproduced, which of course is the most important step to be eventually fixed.

I tried the first report, SBGR Gate 18, using the default A320, no issues and no errors, other than the fact the default airport I tried, the jetway is on the wrong (right) side of the parking spot, which is clearly a scenery error, but the jetway works.

I tried the other report at KPIT Gate 18, which doesn't exists in the default scenery, so the user must have an add-on scenery, but failed to identify it, so I can't check. I tried another random gate with a jetway and, other than the fact the parking is too small (another scenery problem), if I set it to ignore the size, the jetway works with no errors.

So, please, always include everything in your report like:

- the airplane used

- the scenery used, if it's no default, identify the scenery. If you have a custom GSX profile for it, identify the profile.

- the gate used, of course

- the precise, exact, sequence of operations in GSX. Like if you just called "Operate Jetways", or "Boarding", or something else in another other.

[mridout]

As explained so many times, when reporting a problem, you should always include as many details as possible, so it can be tested and possibly reproduced, which of course is the most important step to be eventually fixed.

I tried the first report, SBGR Gate 18, using the default A320, no issues and no errors, other than the fact the default airport I tried, the jetway is on the wrong (right) side of the parking spot, which is clearly a scenery error, but the jetway works.

I tried the other report at KPIT Gate 18, which doesn't exists in the default scenery, so the user must have an add-on scenery, but failed to identify it, so I can't check. I tried another random gate with a jetway and, other than the fact the parking is too small (another scenery problem), if I set it to ignore the size, the jetway works with no errors.

So, please, always include everything in your report like:

- the airplane used

- the scenery used, if it's no default, identify the scenery. If you have a custom GSX profile for it, identify the profile.

- the gate used, of course

- the precise, exact, sequence of operations in GSX. Like if you just called "Operate Jetways", or "Boarding", or something else in another other.

Mine was the PMDG 737-700
BMWorld Amsim KPHX, custom profile by Reverentan
C12 was the gate
Exact sequence to trigger the area was call to operate Jetway, or to call boarding w/o the jetway being attached to the aircraft. Both times resulted in a Couatl crash with the same error the others reported here:

AttributeError: 'Jetway' object has no attribute 'status'

If using the normal flow with the jetway attached/detached using the PMDG FMC everything occurred as normal. Boarding/pushback etc, no crash

[AirbusCaptain]

I ran the FSDT installer and checked for GSX updates instead of running the live updater. Loaded up my flight and it worked this time no issues

[virtuali]

I ran the FSDT installer and checked for GSX updates instead of running the live updater. Loaded up my flight and it worked this time no issues

There isn't the slightest difference between running the FSDT Live Update or the FSDT Installer. They are exactly the same program ( couatl_updater2.exe ), the only difference is the updater has a reduced interface, but they download exactly the same things.

The difference might just be running the installer after some time, that might be enough for your local Cloudflare node to catch with the updated files. This is normal on release day, replicating all files across 270+ servers takes some time.

Which is why, we have the alternative Offline installer, that can be used precisely for this reason, to get at least the latest program code, even if your local node hasn't got it yet.

[mridout]

I ran the FSDT installer and checked for GSX updates instead of running the live updater. Loaded up my flight and it worked this time no issues

There isn't the slightest difference between running the FSDT Live Update or the FSDT Installer. They are exactly the same program ( couatl_updater2.exe ), the only difference is the updater has a reduced interface, but they download exactly the same things.

The difference might just be running the installer after some time, that might be enough for your local Cloudflare node to catch with the updated files. This is normal on release day, replicating all files across 270+ servers takes some time.

Which is why, we have the alternative Offline installer, that can be used precisely for this reason, to get at least the latest program code, even if your local node hasn't got it yet.

Ah that makes sense, I'll try running the update again at a later time after this flight and will report back if I still see any issues

[Flightdoc]

Consistent result. Spawn at any gate with a jetway and request deboarding and GSX crashes. Log file attached.

[virtuali]

Consistent result. Spawn at any gate with a jetway and request deboarding and GSX crashes. Log file attached.

Since there was another message about this thread, I merged your post into that one.  Can you try the Offline installer, to be sure you have all the latest files, to exclude a problem with downloading ?

[MrSauga]

I had tried updating five times consecutively via the Live Update with no success. Kept crashing at 2% as the others mentioned. The sixth time I tried the same way as AirbusCaptain, and nailed it the first time. Lucky? Perhaps, but it worked for me which is all that mattered. As soon as the GSX interface loaded I knew the Jetway would work, since my Safedock system lit up as well. This was not happening when the Jetway wouldn't work.
Great update. Thanks for all the hard work you put into the program.

[virtuali]

I had tried updating five times consecutively via the Live Update with no success. Kept crashing at 2% as the others mentioned.

https://www.fsdreamteam.com/forum/index.php/topic,29515.msg191516.html#msg191516

The updater hasn't crashed, it simply quits after completing to update the only FSDT programs you have installed, so it's normal. It will only complete all steps if you have ALL FSDT products, for FSX, P3D and MSFS, all installed at the same time.

The sixth time I tried the same way as AirbusCaptain, and nailed it the first time. Lucky? Perhaps, but it worked for me which is all that mattered.

Same reason, most likely, some files must haven't been updated yet on your local cloudflare node, but they eventually were.

It's not unlike when a website changes IP address because it moved on a new server, it might take a few minutes, but sometimes up to 24 hours or even more, for all DNS in the world to get the update, so not all users would see the updated site at the same time, but eventually everybody will.

We have the offline installer precisely to cover these cases.