I have had a number of responses from users both on CompuServe and Internet that are using Approach Control v2.0, and I am taking the time to write this Technical Note to help answer some of the questions that have been coming in, as well as discuss some of the ways you can increase the flexibility of the program. Remember, if you have any comments or suggestions, I can be contacted at the addresses given in the README.1ST file in the APP200 archive: mechalas@gn.ecn.purdue.edu (Internet) 71673,3041 (CIS) -------------- - The .VOC Files - The decision to refer to the aircraft as "Flight Simulator" was, to be honest, made for lack of a better option. In real ATC communications, you are typically referred to by the type of aircraft you are flying, followed by your four-digit ident number. For example, "Twin Cessna 4854" or "Learjet 4981". Since there is no way of predictin what kind of aircraft is going to be flown, I didn't want to assign such names in the program, and stuck with "Flight SImulator" which is pretty universal. Those of you with ATP will note that subLOGIC did roughly the same thing, and to be honest, I couldn't think of a better approach to the problem than theirs. I am, however, open to suggestions, so if you have a better name than mine, I'd love to hear them. To be honest, I don't like being referred to as "Flight SImulator" either. :) :) - Airport/Approach Control Names with Multiple Names - Some airports, such as Fort Wayne and Ohio State, have tower or approach controls that require two words in their name. In the current version of APP, due to the I/O routines I used, if you try to enter a two-part name, the space character is interpreted as the termination of the string. So, instead of reading in "Fort Wayne", the program will read in "Fort". One way to circumvent this problem is to use an underscore, and enter the names as Fort_Wayne or whatever. Then, using a text editor, you can do a global search/replace in the .AAF file, and change "Fort_Wayne" to "Fort Wayne". Any kind of search/replace would work, of course...this is just one example. I plan of fixing this little quirk in the next release. - Modifying the Traffic Pattern - The idea of being able to change the traffic pattern is probably the most flexible aspect of the Approach Control program. The default settings in the .APP files are set up for a pattern that is aimed at jet-aircraft, but by modifying these values you can re-size the pattern, as well as alter it's shape, to accomplish any of the following: * "Tighten" the pattern to allow for slow aircraft * Roughly approximate a VFR pattern (not perfect, but it will work) * Modify the flight pattern in case the default vectors have you flying through mountains or other objects :) Before we can alter these settings, though, we need a little basic understanding of how the approach "engine" works: Your flight pattern is defined as three "fixes", a Final Approach Fix, and the flight vectors in between them. The FAF is not defined directly, but rather is indirectly defined by the location of fix number "1", the fix closest to the runway/approach centerline. The default pattern is set up *roughly* as follows (as an example for runway 9): FAF ------------ 9======27 ( <-Runway ) / / / 1 \ \ \ \ <- Flight path \ \ 2 ------------------------ 3 This is hard to draw in ASCII, so bear with me. :) The numbers 1 through 3 denote the fixes that you are vectored to, in order. Note that, depending on your approach angle, ATC may vector you straight to fix number 2 or 1. If you look at the sample OHARE.APP file, you will see that the default distances to the fixes are defined as, 87.5322 <-- distance to fix #1 132.4499 <-- distance to fix #2 171.4833 <-- distance to fix #3 Note that all units are in FS Units. 1 NM = 7.2 FS Units (approx.), so these distances become 12.2 NM, 18.4 NM, and 23.8 NM respectively. The numbers given below the distances in the .APP file give the default angles between the respective fixes and the runway/approach centerline. In OHARE.APP, we see the defaults are: 17.7435 <-- angle between fix #1 and runway heading 45.2737 <-- angle between fix #2 and runway heading 88.6013 <-- angle between fix #3 and runway heading All angles are given in degrees. Most of you will probably recogize this as a polar coordinate system, with the origin centered at the airport, and the "zero" angle being the runway/approach heading. By changing these values, you can alter the size and shape of the traffic pattern to fit your needs. It is definitely a good idea to draw your traffic pattern up on a sheet of graph paper, then calculate the distances and angle offsets that way (it's how I designed my pattern, which exlpains the weird numbers/decimal points). NOTE: The same pattern will be applied to all runways! The only way to alter the pattern for each runway individually is to go into the .AAF file and edit the fixes yourself...a tedious but workable process. It would be too bulky and too complicated to arrange for the program to create a different traffic pattern for each runway, but if I get enough calls for it, I'll consider adding the option in a future release. ANOTHER NOTE: The patterns are "mirrored" about the runway/approach centerline. So, in the above example, somone approach from the "north" would go through a mirror image of the drawn traffic pattern. The FAF is placed so that you intersect the localizer/approach path at a 40 degree angle (real life ATC uses a 30 degree angle, but I didn't want any tight turns...this provides for a wider margin of error in the ATC "engine"). You can modify its distance from the runway by changing the distance to fix #1. DO NOT PLACE FIX #1 ON THE RUNWAY/APPROACH CENTERLINE! The program won't "break" if you do this, but it will bend quite a bit. :) The adventure generator is assuming that the FAF and fix #1 are different points, so if you put them in the same place, you may get some strange results. Below is an example I posted to CompuServe that gives a rough VFR traffic pattern (or the closest approximation to one that APP is capable of). Note that I chose arbitrary distances....those of you with more realistic goals in mind would want to lay out a more accurate setup than this one. This example is for demonstration purposes more than for accurate modeling. Changing the angles and distances as follows, 52.4167 ( <-- these are the distances to fixes 1 through 3 ) 66.3804 61.0942 15.9454 ( <-- these are the angles between fixes 1 through 3 40.6013 and the runway/approach centerline ) 135.0 gives the following traffic pattern: FAF------ 9========27 ( <- runway ) / 1 | | 2-------------------------------3 This gives a 13 NM downwind, 4 NM base with a vector to final, and a 5 NM final. Sharp turns will lead to your being re-vectored during mid-turn, since ATC decides that you are supposed to end up at a certain point. It calculates the heading you need to fly from your current position, and as you are turning, that heading may change, leading to a new flight vector. This is a characteristic of the ATC "engine", and isn't likely to be changed any time soon as I haven't really come up with a better system that gives reliable and consistent results. - Closing Comments - I hope you are enjoying the program. :) I have had a lot of fun both creating it and flying the adventures that it builds, and I am always looking for ways to improve what I have done. Remember to send me any comments or suggestions that you may have, no matter how trivial. I can't always promise a speedy reply (emailing me at Internet is probably the best way to get a hold of me quickly), but I'll do my best to keep up. Happy flying!