I asked the PIS developers about the same symptoms, but they replied to me the GSX developers to ask about what is interfering with the RKSI SODE jetway system
GSX is not "interfering", of course, since it only asks SODE for a list of its own jetways but, in order for GSX to recognize a SODE jetway that has been made with SODE, their associated gate name must be named *EXACTLY* like the matching gate in the AFCAD, because the precise, exact, gate name and number is the only way for SODE to communicate to GSX which jetways is assigned to which gate.
The gate name must follow standard AFCAD naming convention exactly so, for example, a gate named Gate B 23, MUST be referred in the SODE XML file as such:
AfcadGateName="GATE_B" AfcadParkingNumber="23"
That's the only way the gate would be recognized by GSX as well. If the jetway was used only from SODE, the gate name could be specified more loosely, but when GSX communication is involved, the name must be 100% exact and matching the BGL SDK standards, which is the only common frame of reference between GSX and SODE.
Having to stick to the default naming convention in order to enable GSX communication, won't restrict in any way the ability for developers to present the jetways using a more friendly name to users, because SODE has a parameter for that so, to continue the following example:
AfcadGateName="GATE_B" AfcadParkingNumber="23" CustomDesignator="Terminal 1 Gate B23">
The jetway would still follow strict AFCAD naming rules, so it would be recognized by GSX, but it will display with friendlier name on the SODE menu so, no flexibility is ever lost to maintain full GSX compatibility.
So, to reply to your question, the developers of that scenery should be sure they put the precise, exact name and number of the gate according to the SDK in the AfcadGateName and AfcadParkingNumber of the SODE XML file, and eventually use the CustomDesignator parameter to present any name they want in the SODE menu, and this will ensure their jetways will work with GSX.
