Just wanted to know if this is some GSX bug or a limitation of certain 3rd party scenery etc…. And if there‘s a way to possibly fix it.
Whenever you see something weird happening with Jetways and GSX, it's almost invariably either a limitation of the sim/SDK or some issues recognizing the scenery. Some facts:
- The SDK doesn't provide any way to have a list of jetways, even in the upcoming Navdata API, the only information we'll get is if a parking *has* a jetway ( true/false ), but no extra information about it, which is clearly not enough for GSX to work properly, since we need to know about the jetway position. Right now, we get this information by reading the scenery .BGL file.
- The SDK doesn't provide any way to know the docked/undocked status of a jetway. We must infer it by checking one of the variables the SDK *does* provide and, in our case, we check if the cover/hood has moved ahead, and from this information we derive if a jetway docked. To read these variables, we need the actual SimObject that represents the jetway in the scene, because you need to have an handle to SimObject to read any data from it.
- Putting the two previous points together, means GSX needs to FIND Jetways, which is what it does when entering an airport.
- The SDK doesn't give any information or provide for any filter to exclude non-Jetway objects during a search, and Jetways don't have a separate Category the Simconnect "search for objects" call requires. We can search for AI planes, Ground vehicles, Boats, Animals, etc, but we can't search for Jetways, meaning we need to search ALL Simobjects in the area. This means we need to have a way to know if a found object is a Boat, an Animal or...a Jetway.
- The SDK has a bug that, unless you search in a radius of more than 20000 meters ( 20001 it's enough ), Jetways won't appear in the list of objects found. So we need to set a search radius that large, meaning we need to then filter out Jetways over a potentially large list of objects, when we could have simply searched in a limited radius around the airplane, if it wasn't for this bug.
- Putting the two previous points together, means in order to know if a found object is in fact a Jetway, we need to MATCH its position against the position we "know" a Jetway is supposed to be, which we obtained by reading the airport .BGL file. If a found object is in the same position as the jetway we found in the .BGL, we can safely assume that object must be a Jetway. Well "safely", as long the scenery doesn't have another object placed exactly in the same spot as the jetway...
That the first challenge: finding Jetways, which would work so much more reliably if the SDK just gave us with a list of Jetways and where they are, but that would be too easy...and this means, if for some reason the airport .BGL can't be read ( either it's encrypted, or another scenery is read in its place for some reason ), we can't MATCH the Jetway data in the scenery with the Jetway SimObject in the scene, the one we need to know IF a jetway is docked.
So, assuming GSX managed to bypass all these obstacles, and DID find the right Jetway Simobject, we are onto the next task, which is knowing IF a jetway is docked or not, so the SDK limitations in this area are that we don't have a variable to know if a jetway is docked or not, we only a variable to know if it's moving ( but not in which direction, meaning we don't know if it's extending or retracting ) and we have some variables we can read about the Jetway HOOD ( the cover ), that's the only things we have, so we used the variable for the Hood and, if they have been extended and the jetway is not moving, we can "safely" assume the Jetway must have docked.
"Safely", as long the Hood extends properly and of course if the right Jetway object has been found, as explained in all the previous points before.
All of this means, that GSX won't be able to recognize the Jetway docked/undocked status, unless ALL the previous hurdles in finding jetways and their object have been resolved.
"But I can operate the Jetway from GSX, that means it must have found the right jetway!"Well, no. Fact you can operate from GSX doesn't mean much, because GSX is not really "operating" anything. What that menu option does, is just sending the standard command to trigger a Jetway to the sim. It's the simulator that really operates a jetway, not GSX, which is just blindly sending that toggle command.
And of course, the other SDK limitation we have here, is that command is a "Toggle", instead of a proper On/Off command. Toggle commands are limited and they are hated by all airplane developers and developers in general that must do drivers for hardware, so many commands have been changed from their "Toggle" form, to an alternative On/Off format, meaning one can just send an "ON" command to the (example) the Autopilot, and it will turn On if it's Off, but it won't turn Off if it's On, as it would be if it was a "Toggle" command. But with Jetways being the forsaken child of the SDK, their trigger command is only available as a Toggle, meaning we need to know the actual docked/undocked status of a jetway before we can safely send a Trigger command to animate it. So, read all the previous explanation about finding the right Jetway object in the scene.
And of course, as explained so many times, the SDK doesn't give ANY way to know WHERE the jetway ended up when docked. Resulting in "passengers walking in the air", if the Jetway docked to the wrong door, because they only thing we can do from GSX, is HOPING it has docked on the Main Exit and it hasn't docked partially, both conditions we can't check, so we can only create passengers based on that assumption.
And of course, as explained so many times, the jetway sometimes APPEARS to "retract" itself. It hasn't really retracted, as far the simulator is concerned, the jetway is still docked, but due to a LOD BUG, it loses sync across different LODs which shows the jetway in the retracted position when going in/out with the camera. This will also result in "passengers walking in the air", of course they do, they are walking on the correct path, it's just the jetway *appeared* to disconnect itself so, depending on the user reaction, he might either assume GSX has a bug that result in passengers "walking in the air", or he might assume GSX has a bug and disconnected the jetway for no reason ( it hasn't, it's just a LOD bug )
That's all the hurdles GSX has to contend with each time it works with a Jetway. Think about those, next time you see something unexpected appearing with Jetway, before assuming "GSX has a bug".
In any case, I tried default EDDM, which use the GSX default replacement model, selected "Operate Jetways", waited for the jetway to dock, then I selected "Boarding" and, of course, the jetway stayed connected as it should so yes, I can confirm that, PASSING ALL THE PREVIOUS ISSUES ( knowing where Jetways are in the airport file AND finding them in the scene by matching their positions ), when GSX CAN detect the docked/undocked status of a Jetway, it works as expected, so there's no "bug" in the OPERATE Jetway function.
