SODE Jetways not recognized by GSX at some recent third party airports

[Timothy Metzinger]

I have FSDT GSX/GSX Level 2, and I'm finding that at SOME of the Drzewiecki Design airports (I discovered this in Krakow), GSX doesn't recognize that the SODE jetways exist.  That means that GSX tries to board passengers via buses and stairs, which is ugly.  So I'd like to get this figured out.

I have the following DD products, and here's the status of interoperability with GSX:
NY Airports V2 X - Jetways are recognized by SODE and GSX at KLGA,and KJFK
Seattle X -  Jetways are recognized by SODE and GSX at KSEA, KBFI, and KPAE
Washington X -  Jetways are recognized by SODE but not by GSX at KDCA.
EPKK Krakow X V2 -  Jetways are recognized by SODE but not by GSX at EPKK.

I'm also having a similar issue with the new SXAD KHOU scenery, and the developer has acknowledged/reproduced that issue and is looking to see if it's an issue in his code somewhere. 

I suspect that this is a case of the sceneries in question using a property or name or something in their config that GSX just doesn't parse correctly, since the sim and SODE obviously recognize and display the jetways.  I'm just asking for assistance from the scenery developers because if they know what's "different" about these products compared to the way they build SODE jetways in other products, that knowledge will be helpful to solving the problem.

Best wishes,
Tim

[maxhades]

Same here since the latest update.

[Timothy Metzinger]

That's an important data point - do you recall if it was working before the update?  I installed Krakow after the update but can't be certain that GSX was working at DCA beforehand.

[virtuali]

I suspect that this is a case of the sceneries in question using a property or name or something in their config that GSX just doesn't parse correctly, since the sim and SODE obviously recognize and display the jetways.

The problem cannot have anything to do with a recent GSX update, since communication with SODE hasn't changed since a long while, way before GSX Level 2 has been released.

Instead, a while ago, SODE got an update that enforced a more strict naming convention, to be sure the jetway is identified to correct parking, and this resulted on some older sceneries using SODE to stop working with GSX, see this message here:

https://www.fsdeveloper.com/forum/threads/sode-and-gsx.441240/

So, it's difficult to say, without checking both the scenery AFCAD and the SODE XML file for that scenery.

[Timothy Metzinger]

I've confirmed this problem existed before the update by rolling back, and DD KDCA jetways did not work with GSX then either.

It sounds like the potential culprit is that the jetway in the SODE isn't aligned (an exact match) with the parking defined in the AFCAD - do I have that right?

Since I know the normal reaction of a software developer is to blame another software developer rather than do recoding...

Is the "alignment" of XML/AFCAD a GSX requirement?  I mean, since the jetway is controllable by SODE, it's not violating any SODE rules, right?  It's just not aligned in a way that GSX says "THIS jetway is associated with THIS parking".     What I'm worried about is DD telling me to take a walk, since it "works" as far as they are concerned.

On the other hand, if there were a published standard that they were violating, it would probably be easier to get it fixed

Anyway, I've passed along the hint that perhaps the AFD/XML files need to be reviewed.  Will  update this thread here if anything happens.

[virtuali]

It sounds like the potential culprit is that the jetway in the SODE isn't aligned (an exact match) with the parking defined in the AFCAD - do I have that right?

As explained in the post I linked in the SODE forum, made by SODE author himself, then yes, the jetway parking name in the SODE XML file should match the parking name in the AFCAD perfectly, and this stricter enforcement of the rules appeared in a later SODE update, not sure exactly when, but a certain point it required several sceneries using SODE to udpate their XML.

Is the "alignment" of XML/AFCAD a GSX requirement?  I mean, since the jetway is controllable by SODE, it's not violating any SODE rules, right?  It's just not aligned in a way that GSX says "THIS jetway is associated with THIS parking".

The requirement is very sensible, and it's part of the SODE standard, it's just that without GSX, you might not notice it, because I believe SODE CAN figure out the parking/jetway association even by its position, which is possible, but not always reliable. When parking spots are close, especially when a large one is closer to a smallest one, searching by position might not work, and you might end up in the wrong jetway being called (the one from the nearby parking).

That's why it's best to have the parking name in the jetway XML to perfectly match the AFCAD, not "just" to make GSX happy, but to make even stand-alone SODE to work more reliably.

[Timothy Metzinger]

An update - DD agreed to look at their files, and SXAD agree it's an XML/AFCAD issue and are working on it.


EDIT - DD and SXAD have released updates!