home *** CD-ROM | disk | FTP | other *** search
/ DP Tool Club 24 / CD_ASCQ_24_0995.iso / vrac / aafdoc.zip / APP200.TXT < prev    next >
Text File  |  1995-06-15  |  8KB  |  180 lines
  1.    I have had a number of responses from users both on CompuServe and
  2. Internet that are using Approach Control v2.0, and I am taking the time
  3. to write this Technical Note to help answer some of the questions that
  4. have been coming in, as well as discuss some of the ways you can increase
  5. the flexibility of the program.
  6.    Remember, if you have any comments or suggestions, I can be contacted
  7. at the addresses given in the README.1ST file in the APP200 archive:
  8.  
  9.    mechalas@gn.ecn.purdue.edu   (Internet)
  10.    71673,3041                   (CIS)
  11.  
  12.  
  13. --------------
  14.  
  15. - The .VOC Files -
  16.  
  17.    The decision to refer to the aircraft as "Flight Simulator" was, to be
  18. honest, made for lack of a better option.  In real ATC communications,
  19. you are typically referred to by the type of aircraft you are flying,
  20. followed by your four-digit ident number.  For example, "Twin Cessna 
  21. 4854" or "Learjet 4981".  Since there is no way of predictin what kind
  22. of aircraft is going to be flown, I didn't want to assign such names in
  23. the program, and stuck with "Flight SImulator" which is pretty universal.
  24.    Those of you with ATP will note that subLOGIC did roughly the same
  25. thing, and to be honest, I couldn't think of a better approach to the
  26. problem than theirs.  I am, however, open to suggestions, so if you have
  27. a better name than mine, I'd love to hear them.  To be honest, I don't
  28. like being referred to as "Flight SImulator" either.  :)  :)
  29.  
  30.  
  31. - Airport/Approach Control Names with Multiple Names -
  32.  
  33.    Some airports, such as Fort Wayne and Ohio State, have tower or 
  34. approach controls that require two words in their name.  In the current
  35. version of APP, due to the I/O routines I used, if you try to enter
  36. a two-part name, the space character is interpreted as the termination
  37. of the string.  So, instead of reading in "Fort Wayne", the program will
  38. read in "Fort".
  39.    One way to circumvent this problem is to use an underscore, and enter
  40. the names as Fort_Wayne or whatever.  Then, using a text editor, you can
  41. do a global search/replace in the .AAF file, and change "Fort_Wayne" to
  42. "Fort Wayne".
  43.    Any kind of search/replace would work, of course...this is just one
  44. example.
  45.    I plan of fixing this little quirk in the next release.
  46.  
  47.  
  48. - Modifying the Traffic Pattern -
  49.  
  50.    The idea of being able to change the traffic pattern is probably the
  51. most flexible aspect of the Approach Control program.  The default 
  52. settings in the .APP files are set up for a pattern that is aimed at
  53. jet-aircraft, but by modifying these values you can re-size the pattern,
  54. as well as alter it's shape, to accomplish any of the following:
  55.  
  56.    * "Tighten" the pattern to allow for slow aircraft
  57.    * Roughly approximate a VFR pattern (not perfect, but it will work)
  58.    * Modify the flight pattern in case the default vectors have you
  59.      flying through mountains or other objects  :)
  60.  
  61.    Before we can alter these settings, though, we need a little basic 
  62. understanding of how the approach "engine" works:
  63.  
  64.    Your flight pattern is defined as three "fixes", a Final Approach Fix,
  65. and the flight vectors in between them.  The FAF is not defined directly,
  66. but rather is indirectly defined by the location of fix number "1", the
  67. fix closest to the runway/approach centerline.  The default pattern is
  68. set up *roughly* as follows (as an example for runway 9):
  69.  
  70.  
  71.                  FAF ------------ 9======27   ( <-Runway ) 
  72.                 /
  73.                /
  74.               /
  75.             1
  76.              \
  77.                \
  78.                  \
  79.                    \   <- Flight path
  80.                      \
  81.                        \
  82.                         2 ------------------------ 3
  83.  
  84.    This is hard to draw in ASCII, so bear with me.  :)  The numbers
  85. 1 through 3 denote the fixes that you are vectored to, in order.  Note
  86. that, depending on your approach angle, ATC may vector you straight to
  87. fix number 2 or 1.  If you look at the sample OHARE.APP file, you will
  88. see that the default distances to the fixes are defined as,
  89.  
  90. 87.5322          <-- distance to fix #1
  91. 132.4499         <-- distance to fix #2
  92. 171.4833         <-- distance to fix #3
  93.  
  94.    Note that all units are in FS Units.  1 NM = 7.2 FS Units (approx.),
  95. so these distances become 12.2 NM, 18.4 NM, and 23.8 NM respectively.
  96. The numbers given below the distances in the .APP file give the default
  97. angles between the respective fixes and the runway/approach centerline.
  98. In OHARE.APP, we see the defaults are:
  99.  
  100. 17.7435          <-- angle between fix #1 and runway heading
  101. 45.2737          <-- angle between fix #2 and runway heading
  102. 88.6013          <-- angle between fix #3 and runway heading
  103.  
  104.    All angles are given in degrees.  Most of you will probably recogize
  105. this as a polar coordinate system, with the origin centered at the 
  106. airport, and the "zero" angle being the runway/approach heading.  By
  107. changing these values, you can alter the size and shape of the traffic
  108. pattern to fit your needs.  It is definitely a good idea to draw your
  109. traffic pattern up on a sheet of graph paper, then calculate the distances
  110. and angle offsets that way (it's how I designed my pattern, which exlpains
  111. the weird numbers/decimal points).
  112.    NOTE:  The same pattern will be applied to all runways!  The only way
  113. to alter the pattern for each runway individually is to go into the .AAF
  114. file and edit the fixes yourself...a tedious but workable process.  It
  115. would be too bulky and too complicated to arrange for the program to 
  116. create a different traffic pattern for each runway, but if I get enough
  117. calls for it, I'll consider adding the option in a future release.
  118.    ANOTHER NOTE:  The patterns are "mirrored" about the runway/approach
  119. centerline.  So, in the above example, somone approach from the "north"
  120. would go through a mirror image of the drawn traffic pattern.
  121.    The FAF is placed so that you intersect the localizer/approach path
  122. at a 40 degree angle (real life ATC uses a 30 degree angle, but I didn't
  123. want any tight turns...this provides for a wider margin of error in the
  124. ATC "engine").  You can modify its distance from the runway by changing
  125. the distance to fix #1.
  126.    DO NOT PLACE FIX #1 ON THE RUNWAY/APPROACH CENTERLINE!  The program
  127. won't "break" if you do this, but it will bend quite a bit.  :)  The
  128. adventure generator is assuming that the FAF and fix #1 are different
  129. points, so if you put them in the same place, you may get some strange
  130. results.
  131.  
  132.    Below is an example I posted to CompuServe that gives a rough VFR
  133. traffic pattern (or the closest approximation to one that APP is capable
  134. of).  Note that I chose arbitrary distances....those of you with more
  135. realistic goals in mind would want to lay out a more accurate setup than
  136. this one.  This example is for demonstration purposes more than for 
  137. accurate modeling.
  138.  
  139. Changing the angles and distances as follows,
  140.  
  141. 52.4167        ( <-- these are the distances to fixes 1 through 3 )
  142. 66.3804
  143. 61.0942
  144. 15.9454        ( <-- these are the angles between fixes 1 through 3
  145. 40.6013          and the runway/approach centerline )
  146. 135.0
  147.  
  148. gives the following traffic pattern:
  149.  
  150.  
  151.                    FAF------  9========27   ( <- runway )
  152.                    /
  153.                   1
  154.                   |
  155.                   |
  156.                   2-------------------------------3
  157.  
  158. This gives a 13 NM downwind, 4 NM base with a vector to final, and
  159. a 5 NM final. 
  160.    Sharp turns will lead to your being re-vectored during mid-turn,
  161. since ATC decides that you are supposed to end up at a certain point.
  162. It calculates the heading you need to fly from your current position,
  163. and as you are turning, that heading may change, leading to a new
  164. flight vector.  This is a characteristic of the ATC "engine", and isn't
  165. likely to be changed any time soon as I haven't really come up with a
  166. better system that gives reliable and consistent results.
  167.  
  168.  
  169. - Closing Comments -
  170.  
  171.    I hope you are enjoying the program.  :)  I have had a lot of fun
  172. both creating it and flying the adventures that it builds, and I am 
  173. always looking for ways to improve what I have done.  Remember to send
  174. me any comments or suggestions that you may have, no matter how trivial.
  175. I can't always promise a speedy reply (emailing me at Internet is 
  176. probably the best way to get a hold of me quickly), but I'll do my best
  177. to keep up.
  178.    Happy flying!   
  179.  
  180.