Wow Shez,Wonderful, as usual. Just went for a early eve flight in my Mooney. :>)) Around the pattern a couple times to check things out.Thank you again for all your great work and generosity.. Now I can fly to Toledo next summer to watch the Mudhens. :>)Bill

Thanks for the work and sharing it!BTW, which on is the AFCAD file? And is it a ADE or AFCAD2 type?ThanksGhiom

KTOL was done with ADE9X and was compiled using the Extended Compile / Complex Split option. The original ADE file contains Shez's model libraries etc. which will not be available, so trying to open any one of the six bgl files and attempting to import the others does not work. (Attempting to recompile causes the loss of some important airport elements.) I will check to find out if opening only the file that contains the parking and making changes to that file alone will work and report the results here. Please keep in mind that the taxi, path and runways must not be altered because they provide the hard surface for the scenery layer and also are carefully aligned to match the visual aspect of the airport. Do not open anything and save with AFCAD. As a side note; I was only able to successfully work on and compile the KTOL ADE file after Shez supplied me with the complete saved ADE file and model libraries. I hope this answers your question without over complicating it to much.Regards,Mel

I have just finished checking on what I posted in the reply to Ghiom and as I suspected, opening the ADE file that contains only the parking etc, making a change, then recompiling, causes a loss of some airport data such as the communication frequencies and more. So the bottom line, I guess, is to suggest not to attempt any changes. The reason the ADE file(s) was done this way is because the complete airport file was much to complex and extensive and would not compile unless the extended compile / complex split option was used.Best regards,Mel

I have just finished checking on what I posted in the reply to Ghiom and as I suspected, opening the ADE file that contains only the parking etc, making a change, then recompiling, causes a loss of some airport data such as the communication frequencies and more. So the bottom line, I guess, is to suggest not to attempt any changes. The reason the ADE file(s) was done this way is because the complete airport file was much to complex and extensive and would not compile unless the extended compile / complex split option was used.Best regards,Mel

Well I guess I will have to hope that the AFCAD can be worked on by someone. I have MAIW's Toldeo F-16's based there and some of them are parking with the general aviation AI I have and not on the military ramp.

Well I guess I will have to hope that the AFCAD can be worked on by someone. I have MAIW's Toldeo F-16's based there and some of them are parking with the general aviation AI I have and not on the military ramp.

Hi,Please check in your MAIW F-16 aircraft configuration file for the line: "atc_parking_codes=112F" as an example, and change to "atc_parking_codes=112F, F16" I would suggest adding the F16 designation to all the F-16 entries. MAIW parking codes are specific to the AFCAD files they prepare. I used F16 because it is the code used in various parking specs texts and is therefore available for general use, meaning it would work for people who desired to install their own F-16 traffic. Sorry this is a inconvenience, however it was the only way to make the parking usable by MAIW and non MAIW users both. BTW there are 35 spots for F-16s that I placed at the 180th ANG. At the real KTOL there 27 designated spots, 4 in shelters, 23 in the open on the apron, plus space inside the hangar. On the numerous occasions that I was at the ANG I never seen anywhere near a full apron there. If what you are saying is that all the F-16 parking spots are all occupied and they are overflowing to the GA parking then the MAIW flight plans have been very generous with the ai for KTOL. If that is indeed the case, please get me as accurate a count of the max number of F-16s as you can so I will have a handle on what needs to be done. Meanwhile I will contact Shez and request his final version of the complete ADE file so I can make the necessary changes to add more F-16 parking. When that is done anyone who wants the updated version of the parking can PM me and I will email it to them.Mel

Hi,Please check in your MAIW F-16 aircraft configuration file for the line: "atc_parking_codes=112F" as an example, and change to "atc_parking_codes=112F, F16" I would suggest adding the F16 designation to all the F-16 entries. MAIW parking codes are specific to the AFCAD files they prepare. I used F16 because it is the code used in various parking specs texts and is therefore available for general use, meaning it would work for people who desired to install their own F-16 traffic. Sorry this is a inconvenience, however it was the only way to make the parking usable by MAIW and non MAIW users both. BTW there are 35 spots for F-16s that I placed at the 180th ANG. At the real KTOL there 27 designated spots, 4 in shelters, 23 in the open on the apron, plus space inside the hangar. On the numerous occasions that I was at the ANG I never seen anywhere near a full apron there. If what you are saying is that all the F-16 parking spots are all occupied and they are overflowing to the GA parking then the MAIW flight plans have been very generous with the ai for KTOL. If that is indeed the case, please get me as accurate a count of the max number of F-16s as you can so I will have a handle on what needs to be done. Meanwhile I will contact Shez and request his final version of the complete ADE file so I can make the necessary changes to add more F-16 parking. When that is done anyone who wants the updated version of the parking can PM me and I will email it to them.Mel

