There are some data missing from the JETWAY data definition: Jetway name
Jetway position ( Lat/Lon Bias from airport center ) Jetway heading A data
definition for a JETWAY_LINK is also missing entirely, and should include:
Link GUID Link Position Link Heading
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
OK but at the moment you have only the corresponding parking bias information,
not the jetway bias
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.
Hi @Darwikey , We already using the fields in the
Jetway data to know the parking the Jetway is associated to, but that only
tells us that parking spot has a jetway, not where it is or how it’s oriented.
Just knowing if a parking spot has a jetway is not really useful without its
position, and searching for it by looking at all Simobjects in the scene has
many issues: - Because of the “20001 meters bug”, we need to search for
Simobjects in a > 20000 meters range around the user, otherwise Jetways won’t
be returned in the search, causing unnecessary traffic over Simconnect, since
with 20k meters, we often get lots of objects even from nearby airports in
some areas. - Because Jetways don’t have a dedicated Category, like Humans,
Animals, Boats do, the above search must be made for ALL Simobject types. -
Because every Static Object respond to read/write Jetway-specific SimVars with
no errors, we can’t use a strategy of trying to read/write to such variables
and intercepting Exceptions in order to recognize which, of the many Static
Objects are Jetways, so we need to use some heuristic based on their Title and
their proximity to the user airplane. - Because some airports have double
Jetways at gates, one inserted as a “proper” Jetway associated to the
TaxiwayParking and a secondary not animated one ( but with the same Title )
inserted as a SimObject outside the parking hierarchy, there’s no way for us
to know which one of the two is the “real” Jetway that will eventually move,
and which one is the secondary/static one, since they are both named as
Jetways and are both close to the user. This would work so much better if API
could be improved in the following way: 1) The Jetway member in Navdata
included a “Bias” field like the TaxiwayParking, and possibly PBH insertion
parameters as well, so we know exactly where that jetway is. 2) Jetways should
have their separate “Jetway” Category, and we could call
RequestDataOnSimObjectType passing a new SIMCONNECT_SIMOBJECT_TYPE enum
possibly named SIMCONNECT_SIMOBJECT_TYPE_JETWAY. It would be best if only
Jetways associated to a Parking spot would be returned this way, while static
Jetways placed as SimObjects outside a Parking spot should keep their Category
as “StaticObject”, because that’s what they really are. This way, having the
Jetway position in the Navdata API, we could compare it with the Jetway
position in the scene, to finally get the Simobject ID, which we can then
query to know about the Jetway status. It goes without saying that, once we
have the Jetway Simobject itself, it would be really useful to have extra
SimVars added to it, indicating: - A flag telling if the jetway is docked or
not, similar to JETWAY MOVING, but indicating the docked/undocked status -
Variables similar to the Hood or Wheels, indicating the position of the
IK_SecondaryHandle as XYZ Bias from either the Jetway root or the airport, so
we could know for sure which door the Jetway has docked, or if has docked
partially, or not at all.
Hi, An article about exposing Jetway Data through SimConnect has been
published today. Could you please check it and give us feedback to improve it.
[/articles/13114/su12-jetway-api-feedback.html](/articles/13114/su12-jetway-
api-feedback.html) Best Regards Maxime / Asobo