Well I have been called worse Mark - and forgive my somewhat distorted sense of humor (kitchen sink).Right now I am enjoying the cooler temps of Colorado (compared to 100 plus in the Dallas, TX area) and will be on this vacation until the second week in August so am just checking in via a borrowed computer from time to time to see what is going on.

I recently went through everything because I was having CTD's in a few areas. I did find a number of duplicate afcads. I only looked at ones that obviously duplicates, opened them up in AFCAD to make sure they were duplicates and then deleted them.The one surprising thing I found was FSDrteamteam scenery had duplicate afcads in the wrong folders - KFLL in the KLAS scenery folder along with the KLAS AFCAD, LSZH in the KJFK folder... MAIW also had a lot of optional AFCADS that remain after installation. I'm sure it said in the Readme to remove them but...

I only looked at ones that obviously duplicates, opened them up in AFCAD to make sure they were duplicates and then deleted them.

A word of caution to all about doing this. Some of you will know this, this is for those that don't.AF2 files created in Afcad2 cannot alter or control taxiway signs, and excludes. However there is a program called AFX which is similar to Afcad2, but designed more for FSX. It can, however, create AF2 type files that work in FS9 that can include taxiway sign and exclude information.If you use Afcad2 to open a file created with AFX that includes taxiway signs and/or excludes you will loose that info if you save the file in Afcad2.Best to make a copy of the file first before opening with Afcad2. Hope this helps,Joe

Even more interesting reading...thanks Jack! It really must have been ground breaking, (and somewhat satisfying), to develop both Afcad and ScanAFD. It appears that much of the internals of FS9 are secretive by MS nature. I do think you picked up my tack however. It would be nice to have a utility which scans the Afcads and alternate airport objects and only report if they are duplicates. Once an intelligence engine of this type is built, it is not that difficult to continue to refine. It could eventually encompass the entire scope of the BGL layout. It could also lend to easily knowing which other objects are associated with an airport or Afcad.The one thing that prevents the writing of the engine is the compiled BGL file layout. How does one disassemble the file header so the xml relationships and their settings can be interpreted? Have you, (or anyone else for that matter), seen a document of this nature anywhere? Now that would be nice to have, (especially since the ACES wings have been clipped).While I am looking at these issues from both an end user and software engineering perspective, I can't help but remember why I used Borland’s C++ compilers back in the 80's. The MS pathway was confusing and so poorly documented that it made it very difficult to understand all but the most basic Windows internals. So people would buy the Borland products because of their effort to explain the inner workings of the MS Kernel and make the MS documentation irrelevant.So Jack, if you do have the real BGL binary layout and you wouldn’t mind sharing it... :)Mark

A word of caution to all about doing this. Some of you will know this, this is for those that don't.AF2 files created in Afcad2 cannot alter or control taxiway signs, and excludes. However there is a program called AFX which is similar to Afcad2, but designed more for FSX. It can, however, create AF2 type files that work in FS9 that can include taxiway sign and exclude information.If you use Afcad2 to open a file created with AFX that includes taxiway signs and/or excludes you will loose that info if you save the file in Afcad2.Best to make a copy of the file first before opening with Afcad2. Hope this helps,Joe

I have heard this but forgot about this issue. For the above files, I was just checking to see if it was truly a duplicate afcad - not saving anything.BUTI typically make a few adjustments to every afcad when I get scenery - adjust parking codes, radius info... Is there a way to tell how the afcad was created before I save the adjustments? I would hate to hose up an afcad just to make a few adjustments. I have been doing this for year and I have noticed any problems yet. If do have AFX but I usually just use afcad

Is there a way to tell how the afcad was created before I save the adjustments? ... I do have AFX but I usually just use afcad

Short of the filename, no. Afcad will create a default filename beginning with AF2_, and I believe (I don't have it) AFX defaults to filenames beginning with AFX_. However I remember hearing stories of scenery designers creating files in AFX and renaming them AF2_ because this was more familiar to the end user.Maybe someone else knows more than I.Joe

Lee's compiler/decompiler is self made and does not follow any of the schema checksums that the SDK compiler uses (max vertex counts, 255 maximum airline parking spots, segmented taxiways, max node counts, max apron counts, multiple Localizers for a single end runway, etc.). Some of us (Lee's beta group) spent many hours reverse engineering multiple bgl's in order for AFCAD to work.ScanAFD reads airport headers. The problem is not ScanAFD but scenery designers do not know what belongs where in a bgl and add airport headers to a lot of XML compiled bgl's that do not do anything except slow FS down. When a airport header is added to the XML then ScanAFD finds it and reports the bgl as a duplicate airport.There are only 2 elements that AFCAD cannot handle that require a Airport header in a seperate bgl. Those are the approach code (with Terminal_Waypoints) and Taxiway signs. The actual problem starts when scenery designers add airport headers to a bgl that has a generic building, model data, exclusions, NAVAIDS (VOR's, NDB's, WAYPOINTS, etc.).Any element except approach code and taxiway signs are owned by the world database and not the airport database. When the designer places the airport header above a world database element such as an exclusion now ScanAFD thinks that exclusion bgl is a airport. Talk about slowing down FS with some of these so called highend scenery's because FS has to look at every single airport header and find something that is part of the </Airport> tag. Problem is, there is no airport owned data nesting in the airport header and too many of these bgl's that ScanAFD thinks are airports can cause slower loading times for the actual airport or studders in and around the airport.Airports do not ownExclusion Rectanglesany type building sceneryModel DataAdded airport support vehiclesAdded Jetways (FS9 only)NAVAIDS (except a T_Waypoint or T_NDB)Fuel TriggersEffectsWindsocksRotating BeaconsMarkersGeopolesetc.What a airport does own and requires a airport header Approaches (T_Waypoints and T_NDB's) <<<---- not allowed in AFCADApronLightsApronsAirport FrequenciesHelipadsRunways which also own the ILS's StartsTaxiwaysTaxiway signs <<<---- not allowed in AFCADYou can actually have as many duplicate airports that you want. FS does not care if 2 or more AFCAD's exist for the same stock airport. This however does slow the FPS since everything is drawing more then once.What FS cannot tolerate is duplicate start locations when 2 or more AFCAD's exist. This causes a CTD in FS since the "GO TO" is now corrupt with multiple start locations for the same airport. Start Locations can only be blocked one time but many other parts of the airport can have multiple blocking statements. Contrary to popular belief AFCAD does not replace the FS stock airport. When you start FS it loads the stock airport. If you make a AFCAD 3rd party airport it loads it also. FS now needs both airports (stock and AFCAD) in order to work. FS uses fallback code so only certain portions of the AFCAD airport block the stock from showing. MS does not allow anyone to replace their airport with a 3rd party airport. We can only enhance certain parts of the stock airport and MS makes sure that other parts of the stock airport are always present and in use.For the more precise user of FS a duplicate airport term is misleading. Any AFCAD added airport is the duplicate airport header since the stock and AFCAD airport must work together. If there are 2 AFCAD airports then you actually have 3 airports (stock + AFCAD + AFCAD). Most scanners do not understand that the stock and the AFCAD are duplicates. AFCAD does understand this and always list the stock airport in ghost print and the AFCAD in bold print showing 2 airports working togther. ADE has a FSX intellegent scanner that may in the near future be FS9 compatible. It does not rely on just finding a airport header but looks to see what is in the bgl before reporting it as a duplicate airport. jack

I read this again and this really does contain a whole bunch of very useful information on the inner workings of FS9. This should be pinned somewhere so the scenery guys can take a gander and remember this! Thanks again Jack...Mark