Great work Jim. Any plans to include the container terminal of Kwai Chuen underneath the OM in a later update?Regards, Stan (EGPE)

>Darren>>When I released Kai Tak most of the buildings around the short>final to 13 were either default scenery or a few I added. This>was to fill in a voided area as a temp.>>I am working on adding the right size buildings and the old>bill boards that parallel 13 on the right side just before the>new GA Parking stands.>>Jim.Your Kai Tak has now become my fav add scenery. Flying the PMDG 747 into Kai tak in low visibility condition at night is the best flight sim experience I have.Do you have any plans for FSX? :)I hope..I would be able to import this into FSX. if not..please consider the FSX version.You know.. I think, you could make this a payware if you so desire. (I know.. I can feel the dirty looks coming my way right about now :) I know there areThomas KwongNovember 2004VHHH2005b.zip(All new VHHH airport with additional Hong Kong buildings and watercraft scenery)Eddie ChanNovember 2003hkautogen2.zip(Plenty of autogen buildings)Hong Kong Terrain MeshSRTM DataJae Y. Shin.Hongkong.zip(use in place of the mesh I have in the kaitak98.zip)as well as photscenery pvhk11.zip from http://forums.avsim.net/dcboard.php?az=sho...ing_type=searchMaybe,..tweak the buildings with some Chinese billboards and add a custom runway texture for Kai Tak. and you have a Payware if you so desire.Manny

Manny Like many others I also am waiting to see what FSX will enhance or remove but also keep compatible with FS9.I have been working on Kai Tak to enhance the scenery but don't want to get to far a head of what FSX does with the land and water mesh around the bay.My original goal was not scenery design as much as keeping the Airport Facility Database current in FS9 as new runways opened/renumbered over the last 3 years. Even to this day (3 years later) many high end Payware and Freeware scenery designers don't understand the coding of the Airport Facility Data (XML) that must coincide with the actual visible airport scenery they design toward.There are 2 schools of thought and both are weather related to greater then/lesser then 3 mile visiblity . Make the airport look as realistic as possible but then ATC or the AI Traffic does not work correctly as per the missing or misaligned invisible XML approach data. OR, Update the airport invisible approach XML scenery so ATC and AI Planes fly and land at the airport under all weather conditions but the airport scenery still resembles FS9 default.I have always leaned toward the second school of thought due to my level of skill in the design of actual airport scenery.SimFlyers, FlyTampa, Cloud9, Image, SimWings, etc. all design Airport scenery that looks good which leans toward the first school of thought. This is understandable based on their objective and goals. They want the User to enjoy the scenery and to do that the weather must be clear. If the weather falls below 3 mile visibility then the Airport scenery is only for the User Airplane flying on VATSIM and that still has its deceptions.FS9 sets a standard that interfaces the Airport scenery to what ATC says, the User Plane requesting and flying correct vectors/transistions and how well the AI Planes fly the vectors to final approach/land. All of this starts at about 108 NM's from the Airport which is the invisible Airport scenery. When you look at a airport in FS9 (unlike FS2002) you must think outward in all directions which Encompasses the Airport Visual Scenery Zone. Many are not aware of this Zone area and how it impacts all the flights into the redesigned airport.Most people only see the Airport as the visual scenery but when I designed Kai Tak and added default airport scenery that was just one entity of the entire package. Most of my time after adding the scenery was spent sittng in slew mode at 30,000 ft. 108 NM's (in all directions) from Kai Tak with TrafficToolBox.dll in hand or test flying with FS9 ATC to be sure (based on what I write in Approach XML) that all types of planes (AI/User) can find the airport with correct verbage issued by ATC. Once again it is understandable why many scenery designers of airports do not enter this unseen arena. Even MS in some cases could not get the invisible scenery correct (EHAM default transistions). We need to give credit to both Shehryar 'Shez' Ansari and Tom Gibson who design Freeware scenery that address's both schools of thought. There are several others like NL2000 and the designers of the Madrid airport that set their goals so airport scenery continues to work properly under all weather conditions per FS9. When FSX is released it is also Airport Facility dated as was FS9. The Aces team tells us that the Airport cutoff date was April 2005. That means airports like EHAM, KIAH, KMCO, KMIA, KDEN, KCLE, EFHK, LEBL, etc. will be current but others like KATL, KLAS, KMSP, PANC, KCVG, etc. will need updating.If FSX does not include the techniques I introduced for both my crosswind runway and visual curved approaches for AI Planes then many airports/runways will need changes made right out of the box.Kai Tak was designed so the AI Planes would fly the IGS 13 approach (visibility above/below 3 miles) with some small enhancements to the scenery for the User Plane. I have been working on skill levels of scenery design so my uploads will be more complete (both schools of thought used) in future releases.

