P3Dv5 CTD with FSL A320 **SOLVED**

[DVA12924]

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.

[virtuali]

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

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.

[DVA12924]

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.

[Captain Kevin]

But have you tried using GSX on the A320 without doing it through the airplane.

[DVA12924]

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?

[Captain Kevin]

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.

[virtuali]

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.

[srcooke]

How else would you use GSX?

Have you tried following the ATSU tutorial supplied with the FSL documentation ?

[DVA12924]

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/dH6KD3UZA7A

[virtuali]

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.

[virtuali]

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.

[DVA12924]

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

[virtuali]

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.

[DVA12924]

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

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?

[virtuali]

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

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.