FSDreamTeam forum
Products Support => GSX Support FSX/P3D => Topic started by: crauds on March 25, 2012, 01:25:39 pm
-
Hi Umberto. Do not remember having this problem before the last update (1.3) + fix. In a post yesterday I experienced problem that rear conveyor would not remove from plane after loading baggage and rear stairway did not remove far enough to allow clearance from left wing during pushback. That was when I used sequence of Catering-Fuel-Boarding-Pushback.
Today using same airport and gate (VVTS default / Gate 13 / PMDG NGX B739(wl) ) I tried sequence beginning with DEBOARDING and baggage trains drove off after unloading baggage but when passengers had deboarded I received message that baggage was still unloading. This never cleared. I then tried to complete sequence with Catering and Refuel and it would not comply. The following message kept appearing on the screen after ALL deboarding and baggage unloading HAD COMPLETED:
-
An update to my OP:
I used same airport (VVTS) and gate (13) but this time switched aircraft to PMDG B738(wl) instead of B739 and started with Deboarding and I first received "Baggage unloading complete" message (which I can't remember receiving with B739 in my OP) and then again a notice when deboarding was complete. So this time I was then able to proceed with Catering/Fuel. I am going to test the boarding sequence next to see if equipment moves out of the way correctly.
Why would this problem be aircraft type specific?
Craig
-
Continuing from last post. The next step: Boarding.
This time it was very unique. The passengers completed loading before the baggage trains even arrived. So the message: "Boarding completed. Baggage loading in progress" was indeed fitting. After the baggage had been loaded and trains departed the message "Boarding completed" appeared and the conveyors moved back appropriately. The rear staircase, however, still did not move back far enough to allow left wing clearance on pushback.
I am going to try again with the B738(wl) but this time starting with Fuel then Catering then Passenger Boarding and will report the results again in this thread.
Craig
-
...I used sequence of Catering-Fuel-Boarding-Pushback.
You'll need to request deboarding, then catering-fuel-boarding-pushback.
-
Please reread my OP. Both sequences were tested: starting with deboarding AND started with Catering. BTW, a flight from a cold-dark aircraft does not start by deboarding passengers. They don't sleep on the plane overnight! LOL Both sequences worked with the B738 but not with the B739.
-
Both sequences worked with the B738 but not with the B739.
Sounds like an aircraft issue, the 738 is supported internally but the 739 isn't.
-
Ah-ha! Now that is an answer. Thank you! It just could be that the other members of the forum that are having the same issue are using aircraft that are also not supported. Is this something that can be soon corrected? The PMDG models are fast becoming the choice of the sophisticated FSX user and the B739 is being used by many carriers. Is there something that we users can tweak in the new aircraft cfg option that will fix this?
-
That's the conclusion I came up with too after a number of tests! Look at my post in the other thread. If the aircraft is supported, or there is a gsx.cfg file for it, all is well, if it not supported, the process gets stuck!
-
I was under the impression that all FSX default aircraft are supported by GSX. My issue is with the default 737 and default airports posted here http://www.fsdreamteam.com/forum/index.php?topic=6209.msg54748#msg54748 (http://www.fsdreamteam.com/forum/index.php?topic=6209.msg54748#msg54748) I can't get past the default aircraft yet. Maybe I will try a popular 3rd party AC and see if GSX will function as it should.
Regards,
Rob
-
That's the conclusion I came up with too after a number of tests! Look at my post in the other thread. If the aircraft is supported, or there is a gsx.cfg file for it, all is well, if it not supported, the process gets stuck!
That's probably the first really useful post we got about this issue: I didn't even knew a 737-900 existed so no, the airplane is not recognized, so GSX is relying on the aircraft.cfg file and, since PMDG always use custom command for doors, it's very likely everything is stuck, since the program doesn't know what to do with doors.
So, it's possible a supported airplane works, but an unsupported using non-standard doors command might not.
You can test this, by doing a GSX.CFG file that commands to ignore all door open/closed status, with the following command:
code = 0
into every [exitX] section of the GSX.CFG file, there's no need for the moment to include anything else so, it will look like this:
[exit1]
code = 1
[exit2]
code = 0
[exit3]
code = 0
[exit4]
code = 0
[service1]
code = 0
[service2]
code = 0
[cargo1]
code = 0
[cargo2]
code = 0
This will ignore all the doors, put it into the airplane root folder, and check if it makes a difference.
-
Hi Umberto,
What do those of us do who are using the default AC?? The link to my post is here http://www.fsdreamteam.com/forum/index.php?topic=6209.msg54748#msg54748 (http://www.fsdreamteam.com/forum/index.php?topic=6209.msg54748#msg54748) In my case, the default 737 gets "stuck". Didn't have any problems with the default AC in the previous versions of GSX.
Regards,
Rob
-
I'm sorry, but I can't see any problems here. I always try to get ALL this information:
- The EXACT sequence of operations
- The airplane, the airport and the gate.
But, somehow, I usually get some of them, but not all, someone reports the airplane and the airport, another one reports the airport and the gate, nobody every included *everything* in the report and, with the few data I have, I can't replicate the issue.
By "EXACT sequence of operation" I mean something like this:
1) I started FSX
2) Loaded a flight at XXXX, starting at gate YY with the ZZ airplane
3) Used GSX at departure, and asked for catering, then refueling, then boarding.
-
OK, I understand. In my case with a big update like this, I wanted to see the new additions. I started FSX, selected spawn on an active runway at default KCAK with the default 737. Turned off on the second taxiway and called up the GSX menu Ctl F12. Selected a gate, the first being 5 at KCAK. Was marshalled into the parking position without issue. Called up the UI and selected deboarding. The stairs pulled up to the rear of the AC and both belts pulled up to the cargo doors. I also used the jetway. The tugs pulled up, unloaded the bags and drove off. GSX advised deboarding was complete. I called for catering service and thats where GSX goes no futher. The UI advises catering service requested waiting for deboarding to be completed. Waited for over 20 minutes and reset GSX starting with catering service this time skipping deboarding and all services completed without issue. Ended the flight. Spawed on the runway again this time selecting gate 3 at KCAK. Same problem there as well. Didn't have any door issues. I took screens of the UI and gates which are posted on my other post. I have started a flight on the runway before to see GSX in action without any issues. The only thing I did differently this time was not ask for a follow me vehicle. Note: I should also add I selected real world weather updating every 15 min. The runway FSX selected was #1 at default KCAK
An additional note: The sound file that plays when the bags are being unloaded continues to do so long after the baggage tugs have left. I don't remember hearing that sound after the tugs left in the previous versions.
Regards,
Rob
-
One of my tests today was the situation you already described at KCAK, asking Gate 5 from runway 1 with the default 737, and using a Follow Me too. I DID made that test, because you already describe it precisely enough.
Of course, no problems whatsoever, deboarding completed normally without any unusual waiting time.
-
Another complete uninstall and re-install of V1.31 + updates. Made sure no interference with anti-virus and I keep UAC in VISTA 64 always OFF so these aren't issues. Deactivated UT2 but still have same problem. It unloads baggage before it has finished deboarding passengers. When passenger deboarding finishes it announces that "...Baggage unloading in progress." But all trains have left and there is no more baggage that will be unloaded so program must be waiting for some action or variable value so that it can end the deboarding process but it never happens
And here is where it stays with no change:
-
As I've said, in order to fix the problem, we must be able to replicate so, being able to replicate it now, we already fixed it, and it will be released as a Live Update, together with other issues.
The key to find it was moving from the center of the parking (or just not parked correctly), combined with a small parking, which is barely able to handle that aircraft.
-
As I mentioned in my other string, I have been testing using now the default FSX B737-800wl and NOT moving the aircraft. I have let it SPAWN at the parking gate or free stand and I still get the same results. But I think you are on to something. The program before the major upgrade must have polled some internal variable to verify that the REAR (since that is all we had in that version) had completed its baggage handling. It then sent a text message that "baggage loading/unloaded completed" even though the deboarding or boarding process was still ongoing. When THAT process ended it confirmed with the "boarding/deboarding completed" message. Now with 2 baggage loaders you have introduced several different sets of scenarios: 1. Front loader completes first but still passengers in progress; 2. Rear loader completes first, passengers still in progress; 3. passenger process completes first, front loader still in progress; or 4. passenger process completes first, rear loader still in process. I seem to be getting stuck with scenario #1. It could be that I usually use a pretty full payload so it takes much longer for passenger progress so ALWAYS baggage handling is finishing first, but program is acknowleging the completion of the FRONT loader but is failing to detect completion of the REAR loader.
My problem with your current theory/solution is that I have verified that since I am spawning the aircraft for my tests, the aircraft is always sitting DEAD CENTER on the footprint based on the current AFCAD I am using for that airport. I DO NOT move it nor is it position off-center or askew of the AFCAD footprint. But I still am having the same problem described above.
I do hope that whatever you did in the forthcoming live update fixes it for me too but based on my tests since last we communicated I am having my doubts that that is the complete issue. It is definitely related to the rear loader but I think somehow the variable that is being polled to indicate completion is inadvertantly being reset after it has indicated the first loader completed and thus still showing in progress instead of completed for the rear loader. OTHERWISE the same issue would have been present in the original version since we were using the same parking places and a REAR LOADER.
Something is now different in v1.3 in the way you determine when baggage handling has completed. It is that determination that is somehow being misinterpretted by the program.
Craig
-
My problem with your current theory/solution is that I have verified that since I am spawning the aircraft for my tests, the aircraft is always sitting DEAD CENTER on the footprint based on the current AFCAD I am using for that airport. I DO NOT move it nor is it position off-center or askew of the AFCAD footprint. But I still am having the same problem described above.
Moving the airplane or parking off center it's just one way to trigger the problem. It doesn't matter *how* you end up in that situation but, as long as the airplane rear door is in a position that will result the rear loader ending outside the parking BEFORE it has *really* completed loading/unloading, the problem will happen.
I think somehow the variable that is being polled to indicate completion is inadvertantly being reset after it has indicated the first loader completed and thus still showing in progress instead of completed for the rear loader. OTHERWISE the same issue would have been present in the original version since we were using the same parking places and a REAR LOADER.
It's not. There's no "polling" involved, GSX uses a far more modern method of programming, based on messaging, and I've already explained what the problem was: when the rear loader said "I'm outside of the parking", there was nobody expecting that message, because nobody was expecting it would be out of the parking before the finishing its job.
-
Thank you, Umberto, for your patience, diligence, and clarification. I will await the live update with hopeful expectation.
Craig