They move away with the chance of cargo falling out of the airplane because the cargodoors are still open
That's not the case. It's not the cargo loaders have a "timer", so they move out regardless how what the cargo situation on the airplane is. They are obviously syncronized, the loader "knows" how much containers are to be loaded, and it won't go away until all cargo has been loaded so, there's now way you'll ever see cargo falling out of the airplane.
As another example: the cateringvehicles also move away after the doors are closed (same principle should be used with the cargoloaders).
Maybe, but that would only accomplish being consistent between the two services, not because there might be any problems.
2. I'm using the PMDG B744. So, this airplane should be recognised by default. I didn't change anything in the aircraft.cfg. The jetway movement in this example is from AES.
That's an entirely different issue, it's the AES door config that has the AES jetway move to the 2nd door, not the airplane.cfg, GSX is just configured to use the 1st door that is found in the aircraft.cfg or in the GSX internal database, and this WILL work on a scenery that uses standard FSX jetways, because they will move there.
The issue is, since AES uses its own door config, its own jetways will read that one and go to the other door, but GSX couldn't follow this strategy because, it the user doesn't have AES, the default jetway will then move to the 1st one (as specified in the aircraft.cfg, which FSX default jetway follows), ideally GSX might try to recognize if AES is in use and then read the door configuration from the AES file, to know were AES will place the jetway.
We are not very keen on doing this, considering that, 5 months after GSX release, AES still hasn't been modified as it should to integrate better with GSX (it should stop having its vehicles appearing automatically as soon as its menu is opened, and only create them when some operation is selected, like GSX).
So, the best solution in your case, which is only a problem because you are using GSX and AES together, is to modify the AES configuration file for that airplane, to use the 1st door, so it would behave as a default jetway.
3. What I was suggesting is that GSX should recognise that an user is on a FSDT-airport and that GSX is installed
As I've said already, it does it right now.
If that is the case then the default vehicles should already be removed at the gate the user is parked at (and that doesn't mean every other gate) upon loading the flight. Not when you're requesting the services. This prevents default vehicles clashing with an user airplane (e.g. the PMDG B744 at gate 107 at KLAX) before GSX is requested. It just looks nicer then.
If I understood you correctly, you would like to have GSX remove parked vehicles as soon the airplane is positioned there, instead of removing them only after the parking is selected or an operation is selected at the parking ?
First, I don't see how this would be relevant to FSDT sceneries specifically, if we adapted this strategy, it would be exactly the same on any other airport, at least all that have default ground vehicles.
But see my above reply: we made GSX in a way to ease (from our own side) an integration with AES.
The whole idea was to do nothing, unless the user do "something" with the GSX menu and selects something, either select a parking to be serviced, or select an operation when already parked. Doing this, we ensure that, from our side, we are allowing the user to freely choose using GSX or AES to do something, because we don't do anything unless a menu option is selected.
