This has been discussed already. GSX had this feature when it was in Beta. We found that it was just too risky touching the airplane and trying to open/close doors automatically, because you never known what other systems might be affected.
While this is not usually a big problem with default airplanes, with 3rd party airplanes, especially those that use custom variables for doors, it become quickly a big unreliable mess.
SOME 3rd party airplanes use only a single variable, to control the animation of the door, but they maintain an internal state of the door status to simulate, for example, the inability to open doors if there's no hydraulic power. But in some cases, these planes do not expect that something ELSE, not their own code, is changing it, so they get confused, because the doors status will not be in sync anymore with their internal simulation.
SOME other 3rd party airplane don't even have an internal simulation, so that would be probably easier, because we would just animate the door.
SOME other 3rd party airplanes (PMDG, for example) BOTH have their internal simulation AND they also enforce that NO other application can just open/close a door UNLESS a different method, not based on the custom variable that reads the animation, but on a custom EVENT will be used. And they also prevent the door couldn't be used if there's no power to it.
So, it becomes VERY complex ( interesting how it's easy to say "this is easy", if you don't analyze the problem thoroughly, like we did when GSX was still on the drawing board ) and it becomes VERY risky, VERY quickly, because we would have to handle all these cases specifically:
1) default airplanes or 3rd party planes with default commands
2) 3rd party airplanes with custom door commands, with an internal simulation of systems related to it that will get confused of something other than their own code will change the variables. Under case #2, we'll have two sub-cases: those that DO reply to a custom event we can trigger, and those that don't, so the only way to activate a door is to use a gauge that comes with the airplane, and can get confused for the above reasons.
3) 3rd party airplanes that have just animations with no system. Or, more precisely, that have no system that might be affected by a sudden change of the door coming from the outside THAT WE KNOW OF. That is to say, it's no entirely obvious if, in this case, acting on the door won't have side effects on that product
4) 3rd party airplanes that have internal simulations and also actively enforce that nobody is trying to change the doors, like constantly setting the variable to the value they THINK should be, based on their own internal simulation that we don't have any access to. Again, case #4 can have sub-cases, those that DO reply to a custom event we can trigger, and those that don't.
And it gets even more complex: to allow users to customize their airplanes, the airplane configuration editor should offer a way to handle ALL these cases, while now it's reasonably easier to use, because even in case of a custom variable, it's enough to write a single line that returns true/false.
We decided that it was better to be safe, and don't even try to modify anything in your airplane status, that's why GSX only READS informations from your plane, but it doesn't dare to modify any of it, and we'll leave the fun of hunting this entirely new class of potential bugs to the other developers that chose to undertake that route.
