#Dispatcher Walks Too Close to Engine and Takes Too Long to Leave

1 messages · Page 1 of 1 (latest)

vocal kernel
#

During pushback, the "dispatcher" (the person on the headset who connects/disconnects the towbar, tells the pilot to set brakes etc) walks far too close to the aircraft in many instances. Please observe the attached image to indicate where it is safe for the dispatcher to stand. Second to this, that attached image is primarily for widebody aircraft. A general, industry-accepted rule of thumb is that for the 737, you must not be past the "INGESTION HAZARD" line, preferably no closer than the NLG. For the all other narrow-bodies, you must be no closer to the engines than the NLG. The GSX dispatcher actually seems to loosely follow this however begins to wander dangerously close to the engine as the aircraft is lined up on the taxiway.

Furthermore, after pushback, the dispatcher displays the pin for far too long. Not only do they wiggle it around in the air for a while, they then stand still for a few seconds before the animation repeats. The pin display to flight crew should only be a few seconds. The pilot then gives the dispatcher a thumbs up and a wave, and away they go. Often, virtually as soon as the flight crew see the pin, they'll request taxi. For context, see the following clip: https://youtu.be/OkxYC4aapN8?si=dWc7tkGLV3Kem2qU&t=67
My suggestion is to remove the second animation cycle of the pin display, and improve the overall speed of the dispatcher.

From what I have gathered, I'm not the only one who chooses to simply taxi over them while GSX tells me to "SET PARKING BRAKES IMMEDIATELY!" - curfew isn't going to beat itself.

#

In the second image note how close the dispatcher is to the aircraft.

rose goblet
#

I can only reply about the thing we can't change: the bypass pin animation taking "too long". It won't be changed for the following reason.

  • Animations must be connected to each other in order not to have "jumps", because the MSFS engine doesn't automatically blend them together like more advanced game engines and in order to do so, we need to go back to a predictable state at the end of every animation, and this makes all of them longer then they might be in real life, especially for short animations like these, where the transitions might be even longer than the animation itself. But since the first thing that people notice as an animation "bug" it's a "jump", we can't change this just to speed up a process.

Everything else in your suggestion, of course, is taken under consideration, as usual.

vocal kernel
rose goblet
vocal kernel
rose goblet