Trying to understand the logic behind jetway movements

[Framsen]

Hi guys! I'm trying to understand what happens and how could I do it better

My problem is: Jetway moves when I dont want it to be moved.
There could be two differernt scenarios:
1: MSFS loaded, jetway connect, and start preparation
2: Turnaround, I arrive, jetway connects, and disconnect before push

So, unfortunatelly the only way it works is this: MSFS loaded, and request boarding, which connects the jetway.
Okay but there is a few problem with this. I dont want to board a cold&dark plane, this is the last thing I want after, jetway, stair, refuel and catering.

What happenes?

- I request jetway connection, few minutes later aircraft is ready for boarding, request boarding -> jetway disconnects WHY ?
- I arrived on an airport, deboarding has finished -> jetway goes away WHY ? I want to continue for an other flight

Why GSX touches the jetway all the time it should not? I want to connect and I want to disconnect when I am ready and want it. It does stupid things...

Notes:
Assistance services Auto Mode: Unticked
3rd aircraft influences on jetway, for example Fenix's Auto door and jetway simulation: Unticked

Nothing should move the jetway away from the plane, but GSX does. The only reason for disconnection is should be when I request push.

If possible please think about for an option to disable this jetway play.

Thank you very much!

[DroidE326]

There have been a few discussions regarding this and the consensus is that jetway operation is bugged in several ways, and this, like a lot of things, is something that Asobo needs to fix. My own experience is that the default behaviour of jetways seems to depend on whether you are at a default Asobo airport, one purchased from the MS Marketplace, or one purchased from a third party vendor.

For example, at LEBB, purchased and installed via the MS Marketplace, I have to leave the jetway in the default retracted position before asking GSX to start boarding, in which case it will extend automatically and boarding will start (should be noted, that like you, I also have auto door/jetway disabled in the Fenix app). If I extend the jetway before initiating boarding it will simply retract and boarding will fail (stops after a few seconds).

At LPPR, purchased and installed in the community folder via the Orbx app, the exact opposite happens. I have to connect the jetway before starting boarding, or the jetway will not extend automatically and boarding will fail in a similar way to above. As long as I include extension of the jetway as part of the flow before starting the boarding process, it all goes smoothly (this is also true of two other orbx airports I own).

I wish there was a simple answer, but unfortunately there doesn't seem to be one - and what's more - you will go insane if you try to use logic or reason to find one.

[virtuali]

As explained so many times in the forum, whenever you see a problem with jetway, it almost invariably a bug in the default Jetways system. GSX doesn't change ANYTHING in the way Jetways WORK, it only changes their APPEARANCE.

The issues with the default Jetway animation system are very well known, and they were very well known long before GSX came out, and of course the same exact problems will happen without GSX, on default airport using the default Asobo jetways.

- Jetway dock whenever they want. Depending on your position, they might dock on the back door and, in some cases, even on the catering door, with their head reversed! Sometimes they only dock partially.

- There's no sure way for GSX to know if a jetway has docked, or has docked partially, because there aren't any dedicated SimVars in the SDK to check for this. The only way to sort-of knowing if a jetway has docked, is it's not moving (because there is such variable) and if its hood is extended (again, we have such variable). This almost work, provided of course the hood animation works.

- Even if we might more or less know if a jetway has docked, there's no way to know WHERE, meaning to which door, or if it hasn't docked completely. We can only assume (more precisely "hope") it docked on the correct door, because you parked in a sensible way that would result it docking there correctly.

- There's A KNOWN LOD BUG, which makes the jetway "looking disconnected", when in fact it's not. This again happens everywhere, with default jetways and regardless of GSX, and it's more easy to see when using an External/Showcase camera. The jetway lose sync between the animations while it switches LODs, so it "seems" it has Disconnected, but in fact it hasn't, it just looks like it has. That's the most common case in which users are mislead "GSX has Disconnected when it shouldn't have".

- The command to operate a Jetway ( that's the ONLY thing GSX sends to the sim ), it's a "Toggle", meaning it will *invert* the Jetway current status. Which obviously mean if GSX knows it's time to Dock a jetway, it will first (obviously) check if it's not Docked already, and send the command only if it's not. And of course the opposite: when GSX knows it's time to Undock a jetway, it will first (obviously) check if it's Docked, and will send the command only if it is.

Which means, if due to ANY of the reasons already explained above, GSX can't detect the jetway current status correctly, it might send the Toggle command when it shouldn't have. And, if another add-on is sending the command at the same time, they'll cross each other.

That of course wouldn't be a problem if either the Jetway status could be detected more reliably, or the command to operate jetway was made in two separate commands, like a "JETWAY_ON" and "JETWAY_OFF", like in case of other Events in the sim such as "AUTOPILOT_ON" or "AUTOPILOT_OFF", but since neither are true, there might be situations where the jetway might not disconnected/connect correct ( provided is not the previously discussed LOD BUG, which is only a VISUAL Disconnection! )

Another possible issue with Jetways is that, when using the SU10 Navdata option, which allows GSX to use airports from the Marketplace, the Jetway POSITION is UNKNOWN, we only know if a certain parking spot has a Jetway, but we don't know where it is. This forces GSX trying to search for the jetway, using some heuristics on the name and their distance from the user airplane but, in some cases ( Double Jetways with a 2nd static version placed nearby ), it's impossible to reliably detect the correct Jetway object.

If the correct jetway object can't be detected, its Docking status (however unreliably was detected even when we DO have the correct object), can't be detected in ANY way, since we might not looking at the correct jetway. This wouldn't be an issue if we had the exact position of the jetway, since we could just match the position in the Navdata with the position in the scene, and we would be 100% sure which object the jetway is. But this data is missing from the current Navdata.

This has been explained more in detail in the post I've made here, requesting the missing data to be added:

https://forums.flightsimulator.com/t/sdk-q-a-ask-your-questions-here/552074/11

Fortunately, it was the most voted thread, and in the SDK Q&A Streaming session Asobo had Nov. 23rd, it was the first question answered, and they confirmed it has been scheduled for an addition to the SDK for SU12. We'll of course update GSX to take advantage of the new data, as soon the updated SDK will be out, which is likely to be early next year.

[Framsen]

Thank you very very much for the answer!!