The most important things missing in the SDK right now, for us, are these two:
Missing information about the actual position of Jetways in the new SU10 Navdata API.
Currently, the Navdata API will only tell us which Parking spot the Jetway is associated to, but there’s no way to know exactly where it’s located. To do this, we need to search for all SimObjects in the scene, which is inefficient, both because Jetways don’t have a separate Category, but also because there’s a bug in the Simconnect call that doesn’t return all objects in a scene, unless a range > 20000 meters is set. But even when we have a list of all objects, we need to use unreliable heuristics trying to recognize if they are Jetways ( like checking their names ), which will fail in case the same Jetway SimObject is used both as a “proper” Jetway inside a TaxiwayParking element, and as a regular SimObject outside of it, as a static secondary one.
This could be so much easier and reliable if we just had the actual Jetway Position from the Navdata API, so we could find the Jetway Simobjects by position, matching the one from the Navdata to the actual object in the scene. Which will be even faster if the > 20000 meters bug would be fixed and there was a way to filter out Jetway by Category, if they had their own separate category.
The reason why we need a reference to the Jetways Simobject, is because we need to check their associated SimVars to know if they are docked, so we can display Animated Passengers walking inside Jetways reliably. Which brings to the 2nd information that’s missing in the SDK:
A reliable way to know if a Jetway has Docked, and where
Right now, the only way to have some idea if a Jetway has docked, is to check if it’s not moving ( we have a SimVar for that ) and if its Hood has extended, and we have SimVars for that as well.
However, that’s not enough, because we don’t know where the Jetway has docked ( which door ), and we don’t know if it has docked partially or not at all, because sometimes is not fully extended, even if the Hood has moved. Adding extra SimVars to the Jetway objects would be very useful, for example:
- A variable indicating if the Jetway has Docked.
- Some variables indicating the actual position of the IK_SecondaryHandle bone, relative to the Jetway root, which are dynamically updated while the Jetway moves.
This way, we could reliably know if a Jetway docked and where, by matching the IK_SecondaryHandle to the airplane door closest to it, and we could know if the jetway didn’t extend completely.
The reason why we need this data, is to be sure that Animated Passengers walking inside the jetway, will have a path starting from the actual door the Jetway docked to, passing through the actual position of the jetway Head ( IK_SecondaryHandle ), and finally reaching the Jetway root at its end.
Other use cases where knowing the Jetway position ( and PBH insertion ) is important are interactive Maps in separate application or inflight instruments. A Nav Map application is currently unable to draw a Map containing Jetways if using the Navdata API, something it could do by opening the airport .BGL directly, which of course would make sceneries bought on the MS Marketplace not fully usable with such applications.