The AFCAD I'm trying to modify is px_afcad_v3.zip from AVSIM. Specifically, I want to change around the runway take-off/landing assignments. I go in, and make my changes successfully. When I try to compile, I get an error that says something about a VOR or ILS being out of range. I've looked and can't find anything amiss. The fault finder finds some problems with three ILS approaches, but I'm not so sure what it means. Could someone take a look at this AFCAD for me and let me know what I need to do in order to be able to compile it?
thanks
ps I'm using the fs9 version of ADE
These corrupt type AFCADs are all too common throughout the download world. On the surface they look fine but destroy the working part of the airport.
In the following picture the designer has tried to renumber the 01/19 runways to 18/36. In the process and its very hard to do with the AFCAD Utility the ILS's have lost there proper association with the correct runway.
Notice the 19R, 01L and 01R NAVAID Localizers still exist.
Now lets load this EHAM bgl into ADE9. When we run the fault finder we see that not only does the SA, SC and SP Idents still exist (without any information) but FS9 has duplicated them.
If I click on one of those duplicate Localizers it takes me far away from the airport where the designer thought he could move them without problems.
FS does not allow Localizers to be moved (within reason). ADE handles Localizers properly by using a orphan code. FS9 has dupicated the Localizers so 3 have been moved far away from the airport and the same 3 still exist at the airport.
Now when you try and compile this airport with the FS BGLComp Compiler it throws many fault errors and will not compile.
ERROR C2033: XML Parse Error (line, column, error)
ERROR: 169, 31, minInclusive constraint failed.
The attribute: 'frequency' has an invalid value according to its data type.
ERROR C2458: VOR/ILS FREQUENCY can be 108.00 to 117.95 and is in Mhz!
**** DUPLICATE VOR/ILS ****ERROR C2032: XML Parse Error! Element tree follows:
ERROR: 183, 31, minInclusive constraint failed.
The attribute: 'frequency' has an invalid value according to its data type.
ERROR C2458: VOR/ILS FREQUENCY can be 108.00 to 117.95 and is in Mhz!
**** DUPLICATE VOR/ILS ****ERROR C2032: XML Parse Error! Element tree follows:
ERROR: 288, 31, minInclusive constraint failed.
The attribute: 'frequency' has an invalid value according to its data type.
ERROR C2458: VOR/ILS FREQUENCY can be 108.00 to 117.95 and is in Mhz!
FATAL ERROR: Airport Output buffer OVERFLOW
ERROR: Schema errors detected, compilation failed!
The most severe compiler error for this type corrupt AFCAD is the Airport Output buffer OVERFLOW and that in AFCAD can cause FS9 to CTD when in a 108 NM radius of EHAM.
Because AFCAD does not allow any type approach code to be compiled in its XML, FS9 is falling back onto the default approach code in the C:\FS9\Scenery\EURW\scenery\AP949130.BGL. This means ATC cannot find any of the new runway numbers and in the GPS Receiver all the 01/19's now 18/36 approaches have been destroyed.
That can cause all the AI planes to loose their Hard Floor FAF altitude and fall out of the sky on approach to these runways. You will also hear ATC tell you (the user plane) to fly a visual approach to the 18/36 runways. If the weather at EHAM becomes IMC all those new 18/36 runways are useless. Every single FS9 EHAM that someone tried to renumber the runways (including high end payware) are corrupt in this way.
Bottom Line --- this is what we call a VATSIM airport with a possible CTD based on plane position.
My suggestion is to load the default EHAM into ADE9 and start building your airport. ADE9 will renumber the runways properly behind the scene with Jon's brilliant coding. Using AFCAD once some parts of the runway/taxiway are changed you cannot get it back without starting over.
