Sode unavailable cannot test jetway resolving error

[tybread69]

Hello Umberto. Since the most recent GSX update, I have noticed that in modifying a jetway position, pressing the '5' key to test whether the gate will reach the door, I am getting an error message, "Sode unavailable cannot test jetway resolving." Now, that said, I tested the sode connection, and it works perfectly, the jetways work normally as expected. It's just that I am now no longer able to automatically hit the '5' key to check if the jetway is positioned correctly. I tried uninstalling Sode 1.6.5, and upgraded to Sode 1.6.8, but the problem persists, even though the sode otherwise works fine. Could there possibly be a glitch in the recent GSX update that is causing this, or could it be another issue? I am not sure if this type of problem is on my end or your end. What do you think?

[virtuali]

We are investigating this.

[DVA12924]

I’m just wondering if there is a timeframe to when this can be resolved? Thanks for all your hard work

[Nevarc]

Ouch,  get a lot of SODE disconnection errors tiring to test Jetways

[pete_auau]

Ouch,  get a lot of SODE disconnection errors tiring to test Jetways

read post2 of this  thread

[DVA12924]

If it helps anyone (Humberto) with finding and fixing the issue, I have attached my SODE log flie and also my GSX log file. Key points will be at the bottom of both files since they were only started with the intent to duplicate the SODE jetway issue for the logging.

From SODE log:
[23:34:36.258] DEBUG SODE.XML : XML Data successfully read and List created.
[23:34:36.258] DEBUG  : List generated! Trying now to insert into QuadTree...
[23:34:36.258] DEBUG  : QuadTree populated with SimObject references.
[23:34:36.258] DEBUG  : Trying to generate Aircraft Parameter Map from the INI file...
[23:34:36.265] DEBUG SODE.ACFTPARAMS : Door Parameters read for 32 ICAO Aircraft Types.
[23:34:36.265] DEBUG  : SDX/XML/INI Handling done! Going back to the Dispatch Loop...
[23:34:36.265] DEBUG SODE.FSLOOP : Initialize Position after Reset.
[23:34:36.265] WARN SODE.FOLDERMANAGER : SimObject with SimTitle '12bPilot_SODE_VDGS_NW_Marker': 'UNDEFINED.MDL' does NOT exist!
[23:34:36.319] INFO SODE.FSLOOP : ### FILTERING OBJECTS (R=40000m), Bubble Lat/Lon: 23.396587, 113.301857
[23:34:36.319] INFO SODE.FSLOOP : ### Active SimObjects: 0; Active Wind Data Probes: 0
[23:34:37.191] INFO SODE.FSLOOP : SeasonalObjectHandler: Refreshing Season/Time Data...
[23:34:39.937] ERROR SODE.FSLOOP : [JETWAY CONTROL SYSTEM::EXTERNALLY] ObjID overflow for 'inform' return data [jw=1347442748]!
[23:35:02.195] INFO SODE.FSLOOP : SeasonalObjectHandler: Refreshing Season/Time Data...
[23:36:00.728] DEBUG SODE.FSLOOP :  [API::TRIGGER] Received Trigger Client Data: ObjID=2012, DoorDesignator='1L', OwnFlag=1, DoorDataOverrideFlag=1, Mode=1
[23:36:02.196] INFO SODE.FSLOOP : SeasonalObjectHandler: Refreshing Season/Time Data...
[23:36:03.373] DEBUG SODE.FSLOOP :  [API::TRIGGER] Received Trigger Client Data: ObjID=2012, DoorDesignator='1L', OwnFlag=1, DoorDataOverrideFlag=1, Mode=0
[23:36:27.449] ERROR SODE.FSLOOP :  [API] Unknown API Data received! DefineID = 21
[23:36:43.971] DEBUG SODE.FSLOOP :  [API::TRIGGER] Received Trigger Client Data: ObjID=2012, DoorDesignator='', OwnFlag=1, DoorDataOverrideFlag=1, Mode=0
[23:37:02.193] INFO SODE.FSLOOP : SeasonalObjectHandler: Refreshing Season/Time Data...
[23:37:07.952] ERROR SODE.FSLOOP :  [API] Unknown API Data received! DefineID = 21
[23:38:02.198] INFO SODE.FSLOOP : SeasonalObjectHandler: Refreshing Season/Time Data...
[23:39:02.214] INFO SODE.FSLOOP : SeasonalObjectHandler: Refreshing Season/Time Data...
[23:40:02.199] INFO SODE.FSLOOP : SeasonalObjectHandler: Refreshing Season/Time Data...
[23:40:45.386] ERROR SODE.FSLOOP : [JETWAY CONTROL SYSTEM::EXTERNALLY] ObjID overflow for 'inform' return data [jw=1346042355]!
[23:40:45.386] DEBUG SODE.FSLOOP :  [API::TRIGGER] Received Trigger Client Data: ObjID=2685, DoorDesignator='1L', OwnFlag=1, DoorDataOverrideFlag=1, Mode=1
[23:40:45.386] ERROR SODE.FSLOOP :  [API::TRIGGER] Internal Jetway Instance not found -> NULL!
[23:41:02.197] INFO SODE.FSLOOP : SeasonalObjectHandler: Refreshing Season/Time Data...
[23:41:02.233] ERROR SODE.FSLOOP : [JETWAY CONTROL SYSTEM::EXTERNALLY] ObjID overflow for 'inform' return data [jw=1999037784]!
[23:41:02.233] ERROR SODE.FSLOOP : [JETWAY CONTROL SYSTEM::EXTERNALLY] ObjID overflow for 'inform' return data [jw=1999037784]!



