Many if not most of us use ScanAFD to find duplicated airport information is FS9. I did a scan for duplicates this morning and noticed a whole bunch of files, (listed as duplicates), that had titles such as OBEF8 or OBEF8OBEF8 or OBEF8OBEF8OBEF8...and the list goes on. Well, I've always seen these listed before but never had the where-with-all to ask what they are and if they have any effect on FS9. Anyone have any idea? Also, I'm using ScanAFD version 1.1 and was wondering if there is a more recent version of it or possibly a replacement. Let me know your thoughts and thanks!Mark

Many if not most of us use ScanAFD to find duplicated airport information is FS9. I did a scan for duplicates this morning and noticed a whole bunch of files, (listed as duplicates), that had titles such as OBEF8 or OBEF8OBEF8 or OBEF8OBEF8OBEF8...and the list goes on. Well, I've always seen these listed before but never had the where-with-all to ask what they are and if they have any effect on FS9. Anyone have any idea? Also, I'm using ScanAFD version 1.1 and was wondering if there is a more recent version of it or possibly a replacement. Let me know your thoughts and thanks!Mark

Some of those files contain important Navaide data - these are really not duplicates and should not be normally be disturbed.Duplicates which should be investigated are those which actually have the runway data in them. Those are the ones you need to be concerned with. You can easily look at each file it finds and check to see what it contains - just look at the various options the ScanAfd program presents. As far as I know there is no updated version of the ScanAfd utility.

Supposedly this program has an option to be able to look in all FS related folders and not just the "Addon Scenery" folder but I don't see how you add more directories to it. Is this really possible?

I believe this info is obtained by the program reading the scenery.cfg.Joe

Thanks Opa...thanks everyone. I figured that the BGL files simply held the reference point coordinate of an airport which objects were to be placed into. ScanAFD looks like it picks up this airport reference point, (probably from the master airport list?), and displays the object placer BGL/Afcad as a duplicate airport in it's listbox. I just wanted to make sure. One issue that I've always had was that California Central Coast Scenery's wonderful KSBA has a number of objects that they place in the airport via this technique. Not that it hurts anything, although, after you select KSBA as your depature airport and get ready to fly, FS9 will go ahead and list the departure airport as "Taxiway Signs".Mark

I believe this info is obtained by the program reading the scenery.cfg.Joe

Even when I knew I had duplicate AFCAD's loaded (because I did it on purpose) it still did not see them. The reason was because only one of them was located in Addon Scenery directory. I just don't know how to make it look elsewhere.

Even when I knew I had duplicate AFCAD's loaded (because I did it on purpose) it still did not see them. The reason was because only one of them was located in Addon Scenery directory. I just don't know how to make it look elsewhere.

Where was the second AF2 located?Was it in an active scenery folder?Joe

Where was the second AF2 located?Was it in an active scenery folder?Joe

Yes. It was in a different directory where all of my add on scenery packages are.Even when selecting the "All scenery addon directories" option it still didn't find anything.

Just thinking out loud here, was it an exact duplicate or a different AF2?Maybe having 2 exact copies of an AF2 isn't a problem as opposed to have 2 different AF2's for the same airport with conflicting data.Joe

There should be a check box you can click in the program on the bottom to tell it to look in all fs directories and not just the add on folder. I do this when i check for duplicates and it finds them all the time even if in different folders.

Just thinking out loud here, was it an exact duplicate or a different AF2?Maybe having 2 exact copies of an AF2 isn't a problem as opposed to have 2 different AF2's for the same airport with conflicting data.Joe

No, different versions.

There should be a check box you can click in the program on the bottom to tell it to look in all fs directories and not just the add on folder. I do this when i check for duplicates and it finds them all the time even if in different folders.

As mentioned earlier, this box was checked.

Thanks Opa...thanks everyone. I figured that the BGL files simply held the reference point coordinate of an airport which objects were to be placed into. ScanAFD looks like it picks up this airport reference point, (probably from the master airport list?), and displays the object placer BGL/Afcad as a duplicate airport in it's listbox. I just wanted to make sure. One issue that I've always had was that California Central Coast Scenery's wonderful KSBA has a number of objects that they place in the airport via this technique. Not that it hurts anything, although, after you select KSBA as your depature airport and get ready to fly, FS9 will go ahead and list the departure airport as "Taxiway Signs".Mark

As I understand it Mark, ScanAfd and for that matter FS itself, reads a "header" in the bgl file itself to determine if it is what we often call an "afcad" - it does not read the file name as such.Indeed the afcad can have any name you wish to give it - it does not have to use the conventional pattern of AF2_ICAO.bgl. A year or so ago - as a test - I renamed one to Kitchen_sink.bgl and it worked just fine. :(

Ah, Interesting...and the Kitchen Sink too! So now I'm currently hunting down a doc by Mr. Winfried Orthman concerning the binary interpretation of a BGL header. I also read the the BGL comp doc, (from the MS SDK), and saw that you were right Opa. Contained in the header is an airport facility data reference tag for xml. While I was reading the BGL comp doc, I kept seeing Lee's Afcad...it's right out of the spec. I just wonder where he got the info to actually read/write the binary file. Is it just a standard xml compiler...I wonder. Regardless, thanks Opa, you really have been around the block and are always a great resource :)Mark

Ah, Interesting...and the Kitchen Sink too! So now I'm currently hunting down a doc by Mr. Winfried Orthman concerning the binary interpretation of a BGL header. I also read the the BGL comp doc, (from the MS SDK), and saw that you were right Opa. Contained in the header is an airport facility data reference tag for xml. While I was reading the BGL comp doc, I kept seeing Lee's Afcad...it's right out of the spec. I just wonder where he got the info to actually read/write the binary file. Is it just a standard xml compiler...I wonder. Regardless, thanks Opa, you really have been around the block and are always a great resource :)Mark

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

Ah, Interesting...and the Kitchen Sink too! So now I'm currently hunting down a doc by Mr. Winfried Orthman concerning the binary interpretation of a BGL header. I also read the the BGL comp doc, (from the MS SDK), and saw that you were right Opa. Contained in the header is an airport facility data reference tag for xml. While I was reading the BGL comp doc, I kept seeing Lee's Afcad...it's right out of the spec. I just wonder where he got the info to actually read/write the binary file. Is it just a standard xml compiler...I wonder. Regardless, thanks Opa, you really have been around the block and are always a great resource :)Mark

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.