Michael
You might fine some of this useful which was a post made in a non public forum so most here have not seen it. I am talking about FS9/AFCAD but most rules apply to FSX also.
My original post is as follows
I saw a post on another forum where someone was telling someone else to place all approach data into the FS9 AFCAD program using a decompile/compile process.
I simply responded to say do not do that because AFCAD on a reopen and save flushes all data that Lee felt did not belong in AFCAD.
The poster came back a little irrate with questions on where Approach code belongs if not in a AFCAD bgl.
Some of what I posted pertains to all Airport enhancement utilities but the post was refering to FS9 which most of the rules I state are FSX also.
This may help with understanding that the XML is a very complex process that the SDK does not explain. It also gives insight to a further expansion of ADE in the near future.
> carrot symbols are his questions to me that I put in a quote box here
Quote:
>
>Allrighty then... So what do you add your new approach to then.
>
After you write a new XML of approaches and TERMINAL_WAYPOINTS you compile and place into the ...FS9\Scenery\Generic\scenery folder or FSX\\\Global\scenery folder. FS will handle the reindexing and the read sort order (your XML elements/Attributes) of the bgl automactically. What this does is unlocks the Approach data that is in the original AP9nnnn.bgl, layers it as a proper priority and then relocks the approach data at the proper higher layer without any intervention on the designers part.
That should also answer xxxxx question on where to put is Approach bgl which does not belong above all other 3rd party scenery. It MUST BE layered between the AP9/Xnnnnn.bgl appropriate folder and the Addon Scenery\scenery folder which is were MS requires ALL enhanced airports if a sub scenery folder of Addon is not made.
Quote:
>
>I assume they need to be within a set of <Airport> tags somewhere,
>
Yes, Approach data has to nest under a airport header because the Airport owns the data and then everything resides inside the FSdata. This becomes very complex because
1. The Airport header owns most everything that is not a subset to something else except non Terminal Navaids
2. The Airport owns the Runways but the Runway owns the ILS data.
3. The Airport owns the Runways, the Runway owns the ILS, but the ATC owns the Approach data for the ILS or any approach associated to the runway.
4. The Airport owns the Runway, the Runway owns the pattern, but the pattern is owned by the TNG FP for AI Planes and the Control tower (if it exsit) for the User Plane flying circuits. The pattern altitude is also own by the runway but is only honored by VFR (not IFR) TNG FP's that AI Planes are flying.
5. The Airport property does not own the runway but the Airport Header does. This is the foundation of my Crosswind Runway Technique I introduced when FS9 was released. A runway for a airport can be placed halfway around the world and the Airport knows it is there.
6. The Airport owns the Runway, the Runway owns the length, the Aircraft.cfg file for both the USER/AI Plane owns the Empty Weight of the Aircraft (EW) which then tells ATC what runway the AI/User is assigned for takeoff and arrival. This is the foundation I use to open all 5 parallel runways for arrival at my KATL for FSX.
The list can be endless but as you peck your way down through the XML you have to understand who controls and owns what subset.
Another example is some Scenery that you see (or lack of) on airport property is owned by the scenery database. That means you can build a exclude XML and compile every single exclude that you created for the entire world in a master XML because excludes are owned by the World Scenery Database.
Quote:
>
>what do I do, make a new XML with just the
>airport tags and the approaches?
>
Yes if that is all that you want in that bgl. Besides new or edited Approach data you can also place all
1. Multiple excludes which in some cases number more then 50 per airport
2. 100's of scenery libraryObject GUID's including both generic buildings and mdl models that also come from many different Regions. Some designers steer away from certain model.mdl which is in a Region and also suppose to be specific and locked, it is not. This does not require hacking any type FS9/FSX default bgl's and some of us have learned how to move Scenery from one part of the world to another without tampering with any MS protected code.
3. New Control Towers with Beacon's,
4. New Wind Socks,
5. Jetways made by Shez or other public 3rd party
6. Many many different types of static ground support equipment
7. New NDB's both TERMINAL and non TERMINAL based on who owns it and where it is prioritized in the XML structure
8. VOR's if new ones have been commissioned
9. TERMINAL_WAYPOINTS which are owned by the airport
10. WAYPOINTS again based on prioritizing and read sort order that the Airport does not own
11. New Taxiway signs
12. Move exsiting default Taxiway signs once they are unlocked
13. Add STAR approaches so ATC will vector all arrival's USER/AI off the STAR and onto the IAF Transition prior to the 30 degree offset vectors for final
14. Create exoctic VMC (clear weather) approaches so all AI Planes are forced to fly a LDA, SDA, IGS, GPS, RNAV, VORDME, VOR, NDBDME, NDB, Curved approaches to avoid high terrain on final, circle to land type approaches, etc.
the list can be almost endless
Some of what is in the list above requires a deleteALLxxxxxxxxx='s statement to block the default so it is not x2 (duplicated).
Some require a proper XML exclusion.
Some require a certain read order structure.
Some areas cannot be blocked or excluded and even if in your XML are still read from the original AP9/Xnnnnn.bgl.
Some don't require any blocking, read order or excluding.
FS9/FSX is smart enough to know if you add a certain element/attribute in your XML it will not load the default data but load what you have added so no duplicates occur at your airport when processed by the dll's.
Quote:
>
>Doesn't that effectively constitute "duplicate afcads"?
>
No, because none of what I listed above can even be in a Lee Swordy af2_xxxx.bgl enhanced airport unlike other Utilities in design now. A AFCAD bgl is designed to control all Ground behavior of User/AI Airplanes with the exception of the invisible scenery related to Freq's, Start Locations which are multi functional when passed through the dll, and some forms of Navaid data that displays on the Grid which is not owned by the Airport.
Dulicate AFCAD bgl's designed with Lee Swordy's Utility can cause a CTD because a Designer does not understand what causes the CTD inside the XML (AFCAD) to begin with.
You can have many many AFCAD's for one airport. I don't mean put one in and take one out like so many PAYWARE and FREEWARE scenery designers do to open and close different runways based on winds.
What I am talking about is the 8 AFCAD's I have for KATL or the 9 AFCAD's I have for KDFW that all together make up a single entire airport. We call those Overlay AFCAD's which is misleading because they are really side by side independent (8 or 9) Airports to make one functional Airport.
Most of what I have said above is FS9. There are a few exceptions for FSX because of the way MS realigned certain airport elements in the default APXnnnnn.bgl but the same applies during construction of a FSX enhanced airport which also follows the guidlines above.
One of the differences is that FSX did away with the Generic folder so all additional enhanced airport bgl's that are not part of ADE/FSXP/AFX or even AFCAD if it is used in FSX enhanced airport design now belongs in the ....FSX\Scenery\Global\scenery folder.
Probably a lot more then what you wanted to know so I will stop here unless you have more questions.