From GSX log:
Added Menu SubItem "Customize airport positions..." (parentId 82, id 100)
User collision geometries reloaded
onEnteredAirport ZGGG
Changed AVATAR id (3)
Avatar mode False
aircraftEngaged
Slew mode False
Warped to Gate 150
aircraftDisengaged
Slew mode True
Requested parking services to Gate 150
Slew mode False
createCamera() BaggageLoaderFront Behind
createCamera() BaggageLoaderFront Driver 1st Person
createCamera() BaggageLoaderFront Loading Area
createCamera() BaggageLoaderRear Behind
createCamera() BaggageLoaderRear Driver 1st Person
createCamera() BaggageLoaderRear Loading Area
createCamera() PushBack Driver 1st Person
createCamera() PushBack Behind
createCamera() PushBack Front
Total payload:13873 lbs.
Estimated number of passengers =  64
Total payload:13873 lbs.
Estimated number of passengers =  64
Warning: attempted requestData on destroyed SimObject
aircraftEngaged

Full logs are attached, but those are where the errors were happening. I hope we can get this resolved soon.

[virtuali]

As I've said, we are already investigating this, together with SODE author, because it seems some changes in both GSX and SODE will be required.

[DVA12924]

Is it possible to undo whatever was done to cause the issue until GSX and SODE have found a fix to this? The jetways are completely unusable at this point as SODE will disconnect while I’m on final approach to any airport. At least if we can revert back to a working version then we can use the jetways again. I’m having this issue in P3Dv4 as I’m not doing anything more that testing right now with v5 so all my actual full flights are in v4. I know you’re working on it and that is appreciated, but for me, the ability to customize and use SODE jetways was a big selling point to buy GSX.

[virtuali]

Is it possible to undo whatever was done to cause the issue until GSX and SODE have found a fix to this?

You might try an older version of SODE, like 1.6.5 which came with the previous GSX version.

We haven't changed anything in GSX, we are working on some SODE-related changes that will allow AI docking but, none of these changes has been released to the public version yet.

[DVA12924]

I’ll give that a try and report back. I am fairly certain that I had 1.6.5 installed when the issue came about and updated to 1.6.8 in hopes of resolving the issue, as that was said to be a “fix” for SODE disconnect errors.

[virtuali]

I am fairly certain that I had 1.6.5 installed when the issue came about

This conflicts with the OP, which starts with "Since the most recent GSX update" and refers to the TEST function in GSX that stopped working for some reason.

As I've said, we haven't changed anything in the GSX jetway editor code in a while, the only change in the latest GSX udpate is that it comes with a newer SODE, which is mandatory to support P3D V5. The GSX installer now comes with 1.6.7, which was very short lived, since 1.6.8 came out recently and a newer one will surely come to support AI with GSX.

As I've said, we are working on it, if you already had this problem ( are you referring to TEST function, which is what this thread is about ? ) with 1.6.5, then it means your problem might be an entirely different one and you might always had it so, chances are, the work we are doing right now for jetways to add AI support, might lead to find any leftover issues which has always been there.

[DVA12924]