Thanks Jim for the detailed explanation.BTW.. I am curious about something. In your current scenery..How does the AI aircraft know that they have to turn at the MM towards the runway?I mean.. if they are following the IGS 13 LOC/GS...Theoratically...they would go straight into the checkeredbox. How do they know that at that point they have to turn to 130degrees... not any earlier nor later. All that information is in the approach plate. The LOC/GS information does not provide information to turn and align at the rwy.Fascinating stuff!:)Manny

Excellent question and I have had many inquires to how this is done.First, draw an invisible line in your mine from the threshold of runway 13 backwards about 10 miles or so. In actuality, in FS9 it is an invisible extension of the black runway line you see with the AFCAD program.All approaches in FS9 are a 3 stage coded process and always seek the center line of the runway for landing as the end result or 3rd stage of coded programming.If we coded Kai Tak as a straight in approach without the IGS we need a FAF fix about 5 to 7 miles from the runway. We would then add the IAF 10 to 12 miles from the runway. Both these Terminal_Waypoints would be in direct line with the runway black link line.1st stage of FS9's default vectors to final is a 30 degree offset heading coded in the AI_Playr.dll towards a heading/IAF/FAF coded in the APnnnnnn.bgl approach. For a straight in Kai Tak approach to runway 13 it would look like this.This says the AI and User Plane will be instructed by ATC to descend to 3000 ft outside the FAF13/IAF13 and fly either a heading of 106 or 166 degrees which is the 30 degree offset of the runway heading which is 136 mag degrees.All the vectors to final that you fly in FS9 as you know allow you to capture the ILS from a 30 degree offset. That 30 degree offset is based on several values which include the IAF/FAF position and the heading above which 99.9 percent of the time (ILS) in FS9 is the same as the runway heading. So the first stage coded is fly a 30 degree offset and the 2nd and 3rd stage are combined into one because you are already on the extended black link line of the runway when you intercept the Localizer which is also in line with the runway.Now lets play a trick on ATC and FS9.Position a User Plane (slew) at 88 mag degrees in front of the checkerboard so you are at a (somewhat) right offset angle to RWY 13. The charts say the IGS is a 88 degree approach to the runway (I used 86 TRUE degrees) so the approach code looks like this.fixIdent="FAF13" altitude="3000.000F"heading="86.00" missedAltitude="4500.000F">Place the actual Localizer for the IGS as seen with AFCAD behind the checkerboard using a TRUE heading of 86 degrees. This is were the actual real world transmitter was years ago. When you slew backwards from the checkerboard and add the MM, FAF, OM, and IAF in the proper places they are no longer in direct line with the runway but on a inbound mag heading of 88 degrees to the checkerboard. ATC now thinks this is the runway heading. The User Plane also thinks this is the runway heading because of where the AFCAD Localizer transmitter is sitting.Now for the 3 stage approach sequence used by the AI_Playr.dll.1st stageATC directs everybody to a 30 degree offset based off of 88 degrees (IGS) so they can capture and intercept the Localizer maintaining 3000 ft. 2nd stageThe AI Plane locks onto the 88 degrees based on the IAF/FAF position. You the User plane lock onto the 88 degrees based on the instrumentation of the radio which is reading the actual Localizer position. 3rd stage You the User Plane will use visual cues at the MM to make the turn and align with the runway. AI planes have no visual cues.Remember the black link line of the runway that extends outward from the threshold? ATC and the AI Planes think that they are on this extended line but they are not. When the AI Plane nears the MM it starts to fiqure out that it is not on a direct line with the runway. ALSO it is not the MM that the AI Plane is seeking but an additional Terminal_Waypoint I added that coincides with the MM. You can see it with the GPS receiver and I unnamed it LD13AfixIdent="LD13A"flyOver="FALSE"turnDirection="R"theta="266.0"rho="3250.0"magneticCourse="86.0"altitudeDescriptor="A"altitude1="500.00F" />That says to "fly by" not "fly over" the fix (Boolean indicating whether this leg is intended to fly

WOW! Jim. Thank you for that very thorough detailed explanation. Absolutely fascinating stuff. And even more amazing, I actually understood what you said there in detail. :(:)Manny