When I say I see F-16's parking with the GA traffic I don't mean a lot of them, it's only about 4 or 5. And the weird thing is there is plenty of open spaces on the military ramp for those planes to park but they still park on the GA ramp.And thanks for the tip on changing the atc_parking_codes=112F line to atc_parking_codes=112F, F16. Mine only has the 112F code.

When I say I see F-16's parking with the GA traffic I don't mean a lot of them, it's only about 4 or 5. And the weird thing is there is plenty of open spaces on the military ramp for those planes to park but they still park on the GA ramp.And thanks for the tip on changing the atc_parking_codes=112F line to atc_parking_codes=112F, F16. Mine only has the 112F code.

What I did was change the parking code on the MAIW GLAG F16's (C & D models) allocated to Toledo to atc_parking_codes=F16 and the parking is now perfect.

What I did was change the parking code on the MAIW GLAG F16's (C & D models) allocated to Toledo to atc_parking_codes=F16 and the parking is now perfect.

Thanks for letting us know that the parking code change works. I should point out that although that makes the F-16s park correctly at KTOL it may adversely affect parking at other airports where the MAIW flight plans send them. If you have the time could you please check to see if the "atc_parking_codes=112F, F16" works for KTOL parking? If it does, that will keep the F-16s parking correctly elsewhere. I would be happy to do this myself except that I don't have the F-16s installed right now. Maybe I can get around to it tonight. Thanks again.Best regards,Mel

And if anyone is going to fix up the parking you need to add at least 1 space on the military ramp so that a C-5 and KC-135 can park there. There is 1 C-5 and 1 KC-135 going to KTOL (from other MAIW packages) but there is no place for them to park on the military ramp.

I have just finished checking on what I posted in the reply to Ghiom and as I suspected, opening the ADE file that contains only the parking etc, making a change, then recompiling, causes a loss of some airport data such as the communication frequencies and more. So the bottom line, I guess, is to suggest not to attempt any changes. The reason the ADE file(s) was done this way is because the complete airport file was much to complex and extensive and would not compile unless the extended compile / complex split option was used.Best regards,Mel

