FSDreamTeam forum
Products Support => GSX Support FSX/P3D => Topic started by: DVA12924 on May 01, 2022, 07:28:29 pm
-
Forgive me if this was already address somewhere in the thousands of threads here. Using P3Dv5.3.17.28160, latest GSX live update, and Imagine sim KATL. Yesterday I used GSX to fly into KATL in the CapSim B757 and deboard without issues. Today when I attempt to load up the FSL A320 at the same parking position in KATL, GSX menu will pull up, does not read correct "pax number (based on aircraft)" because I put in 148 pax and cargo in the FMS and GSX pulls up 20 pax, GSX allows me to select the jetway to the desired door and then begins to move the jetway. Immediately when the jetway would be done moving to dock with he door, P3D freezes and then a few seconds later a complete CTD of P3D. Since I did not have an issue at all when arriving at KATL at the same parking position but different aircraft, I think it is safe to rule out the scenery or aircraft.
As I said in a prior post about a different topic, I have been away from flight sim for almost a year and with everything being updated, it is possible that I may have missed a simple change in settings in either GSX or FSL A320 to allow the 2 to function properly now. I have not changed any settings on anything, only updated to latest versions, and everything worked without issues the last time I used the FSL A320 over a year ago.
-
It's probably best not to start a thread with such title before being sure GSX is really the "cause" of a problem. Especially when you seem to draw the wrong conclusion from your own report:
"Since I did not have an issue at all when arriving at KATL at the same parking position but different aircraft, I think it is safe to rule out the scenery or aircraft"
No, it's not safe to rule out aircraft. In fact, from your own report, is still possible the problem might well be the aircraft, of just the way you are using it.
GSX menu will pull up, does not read correct "pax number (based on aircraft)" because I put in 148 pax and cargo in the FMS and GSX pulls up 20 pax
GSX IS reading the number of passenger from the aircraft, it's just the aircraft is telling GSX you have 20 passengers.
The reason why I'm 100% sure this is the case, it's because I know the FSL A320 is explicitly setting 20 passengers, when it doesn't know what to set. It was a number we suggested to FSL, because they wanted a way to prevent getting the small Van, when the user didn't set the payload correctly or not at the correct time or not in the correct way so, regardless of the situation, when the FSL doesn't have enough information about the Pax number, it will set to 20 by default, which is slightly higher than the maximum allowed for the Van, so you'll always get the Bus no matter what.
So yes, GSX is doing what it's supposed to do: reading the passenger number from the airplane, you only need to understand why FSL is setting the GSX variable to its default value ( the FSL default, for GSX, the default it's 0, if it's not zero, it means the airplane has set it, because is being reset to 0 each time a new plane is loaded ), instead of the correct one.
Of course, before posting, I checked it, couldn't reproduce it, and made a video:
https://youtu.be/sSTLRYvSLDM (https://youtu.be/sSTLRYvSLDM)
As you can see, I had 93 passengers set in the ATSU, some cargo, called GSX, which confirmed 93 passengers, and after the jetway moved, Deboarding started normally. I don't have any add-on for KATL, so I used the default version but, since you said yourself we can safely exclude the airport ( and I think we can, since if it was a problem with GSX at that airport, it would happen with every airplane ), it's likely there must be something wrong in the communication between GSX and the A320, but I couldn't reproduce it.
-
I don't think the title is inaccurate. I'll explain it again:
1. Using GSX with Captain Sim 757, ARRIVED at KATL, de-boarded without any issues.
2. Closed sim and all addons/eternal sim programs and planned next flight.
3. Using GSX with FSL A320, loaded up at the exact same gate I had previously arrived at, loaded data into ATSU, called GSX to start boarding, immediately froze and then CTD when GSX should have given the message that boarding had started as the jetway finished moving.
I was also able to use the FSL A320 without GSX with no issues - with all addons and programs I use for every flight active except GSX - parked at the gate, loaded pax and cargo in ATSU (verified with VA external ACARS system which reads the pax and cargo data from the aircraft), taxied out to runway, took off and flew for 20 minutes after take off with no issues at all. This should easily rule out the aircraft, scenery, and other addons and programs.
So by process of elimination:
Aircraft - no issues without GSX being used - no CTD - not the cause of CTD
Airport scenery - no issues with GSX upon arrival - no CTD - not the cause of CTD
Other addons I use for P3D including external programs - all worked with GSX and other aircraft in prior recent flights - no CTD - not the cause of CTD
GSX - caused CTD when calling jetway to FSL A320 in boarding after pax and cargo data put into ATSU - positive CTD - this is the cause.
So the only program that caused CTD was when GSX was bringing the jetway to the aircraft. How is the title wrong then? The CTD is specific to ONLY when using GSX with FSL A320. No conflicts with any other aircraft or any other addon. I fly with a virtual airline with an external ACARS program that was reading the data I put into the aircraft ATSU without problems. So I know that the data is there.
I was stating that perhaps some time in the last year GSX may have made some adjustment to how it interacts with the FSL A320 which may be the cause of the CTD for me. Since you are the developer, that would put you in the best position to know if that is the case. I do not have access to the change logs over the last year I was not using or updating anything, and therefore cannot say that is the case myself.
The problem here is not that GSX is saying there is 20 pax. I have the settings so that I can change that number if needed. The issue is that there is a CTD caused by GSX when the jetway is reaching the aircraft in boarding. Despite being away for a year, I still follow checklists including for getting the aircraft set up in the sim and loading pax and cargo. These steps were the exact same steps I took when I was previously active and did not cause any CTD with GSX and the FSL A320. This is why I stated that perhaps GSX changed a way it interacts with the FSL aircraft and is now causing a CTD when previously it had not.
In your video, I have set the pax and cargo the same way and when the message "[GSX] Airplane with custom Battery and support for Jetway Power Unit." message SHOULD appear is where P3D initially freezes and the followed a few seconds later by CTD. Perhaps this can help you figure out where the conflict is and assist in resolving it. But I can say without a doubt that the issues happens ONLY when using GSX, ONLY when using the FSL A320 (I don't have other FSL aircraft to test with), and at ANY scenery. The only common variable for the CTD is GSX connecting the jetway to the FSL A320.
-
But have you tried using GSX on the A320 without doing it through the airplane.
-
But have you tried using GSX on the A320 without doing it through the airplane.
What are you asking? I open and use GSX from the GSX menu (Ctrl+F12 on my system). How else would you use GSX?
-
What are you asking? I open and use GSX from the GSX menu (Ctrl+F12 on my system). How else would you use GSX?
I am pretty sure the FS Labs A320 has GSX integration, so unless I misunderstood what that meant, I thought it was possible to use GSX without opening the GSX menu on this particular aircraft. I don't own the aircraft, so I can't verify.
-
GSX - caused CTD when calling jetway to FSL A320 in boarding after pax and cargo data put into ATSU - positive CTD - this is the cause.
Except it's not, and please stop again to say "GSX is the cause", because it clearly isn't.
If the crash ( which as I've shown on video, doesn't happen here, with the FSL A320 and GSX ) if it's really happening when "GSX calls the jetways", there's another program at play, which is SODE, because GSX doesn't animated jetways, SODE does.
So the only program that caused CTD was when GSX was bringing the jetway to the aircraft. How is the title wrong then?
See above. You forgot SODE, and the aircraft itself. And why you "excluded" the airplane ?
I was stating that perhaps some time in the last year GSX may have made some adjustment to how it interacts with the FSL A320 which may be the cause of the CTD for me. Since you are the developer, that would put you in the best position to know if that is the case. I do not have access to the change logs over the last year I was not using or updating anything, and therefore cannot say that is the case myself.
We couldn't possibly have changed anything in the way GSX interacts with the FSL, or any other airplane, simply because GSX DOES NOT interact with any airplane. All GSX is doing, is publishing some variables the airplane can read, and act with its own code and procedures.
I'll repeat it again: there's no single line of code we wrote that has any knowledge of a *specific* aircraft. Whatever integration is happening, is happening entirely in the airplane own code. The airplane can control GSX, but GSX can't control the airplane, the only rare case in which GSX takes very little control of the airplane, is during pushback.
The problem here is not that GSX is saying there is 20 pax. I have the settings so that I can change that number if needed.
You said it was a problem, I just told you why they are exactly 20, it's the FSL that set that specific default value, to prevent users using it in the wrong way or at the wrong time to ever get the Van. So, whenever you see 20 passengers, it means you are not following some FSL-specific procedure, because (again) it's NOT a value GSX sets by itself.
The issue is that there is a CTD caused by GSX when the jetway is reaching the aircraft in boarding
Nothing in your report tells the crash is "caused" by GSX.
In your video, I have set the pax and cargo the same way and when the message "[GSX] Airplane with custom Battery and support for Jetway Power Unit." message SHOULD appear is where P3D initially freezes and the followed a few seconds later by CTD.
And what makes you think it's GSX that "caused" this ? It might well be the very well known problem of the sim ITSELF crashing due to just the DISPLAY of the message, LM has confirmed they still haven't found *all* issues with HTML5 menus and texts, so there are some situations in which something that display a menu or a text message, results in the sim crashing, for example it might happen because BOTH GSX and ANOTHER add-on tried to display some text at the same time, so it can't always happen, or it can't happen to me, because I don't have any add-on other than GSX and the FSL.
But it's a known fact both menus and texts are still not 100% stable with P3D V5, and since GSX use them a lot, this often misleads users assuming GSX "caused" a crash, when in fact the sim crashed on its own due to its menu/text system ( it's the same system and the same Simconnect call ). It always happen then, if there's a problem with the menu/text system, people always blame GSX, happened so many times in the past, and not a single time it was ever caused by GSX and 100% of the time it was always fixed with a patch by LM. Now it's better than it used to be, but it's still not 100% rock solid.
-
How else would you use GSX?
Have you tried following the ATSU tutorial supplied with the FSL documentation ?
-
Video links at end of this post.
If the problem was with SODE, when why would it work without issues in a different airport? Why would SODE also work flawlessly with the other aircraft I fly (Captain Sim 757, Carenado Saab 340, Aerosoft CRJ 900, PMDG 737, PMDG 747, PMDG 777)?
As I stated, I flew the FSL A320 on a test flight and no CTD. The only single thing different from the test flight in the FSL A320 and the CTD is using GSX. So how does that not clearly say that this is GSX and nothing else? CTD happens ONLY when using GSX to call the jetway to the FSL A320 - at no other time do I get any errors, CTD, or any problems at all EXCEPT when I open the GSX menu and call the jetway. I don't know how I can be more clear with this. I do extensive testing before I point the cause to a specific program or addon and I have eliminated everything else except GSX at that particular point in the use. I can also use SODE directly to call the jetway to the FSL A320 (not using GSX) and it works just fine.
With the original flight in the OP, I switched to the PMDG 737 and had no issues at all for the entire flight. So that again shows ruling out SODE, the scenery, GSX with other aircraft, all the addons and programs used during every flight. And again, the FSL A320 test flight was done using every addon and program used in every flight EXCEPT GSX and again there was no CTD. When using GSX with the FSL A320, 5 times in a row at the exact same point (calling jetway) I got a CTD - take away GSX and no CTD.
There is literally overwhelming evidence to support this. I have created 2 videos showing many tests in which you'll see 2 CTD when using GSX to call the jetway from the FSL A320, 1 non-CTD when using SODE to call the jetway to the FSL A320, 1 non-CTD when using GSX to call the jetway to the PMDG 737, and finally the A320 taxi showing that it is not the aircraft itself. I would LOVE to know how you can say it is not GSX causing the CTD at this point when there is the proof that it only CTD when using GSX to call the jetway to the FSL A320.
The videos needed to be in 2 parts because of a 15 minute max timer on recording and switching between planes to load the A320 over and over took quite a bit of time. If there is anything else you'd like me to try to resolve this issue, I'd love to hear it.
https://youtu.be/iMLrzJwQYeI (https://youtu.be/iMLrzJwQYeI)
https://youtu.be/dH6KD3UZA7A (https://youtu.be/dH6KD3UZA7A)
-
If the problem was with SODE, when why would it work without issues in a different airport? Why would SODE also work flawlessly with the other aircraft I fly (Captain Sim 757, Carenado Saab 340, Aerosoft CRJ 900, PMDG 737, PMDG 747, PMDG 777)?
If the problem was GSX, why it would work without issues with other airplanes and airports ? Why would GSX also work flawlessly with the other aircraft you fly (Captain Sim 757, Carenado Saab 340, Aerosoft CRJ 900, PMDG 737, PMDG 747, PMDG 777)?
Your works.
So how does that not clearly say that this is GSX and nothing else? CTD happens ONLY when using GSX to call the jetway to the FSL A320 - at no other time do I get any errors, CTD, or any problems at all EXCEPT when I open the GSX menu and call the jetway. I don't know how I can be more clear with this.
Because there is when SODE starts moving the jetway. So, there are at least three other possible causes: either SODE or, more likely, the P3D MENU ITSELF, or possibly the airplane code that I know for sure does some interception of the GSX menus, but I'm not entirely sure when this happens.
With the original flight in the OP, I switched to the PMDG 737 and had no issues at all for the entire flight. So that again shows ruling out SODE, the scenery, GSX with other aircraft, all the addons and programs used during every flight.
It surely rules out GSX and the other stuff, it doesn't rule out the FSL A320, on YOUR system. There was a reason why I posted a video with it, to show they work together just fine.
And again, the FSL A320 test flight was done using every addon and program used in every flight EXCEPT GSX and again there was no CTD. When using GSX with the FSL A320, 5 times in a row at the exact same point (calling jetway) I got a CTD - take away GSX and no CTD.
Wrong conclusion, again. If the real cause of the problem is another add-on calling the menu or using the text system *together* with GSX, by removing that add-on, you are mislead thinking the cause was GSX, when in fact it was the fact the other add-on was present *together* with GSX.
There is literally overwhelming evidence to support this.
There isn't a bit of evidence in anything you said to support GSX is the "cause". You are keep confusing cause and effect. I don't doubt you have a crash in that situation, but I'm sure it's NOT GSX.
Because, as explained so many times, GSX runs completely external to the simulator, so it's completely isolated from it, this is not really something open to discussion, it's the way Windows works: an external .EXE CANNOT access memory from another process, thus it cannot cause a crash.
I have created 2 videos showing many tests in which you'll see 2 CTD when using GSX to call the jetway from the FSL A320
So videos are now valid as evidence for you ? Then why you don't ask yourself why it doesn't crash on MY video ? FSL A320, calling the jetway and setting the correct passenger number, which was another issue you had.
And, do you think you are the only one using FSL + GSX and calling jetways ? Don't you think, if the problem was really *caused* by GSX, we would have heard of it already ? I checked the FSL forum as well, there's nothing similar reported there. And, when FSL suspect a problem with GSX, they usually contact me to check it.
-
Also, after looking at your video, I'm 100% sure it's NOT GSX, and it's easy enough to recognize it:
You wrote the CTD happened when the jetway "touches". Well, it's NOT happening when it touches, it's happening a few seconds BEFORE, when it's still in the middle of its movement.
And, at this time, GSX is not doing ANYTHING! On a scenery that comes with its own SODE jetways, meaning they are NOT created by GSX, the sequence of operations works like this:
- SODE has communicated to GSX a list of jetways created by SODE when you entered the airport, so GSX will know it shouldn't create any jetways there.
- When you select the jetway from GSX, GSX will communicate to SODE the airplane door coordinates, according to GSX config for that airplane, and then will ask SODE to move the jetway.
- During the ENTIRE jetway movement, SODE is controlling the jetway by sending commands through Simconnect, and GSX is only waiting for SODE for a message indicating "I've docked the jetway".
- The message from SODE will come AFTER the jetway hood animation has completed, but your CTD happened BEFORE that so, clearly, it couldn't possibly be GSX, that was still waiting for SODE, while SODE was animating the jetway.
So, the only thing your video has proved, is the CTD happened at a time when GSX wasn't doing anything. And, since it work with another airplane, it clearly can't be an issue of communication between GSX and SODE, because this system is proven to be reliable.
Also, you started your video by saying you don't have any add-ons other than GSX and FSL. Well, that's clearly not the case, since your P3D title bar shows you have Wideserver running, and the red name of your main window says the camera is from Chaseplane, so you have at least these two running, according to what I can see.
-
I said "touching" originally because I was in the cockpit view and couldn't see where it actually was. My fault. What I do not understand is why does the same jetway work when not called by GSX but directly from SODE but does not work when used by GSX?
Did you see the video of where the jetway connected fine to the FSL A320 using the SODE menu and not GSX menu? So how can it be SODE? There is something not communicating properly here.
I am not saying that the issue is with ALL users of GSX and FSL A320, I have said numerous times throughout this thread "my system" and even in the OP I said there may have been a change to something over the last year that I am not aware of which is now causing the issues. All I know is that I updated everything when returning to flight sims, and everything worked fine until I tried to attach a jetway to the FSL A320.
I will try with an airport that does not have it's own SODE jetways and see what the result is.
I cannot post this in the SODE support forum because as I said, the jetway connects to the aircraft fine from the SODE menu, so this is telling me that SODE is working as it should. I also thought to check if I had updated SODE, but version 1.7.1 from June 2020 is the latest and the version I have installed.
Here is a video at KSAT which is unedited at all and still uses the GSX replacement jetways for the disables default P3D jetways:
https://youtu.be/403UWjtXWOw (https://youtu.be/403UWjtXWOw)
-
I said "touching" originally because I was in the cockpit view and couldn't see where it actually was. My fault. What I do not understand is why does the same jetway work when not called by GSX but directly from SODE but does not work when used by GSX?
I don't know, because I don't know if SODE does something different at that time. The only SURE thing, is GSX is not doing *anything* while the jetway is still moving.
I am not saying that the issue is with ALL users of GSX and FSL A320
A more accurate description of the issue would instead being it's only happen to you, and nobody else.
All I'm trying to do is figure this out. I don't care to argue any longer so can you PLEASE provide some support in what I need to be looking at to try to resolve this?
Try with an airport with GSX jetways, which still are SODE, but created by GSX and animated by SODE.
-
Try with an airport with GSX jetways, which still are SODE, but created by GSX and animated by SODE.
Please refer to the rest of that post which you ignored that has that test along with a video. Perhaps if you spent less time trying to belittle and degrade people and more time looking at what is provided to you would have seen that already. Here is the link again:
https://youtu.be/403UWjtXWOw (https://youtu.be/403UWjtXWOw)
You keep saying that GSX is not doing anything during that time. But we know already that using SODE menu to call the jetway does not cause CTD (in a video above you probably ignored) but when using GSX it does. So if eliminating GSX takes away the CTD, then you cannot say that GSX does not play a part in the problem in some way. I cannot say if the problem is how GSX is sending the info to SODE, or if it is how SODE is sending the info to GSX, or how either program recieve the data from the other, but either way, I did not code either program so therefore cannot say where the disconnect is - but regardless if you take GSX out of the equation, then the problem does not happen so therefore GSX absolutely MUST play a part in the CTD in some way or another. That is why we turn to those who DID write the code so we can attempt to resolve the problem. I'll say it again - Calling the jetway using the SODE menu directly does not cause any issues at all, it is only when the jetway is called from GSX - that right there should tell you that SODE is not the problem alone, but perhaps how the 2 programs are interacting with each other on this particular aircraft. Where to look to see if that is the case is where I must turn to you so you can ask me to try doing things to identify the problem. If it will make you feel better, I can post on the SODE support forum and show the videos to them that using SODE and bypassing GSX works just fine but Umberto at GSX insists it is not a GSX problem and has nothing to do with the CTD, despite no CTD happening if not using GSX.
Now that you have been provided for a 2nd time the video link showing the test you requested, what would you like me to try now?
-
Please refer to the rest of that post which you ignored that has that test along with a video. Perhaps if you spent less time trying to belittle and degrade people and more time looking at what is provided to you would have seen that already. Here is the link again:
https://youtu.be/403UWjtXWOw (https://youtu.be/403UWjtXWOw)
I didn't checked both videos but yes, they indicate the problem always happens while the jetways is moving, when it's completely outside GSX's control. In fact, this video further proves the crash is NOT caused by GSX, because it makes the FIRST VIDEO I posted way more relevant, because there I used the FSL on a default airport using GSX jetways.
So, while before we could have *some* doubts, because you were using a 3rd party airport with its own SODE jetways, and I had a default airport with GSX/SODE jetways, this 2nd video of yours is made under the same conditions of mine, so at least we can be sure the problem is not GSX, but something ELSE you have installed, and I don't.
if you take GSX out of the equation
You said it doesn't happen with any airplane other than the FSL A320 so no, on YOUR system at least, even taking the FSL out of the equation is another way to solve the crash. Does this means the FSL is the cause ? Yes, by your own reasoning, but then it should happen to everybody using the FSL, so no.
You keep saying that GSX is not doing anything during that time. But we know already that using SODE menu to call the jetway does not cause CTD
There's an easy explanation for this. As I've said, I don't know exactly what SODE does while it's moving the jetway and how it calls GSX back but, if SODE had an issue ( more likely, something you have installed is causing a conflict somehow ) just before it needs to call GSX back, this can mislead you "GSX has a part in it" JUST because SODE needs to do something it normally doesn't do, that is calling GSX back to tell the jetway has docked, which it likely doesn't do when the jetway is called from its own menu.
Of course, we know the communication between GSX and SODE always work, you said it yourself you don't have any issues with any other airplane, but that doesn't mean I'm sure it's the airplane. In fact, I'm quite sure it's not, otherwise it would crash with MY FSL as well.
So, the only possible explanation is a combination of FSL + GSX + SODE + something else you have installed and I don't, that somehow is disrupting the communication between SODE and GSX.
Have you tried checking the SODE error log with the SODE platform manager while this happens ? Maybe it can tell you something.
-
The last minute or 2 of the SODE log:
[16:41:01.655] INFO SODE.FSLOOP : [SEASONALOBJECTHANDLER] Refreshing Season/Time Data...
[16:41:02.679] DEBUG SODE.FSLOOP : [AI DETECTION] N monitored AIObjects = 0, Primary/Chained Jobs:{0/0}, Tracked Jobs: {0}
[16:41:06.666] DEBUG SODE.FSLOOP : [AI DETECTION] N monitored AIObjects = 0, Primary/Chained Jobs:{0/0}, Tracked Jobs: {0}
[16:41:10.668] DEBUG SODE.FSLOOP : [AI DETECTION] N monitored AIObjects = 0, Primary/Chained Jobs:{0/0}, Tracked Jobs: {0}
[16:41:14.670] DEBUG SODE.FSLOOP : [AI DETECTION] N monitored AIObjects = 0, Primary/Chained Jobs:{0/0}, Tracked Jobs: {0}
[16:41:18.673] DEBUG SODE.FSLOOP : [AI DETECTION] N monitored AIObjects = 0, Primary/Chained Jobs:{0/0}, Tracked Jobs: {0}
[16:41:22.660] DEBUG SODE.FSLOOP : [AI DETECTION] N monitored AIObjects = 0, Primary/Chained Jobs:{0/0}, Tracked Jobs: {0}
[16:41:26.693] DEBUG SODE.FSLOOP : [AI DETECTION] N monitored AIObjects = 0, Primary/Chained Jobs:{0/0}, Tracked Jobs: {0}
[16:41:29.237] DEBUG SODE.FSLOOP : [API::TRIGGER] Received Trigger Client Data: ObjID [126], DoorDesignator='1L', OwnFlag=1, DoorDataOverrideFlag=1, Mode=1
[16:41:29.284] DEBUG SODE.FSLOOP : [API::TRIGGER] Received Trigger Client Data: ObjID [126], DoorDesignator='4L', OwnFlag=1, DoorDataOverrideFlag=1, Mode=1
[16:41:30.665] DEBUG SODE.FSLOOP : [AI DETECTION] N monitored AIObjects = 0, Primary/Chained Jobs:{0/0}, Tracked Jobs: {0}
[16:41:34.667] DEBUG SODE.FSLOOP : [AI DETECTION] N monitored AIObjects = 0, Primary/Chained Jobs:{0/0}, Tracked Jobs: {0}
[16:41:38.670] DEBUG SODE.FSLOOP : [AI DETECTION] N monitored AIObjects = 0, Primary/Chained Jobs:{0/0}, Tracked Jobs: {0}
[16:41:42.672] DEBUG SODE.FSLOOP : [AI DETECTION] N monitored AIObjects = 0, Primary/Chained Jobs:{0/0}, Tracked Jobs: {0}
[16:41:46.690] DEBUG SODE.FSLOOP : [AI DETECTION] N monitored AIObjects = 0, Primary/Chained Jobs:{0/0}, Tracked Jobs: {0}
[16:41:50.661] DEBUG SODE.FSLOOP : [AI DETECTION] N monitored AIObjects = 0, Primary/Chained Jobs:{0/0}, Tracked Jobs: {0}
[16:41:54.679] DEBUG SODE.FSLOOP : [AI DETECTION] N monitored AIObjects = 0, Primary/Chained Jobs:{0/0}, Tracked Jobs: {0}
[16:41:58.682] DEBUG SODE.FSLOOP : [AI DETECTION] N monitored AIObjects = 0, Primary/Chained Jobs:{0/0}, Tracked Jobs: {0}
[16:41:58.713] DEBUG SODE.FSLOOP : [API::TRIGGER] Received Trigger Client Data: ObjID [126], DoorDesignator='1L', OwnFlag=1, DoorDataOverrideFlag=1, Mode=0
[16:42:27.767] FATAL SODE.WATCHDOG : Sim Process running test failed!
[16:42:27.776] DEBUG SODE.FSPROCESS : Cleaning up Memory...
[16:42:27.793] DEBUG SODE.FSPROCESS : Removing Top-Menu structure...
[16:42:27.793] DEBUG SODE.FSPROCESS : Closing Connection to FS.
[16:42:27.900] INFO : Terminate SODE.
The only errors I see in the SODE log at all:
[16:27:44.262] WARN SODE.SETTINGS : Could not extract 'Debug::FastJetwaysEnable' setting! Feature is disabled!
[16:27:44.262] WARN SODE.SETTINGS : Not all Settings have been read successfully! See above...
[16:27:44.286] WARN SODE.SETTINGS : Could not extract 'Debug::FastJetwaysEnable' setting! Feature is disabled!
[16:27:44.286] WARN SODE.SETTINGS : Not all Settings have been read successfully! See above...
[16:27:44.290] ERROR SODE.XML : Environmental Data Probe SimObject 'EDP_UUEE' must have absolute value for altitude, not AGL! EDP not added!
[16:27:44.390] DEBUG SODE.XML : Building List from File 'C:\ProgramData\12bPilot\SODE\xml\TropicalSim_TFFF.xml'
[16:27:44.390] WARN SODE.XML : <Stand> CustomDesignator Attribute invalid format 'Gate 4'. Must be 'CustomDesignator;Number'!
[16:27:44.390] WARN SODE.XML : <Stand> CustomDesignator Attribute invalid format 'Gate 5'. Must be 'CustomDesignator;Number'!
[16:27:44.390] WARN SODE.XML : <Stand> CustomDesignator Attribute invalid format 'Gate 6'. Must be 'CustomDesignator;Number'!
[16:27:44.390] WARN SODE.XML : <Stand> CustomDesignator Attribute invalid format 'Gate 6'. Must be 'CustomDesignator;Number'!
[16:27:44.390] WARN SODE.XML : <Stand> CustomDesignator Attribute invalid format 'Gate 7'. Must be 'CustomDesignator;Number'!
[16:27:44.390] WARN SODE.XML : <Stand> CustomDesignator Attribute invalid format 'Gate 8'. Must be 'CustomDesignator;Number'!
[16:27:44.390] WARN SODE.XML : <Stand> CustomDesignator Attribute invalid format 'Gate 8'. Must be 'CustomDesignator;Number'!
[16:27:44.390] DEBUG SODE.XML : Building List from File 'C:\ProgramData\12bPilot\SODE\xml\TropicalSim_TNCC.xml'
[16:27:44.390] WARN SODE.XML : <Stand> CustomDesignator Attribute invalid format 'Gate 1'. Must be 'CustomDesignator;Number'!
[16:27:44.391] WARN SODE.XML : <Stand> CustomDesignator Attribute invalid format 'Gate 2'. Must be 'CustomDesignator;Number'!
[16:27:44.391] WARN SODE.XML : <Stand> CustomDesignator Attribute invalid format 'Gate 3'. Must be 'CustomDesignator;Number'!
[16:27:44.391] WARN SODE.XML : <Stand> CustomDesignator Attribute invalid format 'Gate 4'. Must be 'CustomDesignator;Number'!
[16:27:44.391] WARN SODE.XML : <Stand> CustomDesignator Attribute invalid format 'Gate 5'. Must be 'CustomDesignator;Number'!
None of those seem to have any reason for causing a CTD at any airport, at any gate, using any type of jetway (Custom SODE or GSX SODE), and only in a specific aircraft, at a specific point in the function. Also, the last error message was logged 15 minutes before I called the jetway (I was looking over the aircraft options to make sure nothing there changed that could have been the cause).
I have a second copy of Windows that I use only for university class work and has virtually nothing installed on it. I'll see if I can download and install P3Dv5, GSX, and FSL A320 on that copy of windows and see what happens - That is as close as I am willing to come to "a full reinstall of windows and P3D" ---- as I expected, I cannot activate P3D on the other copy of windows, so I cannot test this idea.
-
[16:41:58.713] DEBUG SODE.FSLOOP : [API::TRIGGER] Received Trigger Client Data: ObjID [126], DoorDesignator='1L', OwnFlag=1, DoorDataOverrideFlag=1, Mode=0
[16:42:27.767] FATAL SODE.WATCHDOG : Sim Process running test failed!
Apart from the usual mistakes in other sceneries SODE jetways definitions, which will cause those jetways not working when called from GSX but are surely not a possible reason for a crash, the above two lines indicates the following:
- In the first line, SODE received a command to trigger a jetway from GSX, and of course the command was correct and understood, since there are no errors reported about it. At this time the jetway started to move.
- The second line, which happened 30 seconds later, indicates SODE was also caught by surprise by the sim crashing, for reason that didn't had anything to do with GSX, since as you can see, no other commands came from GSX during the time the jetway was being moved.
This definitely prove GSX can't be the cause of the crash, for example if it mistakenly sent another jetway trigger command while SODE was still moving the jetway, which might possibly have confused it. Not that I wasn't sure of this ( it should happen with every airplane then ), but at least now you got another confirmation GSX didn't cause the crash, for example if it sent wrong commands to SODE, or at the wrong times.
About reinstalling P3D on a different PC for testing, it's extremely easy to do:
- Uninstall P3D from your main PC. This will NOT require any subsequent reinstallation of add-ons, provided you don't touch any folder after uninstalling it, but will RECLAIM your activation.
- Install P3D on a different PC, so it can be activated with the activation reclaimed from the 1st one.
- When you are done testing, uninstall P3D from the test PC, which will again reclaim its activation to be reused.
- Reinstall P3D and be absolutely sure you are reinstalling on the SAME folder it was installed before.
We do this uninstall\reinstall process like 10-15 times when a new Beta cycle for P3D starts, so I assure you it's safe and won't cause any issue to any installed add-ons, as long you keep reinstalling on the same folder.
-
I will try that reinstall method shortly and see if I can get it to work. I am also posing on the FSL forums to see if they have any ideas but a FSL forum and google search turned up 0 results. I do not see a reason to post on SODE forums since SODE seems to be working fine also. If it is not GSX and not SODE, then it must be FSL and something conflicting with that aircraft. I cannot find a single error message anywhere - SODE log, GSX log, event viewer all come back clean.
-
If it is not GSX and not SODE, then it must be FSL and something conflicting with that aircraft.
Surely it's not GSX, not SODE and not FSL, otherwise it would have:
- Crashed for me ( that was the whole point of my first video )
- Crashed for somebody else, yet you can see yourself there are no similar threads.
So yes, it must be a combination with something else you installed.
-
I have managed to get P3D reinstalled on the other Windows system, but I am struggling to get GSX installed - I either get an error in installation about not having access to the fonts folder or trying to launch GSX from P3D tells me that Live Update must be run but will never actually open (all AV and firewalls turned off during install, and install folder added to exclude lists). I've been extremely busy with work and classes so have not had time to really work on this much, but I will have time come Wednesday. I know the install issue is something I'm not doing right, just don't have the time right now to keep uninstalling and reinstalling to resolve the problem.
-
I either get an error in installation about not having access to the fonts folder
Just ignore the error and continue, it means the font is already installed, but windows is not allowing to be overwritten.
tells me that Live Update must be run but will never actually open (all AV and firewalls turned off during install, and install folder added to exclude lists).
Please indicate the precise message, is there an error log ?
-
Please indicate the precise message, is there an error log ?
Live update opens with the white box window and the "this will update the FSDT support software ... " I click next, it runs like 2 files then closes and that is all. It never actually opens/runs the live update (longer greenish/blue background window where Live Update usually runs). If I go into the sim, Addon manager is in the add-ons menu, but within addon manager, GSX shows deactivated. When I click on "register serial" I get a box saying "The couatl scripting engine hasn't started. This is usually caused by an antivirus that has blocked it. To fix this problem: Exit from the simulator. Configure the antivirus and ass the c:\Program Files (x86)\Addon Manager folder to the antivirus exclusion list. Launch the FSDT Live Update or reinstall the software."
So the file was already added to the antivirus exclusion list, tried again and still the same where Live Update will never actually launch. Uninstalled, restarted computer, and reinstalled GSX, restarted computer, and still I get the exact same when trying to register GSX in the Addon Manager and Live Update not actually launching. I have tried uninstalling and reinstalling like 50 times now, tried installing into a different folder (also added to AV exclusion), I cannot get Live Update to actually run at all, nor can I register GSX.
-
This is on the original windows install (not the test copy of Windows) and was after an uninstall of GSX including deleting all sub-folders and then reinstalling but still getting the CTD in the exact same spot:
OK, I have FINALLY made SOME progress. I uninstalled SODE and deleted all sub-folders, and reinstalled SODE. Loaded up the A321SL and put it on GPU and used the EFB this time to call the jetway (not the FMC nor the GSX menu) - it attached and no CTD. I'll need to investigate more, but perhaps the conflict is with the jetway being called by something OTHER than the EFB? if that is the case, then the base version of the A320 and base A321 would still cause the CTD for me. I still need to see if it was caused by SODE somehow being corrupted, also I have not put back the GSX backup files (or the SODE backup files such as the xml and obj files). But at least this is progress.
This was a reply on the FSL forums and I have a few other things to look at to be sure the problem is fully resolved.
-
Live update opens with the white box window and the "this will update the FSDT support software ... " I click next, it runs like 2 files then closes and that is all.
There's a sticky thread in this section of the forum, named "GSX Couatl scripting engine hasn't started **SOLVED**", which indicates a solution that has worked for several user on the first reply:
http://www.fsdreamteam.com/forum/index.php/topic,25999.0.html
-
I tried the universal installer - It said it wasn't available for FSX/P3D and to download and install the website version, and then universal installer would not open again without an error that it could not launch Live Update. But, I'm not too concerned about that now. It is probably something I've done wrong and I could get GSX installed and run Live Update on the original Windows over and over without any issues using the website version (spent 9 hours uninstalling, restarting computer, reinstalling, restarting computer, launching and testing, CTD, repeat with next item).
That being said, you are correct that the main issue (the CTD) has nothing to do with GSX - The CTD is happening any time a door is commanded open on any FSL aircraft (I purchased and installed the A321 and A321SL and could reproduce the problem on all 3 planes now). The command can come from GSX to auto-open the doors, or manually opening the doors from the MCDU doors options page and that is when the CTD would happen.
The reason I was seeing some jetways attaching and some not had nothing to do with the jetway, but the front baggage loader being in position for the auto-door forward cargo door to open. I can duplicate the CTD by manually calling the door to open directly from the options page, so it is not the GSX command to open the door.
-
To further close the case - P3D did not install correctly when updated. Despite me uninstalling scenery, client, content and then reinstalling, the sim failed to install the update correctly. This caused a seemingly fine version of P3D to CTD when doors were commanded on FSL aircraft, but no other issues were found. A full complete uninstall of P3D and reinstall seems to have fixed the problem.
-
The command can come from GSX to auto-open the doors, or manually opening the doors from the MCDU doors options page and that is when the CTD would happen.
The reason I was seeing some jetways attaching and some not had nothing to do with the jetway, but the front baggage loader being in position for the auto-door forward cargo door to open. I can duplicate the CTD by manually calling the door to open directly from the options page, so it is not the GSX command to open the door.
GSX doesn't have any command to open the door automatically to begin with. Whenever you see a door that opens automatically connected to some GSX operation, it's the airplane itself that open its doors, as part of GSX integration. In some cases, users wrote FSUIPC LUA or LINDA scripts to achieve that for planes that don't integrate themselves. But GSX, as is, doesn't try to open any door by itself, because we know we could possibly interfere with some plane systems (electrics or hydraulics), so we left the task to the airplane itself.
GSX for MSFS will have automatic opening/closing of plane doors from GSX, but only for default planes or 3rd party planes that use standard door systems, but that's because MSFS doesn't have any way for users to open doors on default planes.
A full complete uninstall of P3D and reinstall seems to have fixed the problem.
I think your issue was likely caused by some problem with the Microsoft redistributable libraries used by the sim. They might have been either missing or corrupted or in conflict with another version, which made the program to be unstable. Reinstalling it fixed the problem. It's not a difficult procedure, provided you reinstall in the same folder it was already installed to, and all your add-ons use the add-on.xml method to install wont' require to be reinstalled.