FSDreamTeam forum
Products Support => GSX Support FSX/P3D => Topic started by: tybread69 on April 19, 2020, 02:24:37 pm
-
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?
-
We are investigating this.
-
I’m just wondering if there is a timeframe to when this can be resolved? Thanks for all your hard work
-
Ouch, get a lot of SODE disconnection errors tiring to test Jetways
-
Ouch, get a lot of SODE disconnection errors tiring to test Jetways
read post2 of this thread
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
I would like to kindly ask you to stop making assumption or provide "evidence", when you don't know how GSX works, how SODE works, how the connection between the two works and the constant work we have been doing, even as we speak, with SODE author trying to understand what's going on.
NOBODY is "blaming" anybody, you are getting all wrong, really. As I've said, multiple times, the ONLY thing that has changed in the GSX update you have right now is SODE.
That doesn't obviously mean I'm saying SODE it's at "fault", but I'm sure something must have changed, possibly to fix other issues and we think we found it and, again, it's something that is different now, since we think to have FOUND why it happens and, as I've said (multiple times), it's happening in a part of code we haven't changed, and always worked.
So, either you already had this problem, or something else must have changed in how you are testing.
Obviously, we already found a way to fix it but, since it would involve changing a code that always worked for years, before publishing it, we are asking to Jeffrey his opinion about this, because it can probably done even more efficiently, with a SODE update that would include an additional function it NEVER HAD, which would prevent being confused when a jetway that is being tested is being moved.
Again, you don't really know how the two work together, so it's really useless explaining this in any more detail but, I'll repeat it again, to prevent this from happening, we would both require to make a (small) change in a part of GSX code that USED TO WORK ( your words ) AND we'll likely require another SODE update as well.
I could offer proof but, unfortunately, it won't help much for you, not knowing how GSX+SODE really work together but, just as a sign I'm not blabbering BS, try this:
To test a jetway, instead of using the "customize Jetway" button, use only the "Customize Parking" button, don't try editing the jetway itself, but test it when you are editing the PARKING ITSELF.
and never once did SODE connection disconnect error on final approach
Now you are getting me confused. This thread was about the Jetway TEST function. That's all what I'm talking about.
Not that we changed ANYTHING in GSX during the approach. I think I already said quite clearly what has changed in the latest GSX update: nothing that can possibly have anything to do with SODE.
-
I do know that on airports that come with their own SODE, you must test the jetway from the parking position, not the jetway itself while in edit mode. If that’s all that had to be done, you could have stated earlier or even put that in the release notes. I understand how programs work and communicate with each other. Please don’t assume my level of intelligence. Secondly, it’s how it was perceived when you said that is an “issue (I’ve) had all along” - that does not indicate that you were able to find a code that had always worked and now doesn’t so the issue was lying dormant in the code itself, it seemed more like you were saying that I have always had a disconnect error when testing a jetway from the jetway edit and just never said anything about it until now.
Since I haven’t done another flight since April 18 (haven’t been able to edit my next destination due to unable to verify jetways will connect while editing) I cannot say for certain at this moment if SODE disconnecting on final approach to the 1 flight I have done was a result of this same code, or a result of SODE attaching to AI. I do know that once I landed and called GSX to activate my assigned gate I got an error message about jetways not resolving but everything else GSX related worked correctly. Of course I couldn’t see the passengers because there was no connected jetway.
I will try as you suggested to test the jetway connection from the parking position editor and report back.
-
I do know that on airports that come with their own SODE, you must test the jetway from the parking position, not the jetway itself while in edit mode.
That's not really relevant here.
If that’s all that had to be done, you could have stated earlier or even put that in the release notes.
We found out only TODAY! As I've said, for the umpteen time, it's something in a part of the GSX code that hasn't changed since quite a while. Only SODE is new so, what reason we would have to suspect a problem, considering we haven't changed *anything* in the released code related to jetways.
We are working on it, to add AI support, and that's why we are doing many tests NOW, but none of these changes has been released in public yet.
I understand how programs work and communicate with each other. Please don’t assume my level of intelligence
Intelligence doesn't obviously have anything to do with this.
You don't know, and you cannot possibly know, because you cannot possibly have seen the GSX code. It's not the general "method" I was referring to, they obviously connect through Simconnect, but you cannot possibly know exactly what GSX does and why, for example, it behaves differently when you test when editing a Jetway or when you test when editing a Parking. Are you able to answer this question ? Obviously not, that's why you cannot possibly know.
it seemed more like you were saying that I have always had a disconnect error when testing a jetway from the jetway edit and just never said anything about it until now.
Only because I wanted to believe your report you said you never had a problem with the Test jetway function. I also NEVER had a problem with it, since I know the GSX jetway code hasn't changed ( you cannot be sure, I am ), then the only possible explanation left, is that something in SODE must have changed. Maybe to fix OTHER problems but again, the lack of the TEST function has been found just these days and, even if we would be aware before release, it still doesn't seem reason enough to not relase for P3D V5, it's not as if you constantly test jetways...
That doesn't obviously mean it will not be fixed, because it will surely will, but it's not something you cannot fly without it.
-
If I’m going to fly to an airport, I’d like for it to have all the functions I’ve paid for - customizable working SODE jetways and visual passengers. As I have said before, I DO test every single jetway for an airport prior to flying to as to ensure that once I arrive, I will park in the correct position, the vehicles will be in a position to not interfere with the surroundings, and the jetways will connect. I do this by taking the parking size from the AFCAD and exporting it over to an excel file I have that then tells me from the fleet of aircraft I fly the absolute largest aircraft that will fit in that spot and then load the aircraft, check the scenery for errors, then set up each position for that aircraft before moving on the the next aircraft set. If the jetway tests correctly in the edit mode for that aircraft, it will 99.9% of the time work on a smaller aircraft.
So yes, every jetway is tested at every airport prior to a flight. If I did not want customizable working SODE jetways and passengers at both departure and arrival, I would never have bought level 2. But without testing the jetway first, you don’t know if it will resolve correctly or not until you arrive and if it does not, then I am not getting what I have paid for.
-
I will confirm that testing from the parking position and not from jetway does in fact still work. This is with SODE 1.6.5 as I have not reinstalled 1.6.8 as of yet.
I'm glad you found the error and appreciate that it is being looked into for resolution.
-
If I’m going to fly to an airport, I’d like for it to have all the functions I’ve paid for - customizable working SODE jetways and visual passengers.
You got it backwards: would you rather not use the WHOLE GSX ( in P3D V5, in this case ), just because it's either working with 100% of the features, or shouldn't have even released ?
Not that this makes any difference. As I've said, we discover it AFTER we released the update, following this thread. Something must have changed in SODE (and I'm NOT saying it's a bug, there's likely a reason for it), that seems to require a change in a part of GSX that ( you said it yourself ) always worked and, if you want me to believe you you never had problem, by the same account you should believe me when I said we haven't changed anything in the GSX handling of jetways.
Well, not 100% true. We are changing something but, none of these changes are part of the update that has been released now, which addresses ONLY P3D V5 compatibility and THAT'S why it came with an updated SODE.
-
If I’m going to fly to an airport, I’d like for it to have all the functions I’ve paid for - customizable working SODE jetways and visual passengers.
You got it backwards: would you rather not use the WHOLE GSX ( in P3D V5, in this case ), just because it's either working with 100% of the features, or shouldn't have even released ?
Not that this makes any difference. As I've said, we discover it AFTER we released the update, following this thread. Something must have changed in SODE (and I'm NOT saying it's a bug, there's likely a reason for it), that seems to require a change in a part of GSX that ( you said it yourself ) always worked and, if you want me to believe you you never had problem, by the same account you should believe me when I said we haven't changed anything in the GSX handling of jetways.
Well, not 100% true. We are changing something but, none of these changes are part of the update that has been released now, which addresses ONLY P3D V5 compatibility and THAT'S why it came with an updated SODE.
I don't know where you're getting version from ... I have said nothing about even testing GSX in v5 so I don't know if it is working fine there or not (I am not flying in v5 yet because no real world weather). I am testing my addon scenery, my addon aircraft, my VA ACARS system, and my settings in v5. I did not even look at GSX in v5 because I do have so few issues with it that I assumed it would be working fine. This has nothing to do with versions and you are the one who brought that up so don't even put that on me lol. Since I have never used SODE outside of GSX, I have no way of knowing if it is SODE or GSX, soI leave it up to you and SODE to find and resolve the issue (which you are both doing) and I only report the facts of the issue (information that may help find and fix the problem).
So forgive me for trying to help by providing information only so you can go and get an attitude with me and twist my words about what I have (or have not) said to try to make me look bad. We have found a work-around that keeps everyone happy until the issue is fully resolved. That's all I was asking for...there was NEVER a need for you to get such a hateful attitude with me when DAYS ago you could have said "try testing from the parking editor and not the jetway editor and see if that works because they are separate" -- We are here because we need your assistance, not your attitude. Help us find solutions and work-arounds, not just get angry every time someone asks for help. After all, is it not part of your job to be here helping us with GSX?
-
there was NEVER a need for you to get such a hateful attitude with me when DAYS ago you could have said "try testing from the parking editor and not the jetway editor and see if that works because they are separate" --
You got it wrong, again. "DAYS" you say ? When I told you to try that, I wrote this:
We found out only TODAY!
Why you keep implying we "knew" about this problem, when clearly said otherwise ? I was only trying to:
- help you finding an alternative, while we release an update.
- prove you we are on top of it.
Bonus tip: testing from the parking is probably faster and more useful than testing a single jetway ? Why ? Because testing from the Parking will test ALL jetways there, while testing from editing a jetway, will only test *that* particular jetway you are editing, so it's probably faster if there are more than one jetway to test from the parking.