Technical Terms &
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
||"Automatic Direction Finder" = finding the
direction to a given NDB, see http://en.wikipedia.org/wiki/Radio_direction_finder
measured by radar!
||"Artificial Intelligence" = try to
simulate the human brain by machines, see e.g. http://en.wikipedia.org/wiki/Artificial_intelligence
|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.
||"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
||"Application Program Interface" is the
interface defined by an application, for other programs or devices to
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.
||"American Standard Code for Information Interchange“ defines a world wide
standard how "text" can be stored and transported in communications.
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
enable a human providing ATC to FlightGear-multiplayers.
||"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
||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
Indicator" is the indicator inside a VOR-instrument
to show the course and devitaion to that course. This is needed if
by VOR or landing by ILS. Also see the description
||Is a program that
translates (compiles) a "script" to an
computer-executable "binary". See e.g.
||“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
||"Federal Aviation Administration" is an US-Agency to
regulate all aspects of
civil aviation. See e.g. http://en.wikipedia.org/wiki/FAA
||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
For its functions see the chapter: FGrun
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.)
||"Feet per Minute“
defines how fast an aircraft climbs or sinks.
||"Frams Per Second"
defines the refresh cycle of the screen-images. You can monitor that
» till FlightGear 1.9 via: "Menü
→ View → Rendering Options → Show
» since FlightGear 2.0 via: "Menü → View
→ Display Options → Show
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.
||"General Aviation" defines
"Private" air-traffic against "Public Transportation" -
but GA may also be used for "small aircraft" against "biggies"!
||Defines a "free Operating
System", siehe http://en.wikipedia.org/wiki/GNU
with the license 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
||"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
||“Graphical User Interface” is a little program
allowing users to select/define
options by using graphical devices instead of typing text-based
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
||"Initial Approach Fix“
is the starting point of an IAP which guides an
aircraft on its final approach.
||"Initial Approach Procedure“ is the
predefined way how an aircraft approaches under IFR conditions. See
chapter IFR Cross Country -IAP
|"Indicated AirSpeed“ ist the airspeed as measured at the Pitot.
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
||The “International Civil Aviation Organization” defines the ICAO-ID
for all airports worldwide. Those structured ID's are always 4 digits.
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
||An icon is a
small pictogram used to start programs when clicked on with a mouse.
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
||"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
||"Instrument Landing System" guides aircraft
to the landing point on a runway. ref. http://en.wikipedia.org/wiki/Instrument_landing_system
||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 =
an Operating-System that is based on the free, portable, Unix-like
Linux-Kernel (see e.g. http://en.wikipedia.org/wiki/Linux_distribution)
||"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.
1 == Speed of sound. Usually pilots use Mach (instead of IAS)
above 26.000 ft. ref.: http://en.wikipedia.org/wiki/Mach_number
||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
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"!
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
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
||"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.
||This is an "Open" API for Graphic-Cards. See e.g. http://en.wikipedia.org/wiki/OpenGL
||is a (small) window
appearing on the desktop to enable user selection, input, information,
||is a virtual data
connection between computer programs possibly through a computer network
||is used in this Manual as
a bundle of all activities a pilot has to perform before starting his
engines for a flight.
||within the "FlightGearMenu
→ Debug → Browse Internal Properties" you can inspect, set,
change and trace any values used during the FlightGear simulation.
||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
||The conversion of data
into it's presentation on a screen, depending on the screen performance
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
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
set the exact radial (look it up on a map, e.g. MPmap)!
indicates the directory in which the sceneries for FlightGear are
stored. These include the Sub-Directories "Terrain" and "Objects".
||The in a
programming-language written source-codes
in text-form. These will then be "compiled" to
the machine-readable "binaries"
||Is a group of scripts
needed for a (complex) program. All "scripts" together will be compiled to the so called binary.
||Is a feature-program
enabling FlightGear to download needed sceneries "on the fly". See http://wiki.flightgear.org/index.php/TerraSyn
||"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
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
||"Visual Flight Rules“ are the the oposite to "IFR". See e.g. http://en.wikipedia.org/wiki/Visual_flight_rules
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.
||(hawaiisch for "quick")
are Hypertext-Systems for Internet-Pages, see especially http://wiki.flightgear.org/index.php/Main_Page
If you do not find an option in the following list, start FLightGear in
a Command-Window with
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.
default setting of the options are shown in green!
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:
c172pset.xml (the MasterModel)
c172p2dpanelset.xml (a version with 2D-panels)
c172ppanelonlyset.xml (a version just showing a 2D-panel for
That means you can chose out of 3 different versions which you
define by specifying the name of the "..set.xml"-file -- without the
See also the following "--show-aircraft" and the chapter "Installing Aircraft
Will list all installed aircraft
including submodels, sorted by name
Selects an optional/additional
“Livery”. For available Liveries see the directory
(Available starting ver. 2.0)
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
(Be patient - that searching and
listing may take some time!)
Specify additional aircraft directory
path(s). The standard path is “$FG_ROOT
Lists the most relevant options
--verbose (or "-v")
The combination "-h -v" lists ALL options actually
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.
Shows the active version of FlightGear
installed and some additional Infos, see e.g.:
|FGFS 1.9 on UBUNTU
2.0 on WindowsXP
SimGear version: "2.0.0"
PLIB version: 185
Defines where FlightGear looks for its
data-files. Ref.: $FG_ROOT
Defines where FlightGear looks for its
data-files. Ref.: $FG_SCENERY
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:
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!)
Defines the primary device you use for
control, either joystick, mouse, or keyboard. Watch it: The
device must be attached prior to starting FlightGear.
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
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.
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/X15set.xml
"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
Activates the special artificial
sceneries in which you fly for certain demos, e.g.: --ai-scenario=droptank_demo.
For a list of available
see the *.xml files in $FG_ROOT/AI
Enable/Disable including random scenery objects like buildings etc.
Enable/Disable Heads Up Display
Enable/Disable the 3D HUD
Enable/Disable filters to avoid
“Moiré pattern” e.t.c (see http://en.wikipedia.org/wiki/Aliasing )
Displays the number of triangles
the percentage of triangles culled
The settings here do only affect the FlightGear internal sounds. They
do not affect others, like e.g. FGCOM, Festival, etc.
Enable/Disable sound effects of
FlightGear (NOT FGcom etc.)
Show a list of available audio devices
(starting ver. 2.0)
Explicitly specify the audio device to
use (starting ver. 2.0)
Enable/Disable playing introductory
music when starting FlightGear – this option depends also on other
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
Select the aircraft aerodynamics model.
This selection usually is done by the aircraft itself while
Run the FDM this rate (iterations per
Run the FDM 'n' times faster than real
Activate “trim” only for the
This selection usually is done by the aircraft itself while
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!
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!
Disable will stop the simulation clock
- but not the system-clock.
Please also see the general discussion about which options to chose in
the FlightGear-WIKI http://wiki.flightgear.org/index.php/Initial_Starting_Positions
Defines if the model start "on-ground"
or "in-air". If you define "in-air" you should define further options
like altitude and speed.
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
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.
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.
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.
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
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"
Specifies the distance and direction to
the reference point (in statute miles and deg.). That point could be: --airport,
--vor, --ndb, --fix, --carrier.
Start at a defined altitude (in feet, if not "--units-meters" is
defined). With specifying --altitude
gets set automatically! You also should define a --vc
(speed) if you do not want to crash like a stone!
Specifies the initial airspeed (which may change very fast very
drastically if you do not set the throttle accordingly!)
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!).
Specifies "flight path" angle (can be
positive) and the "climb rate" (can be negative)
Specifies the velocities along the body
X, Y, Z axis (in feet unless --units-meters
Specify velocity along a South-North /
West-East / vertical axis (in feet unless --units-meters
Specify starting position on an AI
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.
Specify a multiplier for the aspect
Specify the bits per pixel to be used
Enable/Disable 2D (flat) cloud layers
Enable/Disable 3D (volumetric) cloud
layers -- very, very nice - but also very, very heavy on your resources
(Processor & Graphic-Card)!
Enable/Disable a more realistic sight
to the runway and approach lights during twilight, especially when
still far away from the airport
Enable/Disable enhanced runway
Enable/Disable the "fullscreen" mode
of your screen
Enable/Disable full-screen game mode
for 3DFX Graphi-Cards (only former VOODOOGraphics)
Enable/Disable the special
mouse-pointer for the older 3DFX
Enable/Disable the rotating 3DFX-Logo when
using the VOODOOGraphics-type Graphics-Card
Enable/Disable celestial body growth
illusion near the horizon
Enable/Disable the instrument panel
Enable/Disable sky blending fog/dust
Enable/Disable specular reflections
on textured objects
Enable/Disable the presentation of
Show/noShow the model-wireframe. Just
try it - it gives you a nice view of how your model constructed.
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
is a compromise between the 2 extremes.
Specify field of view angle in Grad°
Specify window geometry (640x480, etc)
shading. ("Flat shadingflat” 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
Specify the default forward view
direction as an offset from straight ahead. Allowable values are LEFT,
RIGHT, CENTER, or a specific number in degre
If defined it disables
any of the following time-settings!
You can define the following:
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!
Defines which time will be used for the
is the world-time (Greenwich Mean-Time = UTC)
is the time at the latitude your are flying (that is close to the
official tim of where you are flying
is your PC-time
Add this time offset
assign a unique name to a player, see
Specify multiplayer communication
settings, multiple instances can be used. See chapter Multiplayer.
Enable a standard "http server" on the
specified port (usually: 5500).
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.
Enable screen shot "http server" on the
specified port (usually 5502).
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.
you define the Interfaces to other applications, e.g.:
||Open connection using a predefined communication interface
and a preselected communication protocol
||Open connection using the Garmin GPS protocol
||Open connection to an Agwagon joystick
||Open connection to a remote joystick
||Open connection using the FG Native Controls protocol
||Open connection using the FG Native FDM protocol
||Open connection using the FG Native protocol
||Open connection using the NMEA protocol
||Open connection using the OpenGC protocol
||Open connection using the interactive property manager
(LEGACY/DEAD DO NOT USE same as --telnet)
||Open connection using the PVE protocol
||Open connection using the Ray Woodworth motion chair protocol
||Open connection using the RUL protocol
||Enable atc610x interface
e.g. the field
"Protocol" under "Input/Output" on the advanced
Set the COM radios frequency (für ATC,
FGCOM, ATIS, etc.)
Set the NAV-radio frequencies,
optionally followed by a radial (for VOR
). Most aircraft can only use
NAV1 for the autopilot! Notice that the radial must stand after the
(is the ILS EDDF 25L)
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.
Slave the DME
to one of the NAV radios, or set
its internal frequency (if it is not integrated in a VOR
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
Some examples would be:
||makes sure the aircraft does not
start to roll at startup
||prevents the artificial traffic
(use when Multiplayer active)
||sets the com1 frequency-1 to
||starts with engine 1 running
||fill tank 1 with 10 gal.
|activates the AI-models
In FGrun you enter these values into
the sub-chapter "Properties" on the advanced
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.
Abort on encountering a “Floating Point
Just use the “OSG model viewer” rather
than loading the entire simulator “OSG viewer”
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 the reads or writes for a property; multiple instances can be
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!
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.
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=270@10" defines the wind coming
from 270° at 10 knots.
Specify turbulence from 0.0 (calm) to
Use randomly generated wind, i.e.
coming from constantly changing directions in changing strength
with the param="winter" you
switch to a snow-covered scenery. And reverse with param=summer.
Specifies the initial visibility in
meters or miles. Watch it: Default is meter!
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.
means: "Pass over VOR SJC (San Jose) at 5000 ft".
Instead of entering many waypoints with
you can write those into a standard text-file like:
We suggest to save that file into the
with a name of your choice, e.g. as "KIND-DEP.wp
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
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:
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
for the U.S., and
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
- Texture support was added by Curt Olson in spring 1998. This
marked a significant improvement in terms of reality. Some high-quality
textures were submitted by Eric Mitchell for the FlightGear project.
Another set of highquality textures was added by Erik Hofman ever since.
- After improving the scenery and texture support frame rate
dropped down to a point where FlightGear became unflyable in spring
1998. This issue was resolved by exploiting hardware OpenGL support,
which became available at that time, and implementing view frustrum
culling (a rendering technique that ignores the part of the scenery not
visible in a scene), done by Curt Olson. With respect to frame rate one
should keep in mind that the code, at present, is in no way optimized,
which leaves room for further improve ments.
- Scenery was further improved by adding geographic features
including lakes, rivers,and coastlines later, an effort still going on.
Textured runways were added by Dave Cornish in spring 2001. Light
textures add to the visual impression at night. To cope with the
constant growth of scenery data, a binary scenery format was introduced
in spring 2001. Runway lighting was introduced by Curt Olson in spring
2001. Finally, a completely new set of scenery files for the whole
world was created by William Riley based on preparatorydocumentation by
David Megginson in summer 2002. This is based on a data set called
VMap0 as an alternative to the GSHHS data used so far. This scenery is
a big improvement as it has world wide coverage of main streets,
rivers, etc., while it’s downside are much less accurate coast lines.
FlightGear’s base scenery is based on these new scenery files since
- There was support added for static objects to the scenery in
2001, which permits placing buildings, static planes, trees and so on
in the scenery. However, despite a few proofs of concept systematic
inclusion of these landmarks is still missing.
- The world is populated with random ground objects with
appropriate type and density for the local ground cover type since
summer 2002. This marks a mayor improvement of reality and is mainly
thanks to work by D. Megginson.
- A HUD (head up display) was added based on code provided by
Michele America and Charlie Hotchkiss in the fall of 1997 and was
improved later by Norman Vine. While not generally available for real
Cessna 172, the HUD conveniently reports the actual flight performance
of the simulation and may be of further use in military jets later.
- A rudimentary autopilot implementing heading hold was
contributed by Jeff Goeke-Smith in April 1998. It was improved by the
addition of an altitude hold and a terrain following switch in October
1998 and further developed by Norman Vine later.
- Friedemann Reinhard developed early instrument panel code,
which was added in June 1998. Unfortunately, development of that panel
slowed down later. Finally, David Megginson decided to rebuild the
panel code from scratch in January 2000. This led to a rapid addition
of new instruments and features to the panel, resulting in nearly all
main instruments being included until spring 2001. A handy minipanel
was added in summer 2001.
- Finally, LaRCsims Navion was replaced as the default
aircraft when the Cessna 172 was stable enough in February 2000 - as
move most users will welcome. There are now several flight model and
airplane options to choose from at runtime. Jon Berndt has invested a
lot of time in a more realistic and versatile flight model with a more
powerful aircraft configuration method. JSBSim, as it has come to be
called, did replace LaRCsim as the default flight dynamics model (FDM),
and it is planned to include such features as fuel slosh effects,
turbulence, complete flight control systems, and other features not
often found all together in a flight simulator. As an alternative, Andy
Ross added another flight dynamics model called YASim (Yet Another
Flight Dynamics Simulator) which aims at simplicity of use and is based
on fluid dynamics, by the end of 2001. This one bought us flight models
for a 747, an A4, and a DC-3. Alternatively, a group around Michael
Selig from the UIUC group provided another flight model along with
several planes since around 2000.
- A fully operational radio stack and working radios were
added to the panel by Curt Olson in spring 2000. A huge database of
Navaids contributed by Robin Peel allows IFR navigation since then.
There was basic ATC support added in fall 2001 by David Luff. This is
not yet fully implemented, but displaying ATIS messages is already
possible. A magneto switch with proper functions was added at the end
of 2001 by John Check and David Megginson. Moreover, several panels
were continually improved during 2001 and 2002 by John and others.
FlightGear now allows flying ILS approaches and features a Bendix
- In 2002 functional multi-engine support found it’s way into
FlightGear. JSBSim is now the default FDM in FlightGear.
- Support of ‘’true” 3D panels became stable via contributions
from John Check and others in spring 2002. In addition, we got movable
control surfaces like propellers etc., thanks to David Megginson.
- The display of sun, moon and stars have been a weak point
for PC flight-simulators for a long time. It is one of the great
achievements of FlightGear to include accurate modeling and display of
sun, moon, and planets very early. The corresponding astronomy code was
implemented in fall 1997 byDurk Talsma.
- Christian Mayer, together with Durk Talsma, contributed
weather code in the winter of 1999. This included clouds, winds, and
- The foundation for a menu system was laid based on another
library, the Portable Library PLIB, in June 1998. After having been
idle for a time, the first working menu entries came to life in spring
1999. PLIB underwent rapid development later. It has been distributed
as a separate package by Steve Baker with a much broader range of
applications in mind, since spring 1999. It has provided the basic
graphics rendering engine for FlightGear since fall 1999.
- In 1998 there was basic audio support, i.e. an audio library
and some basic background engine sound. This was later integrated into
the above mentioned portable library, PLIB. This same library was
extended to support joystick/yoke/rudder in October 1999, again marking
a huge step in terms of realism. To adapt on different joystick,
configuration options were introduced in fall 2000. Joystick support
was further improved by adding a self detection feature based on xml
joystick files, by David Megginson in summer 2002.
- Networking/multiplayer code has been integrated by Oliver
Delise and Curt Olson starting fall 1999. This effort is aimed at
enabling FlightGear to run concurrently on several machines over a
network, either an Intranet or the Internet, coupling it to a flight
planner running on a second machine, and more. There emerged several
approaches for remotely controlling FlightGear over a Network during
2001. Notably there was added support for the “Atlas” moving map
program. Besides, an embedded HTTP server developed by Curt Olson late
in 2001 can now act a property manager for external programs.
- Manually changing views in a flight simulator is in a sense
always “unreal” but nonetheless required in certain situations. A
possible solution was supplied by Norman Vine in the winter of 1999 by
implementing code for changing views using the mouse. Alternatively,
you can use a hat switch for this purpose, today.
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:
- A property manager was implemented by David Megginson in
fall 2000. It allows parsing a file called .fgfsrc under UNIX/Linux and
system.fgfsrc under Windows for input options. This plain ASCII file
has proven useful in submitting the growing number of input options,
and notably the joystick settings. This has shown to be a useful
concept, and joystick, keyboard, and panel settings are no longer hard
coded but set using *.xml files since spring 2001 thanks to work mainly
by David Megginson and John Check.
- The base of the graphics engine is OpenGL, a platform independent
- Based on OpenGL, the Portable Library PLIB provides
- basic rendering,
- joystick etc ̇outines.
on PLIB is SimGear, which includes all of the basic routines required
for the flight simulator as well as for building scenery.
- On top of SimGear there are
- FlightGear (the simulator itself), and
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:
- which comprises the scenery building tools.
Jon S. Berndt, Oliver Delise, Christian
Mayer, Curt Olson, Tony Peden, Gary R. Van Sickle, Norman Vine, and
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
notable development milestones at
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
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.
names the people who did the job (this information was
essentially taken from the file Thanks accompanying the code).
||Granted permission for the FlightGear project to use some of
the sound effects from their site. Homepage under http://www.a1freesoundeffects.com/
||Added clipping for 2D instruments, ATC volume control and
created a wide variety of aircraft.
||Is the author of Ssystem and provided his kind permission for
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.
||Contributed to the HUD code.
||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
||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.
||Provided a big chunk of online space to store USA scenery for
C++ style, usage, and implementation improvements, STL portability and
much, much more. Added threading support and a threaded tile pager.
||Updated various parts of the manual and wrote the initial
|Bernhard H. Buckel
||Contributed the README.Linux. Contributed several sections to
earlier versions of Installation and Getting Started.
||A lot of work getting FlightGear to compile with the MSVC++
compiler. Numerous hints on detailed improvements.
||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
||Provided some initial code to parse the 30 arcsec DEM files
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 created new cool runway textures plus some of our cloud
a FAQ, Documentation, Public relations. Working on adding some
networking/multi user code. Founder of the FlightGear MultiPilot
||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.
||Contributed some sphere interpolation code used by Christian
Mayer’s weather data base system.
||Wrote the GPL’d tri-striper we use. http://www.cs.sunysb.edu/~stripe/
||Created single engine piston engine sounds as part of an F4U
for FS98. They are pretty cool and Oscar was happy to contribute them
to our little project.
||Contributed patches for MSVC5 compatibility.
||Improved the build system for Windows and provided pre-built
||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.
|Authors of the zlib library. Used for on-the-fly compression
and decompression routines, http://www.gzip.org/zlib/.
||Contributed to the manual.
||Changes and updates for compiling on FreeBSD.
||Contributed the changes for the xml configurable HUD.
||Contributed our first autopilot (Heading Hold). Better
autoconf check for external timezone/daylight variables.
|Michael I. Gold
||Patiently answered questions on OpenGL.
||Made RedHat package building changes for SimGear.
||For allowing us to concert and use his wonderful planes,
http://www.flightsimnetwork.com/mikehill/home.htm, for FlightGear.
||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.
||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
provide the flight model. Bruce has patiently answered many, many
||Added helicopter support, gear/ground interaction and
aerotow/winch support to the YASim FDM.
||Contributed the Debian binary.
||Contributed screen buffer to ppm screen shot routine. Also
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:
Rich’s Homepage is at:
||Ported the audio library first to OpenBSD and IRIX and after
that to Win32.
||Helped with setting up fog effects.
||Redid the Makefile system so it is simpler and more robust.
|Kyler B Laird
||Contributed corrections to the manual.
||Contributed heavily to the IO360 piston engine model.
|Sam van der Mac
||Contributed to The Manual by translating HTML tutorials to
||Working on multi-lingual conversion tools for fgfs as a
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.
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
||FAQ maintainer. Reigning list administrator. Provided man
||Contributed some topnotch scenery textures being all original
creations by him.
||Former maintainer of European web pages.
||Created the Generic Polygon Clipping library. http://www.cs.man.ac.uk/aig/staff/alan/software/
||Author of GNU dbm, a set of database routines that use
extendible hashing and work similar to the standard UNIX dbm routines.
||Created European Scenery. Contributed a script to turn fgfs
into beautifully rendered 2-D maps. Wrote a first draft of a Scenery
||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/
||We made use of his TR library and of course of Mesa: http://www.mesa3d.org/brianp/TR.html,
||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.
||Maintains worldwide airport and runway database for
FlightGear as well as X-Plane
||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.
||Development of an early textured instrument panel.
||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.
||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
||Contributed a new configurable FDM called YASim (Yet Another
Dynamics Simulator, based on geometry information rather than
||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/
||Contributed ideas on audio support.
||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.
||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.
||Contributed cockpit graphics, 3D models, logos, and other
images. Project Bonanza
||Co-Author of The Manual.
||Maintains a database of objects and their location to
populate the worldwide scenery.
||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/.
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:
Moreover, those helped to support the effort:
|U. S. Geological Survey
||Provided geographic data used by this project. http://edc.usgs.gov/geodata/
||Contributed some METAR parsing code and some win32 screen
|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.
||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
||Contributed great photorealistic textures. Founder of
European Scenery Project for X-Plane: http://www.g-point.com/xpcity/esp/
||Porting FlightGear to the Metro Works development environment
||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.
||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/.
||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.
||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/
||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
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
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.
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
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
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.