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

I have so many great sceneries these days that I no longer fly into any others as the excellent ones keep me busy. That means that for me the MAIW designations for other airports don't matter as I never go to any of them. Unless it's a really good scenery, it's no longer very immersive for me and I have so many that are so why bother? It's all because of people like Shez who just keep raising the bar! LOL I'm spoiled...

Morn'n Folks,Are there any screenshots - anywhere ??? I'm dying to see this airport but I won't have access to my PC until at least the weekend... I've checked the usual places...Regards,Scott

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.

Hi Jon,I just attempted to modify the Bgl containing the parking, taxi, path and runway data with AFCAD as you suggested. The compiled Bgl also omitted the comms from the file because of the "deleteAllFrequencies=" flagged to TRUE, . . . . I suppose. I will PM you to provide you with a more detailed description of what I / we did with ADE and why. Thank you for ADE bye the way!Regards,Mel

Morn'n Folks,Are there any screenshots - anywhere ??? I'm dying to see this airport but I won't have access to my PC until at least the weekend... I've checked the usual places...Regards,Scott

Hi Scott,Try here: http://www.sunskyjet...php?topic=574.0These are screen shots from Shez's previews. These are very close to what the uploaded KTOL looks like. You will notice the jetways and some other missing details which are all in the upload.Mel

Shez, any chance you can point me to any more-recent tutorials for scenery creation or tips that you have? (or even better, have your own tutorial? haha).Like I've said, I'm a huge fan of your sceneries and have dabbled in it with almost no success from time to time. Always been interested to know how you guys do it.

Shez, any chance you can point me to any more-recent tutorials for scenery creation or tips that you have? (or even better, have your own tutorial? haha).Like I've said, I'm a huge fan of your sceneries and have dabbled in it with almost no success from time to time. Always been interested to know how you guys do it.

It is difficult as we use many different programs and techniques to develop one scenery. That is why it takes so long these days even for a smaller airport. The bar is going ever higher!A lot of the tips are on the FS Developer site. Check forums there and ask questions. Many people there help out. Of course if you want to ask me then I am willing to help with specific topics.Shez

Hi Mel,Thanks - looks really good - appreciate the assist...;)Regards,Scott

Just to clarify something for use in FS9, you can only use one ATC parking code for both the Aircraft.cfg entry and AFD parking spot entry. You can put as many entries in those values as you want but it's only going to reference the first one in each. In FS9, making the line "atc_parking_code=112F,F16" or changing the spot's code to "112F,F16" won't change anything. If the AI doesn't see "112F" in a parking spot, it will start looking for the next suitable spot. It will not start looking for a spot coded "F16".in this scenario. That's why we only ever use one unique code for the AI in our packs. I wish we could use multiple codes, it would solve many problems when the AI visit other bases. When the AI do visit other bases, they don't find their unique code, "112F" in this case. Since they have the line "atc_parking_type=MIL_COMBAT" in their .CFG file, they will then look for an uncoded MIL_COMBAT spot of a large enough radius to park in. In all of our AFD files, we leave extra, uncoded spots listed as MIL_COMBAT or MIL_CARGO as appropriate to provide a place to park transient fighters and transports in. As far as the numbers of AI included in the packs, we generally try to include every serial number in each pack. This isn't necessarily the most realistic situation as very few units ever have 100% of their aircraft available for missions. So the options are to leave some out in which case people complain that the packs are incomplete OR to put them all in and let each user decide what they want to do with them. BTW, love the scenery! Looks great, especially with the seasonal ground photo textures.

Morn'n All,I had a chance to check out KTOL over the weekend... Beautiful job gentlemen - I'll now be flying here quite often... Greatly appreciated... Only bit of constructive critisism I could offer - is that darn fence... Is there any way to reduce the Moire Effect - as it is pretty bad on my system??? I tried to "remip" and save as DXT3 with ConVimX - I couldn't discern any improvement... If not - is there an option to remove it ???Regards,Scott

Morn'n All,I had a chance to check out KTOL over the weekend... Beautiful job gentlemen - I'll now be flying here quite often... Greatly appreciated... Only bit of constructive critisism I could offer - is that darn fence... Is there any way to reduce the Moire Effect - as it is pretty bad on my system??? I tried to "remip" and save as DXT3 with ConVimX - I couldn't discern any improvement... If not - is there an option to remove it ???Regards,Scott

I find it becomes better at different antialiasing settings.Shez

Just to clarify something for use in FS9, you can only use one ATC parking code for both the Aircraft.cfg entry and AFD parking spot entry. You can put as many entries in those values as you want but it's only going to reference the first one in each. In FS9, making the line "atc_parking_code=112F,F16" or changing the spot's code to "112F,F16" won't change anything. If the AI doesn't see "112F" in a parking spot, it will start looking for the next suitable spot. It will not start looking for a spot coded "F16".in this scenario. That's why we only ever use one unique code for the AI in our packs. I wish we could use multiple codes, it would solve many problems when the AI visit other bases. When the AI do visit other bases, they don't find their unique code, "112F" in this case. Since they have the line "atc_parking_type=MIL_COMBAT" in their .CFG file, they will then look for an uncoded MIL_COMBAT spot of a large enough radius to park in. In all of our AFD files, we leave extra, uncoded spots listed as MIL_COMBAT or MIL_CARGO as appropriate to provide a place to park transient fighters and transports in. As far as the numbers of AI included in the packs, we generally try to include every serial number in each pack. This isn't necessarily the most realistic situation as very few units ever have 100% of their aircraft available for missions. So the options are to leave some out in which case people complain that the packs are incomplete OR to put them all in and let each user decide what they want to do with them. BTW, love the scenery! Looks great, especially with the seasonal ground photo textures.

Hi Mike,Thank you for the info and praise. A PM has been sent.Regards,Mel

Just to clarify something for use in FS9, you can only use one ATC parking code for both the Aircraft.cfg entry and AFD parking spot entry. You can put as many entries in those values as you want but it's only going to reference the first one in each. In FS9, making the line "atc_parking_code=112F,F16" or changing the spot's code to "112F,F16" won't change anything. If the AI doesn't see "112F" in a parking spot, it will start looking for the next suitable spot. It will not start looking for a spot coded "F16".in this scenario. That's why we only ever use one unique code for the AI in our packs. I wish we could use multiple codes, it would solve many problems when the AI visit other bases. When the AI do visit other bases, they don't find their unique code, "112F" in this case. Since they have the line "atc_parking_type=MIL_COMBAT" in their .CFG file, they will then look for an uncoded MIL_COMBAT spot of a large enough radius to park in. In all of our AFD files, we leave extra, uncoded spots listed as MIL_COMBAT or MIL_CARGO as appropriate to provide a place to park transient fighters and transports in. As far as the numbers of AI included in the packs, we generally try to include every serial number in each pack. This isn't necessarily the most realistic situation as very few units ever have 100% of their aircraft available for missions. So the options are to leave some out in which case people complain that the packs are incomplete OR to put them all in and let each user decide what they want to do with them. BTW, love the scenery! Looks great, especially with the seasonal ground photo textures.

Mike - let me take this opportunity to say thank you to you and all the MAIW team for the enormous contribution you have made to this hobby!!!