I can't comment on AAO since I use SPAD.neXt, but at least with SPAD.neXt, if you use the built-in script panel, you could see if there is a variable for the flight deck door. If so, you may attempt to set it up, so when de-boarding is started, the flight deck door is opened, and when boarding is completed, the flight deck door is closed.
That might work (or not), visually, but it's not a clean way of doing it, and it's why we don't do it in GSX, unless the airplane has proper Events to trigger such state changes, because you never know what the side effects might be if you just change an LVar tied to some animation. Without even mentioning some planes have custom code running at ever frame, which actively prevents you from doing it.
As an example, suppose a door animation is linked to another internal system, like electrics or hydraulic and this system runs its own internal simulation, which would normally prevent the door to be opened when you are not supposed to. If you act directly on the LVar that controls the door animation itself, it
might work visually, but you might cause a loss of sync between the internal simulation of the system behind the door, which is still assuming the door should be closed, but you opened it anyway. That is, assuming it's not actively checking at every frame so, you open the door with the LVar, and the simulation will close it again, because according to its own internal status, it shouldn't be opened.
That's why, even if we could write over variables very easily from GSX, we chose NOT TO, so no airplane developer could complain we might screw up its internal simulation by doing things they don't expect.
The proper way to act on the airplane status safely, is always through K: or F: events instead, which will in turn trigger the whole chain of events that might eventually lead to an effect, like the door being opened. Some examples:
- On a default airplane with a door ID of 0, we don't set the A:INTERACTIVE POINT OPEN variable directly. Instead, we send the (>K:TOGGLE_AIRCRAFT_EXIT) which causes the door to be opened AND the variable to change automatically.
- On the PMDG 777, which has a custom LVar for door 1L named L:7X7XCabinDoor1L, we don't set it directly. Instead, we send the 83637 (>F:KeyEvent), which sends a custom key event that according to the PMDG SDK, triggers opening door 1L, causing the door to open (if possible) AND the L: variable to change automatically.
That's the safest possible way of acting on the airplane status, and it's why we only use this Event->Variable method, and with 3rd party airplanes with custom door controls, only if the airplane has a documented way of doing it and if it doesn't, we either leave the task to the airplane developer himself, which can use GSX LVars to know if GSX expects some door to be opened/closed and open it using its own means, and lacking that, to the user, since every airplane with custom door controls will surely offer some way to controls them.
Yes, I understand that we might boast more "compatibility" and automation if we just reversed any L: expression on wrote back to the variable. It might work on some planes, but could have serious issues on others, and the most complex the plane simulation is, the more we would risk affecting it.
Of course, as an user, you are free to experiment with SPAD.neXt or AAO and try on a case by case basis to see if the direct method works for you.
