GSX installer doesn't leave "a bunch of duplicate AFCADs behind".
As a standard behavior with ANY installation routine (and GSX is not any different), unless specifically programmed to remove more than it's supposed to, an Uninstaller will remove ONLY files that were placed by its related INSTALLER.
So, the "duplicate AFCADs" are NOT left behind by GSX Uninstaller by mistake but *just* because you probably added your own AFCADs and/or modified the default ones, so the GSX uninstaller will not remove them, because they weren't placed by that installer in the first place.
The same is happening for the scenery uninstallers: if you add any file to the scenery folder, only those files that were originally copied by the installer will be removed, not the ones you added.
Now, there might be another confusion about AFCADs "duplicates", if you are seeing a file named like this:
AP_KORD.BGL.31-01-2012-21-17-30.BAK
It's not a "duplicate", it's a BACKUP (see the .BAK extension ? this means it won't be active in FSX) made just for the only purpose to PRESERVE your OWN AFCADs.
This what the installer does, exactly:
- It downloads updated AFCADs in a TEMPORARY folder
- It checks every installed FSDT scenery folder, and compares the AFCAD with the same name you might have there, with the version that was just downloaded.
- It doesn't do a simple date/time check, which might not be always reliable, but it does an MD5 Hash comparison.
- If the AFCAD with the same name you have in that folder is different (either because it's an older version that we distributed, or because you modified it), a BACKUP is made, named like the original one, plus DATE+TIME, plus a .BAK extension, so it will be disabled in FSX, but still safe.
For example, updating the KORD AFCAD will result in a backup of your old file named AP_KORD.BGL.31-01-2012-21-17-30.BAK
- After the backup is made, the updated AFCAD is finally copied from the TEMP folder to its final destination in the FSX folder
We need to be sure that GSX works "out of the box" with our sceneries, which means being sure that people initially get the AFCAD we tested for it, but someone able to edit AFCADs, will surely able to figure out what that filename means, and naming it as such, should be the safest possible option, since it's rather unlikely you'll ever have a file overwritten by mistake (unless you start playing with your PC clock...)
Now, let's see your other questions:
if I have to use the original AFCAD/ADE at an airport for GSX to work,
You don't have to use the original AFCAD, GSX works with any standard AFCAD, but we supplied some that have been optimized for it, so we are reasonably sure it will work as we tested it.
Will GSX work with those if I modify the .bgl?
Yes.
How does GSX know the difference between the default Cancun and the Tropicalsim Cancun?
Simply by respecting the priority order of the Scenery Library. If you have Tropicalsim Cancun on an higher layer than any other Cancun airport (and you probably have), GSX will use THAT AFCAD so, it's all really logical, the one that is in use by FSX itself, because it's on a higher level, is the one that is used by GSX.
If not, why won't GSX work with my modified AFCAD files for FSDT airports?
Nobody said it won't, but it might work better with them. However, if you understand were the issues are in your AFCAD that might affect GSX, you can use the same approach in your AFCADs too.
If it will work with my modified FSDT airports, why did GSX install all of those default FSDT AFCADS?
Because, as the say, the devil is in the details...in this case, we are referring the the airport *customization*, which is a way to allow GSX to be fine-tuned to an airport so, if an airport has been already fully customized, it will still work with a different AFCAD, but some things *might* create issues.
When making a customization, we can specify the individual vehicles starting positions in several different ways, either by specifying a *radius* (from the center of the parking spot) on which the vehicles will be spread, but also using precise Lat/Lon coordinates. When Lat/Lon are used, there aren't any problems with replacing the AFCAD but, if a center+radius method is used AND you *move* the parking center, it MIGHT happen that vehicles that were ok using the original parking center as a reference, will appear offset up to the point of starting inside a building, or clashing with a static scenery object.
Another example is the Pushback paths. GSX operates the Pushback in two different ways: either using an automatic method that, based on the Left/Right/Both preferences will try to figure out the exit path automatically OR by specifying an existing AFCAD node as a "target" for the pushback.
This means, if you alter the nodes layout a lot AND there are custom Pushback paths AND the affected node was moved in a very different location (the program is not so dumb to search for a *specific* node, but it wil take the closest one to the coordinates specified as the original target so, it CAN tolerate moving nodes a bit), it's possible that you might have troubles with Pushback in that place, not always, sometimes the automatic can deal with it reasonably.
So no, GSX doesn't force you to use our supplied AFCADs. In fact, when an airport is "unsupported" (which means it doesn't have any kind of customization offered by us), you won't have to be very careful breaking things, since any random default airport is not really different than one with an AFCAD made by you.
This, assuming the AFCAD is made in a reasonable way, and no strange tricks like strange paths or what they call "plumbing technique" are used. Usually the simplest are the better ones, which doesn't mean you can't create an AFCAD with many nodes, but vehicles will move more naturally over simpler paths.