When the Frequencies are not copied up into the ADE9 KTOL bgl the deleteAllFrequencies="TRUE" flag could have been set to "FALSE". This means FS9 must use the fallback method of reading certain airport data at the stock default bgl.When you open ADE9X and do work and save/compile, by default we set the False flag to True. If the frequencies are missing we use the load stock data tool to capture the missing data and other data as needed (Comm's, navaids and waypoints, Approach, nearby airports, etc.)This still may not work for KTOL if any of Shez's model data is compiled in the same bgl where the parking spots are compiled. That would require Shez to move any library models out of the bgl that has the airport and then users could make changes.hope this is helpfuljim

Hi Jim,Thank you for your input. You are correct of course. What we had to do is after using the Extended Compile / Complex Split option, we had to save the XMLs and manually make the corrections you mention for the data you described to be generated. The problem arises, it seems, when the airport is split, some data ends up in one bgl and some in others. As an example when the bgl file containing the parking is opened with ADE the Comm's etc are missing, yet everything is present in the Sim, however upon compiling that bgl everything goes missing. As near as I can figure, hand editing the relevant XMLs is the only way to maintain functionality. BTW Neither Shez's models nor mine are contained in the file with the parking, taxi, path, and runways. Again, thank you for the feedback and any further thoughts or suggestions would certainly be most welcome.From the XML containing the parking, taxi, path, and runways etc <Airport country="United States" state="Ohio" city="Toledo" name="Toledo Express" lat="41.5868048742414" lon="-83.8078334927559" alt="683.996F" magvar="5.59999990463257" ident="KTOL" > <Services> </Services> <DeleteAirport deleteAllRunways="TRUE" deleteAllStarts="TRUE" deleteAllHelipads="TRUE" deleteAllFrequencies="FALSE" <-------- changed from TRUE to FALSE ---- comms ect are present after compiling with bglcomp deleteAllTaxiways="TRUE" deleteAllAprons="TRUE" deleteAllApronLights="TRUE" deleteAllApproaches="FALSE"/> <Tower lat="41.5868048742414" lon="-83.8078334927559" <--------- draw back here is the tower location is lost and reverts to the default airport location. alt="0.0F" />Best regards,Mel

MelWe need to go back into the ADE9X code and see why the split compile may not be capturing all the airport data into a single bgl but I can see the problem.If no models exist in the ADE9 KTOL bgl then Open the bgl, Save the bgl as a .ad2 project file and compile. This will force all deleteall's to TRUE. Now use the tool "Load Stock Data" and it will give you the Freq's, waypoints, approaches, etc. back into the ADE9 bgl. Once that is done everyone could change their own airport parking.Probably no need to load back in the stock taxiway signs and default FS9 scenery since you and Shez used your own.jim

Is it just me or does Lee Swordy's AFCAD seem to be a lot easier to use? I mean you just want to resize 1 or 2 parking spots and maybe add or subtract a few parking codes. With AFCAD you open it up make the changes save and done, but look at all the stuff you have to go through with ADE.PS: I do you ADE but just for basic stuff. I use AFCAD a lot more.

AFCAD was designed with assumptions about scenery objects being limited in afd property type files before MS released that data as an SDK for developers. Opening and saving such a file in AFCAD could strip out any extra objects. In addition AFCAD will not do anything for approach paths.ADE is a two step process to modify airports. You can operate it as a one step process but you can lose changes by saving and opening a bgl created in it because special design tags are lost in the process. Generally you save the airport modification as a project file first (type ade) which can be reloaded later for further editing. After saving the airport project file you can then compile the .bgl file.There's more to that but that is an overview of ADE vs AFCAD.ADE for just modifying runways and stuff works just about like AFCAD for its interface such as dragging items around. ADE does not automatically import stock data but as Jim stated that can be done. If you open an AF_2 file and do Lists/Comms and see the comm frequencies you are all set to go make your changes and then save the project file and then compile it.But wait, there's more :) but that is it for now.

Jim has just made me aware of this thread and potential issues. I need to understand a bit more what the actual issue is. I think it has already been well covered that when ADE9 spilts the compile it creates a number of Bgl files. Spiltting was designed almost entirely to deal with the buffer overflow that the FS9 Bgl compiler suffers from when compiling complex airports (the FSX compiler does not have this limitation BTW). Each file contains what we call the airport header - so each Bgl file is in effect a copy of the airport that contains some groups of objects. To make sure they all work together we set the delete flags to ensure that only the object groups contained in that bgl file are set to true. Thus all the files are needed to work together to make the airport work. Loading one of them into ADE is likely to cause problems since some delete flags are set automatically. There is a method to get back to the original project if the project file is not available. You should be able to do this by opening the airport bgl file and then importing all the other files.I would not be able to guarantee that any partial load of a Bgl file created by Split Compile will work as expected and may well cause unexpected consequences with other elements.I think that one problem appears to be in relation to comms. Comms will be in the airport Bgl file and if the DeleteAll value does get changed by loading and compiling the airport Bgl file then we may have a bug. Loading and compiling another of the split Bgl files may well result in falling back to stock comms. All the other Bgl files must have the DeleteAll for Comms set to false since they are not handling comms. I am sorry if this comes across as complex (it is and I would much rather not have to engage in split compling to get around the compiler limitation) or I have not understood the problem correctly. If we have a bug then we will do our best to fix it.Finally AFCAD is mentioned. AFCAD does not have the compiler limitation since it uses its own non MS compliant compiler (as does AFX). It also does not handle a lot of things that ADE does such as approaches, taxi signs and scenery objects.. I surmise that you might be able to modify the Airport Bgl File alone with AFCAD.As to why ADE is two stage and AFCAD is single stage. Well there are several reasons - some already covered but here are a couple to consider:

• ADE stores a lot of information about the project that AFCAD does not. We store information about object states - locking and so on. We store and remember background image information; we store and remember helper shapes and guidelines.
• While AFCAD uses its own compiler we know that repeated load and save from the Bgl format with MS Compilers can cause loss of precision in placement and other data.
• To do everything that ADE does for an airport would require several tools in addition to AFCAD such as SBuilder, Rwy12 and so on. Also generally approaches would be hand crafted with XML.