Idea

Would like to have a comment about this. We would like to support the new API as soon it's out, but missing data about Jetways and Jetway links are really a problem.

It's very nice you confirmed Runway Starts will be added, but for us Jetway (and Jetway Links) are far more important: we need to let passengers walk through them and right now it's not possible if the airport has been bought on the Marketplace.

Another possible way out of this, lacking a proper support in the API (which would be preferred), might be at least giving Jetways a separate Category, like for Boats, Humans, Animals, at least we could search for them.

Right now, they are returned as StaticObjects and only by setting the search radius to 20001 meters (has this issue being fixed ?), so a very convoluted way we tried to use to know which ones are jetways, is try to read the hood variables on every single StaticObject found in the scenery, and get the ones that don't return an exception. This was just during a test, I wouldn't want to use that method in a real product, but if Jetway data is missing from the Facilities API, I don't see any other ways which could work with Marketplace airports as well standard DRM-free airports.

Please include Jetway data as above listed.

Would be nice to have some confirmation if this feature is at least taken into consideration, because right now the only data about jetways in the new APIs is knowing if a parking has a jetway or not.

While is still useful, it's not enough to make the API really usable, without knowing the jetway position.

And, searching for jetways around the user is hampered by the other bug of not getting all objects (including, but not only, jetways) unless the search radius is set to 20001 meters or more.

And if we really need to search for Jetways, we should have at least have a separate Category for Jetways because right now, they are returned mixed with other objects so, the only way to be sure a found SimObject it's a Jetway, is to try reading the Jetway-specific variables (over possibly 100+ of objects, because of the 20001 meters bug) and catch all exceptions, hardly an efficient or safe way of doing things.

And since there's no way to search for Jetway Links, since they are not SimObjects, those should be probably added to the Facilities definitions as well, since they are usually an integral part of the Jetway.

It would be very useful to have at least the jetway position

@virtuali,

We had a look at this when you first posted and forgot to reply - apologies for this.

The data you are requesting is not as easily accessible as other parts we already return. We'll get back to this and see if/how additional information could be provided.

Best regards,

Eric / Asobo

@EPellissier , it would be very useful it you found a way to know where jetways ( and possibly jetway links ) are.

We noticed another issue, which makes finding Jetways and associated them to a gate even more difficult: it seems that reading/writing Jetway-specific Simvars works with every StaticObject, regardless if it's a Jetway or not. We hoped to use managed data error exceptions to find Jetways that way, but it can't, since every StaticObject accepts reading and even writing Jetway variables, so we don't have any other way than using some heuristic based on their names. And even in that case, their association with a parking position is not very reliable, since we would need to use another heuristic, like assuming jetways are usually placed on the top-left area of the parking radius, which is not very reliable at all.

It we had the Jetway position from the Navdata API, we could just compare its position with the position of the found Simobject in the scene, and be fairly accurate detecting that object as a Jetway.

Some things or alternatives that might help as well:

- Giving Jetways a dedicated Category, one that can possibly passed as a filter to the RequestDataOnSimObjectType call.

Right now, StaticObjects don't have their own SIMCONNECT_SIMOBJECT_TYPE enum, which is another problem, that force searching with SIMCONNECT_SIMOBJECT_TYPE_ALL, reading the Category SimVar and make another pass to exclude things that are not StaticObjects ), if Jetways had their own separate category and a SIMOBJECT_TYPE_JETWAY, the search would be easier and would generate less traffic on Simconnect.

- Fix the bug that requires to set at 20001 meters search range for Jetways to be included in the returned objects, please. This increases Simconnect traffic for no reason, since we need to use that large range, even if we only need to find the Jetway closest to the user.

- Add some SimVars to the Jetway objects indicating their associated parking spot, like the Parking Name, Number and Suffix. This could be used as an alternative to getting the data from the NavData API: once we know a particular parking spots has a Jetway, we could query the SimObjects in the scene until we find the one with SimVars set to match the parking. If this could be added to the previous two points, finding the Jetway closest to the user should be very quick.

But the most important thing missing from Jetways in general is still this one:

- There's not way to know IF and WHERE a Jetway has Docked. We have the Hood variables, which are useful to a point, to at least figure it out a Jetway docked ( if it's not moving and any of the hood variables are not zero, it should have docked ), but the problem is, it doesn't help knowing where it has docked, or if it docked partially because it couldn't reach the door.

This could be fixed if we had some extra SimVars for the Jetway object to report the actual position of the bone associated to the IK_SecondaryHandle, possibly expressed as XYZ offset from the Jetway reference point. This would allow us to know where the jetway end is at the end of the animation.

Hi @virtuali @MaxHype,

Actually if I'm not wrong, you can already retrieve jetway position by looking for the corresponding parking and it has the bias information. You have to compare parking name, suffix and number to jetway members "parking_gate" "parking_suffix" and "parking_spot" respectively (the naming is not great here...)

Regards,
Xavier

Would be possible to get some answer if the BIAS for the Jetway object itself would be added to the Navdata API ?

It's really important for us, to get the actual Simobject in the scene associated to each parking, and searching by name using some heuristic is not efficient ( we need to ask for *all* Simobjects in the scene ), and it's not reliable either, because sometimes the jetway closest to the parking center is not the one associated to it, and some sceneries have double jetways, the working one inserted as a proper Jetway, and a static one as a Simobject with the same title, but not associated to a parking, so it's basically impossible to know which one is the real one.