Appendix


A DHC3F Otter in the Livery of "RACF - rescue"

Technical Terms & Abbreviations

If you look for a term not listed here, i suggest you look at: http://en.wikipedia.org/wiki/List_of_aviation,_aerospace_and_aeronautical_abbreviations
ADF "Automatic Direction Finder" = finding the direction to a given NDB, see http://en.wikipedia.org/wiki/Radio_direction_finder
AGL "Altitude above Ground-Level": Usually measured by radar!
AI "Artificial Intelligence" = try to simulate the human brain by machines, see e.g. http://en.wikipedia.org/wiki/Artificial_intelligence
Airport
Is defined in FlightGear by the international 4 digit ICAO-code. If you only know 3 digits add a "K" or a "3" in front.
AoA
"Angle of Attack" is the angle between the "chord line" of the wing to the motion-vector of the air. See also http://en.wikipedia.org/wiki/Angle_of_attack
API "Application Program Interface" is the interface defined by an application, for other programs or devices to attach.
Airway
That are standard routs, defined by VORs, NDBs, and/or FIXpoints. Thus you can define a rout much easier by e.g. "V334" than by "from VOR SJC radial 009, to FIX SUNO, to FIX ALTAM, to OAKEY, etc....). Those airways are outlined in aironautical charts, but also in MPmap, etc.
ASCII "American Standard Code for Information Interchange“ defines a world wide standard how "text" can be stored and transported in communications. ref. http://en.wikipedia.org/wiki/ASCII
ATC "Air Traffic Control" in FlightGear can be an AI-ATC manipulated by  "menu » Multiplayer » Chat Menu"  or it can be  a Model  with a  big Radar-Screen and some tools to enable a human providing ATC to FlightGear-multiplayers. 
ATIS "Automatic Terminal Information Service" is a continuous broadcast of recorded information at busy airports, providing informations like Weather, active Runway, etc. See http://en.wikipedia.org/wiki/Automatic_Terminal_Information_Service
Binaries or "Binary file" is a program that can directly be executed by a computer (oposed to a "script" that has to be compiled to a binary prior that it can be executed. See e.g. http://en.wikipedia.org/wiki/Binary_file
CDI "Course Deviation Indicator" is the indicator inside a VOR-instrument to show the course and devitaion to that course. This is needed if flying by VOR or landing by ILS. Also see the description under Radio-NAV.
Compiler Is a program that translates (compiles) a "script" to an computer-executable "binary". See e.g. http://en.wikipedia.org/wiki/Compiler
DME Distance Measuring Equipment” measures the distance of an aircraft to a Radio-station. Most of the "VOR"-stations today are equipt with DME, but there are also DME standalone stations with an own frequency. See e.g. http://en.wikipedia.org/wiki/Distance_measuring_equipment
FAA "Federal Aviation Administration" is an US-Agency to regulate all aspects of civil aviation. See e.g.  http://en.wikipedia.org/wiki/FAA
FGrun Is a GUI for starting FlightGear. It is also known as the "FlightGear Wizard" (in Windows) and/or GUI-Launcher (in MAC OS X). It is included in the binaries for Windows and MAC OS X - and also contained in a Linux Installation script (http://wiki.flightgear.org/index.php/Scripted_Compilation_on_Linux_Debian/Ubuntu). For its functions see the chapter: FGrun
FIX Is a fixed Navigation-point for aviation. It has no Radio-functions itself - but may be defined by multiple radio-stations (e.g. a crosspoint of radials from two VORs, and similar.)
FPM "Feet per Minute“ defines how fast an aircraft climbs or sinks.
FPS "Frams Per Second" defines the refresh cycle of the screen-images. You can monitor that FPM-rate
  » till FlightGear 1.9 via: "Menü → View → Rendering Options → Show frame Rate
  » since FlightGear 2.0 via: "Menü → View → Display Options → Show frame rate
For movies a typical FPS is 24 - in FlightGear values as low as 10 may be satisfactory. The FPS may vary extremely depending on flying over open water (no scenery at all) and e.g. a city like "Paris/France" with all famous buildings modeled.

GA "General Aviation" defines "Private" air-traffic against "Public Transportation" - but GA may also be used for "small aircraft" against "biggies"!
GNU Defines a "free Operating System", siehe http://en.wikipedia.org/wiki/GNU with the license GPL
GPL General Public License” (i.e. can be used, copied, redistributed, sold, "but must remain open", etc.), is the formal license for "free" products. See e.g. http://en.wikipedia.org/wiki/Gpl
GPS "Global Positioning System" is used in this manual as a means to define any position on earth by Longitude and Latitude . See e.g. http://en.wikipedia.org/wiki/Global_Positioning_System
GUI Graphical User Interface” is a little program allowing users to select/define options by using graphical devices instead of typing text-based interfaces.
HUD "Head-Up-Display" is a transparent display that presents data without requiring users to look away from their usual viewpoint. See e.g. http://en.wikipedia.org/wiki/Head-up_display
IAF "Initial Approach Fix“ is the starting point of an IAP which guides an aircraft on its final approach.
IAP "Initial Approach Procedure“ is the predefined way how an aircraft approaches under IFR conditions. See chapter IFR Cross Country -IAP
 IAS
CAS
GS
TAS
"Indicated AirSpeed“ ist the airspeed as measured at the Pitot.
"Calibrated AirSpeed“ is the IAS, corrected according to indicator and position errors within an aircraft
"Ground-Speed" is the speed over terrain (measured  e.g. by GPS).

"True Airspeed“ is GS ± the wind
see http://wiki.flightgear.org/index.php/Understanding_airspeed_measures
ICAO The “International Civil Aviation Organization” defines the ICAO-ID for all airports worldwide. Those structured ID's are always 4 digits. In the US there may be used also the 3 digit IATA codes. The difference is usually just a "K" or "3" as first digit in the code. See e.g.: http://en.wikipedia.org/wiki/International_Civil_Aviation_Organization_airport_code
Icon An icon is a small pictogram used to start programs when clicked on with a mouse.
ID "Identification": Can be a "personal number" (e.g. social security). For Navigation purposes it is the Morse-code that is sent by a transmitter to identify itself.
IFR "Instrument Flight Rules“ are the rules a pilot has to comply with when flying without visual contact to ground. See e.g.: http://en.wikipedia.org/wiki/Instrument_flight_rules
ILS "Instrument Landing System" guides aircraft to the landing point on a runway. ref. http://en.wikipedia.org/wiki/Instrument_landing_system
Joystick A joystick is an input device consisting of a stick that pivots on a base and reports its angle or direction to the device it is controlling (ref.: http://en.wikipedia.org/wiki/Joystick). In this book used for any external control-device (e.g. yoke, throttle, rudder pedals, etc.) with the exception of mouse and keyboard.
kn, nm, km "kt“ is the old abbreviation for the modern "kn“! 1 kn = 1 Nautical Mile/hour = 1,852 Kilometer/hour ≈ 0,51444 meter/second (1 km/h = 0,539954 kn/h):
        mi          kn/nm            km
        1             0,87              1,61
       1,15           1                 1,85
       0,62         0,54                1
Linux defines an Operating-System that is based on the free, portable, Unix-like Linux-Kernel (see e.g. http://en.wikipedia.org/wiki/Linux_distribution)
LOM "Locator Outer Marker“ is a radio-beacon about 4 NM outbound the landing-point of a runway. At this point an aircraft should be on an altitude of about 4 × 318ft/NM + 50 ft == 1320 ft (for the standard 3° glideslope). See e.g. http://en.wikipedia.org/wiki/Instrument_landing_system.
Mach Mach 1 == Speed of sound. Usually pilots use Mach (instead of IAS) above 26.000 ft. ref.: http://en.wikipedia.org/wiki/Mach_number
Metar A METAR is an internationally codified observation message indicating an airfield weather conditions observed at a given time. See http://wiki.flightgear.org/index.php/METAR#METAR and/or http://en.wikipedia.org/wiki/METAR
MPchat
When you activated the Multiplayer mode (see next), then you can exchange messages with other Multiplyers inside a range of 100 nm. See the then available Menu-Bar options under "Multiplayer"!
Multiplayer Are FlightGear events with several participants, e.g. Sightseeing trips, "Dog-Fights", ATC, Air to Air refueling, flight-training, towing/gliding, etc.. See e.g. http://wiki.flightgear.org/index.php/Howto:_Multiplayer 
NDB Non-Directional Beacon” is the Radio-Beacon that transmits the signal which can be received by the ADF inside the aircraft. The ADF-Instrument then directs the aircraft into the direction of the NDB. See e.g. http://en.wikipedia.org/wiki/Non-directional_beacon
OBS "Omni BearingSelector", the knob at the round NAV-displays with which you set the radial on wich you want to fly "TO" or "FROM" a VOR. See the description under Radio-NAV.
OpenGL This is an "Open" API for Graphic-Cards. See e.g. http://en.wikipedia.org/wiki/OpenGL
PopUp is a (small) window appearing on the desktop to enable user selection, input, information, etc.
Port is a virtual data connection between computer programs possibly through a computer network
Preflight is used in this Manual as a bundle of all activities a pilot has to perform before starting his engines for a flight.
Properties within the "FlightGear­Menu → Debug → Browse Internal Properties" you can inspect, set, change and trace any values used during the FlightGear simulation. 
QNH is the "barometric pressure adjusted to sea level." See e.g. http://en.wikipedia.org/wiki/QNH. So if you adjust your altimeter to the airport-altitude while parked on ground - then the barometric indication inside the altimeter will show the QNH-barometric pressure. And reverse: If setting the QNH (as announced by weather-stations or ATIS) in the altimeter, the altimeter will show the true altitude above sea-level. So prior to take-off you should set your altimeter to the airport-altitude -- and prior landing according to the QNH reported by ATIS.
render The conversion of data into it's presentation on a screen, depending on the screen performance data.
Runway The runways on airports are defined by the first 2 digits of the runway-heading and optional one alpha (R(ight), L(eft), C(center)). See e.g. EHAM with 3 parallel runways 18R, 18C, and 18L -- and also a "standalone" runway 09. If more then 3 runway are parallel then the 2 digit number may vary by ±1 (see e.g. KATL with 08L, 08R, 09L, 09R, 10 (the actual heading being for all 5: 89.98°). Those ID's are always painted in big letters onto the runway-pavement at the startpoint, so that all pilots can see it prior landing (e.g. if the wind just happened to blow the airmap out the window!). This 2 digit direction (±1°) is good enough for a casual pilot - but when setting the autopilot you should set the exact radial (look it up on a map, e.g. MPmap)!
Scenery $FG_Scenery indicates the directory in which the sceneries for FlightGear are stored. These include the Sub-Directories "Terrain" and "Objects".
Scripts The in a programming-language written source-codes in text-form. These will then be "compiled" to the machine-readable "binaries"
Simmers Fans of Simulation-Applications
Source-Code Is a group of scripts needed for a (complex) program. All "scripts" together will be compiled to the so called binary.
TerraSync Is a feature-program enabling FlightGear to download needed sceneries "on the fly". See http://wiki.flightgear.org/index.php/TerraSyn
TACAN "Tactical Air Navigation" is the military equivalent to the civil VOR, ADF, DME, see e.g. http://en.wikipedia.org/wiki/Tactical_air_navigation_system
TakeOff The beginning of a flight after the aircraft has been started and taxied to and onto the runway. All these steps do require a prior clearance from ATC.
VFR "Visual Flight Rules“ are the the oposite to "IFR". See e.g. http://en.wikipedia.org/wiki/Visual_flight_rules
VOR VHF Omnidirectional Radio Range” sends radials which the aircraft-instruments use to indicate in what direction the VOR is. The pilot can follow such a radial to track an exact course to/from a VOR, or define his current position by using multiple Navigation-Radios. See e.g. http://en.wikipedia.org/wiki/VHF_omnidirectional_range and part Radio-NAV in this book.
wiki (hawaiisch for "quick") are Hypertext-Systems for Internet-Pages, see especially http://wiki.flightgear.org/index.php/Main_Page

Command Options

If you do not find an option in the following list, start FLightGear in a Command-Window  with the only options "--fg-root=directory" and "-h -v"

In the following you find ALL options grouped according to the FGrun sequence. At the top of each group there is a short summary what is being defined on the FGrun-pages. The options are listed in alphabetical order within their groups, after prefixes enable/disable have been neglected.

The default setting of the options are shown in green!


Aircraft

--aircraft=model             (Synonym: ­­--vehicle=model)
Defines which aircraft will you will use (e.g. --aircraft=c172p). See all installed/downloaded models in $FG_ROOT/Aircraft, there you also find the aircraft-directories you also find the available sub-models » see the "...set.xml" files.
e.g. for the c172p you will find:
c172p­set.xml (the Master­Model)
c172p­2dpanel­set.xml (a version with 2D-panels)
c172p­panel­only­set.xml (a version just showing a 2D-panel for ILS-training)
That means you can chose out of 3 different versions which you define by specifying the name of the "..set.xml"-file -- without the set.xml:
1. ­­aircraft=c172p
2. ­­aircraft=c172p­2dpanel
3. ­­aircraft=c172ppanel­only
See also the following "--show-aircraft" and the chapter "Installing Aircraft"

--show-­aircraft
Will list all installed aircraft including submodels, sorted by name

-
-livery=Name
Selects an optional/additional “Livery”. For available Liveries see the directory FG__ROOT/Aircraft/Model­Name/Models/Liveries. (Available starting ver. 2.0)

--min-­status=
{alpha,beta,early-production,production}
Allows you to define a minimum status level (=development status) for all listed aircraft. Be patient: Gathering all that information takes some time, if you have downloaded many aircrafts!

(Be patient - that searching and listing may take some time!)

--fg-aircraft=Pfath
Specify additional aircraft directory path(s). The standard path is “$FG_ROOT/Aircraft”.


General

-- help          (or "-h")
Lists the most relevant options actually installed

--verbose      (or  "-v")
The combination  "-h -v" lists ALL options actually installed

--language=
code
Defines in what language the FlightGear-menus shall be presented, e.g. de, en, fr, it, nl, pl. See all installed translations in your directory $FG_RROT/Translation. This option is new staring with ver. 2.0.

-- version
Shows the active version of FlightGear installed and some additional Infos, see e.g.:
FGFS 1.9 on UBUNTU FGFS 2.0 on Windows­XP
1.9.1 
 $FG_ROOT=/usr/share/FlightGear/data 
 $FG_HOME=/home/YourName/.fgfs

 $FG_ROOT=D:\FlightGear_2\data
 $FG_HOME=C:/Dokumente und
     Einstellungen/YourName/application/flightgear.org
  $FG_SCENERY=D:/FlightGear_2/data/Scenery:
     D:/FlightGear_2/data/Scenery/Terrain:D:/
     FlightGear_2/data/Scenery/Objects:
  SimGear version: "2.0.0"
  PLIB version: 185


-- fg-­root=path
Defines where FlightGear looks for its data-files.  Ref.:  $FG_ROOT.

-- fg-scenery=path
Defines where FlightGear looks for its data-files.  Ref.:  $FG_SCENERY

-- ­­browser-­app=path
If you have multiple browsers installed you can define which one you will use for FlightGear. To force FlightGear to use the Windows browser you define: ­­--browser-­app=C:\Program Files\Internet Explorer\iexplore.exe

--­­enable-­save-­on-­exit
­­        --disable-­save-­on-­exit

Allow(or not) saving preferences at program exit to prime with the next start. The "saving" only works when exiting via "file » exit" (so do not use the "X" in the titelbar!)

--control=mode
Defines the primary device you use for control, either joystick, mouse, or keyboard. Watch it: The device must be attached prior to starting FlightGear.

--enable-­auto-­coordination ­­        --disable-­auto-­coordination
Activates the automatic coordination between Aileron and Rudder. Enabled it helps beginners to fly turns -- but it also prevents you from performing advanced procedures like "Slip", etc.

--units-­feet ­­            --units-­meters
Defines if you want to use "feet" or "meter" -- when you fly in multiplayer-mode we urge you to use "feet", so that all pilots can exchange attitude  informations.

--config=path
Will load additional XML-files to configure special models. During the installation of that unique model the designer must tell you which additional files must be loaded. You would the define e.g.:  --config=./Aircraft/X15­set.xml


Features

--enable-­ai-­models ­­            --disable-­ai-­models
Enable/Disable  showing "artificial intelligence" models. That includes the aircrafts of other multiplayer users and also those generated by the "artificial traffic" that is established for many major airports. If you are flying in multiplayer-mode together with others you should set "--props:/sim/traffic­-manager/enabled=false" in order to disable the artificially traffic, because that is different for each user, i.e. each multiplayer would see different traffic. Also "artificial traffic" might make it very difficulties to differentiate between the aircraft of other users and the artificial ones.

--ai-­scenario=name
Activates the special artificial sceneries in which you fly for certain demos, e.g.: ­­--ai­-scenario=droptank_demo. For a list of available demos see the *.xml files in $FG_ROOT/AI

--enable-­random-­objects ­­            --disable-­random-­objects
Enable/Disable including random scenery objects like buildings etc.


HUD Options (Head­Up­Display)

--enable-­hud ­­                        --disable-­hud
Enable/Disable Heads Up Display

--enable-­hud­3d ­­                    --disable-­hud­3d
Enable/Disable the 3D HUD

--enable-­anti-­alias-­hud ­­        --disable-­anti-­alias-­hud
Enable/Disable filters to avoid “Moiré pattern” e.t.c (see http://en.wikipedia.org/wiki/Aliasing )

--hud-­tris
Displays the number of triangles rendered

--hud-­culled
displays the percentage of triangles culled


Audio

The settings here do only affect the FlightGear internal sounds. They do not affect others, like e.g. FGCOM, Festival, etc.

--enable-­sound ­­                --disable-­sound
Enable/Disable sound effects of FlightGear (NOT FGcom etc.)

--show-­sound-­devices
Show a list of available audio devices (starting ver. 2.0)

--sound-­device=device
Explicitly specify the audio device to use (starting ver. 2.0)

--enable-­intro-­music ­­        --disable-­intro-­music
Enable/Disable playing introductory music when starting FlightGear – this option depends also on other audio-settings


FDM

--fdm=abcd
Select the core flight dynamics model. Can be one of  jsb, larcsim, yasim, magic, balloon, ada, external, or null. This selection usually is done by the aircraft itself while initializing!

--aero=aircraft
Select the aircraft aerodynamics model. This selection usually is done by the aircraft itself while initializing!

--model-­hz=n
Run the FDM this rate (iterations per second)

--speed=n
Run the FDM 'n' times faster than real time

--trim ­­            --notrim
Activate “trim” only for the JSBSim-FDM. This selection usually is done by the aircraft itself while initializing!


Freeze

--enable-­freeze ­­            --disable-­freeze
If enabled, the aircraft will start in "Pause"-mode - i.e. you have to awake it by typing "p". Be aware that other multiplayer users will not see you in "Pause"-mode and some models may not even start in that mode!

--enable-­fuel-­freeze ­­            --disable-­fuel-­freeze
Defines if fuel will be consumed. When "enabled" you can fly with empty tanks as long as you want -- that is very good for the (artificial) environment -- but may seriously degrade your reputation as a pilot. Also you would miss the challenge of noticing the different behavior between a light and a heavy model - especially during Take-Off and Landing!

--enable-­clock-­freeze ­­            --disable-­clock-­freeze
Disable will stop the simulation clock - but not the system-clock.


Initial Position

Please also see the general discussion about which options to chose in the FlightGear-WIKI http://wiki.flightgear.org/index.php/Initial_Starting_Positions

--on-­ground ­­            --in-­air
Defines if the model start "on-ground" or "in-air". If you define "in-air" you should define further options like altitude and speed.

--airport=ICAO
Specifies the starting position relative to an by giving the ICAO code. In case you are looking for a small airfield inside the USA, that might not have an official ICAO-code try it by using a "3" instead of the usually first alpha "K". If you define --airport, but neither a --parkpos nor a --runway then you will be placed onto a runway of that airport, which fits best according to wind etc.

--parkpos=Ann
Defines a parking-lot, terminal, gate etc. on an airport to start from. If the airport has such "parkpos" you should use that one instead of the "runway"-option - that way you do not pop up just in front of  someone being on short final. People might become rather angry on you! If you are not using FGrun you find the parkpositions in $FG_SCENERY/Airports/I/C/A/ICAO/ICAO.parking.xml. e.g. for KSFO: $FG_SCENERY/Airports/K/S/F/KSFO.parking.xml.

--runway=nnA
If you define a runway (together with an --airport) FlightGear will start you direct on that runway. The runway number only shows the first 2 digit of its heading and may be a code L=left, R=right, C=center. See e.g. KOAK with 18R and 18C and 18L, and also 09.

--lon=degrees ­­                --lat=degrees
Specifies the starting point by GPS-data. For lon=west and lat=south use the minus sign. Thus KSFO is --lon=-122.372832 --lat=37.618583 (compare on MPmap).

--vor=ID ­­            --ndb=ID ­­            --fix=ID
Specifies the starting position relative to a VOR, NDB, or FIX. As ID you must define the ID - not the name! e.g. "SFO" instead of "SAN FRANCISCO"

--offset-­distance=mi ­­                --offset-­azimuth=deg
Specifies the distance and direction to the reference point (in statute miles and deg.). That point could be: --airport, ­­--vor, ­­--ndb, ­­--fix, ­­--carrier.

--altitude=nn
Start at a defined altitude (in feet, if not "--units-meters" is defined). With specifying  --altitude  also  --in-air  gets set automatically! You also should define a  --vc  (speed) if you do not want to crash like a stone!

--vc=knots ­­            --mach=num
Specifies the initial airspeed (which may change very fast very drastically if you do not set the throttle accordingly!)

--heading=degrees ­­            --roll=degrees ­­            --pitch=degrees
Defines the heading (yaw) and roll (Phi) and pitch (Theta) at startup. If you define nothing, then that values will be initiated to "0" - that means you start with a horizontal, straight forward flight northbound (if you defined also altitude and speed!).

--glideslope=
degrees ­­            --roc=fpm
Specifies "flight path" angle (can be positive) and the "climb rate" (can be negative)

--uBody=X ­­            --vBody=Y ­­            --wBody=Z
Specifies the velocities along the body X, Y, Z axis (in feet unless  --units-meters  specified)

--vNorth=N ­­            --vEast=E ­­            --vDown=D
Specify velocity along a South-North / West-East / vertical axis (in feet unless  --units-meters  specified)

--carrier=[name|ID]
Specify starting position on an AI carrier.


Rendering

Be aware: The following options may raise the workload for your processor and/or graphics-card significantly - and may even overload them. Watch your FPS when you change those options.

--aspect-­ratio-­multiplier=n
Specify a multiplier for the aspect ratio.

--bpp=depth
Specify the bits per pixel to be used

--enable-­clouds ­­                                --disable-­clouds
Enable/Disable 2D (flat) cloud layers

--enable-­clouds3d ­­                            --disable-­clouds3d
Enable/Disable 3D (volumetric) cloud layers -- very, very nice - but also very, very heavy on your resources (Processor & Graphic-Card)!

--enable-­distance-­attenuation ­­            --disable-­distance-­attenuation
Enable/Disable a more realistic sight to the runway and approach lights during twilight, especially when still far away from the airport

--enable-­enhanced-­lighting ­­                --disable-­enhanced-­lighting
Enable/Disable enhanced runway lighting

--enable-­fullscreen ­­                            --disable-­fullscreen
Enable/Disable the "fullscreen" mode of your screen

--enable-­game-­mode ­­                        --disable-­game-­mode
Enable/Disable full-screen game mode for 3DFX Graphi-Cards (only former VOODOO­Graphics)

--enable-­mouse-­pointer ­­                    --disable-­mouse-­pointer
Enable/Disable the special mouse-pointer for the older 3DFX VOODOO­Graphics-Cards

--enable-­splash-­screen ­­                    --disable-­splash-­screen
Enable/Disable the rotating 3DFX-­Logo when using the VOODOO­Graphics-type Graphics-Card

--enable-­horizon-­effect ­­                    --disable-­horizon-­effect
Enable/Disable celestial body growth illusion near the horizon

--enable-­panel ­­                                --disable-­panel
Enable/Disable the instrument panel

--enable-­skyblend ­­                          --disable-­skyblend
Enable/Disable sky blending fog/dust

--enable-­specular-­highlight ­­           --disable-­specular-­highlight
Enable/Disable specular reflections on textured objects

--enable-­textures ­­                        --disable-­textures
Enable/Disable the presentation of textures

--enable-­wireframe ­­                    --disable-­wireframe
Show/noShow the model-wireframe. Just try it - it gives you a nice view of how your model constructed.

--fog-­disable ­­            --fog-­fastest ­­            --fog-­nicest
Varies the complexity of the generated fog/haze. In order to reduce the load for PC and Graphic-Card the program overlays far distance sceneries and objects with fog/haze if the default  --fog-nicest  is active (i.e the fog is nice but you do not see any scenery far away!). If in the contrary you choose  --fog-disable  then you can see very far - but your FPS-rates may be reduced significantly!  --fog-fastest  is a compromise between the 2 extremes.

--fov=Grad (Standard=55°)
Specify field of view angle in Grad°

--geometry=WWWxHHH
Specify window geometry (640x480, etc)

--shading-­smooth ­­                --shading-­flat
Enable/Disable  flat shading.  ("Flat shading­flat” is significantly faster - but by far not as beautiful == a question of your resources!)

--texture-­filtering=N     (Standard N=1)
Anisotropic Texture Filtering: values should be 1 (default),2,4,8 or 16

--view-­offset=xxx
Specify the default forward view direction as an offset from straight ahead. Allowable values are LEFT, RIGHT, CENTER, or a specific number in degre


Time

--timeofday=param
If defined it disables any of the following time-settings!
You can define the following:
morning   ~07:00
noon         ~12:00
afternoon ~15:20
dusk         ~18:40
evening    ~19:50
midnight   ~00:00

--time-­match-­local ­­            --time-­match-­real
If defined it disables any of the following time-settings!
With the default --time-­match-­real the FlightGear-Time will be synchronized with the system-time. Otherwise it is synchronized with the area you are simulating in. For Multiplayer events you should set --time-­match-­local - that way all participants have the same time and visibility!

--start-­date-­gmt=yyyy:mm:dd:hh:mm:ss
--­­start-­date-­lat=yyyy:mm:dd:hh:mm:ss
­­--start-­date-­sys=yyyy:mm:dd:hh:mm:ss
Defines which time will be used for the simulation:
--time-­offset=[+-]hh:mm:ss
Add this time offset


Network Options

--callsign=YourCode
assign a unique name to a player, see chapter Multiplayer

--multiplay=dir,Hz,host,port
Specify multiplayer communication settings, multiple instances can be used. See chapter Multiplayer.

--httpd=port
Enable a standard "http server" on the specified port (usually: 5500).

--telnet=port
Enable a standard "telnet server" on the specified port (usually: 5501). This is needed to view the "Internal Properties" onto the browser for easy listing and editing.

--jpg-­httpd=port
Enable screen shot "http server" on the specified port (usually 5502).

--proxy=[user:password@]host:port
Specify which proxy server (and port) to use. The username and password are optional and should be MD5 encoded already. This option is only useful when used in conjunction with the real-weather-fetch option.


Input/Output

Here you define the Interfaces to other applications, e.g.: 
--generic=params Open connection using a predefined communication interface and a preselected communication protocol
--garmin=params Open connection using the Garmin GPS protocol
--joyclient=params Open connection to an Agwagon joystick
--jsclient=params Open connection to a remote joystick
--native-ctrls=params Open connection using the FG Native Controls protocol
--native-fdm=params Open connection using the FG Native FDM protocol
--native=params Open connection using the FG Native protocol
--nmea=params Open connection using the NMEA protocol
--opengc=params Open connection using the OpenGC protocol
--props=params Open connection using the interactive property manager (LEGACY/DEAD DO NOT USE same as --telnet)
--pve=params Open connection using the PVE protocol
--ray=params Open connection using the Ray Woodworth motion chair protocol
--rul=params Open connection using the RUL protocol
--atc610x Enable atc610x interface

See e.g. the field "Protocol" under "Input/Output" on the advanced FGrun page. e.g.:

     --generic=socket,out,10,localhost,16661,udp,fgcom
see chapter FGCOM

     --atlas=socket,out,1,localhost,5505,udp
see chapter Atlas


Avionics

--com1=frequency ­­                    --com2=frequency ­­
Set the COM radios frequency (für ATC, FGCOM, ATIS, etc.)

--nav1=[radial:]frequency ­­ ­­           --nav2=[radial:frequency ­­
Set the NAV-radio frequencies, optionally followed by a radial (for VOR or ILS). Most aircraft can only use NAV1 for the autopilot! Notice that the radial must stand after the frequency.
e.g.: ­­  nav1=110.70:248     (is the ILS EDDF 25L)

--adf=[radial:]frequency ­­
Set the ADF radio frequency, optionally preceded by a card rotation. Some aircraft also offer an ADF2, those must be set on a unique GUI for that model or by using buttons on the instrument-panel.

--dme=nav1|nav2|frequency ­­
Slave the DME to one of the NAV radios, or set its internal frequency (if it is not integrated in a VOR).


Properties

--prop:[type:]name=value
With this option you can prime any property (see FlightGear » menu » Debug » Browse Internal Properties) prior to startup. With the optional "type" you can define the type of the value assigned to that property with the allowed values: double,string,boolean.

Some examples would be:
--prop:/controls/gear/brake-parking=1 makes sure the aircraft does not start to roll at startup
--prop:/sim/traffic-manager/enabled=false prevents the artificial traffic (use when Multiplayer active)
--prop:/sim/user/callsign=jomo your userID
--prop:/instrumentation/comm/frequencies/selected-mhz=127.32 sets the com1 frequency-1 to 127.32
--prop:/engines/engine[0]/running=true starts with engine 1 running
--prop:/consumables/fuels/tank[0]/level­gal=10 fill tank 1 with 10 gal.
--prop:boolean:/sim[0]/ai/enabled=true
activates the AI-models

In FGrun you enter these values into the sub-chapter "Properties" on the advanced page.


Debugging

--failure=system
Simulates randomly occurring failures during the flight - that can make flying very interesting. You define which failures: Pitot, static, vacuum, or electric. You can define several at once. You can define those settings more comfortable from inside the aircraft:  menu » Equipment » failures.

--enable-­fpe
Abort on encountering a “Floating Point Exception” (Gleitkomma-Fehler)

--fgviewer
Just use the “OSG model viewer” rather than loading the entire simulator “OSG viewer”

--log-­level={bulk, debug, info, warn, alert}
Specify which logging level to use (and thus how many log-entries!). With "bulk" everything will be logged -- with "alert" only the most serious ones.

--trace-­read=prop ­­            --trace-­write=prop
Trace the reads or writes for a property; multiple instances can be used.
Since ver.2.0 you can also trace properties on the screen by opening  "FGFSmenue » Debug » Browse Internal Properties", then search for the property wanted and mouseclick on it WHILE UPPERCASE is activated!


Environment, Weather, Clouds

--enable-­real-­weather-­fetch ­­            --disable-­real-­weather-­fetch
Enable/Disable the downloading and constantly refreshing of actual weather-data from a weather-station nearest to your aircraft. This is available only if you have a constant access to the Internet.

--metar=MetarString
If you do not have a constant access to the Internet you might get actual weather-data by any other means and enter this data with this option. Of that string must meet the international coding-conventions. There may be minor differences between an international metar-string and the US version. See e.g. http://en.wikipedia.org/wiki/METAR

--ceiling=FT ASL[:Thickness in ft]
Create an overcast ceiling, optionally with specific thickness (defaults to 2000 ft)

--wind=Grad@kt
"--wind=270@10" defines the wind coming from 270° at 10 knots.

--turbulence=n.n
Specify turbulence from 0.0 (calm) to 1.0 (severe)

--random-­wind
Use randomly generated wind, i.e. coming from constantly changing directions in changing strength

--season=param    (winter/summer)
with the  param="winter" you switch to a snow-covered scenery. And reverse with param=summer.

--visibility=meters ­­            --visibility-­miles=miles
Specifies the initial visibility in meters or miles. Watch it: Default is meter!


Navigation

--wp=ID[@alt]
Define a "waypoint" for the GC autopilot, you can repeat  --wp  for as many WP's you like. As "ID" you can use a Navigation-items like airport, VOR, NDB, Fix.  The optional "@alt" defines the altitude you want to have reached at that point.
e.g.  --wp=SJC@5000  means: "Pass over VOR SJC (San Jose) at 5000 ft".

--flight-­plan=[file]
Instead of entering many waypoints with singlw --wp  you can write those into a standard text-file like:
CADIT
SPI@32000
UIN
We suggest to save that file into the directory "$FG_ROOT/AI/FlightPlans“ with a name of your choice, e.g. as "KIND-DEP.wp“.



EPILOG


The History of FlightGear

History may be a boring subject. However, from time to time there are people asking for the history of FlightGear. As a result, we’ll give a short outline:

The FlightGear project goes back to a discussion among a group of net citizens in 1996 resulting in a proposal written by David Murr who, unfortunately, dropped out of the project (as well as the net) later. Although the names of the people and several of the details have changed over time, the spirit of that proposal has clearly been retained up to the present time.

Actual coding started in the summer of 1996 and by the end of that year essential graphics routines were completed. At that time, programming was mainly performed and coordinated by Eric Korpela from Berkeley University. Early code ran under Linux as well as under DOS, OS/2, Windows 95/NT, and Sun-OS. This was found to be quite an ambitious project as it involved, among other things, writing all the graphics routines in a system-independent way entirely from scratch.

Development slowed and finally stopped in the beginning of 1997 when Eric was completing his thesis. At this point, the project seemed to be dead and traffic on the mailing list went down to nearly nothing.

It was Curt Olson from the University of Minnesota who re-launched the project in the middle of 1997. His idea was as simple as it was powerful: Why invent the wheel a second time? There have been several free flight simulators available running on workstations under different flavors of UNIX. One of these, LaRCsim (developed by Bruce Jackson from NASA), seemed to be well suited to the approach. Curt took this one apart and re-wrote several of the routines such as to make them build as well as run on the intended target platforms. The key idea in doing so was to exploit a system-independent graphics platform: OpenGL.

In addition, a clever decision on the selection of the basic scenery data was made in the very first version. FlightGear scenery is created based on satellite data published by the U. S. Geological Survey. These terrain data are available from
http://eros.usgs.gov/
for the U.S., and
http://www1.gsi.go.jp/geowww/globalmap-gsi/gtopo30/gtopo30.html
resp., for other countries.

Those freely accessible scenery data, in conjunction with scenery building tools included with FlightGear!, are an important feature enabling anyone to create his or her own scenery. This new FlightGear code - still largely being based on the original LaRCsim code - was released in July 1997. From that moment the project gained momentum again. Here are some milestones in the more recent development history.

Scenery

Aircraft

Environment

User Interface

During development there were several code reorganization efforts. Various code subsystems were moved into packages. As a result, code is organized as follows at present:
This is by no means an exhaustive history and most likely some people who have made important contributions have been left out. Besides the above-named contributions there was a lot of work done concerning the internal structure by:
Jon S. Berndt, Oliver Delise, Christian Mayer, Curt Olson, Tony Peden, Gary R. Van Sickle, Norman Vine, and others.

A more comprehensive list of contributorscan be found in Chapter B as well as in the Thanks file provided with the code. Also, the FlightGear Website contains a detailed history worth reading of all of the
notable development milestones at
http://www.flightgear.org/about/news/


Those, who did the work

Did you enjoy the flight? In case you did, don’t forget those who devoted hundreds of hours to that project. All of this work is done on a voluntary basis within spare time, thus bare with the programmers in case something does not work the way you want it to. Instead, sit down and write them a kind (!) mail proposing what to change. Alternatively, you can subscribe to the FlightGear mailing lists and contribute your thoughts there. Instructions to do so can be found at
http://www.flightgear.org/mail.html.

Essentially there are two lists, one of which being mainly for the developers and the other one for end users. Besides, there is a very low-traffic list for announcements.

The following names the people who did the job (this information was essentially taken from the file Thanks accompanying the code).

Free Sounds Granted permission for the FlightGear project to use some of the sound effects from their site. Homepage under http://www.a1freesoundeffects.com/
Syd Adams Added clipping for 2D instruments, ATC volume control and created a wide variety of aircraft.
Raul Alonzo Is the author of Ssystem and provided his kind permission for using the moon texture. Parts of his code were used as a template when adding the texture. His System Homepage can be found at: http://www1.las.es/~amil/ssystem.
Michele America Contributed to the HUD code.
Michael Basler Author of Installation and Getting Started. Flight Simulation Page at http://www.geocities.com/pmb.geo/flusi.htm
Jon S. Berndt Working on a complete C++ rewrite/reimplimentation of the core FDM. Initially he is using X15 data to test his code, but once things are all in place we should be able to simulate arbitrary aircraft. Jon maintains a page dealing with Flight Dynamics at: http://jsbsim.sourceforge.net/. Special attention to X15 is paid in separate pages on this site. Besides, Jon contributed via a lot of suggestions/corrections to this Guide.
Paul Bleisch Redid the debug system so that it would be much more flexible, so it could be easily disabled for production system, and so that messages for certain subsystems could be selectively enabled. Also contributed a first stab at a config file/command line parsing system.
Jim Brennan Provided a big chunk of online space to store USA scenery for FlightGear!
Bernie Bright Many C++ style, usage, and implementation improvements, STL portability and much, much more. Added threading support and a threaded tile pager.
Stuart Buchanan Updated various parts of the manual and wrote the initial tutorial subsystem.
Bernhard H. Buckel Contributed the README.Linux. Contributed several sections to earlier versions of Installation and Getting Started.
Gene Buckle A lot of work getting FlightGear to compile with the MSVC++ compiler. Numerous hints on detailed improvements.
Ralph Carmichael Support of the project. The Public Domain Aeronautical Software web site at http://www.pdas.com/ has the PDAS CD-ROM for sale containing great programs for astronautical engineers.
Didier Chauveau Provided some initial code to parse the 30 arcsec DEM files found at: http://edcwww.cr.usgs.gov/landdaac/gtopo30/gtopo30.html.
John Check John maintains the base package CVS repository. He contributed cloud textures, wrote an excellent Joystick Howto as well as a panel Howto. Moreover, he contributed new instrument panel configurations. FlightGear page at http://www.rockfish.net/fg/.
Dave Cornish Dave created new cool runway textures plus some of our cloud textures.
Oliver Delise Started a FAQ, Documentation, Public relations. Working on adding some networking/multi user code. Founder of the FlightGear MultiPilot
Jean-Francois Doue Vector 2D, 3D, 4D and Matrix 3D and 4D inlined C++ classes. (Based on Graphics Gems IV, Ed. Paul S. Heckbert) http://www.animats.com/simpleppp/ftp/public_html/topics/developers.html.
Dave Eberly Contributed some sphere interpolation code used by Christian Mayer’s weather data base system.
Francine Evans Wrote the GPL’d tri-striper we use. http://www.cs.sunysb.edu/~stripe/
Oscar Everitt Created single engine piston engine sounds as part of an F4U package for FS98. They are pretty cool and Oscar was happy to contribute them to our little project.
Bruce Finney Contributed patches for MSVC5 compatibility.
Olaf Flebbe Improved the build system for Windows and provided pre-built dependencies.
Melchior Franz Contributed joystick hat support, a LED font, improvements of the telnet and the http interface. Notable effort in hunting memory leaks in FlightGear, SimGear, and JSBSim.
Jean-loup Gailly
Mark Adler
Authors of the zlib library. Used for on-the-fly compression and decompression routines, http://www.gzip.org/zlib/.
Mohit Garg Contributed to the manual.
Thomas Gellekum Changes and updates for compiling on FreeBSD.
Neetha Girish Contributed the changes for the xml configurable HUD.
Jeff Goeke-Smith Contributed our first autopilot (Heading Hold). Better autoconf check for external timezone/daylight variables.
Michael I. Gold Patiently answered questions on OpenGL.
Habibe Made RedHat package building changes for SimGear.
Mike Hill For allowing us to concert and use his wonderful planes, available form http://www.flightsimnetwork.com/mikehill/home.htm, for FlightGear.
Erik Hofman Major overhaul and parameterization of the sound module to allow aircraft-specific sound configuration at runtime. Contributed SGI IRIX support (including binaries) and some really great textures.
Charlie Hotchkiss Worked on improving and enhancing the HUD code. Lots of code style tips and code tweaks.
Bruce Jackson (NASA) Developed the LaRCsim code under funding by NASA which we use to provide the flight model. Bruce has patiently answered many, many questions.
Maik Justus Added helicopter support, gear/ground interaction and aerotow/winch support to the YASim FDM.
Ove Kaaven Contributed the Debian binary.
Richard Kaszeta Contributed screen buffer to ppm screen shot routine. Also helped in the early development of the "altitude hold autopilot module" by teaching Curt Olson the basics of Control Theory and helping him code and debug early versions. Curt’s BossBob Hain also contributed to that. Further details available at:
http://www.menet.umn.edu/ ̃curt/fgfs/Docs/Autopilot/AltitudeHold/AltitudeHold.html.
Rich’s Homepage is at: http://www.kaszeta.org/rich/.
Tom Knienieder Ported the audio library first to OpenBSD and IRIX and after that to Win32.
Reto Koradi Helped with setting up fog effects.
Bob Kuehne Redid the Makefile system so it is simpler and more robust.
Kyler B Laird Contributed corrections to the manual.
David Luff Contributed heavily to the IO360 piston engine model.
Sam van der Mac Contributed to The Manual by translating HTML tutorials to Latex.
Christian Mayer Working on multi-lingual conversion tools for fgfs as a demonstration of technology. Contributed code to read Microsoft Flight Simulator scenery textures. Christian is working on a completely new weather subsystem. Donated a hot air balloon to the project.
David Megginson Contributed patches to allow mouse input to control view direction yoke. Contributed financially towards hard drive space for use by the flight gear project. Updates to README.running. Working on getting fgfs and ssg to work without textures. Also added the new 2-D panel and the save/load support. Further, he developed new panel code, playing better with OpenGL, with new features. Developed the property manager and contributed to joystick support. Random ground cover objects
Cameron Moore FAQ maintainer. Reigning list administrator. Provided man pages.
Eric Mitchell Contributed some topnotch scenery textures being all original creations by him.
Anders Morken Former maintainer of European web pages.
Alan Murta Created the Generic Polygon Clipping library. http://www.cs.man.ac.uk/aig/staff/alan/software/
Phil Nelson Author of GNU dbm, a set of database routines that use extendible hashing and work similar to the standard UNIX dbm routines.
Alexei Novikov Created European Scenery. Contributed a script to turn fgfs scenery into beautifully rendered 2-D maps. Wrote a first draft of a Scenery Creation Howto.
Curt Olson Primary organization of the project. First implementation and modifications based on LaRCsim. Besides putting together all the pieces provided by others mainly concentrating on the scenery subsystem as well as the graphics stuff. Homepage at: http://www.menet.umn.edu/~curt/
Brian Paul We made use of his TR library and of course of Mesa: http://www.mesa3d.org/brianp/TR.html, http://www.mesa3d.org
Tony Peden Contributions on flight model development, including a LaRCsim based Cessna 172. Contributed to JSBSim the initial conditions code, a more complete standard atmosphere model, and other bugfixes/additions.
Robin Peel Maintains worldwide airport and runway database for FlightGear as well as X-Plane
Alex Perry Contributed code to more accurately model VSI, DG, Altitude. Suggestions for improvements of the layout of the simulator on the mailing list and help on documentation.
Friedemann Reinhard Development of an early textured instrument panel.
Petter Reinholdtsen Incorporated the GNU automake/autoconf system (with libtool). This should streamline and standardize the build process for all UNIX-like platforms. It should have little effect on IDE type environments since they don’t use the UNIX make system.
William Riley Contributed code to add ”brakes”. Also wrote a patch to support a first joystick with more than 2 axis. Did the job to create scenery based on VMap0 data.
Andy Ross Contributed a new configurable FDM called YASim (Yet Another Flight Dynamics Simulator, based on geometry information rather than aerodynamic coefficients.
Paul Schlyter Provided Durk Talsma with all the information he needed to write the astro code. Mr. Schlyter is also willing to answer astro-related questions whenever one needs to. http://www.welcome.to/pausch/
Chris Schoeneman Contributed ideas on audio support.
Phil Schubert Contributed various textures and engine modeling. http://www.zedley.com/Philip/.
Jonathan R. Shewchuk Author of the Triangle program. Triangle is used to calculate the Delauney triangulation of our irregular terrain.
Gordan Sikic Contributed a Cherokee flight model for LaRCsim. Currently is not working and needs to be debugged. Use configure --with-flight-model=cherokee to build the cherokee instead of the Cessna.
Michael Smith Contributed cockpit graphics, 3D models, logos, and other images. Project Bonanza
Martin Spott Co-Author of The Manual.
Jon Stockill Maintains a database of objects and their location to populate the worldwide scenery.
Durk Talsma Accurate Sun, Moon, and Planets. Sun changes color based on position in sky. Moon has correct phase and blends well into the sky. Planets are correctly positioned and have proper magnitude. Help with time functions, GUI, and other things. Contributed 2-D cloud layer. Website at: http://people.a2000.nl/dtals/.
UIUC Department of Aeronautical and Astronautical Engineering
Contributed modifications to LaRCsim to allow loading of aircraft parameters from a file. These modifications were made as part of an icing research project.
Those did the coding and made it all work:
Jeff Scott
Bipin Sehgal
Michael Selig
Moreover, those helped to support the effort:
Jay Thomas
Eunice Lee
Elizabeth Rendon
Sudhi Uppuluri
U. S. Geological Survey Provided geographic data used by this project. http://edc.usgs.gov/geodata/
Mark Vallevand Contributed some METAR parsing code and some win32 screen printing routines.
Gary R. Van Sickle Contributed some initial GameGLUT support and other fixes. Has done preliminary work on a binary file format. Check http://www.woodsoup.org/projs/ORKiD/fgfs.htm.
His Cygwin Tipspage might be helpful for you at: http://www.woodsoup.org/projs/ORKiD/cygwin.htm.
Norman Vine Provided more numerous URL’s to the “FlightGear Community”. Many performance optimizations throughout the code. Many contributions and much advice for the scenery generation section. Lots of Windows related contributions. Contributed wgs84 distance and course routines. Contributed a great circle route autopilot mode based on wgs84 routines. Many other GUI, HUD and autopilot contributions. Patch to allow mouse input to control view direction. Ultra hires tiled screen dumps. Contributed the initial goto airport and reset functions and the initial
http image server code
Roland Voegtli Contributed great photorealistic textures. Founder of European Scenery Project for X-Plane: http://www.g-point.com/xpcity/esp/
Carmelo Volpe Porting FlightGear to the Metro Works development environment (PC/Mac).
Darrell Walisser Contributed a large number of changes to porting FlightGear to the Metro Works development environment (PC/Mac). Finally produced the first Macintosh port. Contributed to the Mac part of Getting Started, too.
Ed Williams Contributed magnetic variation code (impliments Nima WMM 2000). We’ve also borrowed from Ed’s wonderful aviation formulary at various times as well. Website at http://williams.best.vwh.net/.
Jim Wilson Wrote a major overhaul of the viewer code to make it more flexible and modular. Contributed many small fixes and bug reports. Contributed to the PUI property browser and to the autopilot.
Jean-Claude Wippler Author of MetaKit - a portable, embeddible database with a portable data file format previously used in FlightGear. Please see the following URL for more info: http://www.equi4.com/metakit/
Woodsoup Project While FlightGear no longer uses Woodsoup servies we appreciate the support provided to our project during the time they hosted us. Once they provided computing resources and services so that the FlightGear project could have a real home. http://www.woodsoup.org/
Robert Allan Zeh Helped tremendously in figuring out the Cygnus Win32 compiler and how to link with dll’s. Without him the first run-able Win32 version of FlightGear would have been impossible.


Others
The following individuals have contributed to the scenery object database: Jon Stockill, Martin Spott, Dave Martin, Thomas Foerster, Chris Metzler, Frederic Bouvier, Melchior Franz, Roberto Inzerillo, Erik Hofman, Mike Round, Innis Cunningham, David Megginson, Stuart Buchanan, Josh Babcock, Esa Hyytia, Mircea Lutic, Jens Thoms Toerring, Mark Akermann, Torsten Dreyer, Martin C. Doege, Alexis Bory, Sebastian Bechtold, Julien Pierru, Bertrand Augras, Gerard Robin, Jakub Skibinski, Morten Oesterlund Joergensen, Carsten Vogel, Dominique Lemesre, Daniel Leygnat, Bertrand Gilot, Morten Skyt Eriksen, Alex Bamesreiter, Oliver Predelli, Georg Vollnhals, and Paul Richter.

What remains to be done

If you read (and, maybe, followed) this guide up to this point you may probably agree: FlightGear even in its present state, is not at all for the birds. It is already a flight simulator which sports even several selectable flight models, several planes with panels and even a HUD, terrain scenery, texturing, all the basic controls and weather.

Despite, FlightGear needs – and gets – further development. Except internal tweaks, there are several fields where FlightGear needs basics improvement and development. A first direction is adding airports, buildings, and more of those things bringing scenery to real life and belonging to realistic airports and cities. Another task is further implementation of the menu system, which should not be too hard with the basics being working now. A lot of options at present set via command line or even during compile time should finally make it into menu entries.

Finally, FlightGear lacks any ATC until now.

There are already people working in all of these directions. If you’re a programmer and think you can contribute, you are invited to do so.

Acknowledgements

Obviously this document could not have been written without all those contributors mentioned above making FlightGear a reality.

First, I was very glad to see Martin Spott entering the documentation effort. Martin provided not only several updates and contributions (notably in the OpenGL section) on the Linux side of the project but also several general ideas on the documentation in general.

Besides, I would like to say special thanks to Curt Olson, whose numerous scattered Readmes, Thanks, Webpages, and personal eMails were of special help to me and were freely exploited in the making of this booklet.

Next, Bernhard Buckel wrote several sections of early versions of that Guide and contributed at lot of ideas to it.

Jon S. Berndt supported me by critical proofreading of several versions of the document, pointing out inconsistences and suggesting improvements.

Moreover, I gained a lot of help and support from Norman Vine. Maybe, without Norman’s answers I would have never been able to tame different versions of the Cygwin – FlightGear couple.

We were glad, our Mac expert Darrell Walisser contributed the section on compiling under Mac OS X. In addition he submitted several Mac related hints and fixes.

Further contributions and donations on special points came from John Check, (general layout), Oliver Delise (several suggestions including notes on that chapter), Mohit Garg (OpenGL), Kyler B. Laird (corrections), Alex Perry (OpenGL), Kai Troester (compile problems), Dave Perry (joystick support), and Michael Selig (UIUC models).

Besides those whose names got lost withing the last-minute-trouble we’d like to express our gratitude to the following people for contributing valuable ‘bug fixes’ to this version of The FlightGear Manual (in random order): Cameron Moore, Melchior Franz, David Megginson, Jon Berndt, Alex Perry,, Dave Perry,, Andy Ross, Erik Hofman, and Julian Foad.