Since AFCAD was the sole - or at least by a very wide margin most popular - tool for airport design, its name became synonymous with that kind of file.
Not synonymous enough, apparently.
But wait, I think we are missing something here. AFCAD files are nothing else than BGL files made according to the Fs2004 XML format (BGLComp SDK). As they are made with AFCAD we tend to call them AFCAD files, but with SceneGenX or a bit of handwritten XML code you could create exactly the same BGL file. So please keep that in mind when you see the term AFCAD files next time.
https://www.scenerydesign.org/2006/09/what-is-a-afcad-file/
Nowadays you might as well use "ADE file" and most will know what you mean.
Only if they are clairvoyant. ADE makes airport files according to the FSX/P3D XML format, as well as airport files according to the FS9 XML format, therefore they are distinct from AFCAD's. The distinction is important, they are more than simple FS9 AFCAD. Airport Facilitator X (AFX) makes airport .bgls using FSX/P3D XML, but it does not use, nor recognize, "ADE files." Extending the logic of using the lowest common denominator to define something, perhaps we should call every computer generated file "file," so most will know what we mean.
This is the inherent problem with terminology. Call them what you will, but Ultimate Traffic most assuredly uses
airport.bgl’s, I have used the software myself and can confirm it - but, since they don’t call them AFCAD’s either, they simply don’t exist (and therefore it’s your problem)!
The good news is that, although it is indeed your problem, it’s a relatively simple fix. The situation involves the 30k airports, or 60k airports, included with the original FSX. Whatever the number, it's only a fraction of the actual airports serving world traffic, so AI traffic developers,
must add more destinations, in order to "fluff out the stock." So the problem isn't the actual traffic files, it is the bajillions of little stubish airports these software packages add, because AI traffic will not function without a valid departure/destination.
I am not sure of the UT naming convention, MyTraffic uses the ICAO code, plus a few characters to define folder location, almost as if it is set up for a user to tabulate their way to the airport they want to disable. You can use Airport Scanner to find all instances of an ICAO and disable the UT entries. The simplest solution, of all, is to disable the UT scenery layer. This will deactivate
all the added airports and it is something you can ask your users to do, Tic, to prove to then that the problems are caused by an interaction between your scenery and UT.
They can place their AFCAD in Addon Scenery folder or wherever but not that folder. Once users get the new airport and set priority over their AFCAD, every thing will be just fine.
Airport .bgl files (you call AFCAD's) are never stored in scenery/world/scenery, traffic .bgl's are and UT airport .bgl's should not be placed in addon scenery, they should be kept the the distinct UT scenery layer/folder and activated/deactivated from there. AI traffic package airport files are already set at a very low priority, somewhere down around US Cities. Addon Scenery and all addon packages reside much higher, so there should never be a need to change hierarchy to accomplish this. I believe it is confusion between the traffic .bgl's and airport bgl's that allows the assumption about the need to set priority.
Have a look at this software. Consider suggesting that your customer, who is so skilled at customizing his or her simulator to their exact specifications, take a more proprietary approach and start managing all these changes. One can type "VTBS" into the search field and explore and disable all version of VTBS that are not desired.
http://www.scruffyduck.org/simple-airport-scanner/4584282795
Remember, it is not the traffic schedules that are the problem. It is the added and consequently duplicated airports, that are necessary to enable the traffic schedules.