I first noticed the issue on April 18. While making my approach into KSFO, P3Dv4 became very slow and laggy for a few seconds. This was while on final approach. Once I landed and ATC assigned me a gate, I went into GSX menu to select that gate to activate it and then I got a SODE disconnected error and when I parked at the assigned gate, the jetway would not work. I did notice the SODE jetway to the gate beside me was attached to an AI aircraft. I thought that strange because I’d never seen that before and thought that may have been the issue - Too many SODE commands coming in all at once which would have slowed the sim down and could have caused the SODE crash. I made sure the “detect ai” option was off in SOFE manager. I then went to start editing my next destination and found that I was still getting the error and started researching. I found a post that others with the same issue reported it resolved by updating to 1.6.8 and at that point is when I updated SODE but the issue still remains. The KSFO scenery is from FlightBeam, but I am having the exact same issue at a freeware AFCAD file for ZGGG and also at the default P3Dv4 airport.

[DVA12924]

I’ve just tested SODE 1.6.5 and it’s still the exact same error. I first uninstalled 1.6.8 and deleted the 12b folders in program data and program files x86 to ensure that I would be a clean reinstall. I then restarted my computer and then installed SODE 1.6.5 without copying back the backed up files for the airports I have installed that use their own SODE jetways.

Once P3Dv4 is open, I select my CRJ900 and place it at a gate at ZGGG (freeware afcad) and open gsx menu and select “customize airport positions” and click “customize jetway” ... I then push shift+numpad 5 and after a 3-5 second delay, I get the error “SODE disconnected” immediately followed by a gsx error “gate 150 no SODE object. Jetway will not resolve” or something along those lines.

Without doing anything more than then pressing y to exit the editor and closing the editor window, I can pull up the gsx menu using ctrl+f12 and the jetway will connect time the aircraft, but there is also a static jetway still where the resting position of the jetway should be. It is an exact replica of the jetway that attaches, but static ... same type, same bridge, same textures, same logo. I don’t know if any of that helps but I’ve been using GSX L2 and SODE 1.6.5 for a long time and did not have any issues until both GSX and SODE were updated for the release of v5. Since I’ve reverted back SODE the issue still remains, it is not the version of SODE that is causing the conflict.

[virtuali]

I’ve just tested SODE 1.6.5 and it’s still the exact same error.

Then it means it must have been a problem you always had.

both GSX and SODE were updated for the release of v5. Since I’ve reverted back SODE the issue still remains, it is not the version of SODE that is causing the conflict.

As I've said, nothing that has anything to do with the jetway editor has been touched in GSX for P3D V5. The only changes we made, is the installer that knows about V5 locations and folder entries, and the Addon Manager has "Render To Texture" disabled in V5, because DX12 is not yet supported, which would result in blank jetway logos. Other than that, the code is exactly the same.

But as I've also said, the work we are doing now ( which we haven't released yet ) to support AI, will surely result in changes to the jetway handling in GSX so, after they'll be out, it's likely those problems you surely must always had and only noticed it now, will eventually be fixed, since we'll obviously have to undergo another round of testing of the jetway functions which, as I've said, hasn't been touched in many months.

[DVA12924]

I’ve never had the issue before. I fly with a large VA and have a database of over 9,000 routes. I use GSX to edit and adjust every single parking position of every single airport before I fly to it checking every jetway connection. Furthermore I have logged over 2,000 flights since I’ve purchased GSX and never once did SODE connection disconnect error on final approach. I 1 million % assure you I have NEVER had this issue before. And the fact that I am not the only one reporting this as a new issue should be further evident of that. If I had had any issue whatsoever with either GSX or SODE I would have immediately reported it as I rely on both of those programs properly, yet myself nor any other user reported this until the last release.

This issue started when GSX was updated after v5 release along with SODE. However, before GSX update, I had no issues with SODE. I did not update SODE from 1.6.5 to 1.6.8 until after I had got the error. You can even see in the logs posted above that SODE shows “ [23:40:45.386] ERROR SODE.FSLOOP :  [API::TRIGGER] Internal Jetway Instance not found -> NULL! “ with GSX throwing this error at the same time “ Warning: attempted requestData on destroyed SimObject ”

So to me, that looks like SODE tried to request jetway data from GSX and GSX reported that the jetway (SimObject) was destroyed.

Seriously, don’t put the blame of this back on the user. I have more than enough evidence to prove this issue did not start until after the last updates. GSX blames SODE and SODE blames GSX. If reverting back to a known working SODE version doesn’t work now, clearly the issue isn’t SODE.