More about PMDG B737-900

[crauds]

That still is strange because I know Rob has been suggesting this with his tests, but to eliminate that I have just been allowing FSX to spawn the aircraft at the parking place WITHOUT moving it.  I have test both "stand" parking (without gates) and gate parking with jetways and the problem as you correctly state is that it does not recognize when the REAR baggage handling has completed.  If I start with "boarding" when it completes the front conveyor moves back but the rear stays in place with the message "boarding completed.  Baggage loading in progress" and there it locks.

More curious than all of the above is WHY do Rob and I have that problem and for others it seems to have been corrected with the last live update?  I have since last evening uninstalled and reinstalled V3.1 several times and without my Kaspersky antivirus (and that's like unprotected sex, lol) but I still get the same problem.  I have switched to the default FSX b737-800 since that is what Rob was using in his tests but no luck.  I hope your discovery answers it for me too.

Craig

[virtuali]

That still is strange because I know Rob has been suggesting this with his tests, but to eliminate that I have just been allowing FSX to spawn the aircraft at the parking place WITHOUT moving it.

It's not strange, and there's no need to move the airplane, it would be enough the parking being small enough that, in the parking position, the rear door of the airplane would force the rear loader to be already outside of the parking radius, this might be caused either by moving the airplane, but also by simply parking a bit early, enough to have the rear door outside of the parking radius.

More curious than all of the above is WHY do Rob and I have that problem and for others it seems to have been corrected with the last live update?

This is an entirely different problem that doesn't have anything to do with the other problem which, instead, was caused by calling the catering vehicle without deboarding first. Only the end result is similar, but the causes are very different.

[crauds]

I hope you are right.  But with my tests I SPAWNED the aircraft so it is perfectly aligned with the fSX AFCAD footprint.  I did not DRIVE it to the gate.  Also verified your test with ZERO payload as I mentioned earlier and in that scenario the Passenger handling always ends BEFORE baggage handling completes.  The program correctly gives the "boarding/deboarding completed" message AFTER baggage handling completes.  The fact that this scenario works would eliminate the possibility that it is a parking issue since the rear loader is in the same position as it is when I change the load and have the problem.  I still think it is the change to the two loaders that now requires the program to verify that each loader has completed and it acknowledges the first loader completed but does not acknowledge the second one.  In case of boarding, my tests always had the first one finish first and it would back away but the rear would stay connected and program would not acknowledge that it had completed.  If it were positional, however, then it would be same problem with ZERO load test and it wasn't.


Craig

[virtuali]

I hope you are right.  But with my tests I SPAWNED the aircraft so it is perfectly aligned with the fSX AFCAD footprint.  I did not DRIVE it to the gate.  Also verified your test with ZERO payload as I mentioned earlier and in that scenario the Passenger handling always ends BEFORE baggage handling completes

As I've said (quite a few times already) fact you moved, spawned, loaded, slewed or ended up in any other way in the parking, even in the dead center, doesn't matter.

What matters is the radius of the parking in relationship to the rear door position of the airplane that would result the rear train ending up outside the parking areas before it's finished.

That I was able to replicate the problem by moving the airplane, is entirely irrelevant, that was just ONE way of triggering it, but unfortunately it was the only one I managed to find, following Rob's report.

If it were positional, however, then it would be same problem with ZERO load test and it wasn't.

No, that's only proving it even more, because with Zero payload, a shorter train will have less chances to end up outside the parking radius before it's done loading, compared with the full length one.