Getting Started version 0.51
+class="ptmr7t---120">Getting Started Version 0.6 February, 16th, 2002
+class="ptmr7t---120">September, 9th, 2002 This documentation was written for Manual was written for FlightGear version 0.7.9.
href="getstartch1.html#x5-40001" name="QQ2-5-4">Want to have a free flight? Take FlightGear!
1.1 Yet another Flight Simulator?
+href="getstartch1.html#x5-50001.1" name="QQ2-5-5">Yet Another Flight Simulator?
1.2 System requirements
+href="getstartch1.html#x5-60001.2" name="QQ2-5-6">System Requirements
1.3 Which version should I use?
+href="getstartch1.html#x5-70001.3" name="QQ2-5-7">Choosing A Version
1.4 Flight models
+href="getstartch1.html#x5-80001.4" name="QQ2-5-8">Flight Dynamics Models
1.5 To whom this guide is addressed and how it is organized
+href="getstartch1.html#x5-90001.5" name="QQ2-5-9">About This Guide
2 Building the plane: Compiling the program 2.1 Getting a development environment under Windows
+href="getstartch2.html#x6-110002.1" name="QQ2-6-11">Preparing the development environment under Windows
2.2 Compiling FlightGear under Linux/Windows
+href="getstartch2.html#x6-120002.2" name="QQ2-6-12">Preparing the development environment under Windows
2.3 Compiling FlightGear under Mac OS 10.1
+href="getstartch2.html#x6-130002.3" name="QQ2-6-13">One-time preparations for Linux and Windows users
2.4 Compiling on other systems
+href="getstartch2.html#x6-160002.4" name="QQ2-6-16">Compiling FlightGear under Linux/Windows
2.5 Installing the base package
+href="getstartch2.html#x6-170002.5" name="QQ2-6-17">Compiling FlightGear under Mac OS X
2.6 For test pilots only: Building the CVS snapshots
+href="getstartch2.html#x6-180002.6" name="QQ2-6-18">Compiling on other systems
+ 2.7 Installing the base package
+ 2.8 For test pilots only: Building the CVS snapshots 3 Preflight: Installing Preflight: Installing FlightGear 3.1 Installing the binary distribution on a Windows system
+href="getstartch3.html#x7-220003.1" name="QQ2-7-22">Installing the binary distribution on a Windows system
3.2 Installing the binary distribution on a Macintosh system
+href="getstartch3.html#x7-230003.2" name="QQ2-7-23">Installing the binary distribution on a Macintosh system
3.3 Installing the binary distribution on a Debian Linux system
+href="getstartch3.html#x7-240003.3" name="QQ2-7-24">Installing the binary distribution on a Debian Linux system
3.4 Installing the binary distribution on a SGI IRIX system
+href="getstartch3.html#x7-250003.4" name="QQ2-7-25">Installing the binary distribution on a SGI IRIX system
3.5 Installing add-on scenery
+href="getstartch3.html#x7-260003.5" name="QQ2-7-26">Installing add-on scenery
3.6 Installing documentation
+href="getstartch3.html#x7-270003.6" name="QQ2-7-27">Installing documentation
Flying with Flying with FlightGear 4 Takeoff: How to start the program
+href="getstartch4.html#x9-290004" name="QQ2-9-29">Takeoff: How to start the program
4.1 Launching the simulator under Unix/Linux
+href="getstartch4.html#x9-300004.1" name="QQ2-9-30">Launching the simulator under Unix/Linux
4.2 Launching the simulator under Windows
+href="getstartch4.html#x9-310004.2" name="QQ2-9-31">Launching the simulator under Windows
4.3 Launching the simulator under Mac OS X
+href="getstartch4.html#x9-320004.3" name="QQ2-9-32">Launching the simulator under Mac OS X
4.4 Command line parameters
- 5 In-flight: All about instruments, keystrokes and menus
- 5.1 Starting the engine
+href="getstartch4.html#x9-330004.4" name="QQ2-9-33">Command line parameters
+ 4.5 Joystick support
+ 4.6 A glance over our hangar
+ 5 In-flight: All about instruments, keystrokes and menus
+ 5.1 Starting the engine 5.2 Keyboard controls
+href="getstartch5.html#x10-590005.2" name="QQ2-10-59">Keyboard controls
5.3 Menu entries
+href="getstartch5.html#x10-600005.3" name="QQ2-10-60">Menu entries
5.4 The Instrument Panel
+href="getstartch5.html#x10-610005.4" name="QQ2-10-61">The Instrument Panel
5.5 The Head Up Display
+href="getstartch5.html#x10-620005.5" name="QQ2-10-62">The Head Up Display
5.6 Mouse controlled actions
+href="getstartch5.html#x10-630005.6" name="QQ2-10-63">Mouse controlled actions
5.7 Some further reading for pilot students
+href="getstartch5.html#x10-640005.7" name="QQ2-10-64">Some further reading for student pilots
Appendices
+href="getstartpa3.html#x11-65000III" name="QQ2-11-65">Appendices
A Missed approach: If anything refuses to work
+href="getstartap1.html#x12-66000A" name="QQ2-12-66">Missed approach: If anything refuses to work
A.1 FlightGear Problem Reports
+href="getstartap1.html#x12-67000A.1" name="QQ2-12-67">FlightGear Problem Reports
A.2 General problems
+href="getstartap1.html#x12-68000A.2" name="QQ2-12-68">General problems
A.3 Potential problems under Linux
+href="getstartap1.html#x12-69000A.3" name="QQ2-12-69">Potential problems under Linux
A.4 Potential problems under Windows
+href="getstartap1.html#x12-70000A.4" name="QQ2-12-70">Potential problems under Windows
B Some words on OpenGL graphics drivers
+href="getstartap2.html#x13-71000B" name="QQ2-13-71">Some words on OpenGL graphics drivers
B.1 NVIDIA chip based cards under Linux
+href="getstartap2.html#x13-72000B.1" name="QQ2-13-72">NVIDIA chip based cards under Linux
B.2 NVIDIA chip based cards under Windows
+href="getstartap2.html#x13-73000B.2" name="QQ2-13-73">NVIDIA chip based cards under Windows
B.3 3DFX chip based cards under Windows
+href="getstartap2.html#x13-74000B.3" name="QQ2-13-74">3DFX chip based cards under Windows
B.4 An alternative approach for Windows users
+href="getstartap2.html#x13-75000B.4" name="QQ2-13-75">An alternative approach for Windows users
B.5 3DFX chip based cards under Linux
+href="getstartap2.html#x13-76000B.5" name="QQ2-13-76">3DFX chip based cards under Linux
B.6 ATI chip based cards under Linux
+href="getstartap2.html#x13-77000B.6" name="QQ2-13-77">ATI chip based cards under Linux
B.7 Building your own OpenGL support under Linux
+href="getstartap2.html#x13-78000B.7" name="QQ2-13-78">Building your own OpenGL support under Linux
B.8 OpenGL on MacIntosh
+href="getstartap2.html#x13-79000B.8" name="QQ2-13-79">OpenGL on Macintosh
C Landing: Some further thoughts before leaving the plane
+href="getstartap3.html#x14-80000C" name="QQ2-14-80">Landing: Some further thoughts before leaving the plane
C.1 A not so Short History of A Sketch on the History of FlightGear C.2 Those, who did the work
+href="getstartap3.html#x14-86000C.2" name="QQ2-14-86">Those, who did the work
C.3 What remains to be done
+href="getstartap3.html#x14-87000C.3" name="QQ2-14-87">What remains to be done
Index
+href="getstartap3.html#Q1-14-89">Index
Index
+href="getstartli3.html#x15-89000C.3" name="QQ2-15-90">Index
diff --git a/Docs/InstallGuide/html/getstart0x.gif b/Docs/InstallGuide/html/getstart0x.gif
index 217267f2e..710d156ed 100644
Binary files a/Docs/InstallGuide/html/getstart0x.gif and b/Docs/InstallGuide/html/getstart0x.gif differ
diff --git a/Docs/InstallGuide/html/getstart10x.gif b/Docs/InstallGuide/html/getstart10x.gif
index 7ddcfe91b..de01c330d 100644
Binary files a/Docs/InstallGuide/html/getstart10x.gif and b/Docs/InstallGuide/html/getstart10x.gif differ
diff --git a/Docs/InstallGuide/html/getstart11x.gif b/Docs/InstallGuide/html/getstart11x.gif
index 7ddcfe91b..bf969709a 100644
Binary files a/Docs/InstallGuide/html/getstart11x.gif and b/Docs/InstallGuide/html/getstart11x.gif differ
diff --git a/Docs/InstallGuide/html/getstart12x.gif b/Docs/InstallGuide/html/getstart12x.gif
index 7ddcfe91b..76cf1a4e0 100644
Binary files a/Docs/InstallGuide/html/getstart12x.gif and b/Docs/InstallGuide/html/getstart12x.gif differ
diff --git a/Docs/InstallGuide/html/getstart3x.gif b/Docs/InstallGuide/html/getstart3x.gif
index b7fa5e16e..7ddcfe91b 100644
Binary files a/Docs/InstallGuide/html/getstart3x.gif and b/Docs/InstallGuide/html/getstart3x.gif differ
diff --git a/Docs/InstallGuide/html/getstart4x.gif b/Docs/InstallGuide/html/getstart4x.gif
index d172dc3ff..7ddcfe91b 100644
Binary files a/Docs/InstallGuide/html/getstart4x.gif and b/Docs/InstallGuide/html/getstart4x.gif differ
diff --git a/Docs/InstallGuide/html/getstart5x.gif b/Docs/InstallGuide/html/getstart5x.gif
index de01c330d..b7fa5e16e 100644
Binary files a/Docs/InstallGuide/html/getstart5x.gif and b/Docs/InstallGuide/html/getstart5x.gif differ
diff --git a/Docs/InstallGuide/html/getstart6x.gif b/Docs/InstallGuide/html/getstart6x.gif
index bf969709a..dc04dba53 100644
Binary files a/Docs/InstallGuide/html/getstart6x.gif and b/Docs/InstallGuide/html/getstart6x.gif differ
diff --git a/Docs/InstallGuide/html/getstart7x.gif b/Docs/InstallGuide/html/getstart7x.gif
index 497bd820e..4bbdc0039 100644
Binary files a/Docs/InstallGuide/html/getstart7x.gif and b/Docs/InstallGuide/html/getstart7x.gif differ
diff --git a/Docs/InstallGuide/html/getstart8x.gif b/Docs/InstallGuide/html/getstart8x.gif
index 076ee9ebf..4bbdc0039 100644
Binary files a/Docs/InstallGuide/html/getstart8x.gif and b/Docs/InstallGuide/html/getstart8x.gif differ
diff --git a/Docs/InstallGuide/html/getstart9x.gif b/Docs/InstallGuide/html/getstart9x.gif
index 7ddcfe91b..aab177a98 100644
Binary files a/Docs/InstallGuide/html/getstart9x.gif and b/Docs/InstallGuide/html/getstart9x.gif differ
diff --git a/Docs/InstallGuide/html/getstartap1.html b/Docs/InstallGuide/html/getstartap1.html
index c8c4e4057..5dae8b680 100644
--- a/Docs/InstallGuide/html/getstartap1.html
+++ b/Docs/InstallGuide/html/getstartap1.html
@@ -6,7 +6,7 @@
-
+
+href="getstart.html#QQ2-12-66" name="x12-66000A">Missed approach: If anything refuses to work
In the following section, we tried to sort some problems according to operating
-system, but if you encounter a problem, it may be a wise idea to look beyond
-”your” operating system - just in case. If you are experiencing problems, we
-would strongly advise you to first check the FAQ maintained by Cameron Moore
-at
-
according to operating system,
+but if you encounter a problem, it may be a wise idea to look beyond ”your”
+operating system - just in case. If you are experiencing problems, we would
+strongly advise you to first check the FAQ maintained by Cameron Moore at
+
Moreover, the source code contains a directory docs-mini containing numerous
ideas on and solutions to special problems. This is also a good place to go for further
reading.
+href="getstart.html#QQ2-12-67" name="x12-67000A.1">FlightGear Problem Reports
-
The best place to look for help is generally the mailing lists, specifically the
+ name="dx12-67001">
+
The best place to look for help is generally the mailing lists, specifically the
[Flightgear-User] mailing list. If you happen to be running a CVS version of
FlightGear, you may want to subscribe to the [Flightgear-Devel] list. Instructions for
subscription can be found at
-
It’s often the case that someone has already dealt with the issue you’re dealing with, so it
+
It’s often the case that someone has already dealt with the issue you’re dealing with, so it
may be worth your time to search the mailing list archives at
-
There are numerous developers and users reading the lists, so questions are generally
answered. However, messages of the type
-
FlightGear does not compile on my system. What shall I do?
-
are hard to answer without any further detail given, aren’t they? Here are some things to
+
are hard to answer without any further detail given, aren’t they? Here are some things to
consider including in your message when you report a problem:
Type of problem: (Linker dies with message. . . )
Steps to recreate the problem: Start at KSFO, turn off brakes . . .
-
One final remark: Please avoid posting binaries to these lists! List subscribers
-are widely distributed, and some users have low bandwidth and/or metered
-connections. Large messsages may be rejected by the mailing list administrator.
-Thanks.
+
For getting a trace of the output which FlightGear produces, then following
+command may come in handy (may need to be modified on some OSs or may not work
+on others at all, though):
+
%FGROOT/BIN/fgfs >log.txt 2>&1
+
One final remark: Please avoid posting binaries to these lists! List subscribers
+are widely distributed, and some users have low bandwidth and/or metered
+connections. Large messages may be rejected by the mailing list administrator.
+Thanks.
FlightGear runs SOOO slow.
If FlightGear says it’s running with something like 1 fps (frame per second)
or below you typically don’t have working hardware OpenGL support. There
+ name="dx12-68002"> support. There
may be several reasons for this. First, there may be no OpenGL hardware
drivers available for older cards. In this case it is highly recommended to get
a new board.
-
Second, check if your drivers are properly installed. Several cards need
+
Second, check if your drivers are properly installed. Several cards need
additional OpenGL support drivers besides the ”native” windows ones. For
more detail check Appendix B.
+href="getstartap2.html#x13-71000B">B.
Either configure or libplibpu.a should be under /lib. Double check
there are no stray PLIB headers/libraries sitting elsewhere!
-
Besides check careful the error messages of
Besides check careful the error messages of configure. In several cases
it says what is missing.
+href="getstart.html#QQ2-12-69" name="x12-69000A.3">Potential problems under Linux
-
Since we don’t have access to all possible flavors of Linux distributions, here are some
+ name="dx12-69001">
+
Since we don’t have access to all possible flavors of Linux distributions, here are some
thoughts on possible causes of problems. (This Section includes contributions by Kai
Troester.)
+ name="dx12-69002">
Wrong library versions
This is a rather common cause of grief especially when you prefer to install
- the libraries needed by FlightGear by hand. Be sure that especially the Mesa
- library contains support for the 3DFX board and that GLIDE libraries are
- installed and can be found. If a ldd `which fgfs` complains about
- missing libraries you are in trouble.
-
You should also be sure to always keep the latest version of PLIB on your
+ the libraries needed by FlightGear by hand. Be sure that especially the Mesa
+ library contains support for the 3DFX board and that GLIDE libraries are
+ installed and can be found. If a ldd `which fgfs` complains about
+ missing libraries you are in trouble.
+
You should also be sure to always keep the latest version of PLIB on your
system. Lots of people have failed miserably to compile FlightGear just
because of an outdated plib.
Missing permissions
+ name="dx12-69005">
In case you are using XFree86 before release 4.0 the before release 4.0 the FlightGear binary may
need to be setuid root in order to be capable of accessing some accelerator
boards (or a special kernel module as described earlier in this document)
based on 3DFX chips. So you can either issue a
-
to give the FlightGear binary the proper rights or install the 3DFX module.
- The latter is the “clean” solution and strongly recommended!
+ The latter is the ”clean” solution and strongly recommended!
Non-default install options
FlightGear as they
Problems with linking
There may be several reasons; however in case you get a message like
-
libmk4.so.0: cannot open shared object file
-
the reason is a missing library package called Metakit. This is provided with
- Simgear in packed form. Unpack and install it first.
The executable refuses to run.
You may have tried to start the executable directly either by double-clicking
@@ -214,15 +224,15 @@ class="pcrr7t---109">ROOT
in autoexec.bat or otherwise). Rather
double-click runfgfs.bat. For more details, check Chapter 4.
-
Another cause of grief might be that you did not download the most recent
+href="getstartch4.html#x9-290004">4.
+
Another cause of grief might be that you did not download the most recent
versions of the base package files required by FlightGear, or you did not
download any of them at all. Have a close look at this, as the scenery/texture
format is still under development and may change frequently. For more
details, check Chapter 3.
-
Next, if you run into trouble at runtime, do not use windows utilities for
+href="getstartch3.html#x7-210003">3.
+
Next, if you run into trouble at runtime, do not use windows utilities for
unpacking the .tar.gz. If you did, try it in the Cygnus shell with tar
@@ -237,21 +247,24 @@ class="pcrr7t---109">runfgfs.bat.
I am unable to build FlightGear under MSVC/MS DevStudio.
+ name="dx12-70002">/MS DevStudio.
By default, FlightGear is build with GNU GCC. The Win32 port of GNU
GCC is known as Cygwin. For hints on Makefiles required for MSVC for
+ name="dx12-70004">. For hints on Makefiles required for MSVC for
MSC DevStudio have a look into
-
In principle, it should be possible to compile FlightGear with the project
files provided with the source code.
Compilation of FlightGear dies.
+
+
+
There may be several reasons for this, including true bugs. However, before
trying to do anything else or report a problem, make sure you have the latest
version of the
-
+
@@ -17,21 +17,21 @@ href="getstartap1.html#tailgetstartap1.html" >prev-tail] [tail] [up]
+href="getstart.html#QQ2-13-71" name="x13-71000B">Some words on OpenGL graphics drivers
FlightGear’s graphics engine is based on a graphics library called OpenGL. Its primary
+ name="dx13-71001"> called OpenGL. Its primary
advantage is its platform independence, i. e., programs written with OpenGL support can
+ name="dx13-71003"> support can
be compiled and executed on several platforms, given the proper drivers having been
installed in advance. Thus, independent of if you want to run the binaries only or if you
want to compile the program yourself you must have some sort of OpenGL support
+ name="dx13-71004"> support
installed for your video card.
+ name="dx13-71005">.
A good review on OpenGL drivers can be found at
+ name="dx13-71006"> can be found at
Specific information is collected for windows at
@@ -43,7 +43,7 @@ href="http://www.x-plane.com/SYSREQ/v5mac.html" >http://www.x-plane.com/SYSREQ/v
An excellent place to look for documentation about Linux and 3-D accelerators is the
Linux QuakeHOWTO at
http://www.linuxquake.com.
@@ -54,14 +54,14 @@ are unable to provide a complete description for all systems. Given the present
dominance of NVIDIA combined with the fact that their chips have indeed been proven
powerful for running FlightGear, we will concentrate on NVIDIA drivers in what
+ name="dx13-71008"> in what
follows.
+href="getstart.html#QQ2-13-72" name="x13-72000B.1">NVIDIA chip based cards under Linux
Recent Linux distributions include and install anything needed to run OpenGL programs
+ name="dx13-72001"> distributions include and install anything needed to run OpenGL programs
under Linux. Usually there is no need to install anything else.
+ name="dx13-72002">. Usually there is no need to install anything else.
If for whatever reason this does not work, you may try to download the most recent
drivers from the NVIDIA site at
RedHat 7.1, Redhat 7.0, Redhat 6.2, Redhat 6.1, Mandrake 7.1, Mandrake
7.2, SuSE 7.1, SuSE 7.0 in several formats (.rpm, .tar.gz). These drivers support OpenGL
natively and do not need any additional stuff.
The page named above contains a detailed README and Installation
class="pcrr7t---109">Guide
giving a step-by-step description, making it unnecessary to copy the material
here.
+href="getstart.html#QQ2-13-73" name="x13-73000B.2">NVIDIA chip based cards under Windows
Again, you may first try the drivers coming with your graphics card. Usually they should
include OpenGL support. If for whatever reason the maker of your board did not include
+ name="dx13-73001"> support. If for whatever reason the maker of your board did not include
this feature into the driver, you should install the Detonator reference drivers made by
+ name="dx13-73002"> made by
NVIDIA (which might be a good idea anyway). These are available in three
+ name="dx13-73004"> (which might be a good idea anyway). These are available in three
different versions (Windows 95/98/ME, Windows 2000, Windows NT) from
http://www.nvidia.com/products.nsf/htmlmedia/detonator3.html
@@ -96,56 +96,58 @@ href="http://www.nvidia.com/products.nsf/htmlmedia/detonator3.html" >http://www.
uninstall your present driver and install a standard VGA graphics adapter before
switching to the new NVIDIA drivers first.
+href="getstart.html#QQ2-13-74" name="x13-74000B.3">3DFX chip based cards under Windows
With the Glide drivers no longer provided by 3DFX there seems to be little chance to
get it running (except to find older OpenGL drivers somewhere on the net or
privately). All pages which formerly provided official support or instructions for
3DFX are gone now. For an alternative, you may want to check the next section,
though.
+href="getstart.html#QQ2-13-75" name="x13-75000B.4">An alternative approach for Windows users
There is now an attempt to build a program which detects the graphics chip on your
board and automatically installs the appropriate OpenGL drivers. This is called
OpenGL Setup and is presently in beta stage. It’s home page can be found at
+ name="dx13-75001"> and is presently in beta stage. It’s home page can be found at
+href="getstart.html#QQ2-13-76" name="x13-76000B.5">3DFX chip based cards under Linux
Notably, with 3DFX now having been taken over by NVIDIA, manufacturer’s support
+ name="dx13-76001"> now having been taken over by NVIDIA, manufacturer’s support
already has disappeared. However with XFree86-4.x (with x at least being greater than 1)
-Voodoo3 cards are known to be pretty usable in 16 bit colour mode. Newer cards should
+Voodoo3 cards are known to be pretty usable in 16 bit color mode. Newer cards should
work fine as well. If you are still running a version of Xfree86 3.X and run into problems,
consider an upgrade. The recent distributions by Debian or SuSE have been reported to
work well.
There is excellent support for ATI chips in XFree86-4.1 and greater. Lots of AGP boards
-based on the Rage128 chip - from simple Rage128 board to ATI Xpert2000 - are pretty
-usuable for FlightGear. Since XFree86-4.1 you can use early Radeon chips - up to
-Radeon7500 with XFree86-4.2.
+href="getstart.html#QQ2-13-77" name="x13-77000B.6">ATI chip based cards under Linux
+
There is support for ATI chips in XFree86-4.1 and greater. Lots of AGP boards based on
+the Rage128 chip - from simple Rage128 board to ATI Xpert2000 - are mostly usable for
+FlightGear. Since XFree86-4.1 you can use early Radeon chips - up to Radeon7500 with
+XFree86-4.2.
+href="getstart.html#QQ2-13-78" name="x13-78000B.7">Building your own OpenGL support under Linux
Setting up proper OpenGL support with a recent Linux distribution should be pretty
+ name="dx13-78001"> with a recent Linux distribution should be pretty
simple. As an example SuSE ships everything you need plus some small shell scripts to
+ name="dx13-78002"> ships everything you need plus some small shell scripts to
adjust the missing bits automagically. If you just want to execute pre-built binaries of
-FlightGear, then you’re done by using the supplied FlightGear package plus the
+FlightGear, then you’re done by using the supplied FlightGear package plus the
mandantory runtime libraries (and kernel modules). The package manager will tell you
which ones to choose.
-
In case you want to run a selfmade kernel, you want to compile FlightGear yourself,
-you’re tweaking your X server configuration file yourself or you even run a homebrewn
-Linux ”distribution” (this means, you want to compile everything yourself), this chapter
-might be useful for you.
+
In case you want to run a self-made kernel, you want to compile FlightGear
+yourself, you’re tweaking your X server configuration file yourself or you even run a
+homebrewed Linux ”distribution” (this means, you want to compile everything yourself),
+this chapter might be useful for you.
Now let’s have a look at the parts that build OpenGL support on Linux. First there’s a
Linux kernel with support for your graphics adapter.
Examples on which graphics hardware is supported natively by Open Source drivers
@@ -154,11 +156,11 @@ are provided on
href="http://dri.sourceforge.net/status.phtml" >http://dri.sourceforge.net/status.phtml.
There are a few graphics chip families that are not directly or no more than partly
supported by XFree86, the X window implementation on Linux, because vendors don’t
+ name="dx13-78003">, the X window implementation on Linux, because vendors don’t
like to provide programming information on their chips. In these cases - notably
IBM/DIAMOND/now: ATI FireGL graphics boards and NVIDIA GeForce based cards -
+ name="dx13-78004"> FireGL graphics boards and NVIDIA GeForce based cards -
you depend on the manufacturers will to follow the ongoing development of the XFree86
@@ -166,20 +168,21 @@ you depend on the manufacturers will to follow the ongoing development of the XF
graphics display infrastructure. These boards might prove to deliver impressing
performance but in many cases - considering the CPU’s speed you find in today’s
PC’s - you have many choices which all lead to respectable performance of
-FlightGear.
+FlightGear.
As long as you use a distribution provided kernel, you can expect to find all
-necessary kernel modules at the approriate location. If you compile the kernel yourself,
-then you have to take care of two submenues in the kernel configuration menue. You’ll
-find them in the ”Character devices” menue. Please notice that AGP support is not
+necessary kernel modules at the appropriate location. If you compile the kernel yourself,
+then you have to take care of two sub-menus in the kernel configuration menu. You’ll
+find them in the ”Character devices” menu. Please notice that AGP support is not
compulsory for hardware accelerated OpenGL support on Linux. This also works quite
fine with some PCI cards (3dfx Voodoo3 PCI for example, in case you still own one).
+ name="dx13-78006"> Voodoo3 PCI for example, in case you still own one).
Although every modern PC graphics card utilizes the AGP ’bus’ for fast data
transfer.
Besides ”AGP Support” for your chipset - you might want to ask your mainboard
-manual which one is on - you defnitely want to activate ”Direct Rendering Manager”
-for your garphics board. Please note that recent releases of XFree86 - namely
+ name="dx13-78007">” for your chipset - you might want to ask your mainboard
+manual which one is on - you definitely want to activate ”Direct Rendering Manager”
+for your graphics board. Please note that recent releases of XFree86 - namely
4.1.0 and higher might not be supported by the DRI included in older Linux
kernels. Also newer 2.4.x kernels from 2.4.8 up to 2.4.17 do not support DRI in
XFree86-4.0.x.
@@ -198,15 +201,15 @@ class="pcrr7t---109">> agpgart: Detected Via Apollo Pro chipset
> agpgart: AGP aperture is 64M @ 0xe4000000
If you don’t encounter such messages on Linux kernel boot, then you might have
-missed the right chipset. Part one of activation hardware accelerated OpenGL support on
+missed the right chip set. Part one of activation hardware accelerated OpenGL support on
your Linux system is now completed.
The second part consists of configuring your X server for OpenGL. This is not a big
+ name="dx13-78008"> for OpenGL. This is not a big
deal as it simply consists of to instructions to load the appropriate modules on startup of
the X server. This is done by editing the configuration file /etc/X11/XF86Config.
Today’s Linux distributions are supposed to provide a tool that does this job
-for you on your demand. Please make shure there are these two instructions:
+for you on your demand. Please make sure there are these two instructions:
in the ”Module” section your X server configuration file. If everything is right
+ name="dx13-78009"> configuration file. If everything is right
the X server will take care of loading the appropriate Linux kernel module for
DRI support of your graphics card. The right Linux kernel module name is
determined by the ’Driver’ statement in the ”Device” section of the XF86Config.
@@ -274,9 +277,9 @@ class="pcrr7t---109">VendorName ''ATI''
class="pcrr7t---109">EndSection
By using the Option ”AGPMode” you can tune AGP performance as long as the
mainboard and the graphics card permit. The BusID on AGP systems should always be
+ name="dx13-78010"> systems should always be
set to ”1:0:0” - because you only have one AGP slot on your board - whereas the PCI
+ name="dx13-78011">
BusID differs with the slot your graphics card has been applied to. ’lspci’ might be your
@@ -287,102 +290,106 @@ resides.
This has been the second part of installing hardware accelerated OpenGL support on
your Linux box.
The third part carries two subparts: First there are the OpenGL runtime libraries,
+ name="dx13-78012">
sufficient to run existing appliactions. For compiling FlightGear you also need the suiting
-develoment headers. As compiling the whole X window system is not subject to this
+developmental headers. As compiling the whole X window system is not subject to this
abstract we expect that your distribution ships the necessary libraries and headers. In case
you told your package manager to install some sort of OpenGL support you are
supposed to find some OpenGL test utilities, at least there should be ’glxinfo’ or
’gl-info’.
-
These commandline utilities are useful to say if the previous steps where successfull.
-If they refuse to start, then your package manager missed something because he should
-have known that these utilities usually depend on the existence of OpenGL runtime
-libraries. If they start, then you’re one step ahead. Now watch the output of this tool and
-and have a look at the line that starts with
-
OpenGL renderer string:
-
If you find something like
-
These command-line utilities are useful to say if the previous steps where
+successfull. If they refuse to start, then your package manager missed something because
+he should have known that these utilities usually depend on the existence of OpenGL
+runtime libraries. If they start, then you’re one step ahead. Now watch the output of this
+tool and and have a look at the line that starts with
+
mind the word ’Indirect’, then it’s you who missed something, because OpenGL gets
+
mind the word ’Indirect’, then it’s you who missed something, because OpenGL gets
dealt with in a software library running solely on your CPU. In this case you might want
-to have a closer look at the preceding paragraphs of this chapter. Now please make
-shure all necessary libraries are at their proper location. You will need three
-OpenGL libraries for running FlightGear. In most cases you will find them in
+to have a closer look at the preceding paragraphs of this chapter. Now please
+make sure all necessary libraries are at their proper location. You will need three
+OpenGL libraries for running FlightGear. In most cases you will find them in
/usr/lib/:
-
/usr/lib/libGL.so.1
-
/usr/lib/libGLU.so.1
-
/usr/lib/libglut.so.3
-
These may be the libraries itself or symlinks to appropriate libraries located in some
+
These may be the libraries itself or symlinks to appropriate libraries located in some
other directories. Depending on the distribution you use these libraries might be shipped
in different packages. SuSE for example ships libGL in package ’xf86_glx’, libGLU in
-’xf86glu’ and libglut in ’mesaglut’. Additionally for FlightGear you need libplib which is
-part of the ’plib’ package.
-
For compiling FlightGear yourself - as already mentioned - you need the appropriate
+ name="dx13-78014"> for example ships libGL in package ’xf86_glx’, libGLU in
+’xf86glu’ and libglut in ’mesaglut’. Additionally for FlightGear you need libplib which
+is part of the ’plib’ package.
+
For compiling FlightGear yourself - as already mentioned - you need the appropriate
header files which often reside in /usr/include/GL/. Two are necessary for libGL and they
come in - no, not ’xf86glx-devel’ (o.k., they do but they do not work correctly) but in
’mesa-devel’:
-
/usr/include/GL/gl.h
-
/usr/include/GL/glx.h
-
One comes with libGLU in ’xf86glu-devel’:
-
One comes with libGLU in ’xf86glu-devel’:
+
/usr/include/GL/glu.h
-
and one with libglut in ’mesaglut-devel’
-
and one with libglut in ’mesaglut-devel’
+
/usr/include/GL/glut.h
-
The ’plib’ package comes with some more libraries and headers that are too
+
The ’plib’ package comes with some more libraries and headers that are too
many to be mentioned here. If all this is present and you have a comfortable
-compiler environment, then you are ready to compile FlightGear and enjoy the
+compiler environment, then you are ready to compile FlightGear and enjoy the
result.
-
Further information on OpenGL issues of specific XFree86 releases is avaliable here:
-
http://www.xfree86.org/
Further information on OpenGL issues of specific XFree86 releases is available here:
+
You should receive the updates automatically for Mac OX 10.x.
+
You should receive the updates automatically for Mac OSX.
-
One final word: We would recommend that you test your OpenGL support with one
+ name="dx13-79004"> support with one
of the programs that accompany the drivers, to be absolutely confident that
it is functioning well. There are also many little programs, often available as
screen savers, that can be used for testing. It is important that you are confident
diff --git a/Docs/InstallGuide/html/getstartap3.html b/Docs/InstallGuide/html/getstartap3.html
index 7c922655c..cad3bbb39 100644
--- a/Docs/InstallGuide/html/getstartap3.html
+++ b/Docs/InstallGuide/html/getstartap3.html
@@ -6,7 +6,7 @@
-
+
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. The original proposal is still available from the
+
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. The original proposal is still available from the
FlightGear web site and can be found under
-
Although the names of the people and several of the details have changed over time, the
+
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
+
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
+ name="dx14-81003">
from Berkeley University. Early code ran
under Linux as well as under DOS, OS/2, Windows 95/NT, and Sun-OS. This
+ name="dx14-81004"> 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
+ name="dx14-81009"> in a system-independent way entirely from
scratch.
-
Development slowed and finally stopped in the beginning of 1997 when Eric was
+
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 exploite a system-independent graphics platform: OpenGL.
-
-
-
-
-
Fig. 7: LaRCsim’s Navionis still available in FlightGear.
-
In addition, a clever decision on the selection of the basic scenery data was made
+
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
-
resp., for other countries. Those freely accessible scenery data, in conjunction with
+ name="dx14-81018">. These terrain data are available from
+
+
+
+
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
This new FlightGear code - still largely being based on the original LaRCsim code -
+ name="dx14-81019"> code -
was released in July 1997. From that moment the project gained momentum again. Here
-are some milestones in the more recent development history:
+are some milestones in the more recent development history.
+
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
+ high-quality textures was added by Erik Hofman in summer 2002.
+
+
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
+ improvements.
+
+
In September 1998 Curt Olson succeeded in creating a complete terrain
+ model for the U.S. The scenery is available worldwide now, via a clickable
+ map at:
+
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
+ preparatory documentation 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
+ summer 2002. The complete set is available via a clickable map, too, from
+
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 transponder.
+
+
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 by
+ name="dx14-84002"> was implemented in fall 1997 by
Durk Talsma.
+ name="dx14-84003">.
-
Texture support was added by Curt Olson in spring 1998. This marked a
- significant improvement in terms of reality. You may recall that Microsoft
-
-
-
- Flight Simulator had non-textured scenery up until version 4.0. Some
- high-quality textures were submitted by Eric Mitchell for the FlightGear
- project.
-
-
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.
-
-
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. Taking these measures made FlightGear flyable again as long as they
- included a 3-D graphics board that featured hardware OpenGL support. 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 improvements.
-
-
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.
-
-
The basis for a menu system was laid based on another library, the Portable
- Library Christian Mayer, together with Durk Talsma, contributed weather code in the
+ winter of 1999. This included clouds, winds, and even thunderstorms.
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.
-
, 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
+ 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.
-
-
Friedemann Reinhard developed early instrument panel code, which was
- added in June 1998. Unfortunately, development of that panel slowed down
- later, partly because of OpenGL compatibility problems. 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.
In 1998 there was basic audio support, i. e. an audio library and
+ name="dx14-85005">, 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
+ name="dx14-85006">. This same library was extended to
support joystick/yoke/rudder in October 1999, again marking a huge step in
+ name="dx14-85007"> in October 1999, again marking a huge step in
terms of realism. To adapt on different joystick, configuration options were
- introduced in fall 2000.
-
-
In September 1998 Curt Olson succeeded in creating a complete terrain
- model for the U.S. The scenery is available worldwide via a clickable map
- at:
-
http://www.flightgear.org/Downloads/world-scenery.html.
+ 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
+ name="dx14-85010"> 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 working
- together wirth the ”Atlas” moving map program. Besides, an embedded
- HTTP server developed late in 2001 by Curt Olson can now act a property
- manager for external programs.
-
-
Christian Mayer, together with Durk Talsma, contributed weather code in the
- winter of 1999. This included clouds, winds, and even thunderstorms.
+ name="dx14-85013"> 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”
+ name="dx14-85021"> 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
+ name="dx14-85022"> 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.
-
-
-
-
-
Finally, LaRCsims Navion was replaced as the default aircraft when the
- Cessna 172 was stable enough in February 2000 - a move most users will
- welcome. There are now several flight model options to choose from at
- runtime: a modified and improved LaRCsim Cessna 172 developed by Tony
- Peden, Jon Berndt’s X15, and Christian Mayer’s hot air balloon. 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, may eventually 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 simpliciy of use, by the end of 2001. This one
- bought us flight modles for a 747, an A4, and a DC-3.
-
-
The scenery was further improved by adding geographic features including
- lakes, rivers, and coastlines later, an effort still going on. Since the end of
- 2000, there was again stronger focus on scenery. 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.
-
-
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.
A property manager was implemented by David Megginson in fall
+ name="dx14-85023"> was implemented by David Megginson in fall
2000. It allows parsing a file called .fgfsrc under UNIX/Linux and
+ name="dx14-85025"> under UNIX/Linux and
system.fgfsrc under Windows for input options. This plain ASCII file
+ name="dx14-85026"> 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 proven 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.
-
-
There was support added for static objects to the scenery in 2001, which
-
-
-
- permits placing buildung, static planes, trees and so on in the scenery.
- However, despite a few profs systematic includion of these landmarks is still
- missing.
-
-
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.. Actually, several panels were vastly
- improved during 2001 by John and others.
-
During development there were several code reorganization efforts. Various code
-subsystems were moved into packages. As a result, presetnly code is organized as
-follows:
-
The base of the graphics engine is . 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.
+
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:
+
The base of the graphics engine is OpenGL, a platform independent graphics library.
+ name="dx14-85029">, a platform independent graphics library.
Based on OpenGL, the Portable Library , the Portable Library PLIB provides basic rendering, audio, joystick
+ name="dx14-85031"> provides basic rendering, audio, joystick
etc. routines. Based on PLIB is is SimGear, which includes all of the basic routines
+ name="dx14-85033">, which includes all of the basic routines
required for the flight simulator as well as for building scenery. On top of SimGear there
+ name="dx14-85034"> there
are (i) FlightGear (the simulator itself), and (ii) (the simulator itself), and (ii) TerraGear, which comprises the scenery
+ name="dx14-85036">, which comprises the scenery
building tools.
-
This is by no means an exhaustive history and most likely some people who have
+
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
+ name="dx14-85037">, Oliver
Delise, Christian Mayer, Curt Olson, Tony Peden, Gary R. Van Sickle, Norman Vine, and
+ name="dx14-85038">Christian Mayer, Curt Olson, Tony Peden, Gary R. Van Sickle, Norman Vine, and
others. A more comprehensive list of contributors can be found in Chapter C as well as in
+href="#x14-80000C">C as well as in
the Thanks file provided with the code. Also, the FlightGear Website contains a
+ name="dx14-85044"> contains a
detailed history worth reading of all of the notable development milestones at
-
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
+
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
-
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
+
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
+
The following names the people who did the job (this information was essentially taken
from the file Thanks accompanying the code).
-
A1 Free Sounds ( (techie@mail.ev1.net)
- Granted permission for the flightgear project to use some of the sound effects from their
-site. Homepage under
-
-
Granted permission for the FlightGear project to use some of the sound effects from
+their site. Homepage under
+
Raul Alonzo ( (amil@las.es)
Mr. 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.
Ssystem Homepage can be found at:
-
Jon S. Berndt ( (jsb@hal-pc.org)
Working on a complete C++ rewrite/reimplimentation of the core FDM. Initially he is
+ name="dx14-86010">
. 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:
-
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 ( (pbleisch@acm.org)
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 ( (jjb@kingmont.com)
Provided a big chunk of online space to store USA scenery for FlightGear.
-
Bernie Bright (bbright@c031.aone.net.au)
+ name="dx14-86013"> (bbright@bigpond.net.au)
Many C++ style, usage, and implementation improvements, STL portability and much,
-much more. Currently he is trying to create a BeOS port. Added threading support and a
-threaded tile pager.
-
Bernhard H. Buckel ( (buckel@mail.uni-wuerzburg.de)
Contributed the README.Linux. Contributed several sections to earlier versions of
Installation and Getting Started.
-
Gene Buckle ( (geneb@deltasoft.com)
A lot of work getting FlightGear to compile with the MSVC++ compiler. Numerous
+ name="dx14-86016">++ compiler. Numerous
hints on detailed improvements.
-
Ralph Carmichael ( (ralph@pdas.com)
Support of the project. The Public Domain Aeronautical Software web site at
-
John Check ( (j4strngs@rockfish.net)
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
+excellent Joystick Howto as well as a panel Howto. Moreover, he contributed new
instrument panel configurations. FlightGear page at
-
Dave Cornish ( (dmc@halcyon.com)
- Dave created new cool runway textures.
-
Dave created new cool runway textures plus some of our cloud textures.
+
Oliver Delise((delise@mail.isis.de)
Started a FAQ, Documentation, Public relations. Working on adding some
networking/multi-user code. Founder of the FlightGear MultiPilot Project at
-
Jean-Francois Doue
+ name="dx14-86023">
Vector 2D, 3D, 4D and Matrix 3D and 4D inlined C++ classes. (Based on Graphics
Gems IV, Ed. Paul S. Heckbert)
-
Dave Eberly((eberly@magic-software.com)
Contributed some sphere interpolation code used by Christian Mayer’s weather data
base system. On Dave’s web site there are tons of really useful looking code at
-
Oscar Everitt ( (bigoc@premier.net)
Created single engine piston engine sounds as part of an F4U package for FS98. They
+ name="dx14-86027">. They
are pretty cool and Oscar was happy to contribute them to our little project.
-
Bruce Finney ( (bfinney@gte.net)
Contributed patches for MSVC5 compatibility.
-
Melchior Franz (a8603365@unet.univie.ac.at)
+ 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 and and Mark Adler ( (zlib@gzip.org)
Authors of the zlib library. Used for on-the-fly compression and decompression
+ name="dx14-86032">. Used for on-the-fly compression and decompression
routines,
-
Erik Hofman ( (erik.hofman@a1.nl)
- Contributed SGI IRIX support and binaries.
-
Major overhaul and parameterization of the sound module to allow aircraft-specific
+sound configuration at runtime. Contributed SGI IRIX support and binaries.
+
Charlie Hotchkiss ( (clhotch@pacbell.net)
Worked on improving and enhancing the HUD code. Lots of code style tips and code
+ name="dx14-86045">
Richard Kaszeta((bofh@me.umn.edu)
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
+ name="dx14-86050"> by teaching Curt Olson the basics of
Control Theory and helping him code and debug early versions. Curt’s ”Boss” Bob
Hain (bob@me.umn.edu) also contributed to that. Further details available at:
-
Christian Mayer ( (flightgear@christianmayer.de)
Working on multi-lingual conversion tools for fgfs as a demonstration of technology.
+ name="dx14-86059"> 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
+ name="dx14-86060"> subsystem. Donated a hot air balloon to the
project.
-
David Megginson ( (david@megginson.com)
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.
-
Cameron Moore (cameron@unbeatenpath.net)
- FAQ maintainer. Reigning list administrator. Provided man pages.
-
Eric Mitchell (mitchell@mars.ark.com)
- Contributed some topnotch scenery textures being all original creations by him.
-
Phil Nelson (phil@cs.wwu.edu)
- Author of GNU dbm, a set of database routines that use extendible hashing and work
-similar to the standard UNIX dbm routines.
-
Alexei Novikov (anovikov@heron.itep.ru)
- 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 (curt@flightgear.org)
- Primary organization of the project.
+ name="dx14-86063">
+code, playing better with OpenGL, with new features. Developed the property
+manager and contributed to joystick support. Random ground cover objects
+
Cameron Moore (cameron@unbeatenpath.net)
+ FAQ maintainer. Reigning list administrator. Provided man pages.
+
Eric Mitchell (mitchell@mars.ark.com)
+ Contributed some topnotch scenery textures being all original creations by him.
+
Anders Morken (amrken@online.no)
+ Former maintainer of European web pages.
+
Phil Nelson (phil@cs.wwu.edu)
+ Author of GNU dbm, a set of database routines that use extendible hashing and work
+similar to the standard UNIX dbm routines.
+
Alexei Novikov (anovikov@heron.itep.ru)
+ 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 (curt@flightgear.org)
+ Primary organization of the project.
First implementation and modifications based on LaRCsim.
+ name="dx14-86072">.
Besides putting together all the pieces provided by others mainly concentrating on the
scenery subsystem as well as the graphics stuff. Homepage at
-
Tony Peden ( (apeden@earthlink.net)
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. His Flight Dynamics page can be found at:
-
Robin Peel ( (robin@cpwd.com)
Maintains worldwide airport and runway database for FlightGear as well as X-Plane.
-
Alex Perry ( (alex.perry@ieee.org)
- Contributed code to more accurately model VSI, DG, Alticude. Suggestions for
+ 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.
-
Petter Reinholdtsen ( (pere@games.no)
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 ( (riley@technologist.com)
Contributed code to add ”brakes”. Also wrote a patch to support a first joystick with
-more than 2 axis.
-
”. 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 ( (andy@plausible.org)
- Contributed a new configurable FDM called YASim (Yet Another Fligth Dynamics
+ Contributed a new configurable FDM called YASim (Yet Another Flight Dynamics
Simulator, based on geometry information rather than aerodynamic coefficients.
-
Paul Schlyter ( (pausch@saaf.se)
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.
-
Jonathan R. Shewchuk (Jonathan_R_Shewchuk@ux4.sp.cs.cmu.edu)
Author of the Triangle program. Triangle is used to calculate the Delauney triangulation
+ name="dx14-86088">
program. Triangle is used to calculate the Delauney triangulation
of our irregular terrain.
-
Gordan Sikic ( (gsikic@public.srce.hr)
Contributed a Cherokee flight model for LaRCsim. Currently is not working and needs to
+ name="dx14-86090"> 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 ( (msmith99@flash.net)
Contributed cockpit graphics, 3-D models, logos, and other images. Project Bonanza
-
Durk Talsma ( (d.talsma@chello.nl)
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
-
UIUC - Department of Aeronautical and Astronautical Engineering
+ name="dx14-86097"> - 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.
-
Mark Vallevand (Mark.Vallevand@UNISYS.com)
+ Contributed some METAR parsing code and some win32 screen printing routines.
+
Gary R. Van Sickle (tiberius@braemarinc.com)
+ Contributed some initial GameGLUT support and other fixes. Has done preliminary
+work on a binary file format. Check
+
Mark Vallevand (Mark.Vallevand@UNISYS.com)
- Contributed some METAR parsing code and some win32 screen printing routines.
-
Gary R. Van Sickle (tiberius@braemarinc.com)
- Contributed some initial GameGLUT support and other fixes. Has done some interesting
-preliminary work on a binary file format. Check
-
Norman Vine ( (nhv@yahoo.com)
Provided more numerous URL’s to the ”FlightGear Community”. Many performance
optimizations throughout the code. Many contributions and much advice for the scenery
@@ -926,154 +1008,166 @@ and course routines. Contributed a great circle route autopilot mode based on wg
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 ( (webmaster@sanw.unibe.ch)
Contributed great photorealistic textures. Founder of European Scenery Project for
X-Plane:
-
Carmelo Volpe ( (carmelo.volpe@mednut.ki.se)
Porting FlightGear to the Metro Works development environment (PC/Mac).
-
development environment (PC/Mac).
+
Darrell Walisser (dwaliss1@purdue.edu)
+ name="dx14-86112"> (walisser@mac.com)
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.
-
Jim Wilson (jimw@kelcomaine.com).
+ 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 ( (jcw@equi4.com)
Author of MetaKit - a portable, embeddible database with a portable data file format
+ name="dx14-86116"> - a portable, embeddible database with a portable data file format
used in FlightGear. Please see the following URL for more info:
-
While FlightGear no longer uses Woodsoup servies we appreciate the support
-provied 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.
-
Robert Allan Zeh ( (raz@cmg.FCNBD.COM)
Helped tremendously in figuring out the Cygnus Win32 compiler and how to link with
+ name="dx14-86119"> Win32 compiler and how to link with
.dll’s. Without him the first run-able Win32 version of FlightGear would have been
impossible.
If you read (and, maybe, followed) this guide up to this point you may probably agree:
+href="getstart.html#QQ2-14-87" name="x14-87000C.3">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,
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, streets, and more of those things bringing scenery to real
-life and belonging to realistic airports. 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, s, 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
+ name="dx14-87003"> until
now.
-
There are already people working in all of these directions. If you’re a programmer
+
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
+href="#x14-88000C.3" name="x14-88000C.3">Achnowledgements 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
+
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
+
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
+
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
+
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
+
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
+
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,
+
Further contributions and donations on special points came from John Check,
(general layout), Oliver Delise (several suggestions including notes on that chapter),
+ name="dx14-88008">(several suggestions including notes on that chapter),
Mohit Garg (OpenGL), Kyler B. Laird (corrections), Alex Perry (OpenGL), and Kai
-Troester (compile problems).
-
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 Getting Started (in random order): Cameron Moore,
-Melchior Franz, David Megginson, Jon Berndt, Alex Perry, Andy Ross, Erik
-Hofman.
+ name="dx14-88009">(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 Getting Started (in random order): Cameron Moore, Melchior Franz, David
+Megginson, Jon Berndt, Alex Perry,, Dave Perry,, Andy Ross, Erik Hofman, and Julian
+Foad.
+ name="Q1-14-89">
diff --git a/Docs/InstallGuide/html/getstartch1.html b/Docs/InstallGuide/html/getstartch1.html
index 26f8c4742..fb0a16750 100644
--- a/Docs/InstallGuide/html/getstartch1.html
+++ b/Docs/InstallGuide/html/getstartch1.html
@@ -6,7 +6,7 @@
-
+
Did you ever want to fly a plane yourself, but lacked the money or ability to do so? Are
-you a real pilot looking to improve your skills without having to take off? Do you want to
-try some dangerous maneuvers without risking your life? Or do you just want to have fun
-with a more serious game not killing any people? If any of these questions applies, PC
-flight simulators are just for you.
-
Did you ever want to fly a plane yourself, but lacked the money or ability to
+do so? Are you a real pilot looking to improve your skills without having to
+take off? Do you want to try some dangerous maneuvers without risking your
+life? Or do you just want to have fun with a more serious game without any
+violence? If any of these questions apply to you, PC flight simulators are just for
+you.
+
Why then that effort of spending hundreds or thousands of hours of programming to
-build a free simulator? Obviously there must be good reason to do so:
+usually within the $50 range, buying one of them should not be a serious problem given
+that running any serious PC flight simulator requires PC hardware within the $1500
+range, despite dropping prices.
+
With so many commercially available flight simulators, why would we spend
+thousands of hours of programming and design work to build a free flight simulator?
+Well, there are many reasons, but here are the major ones:
-
All of the commercial programs have a serious drawback: They are made
- by a small group of developers defining their properties - often quite inert
- and not listening too much to the customer. Anyone ever trying to contact
- Microsoft will immediately agree.
-
-
Commercial PC flight simulators usually try to cover a market segment as
- broad as possible. For obvious reason, most of them want to serve the serious
- pilot as well as the beginner and the gamer. The result is a compromise. As
+
All of the commercial simulators have a serious drawback: they are made
+ by a small group of developers defining their properties according to what
+ is important to them and providing limited interfaces to end users. Anyone
+ who has ever tried to contact a commercial developer would agree that
+ getting your voice heard in that environment is a major challenge. In contrast,
FlightGear is free, there is no need for such compromise; it just can be given
- the properties its users want. It defines itself via building.
+class="ptmbi7t---109">FlightGear
is designed by the people and for the people with everything out
+ in the open.
-
Building a flight simulator is a challenge to the art of programming.
- Contributing to that project makes you belong to those being able to
- contribute to serious, ambitious and advanced software projects.
+
Commercial simulators are usually a compromise of features and usability.
+ Most commercial developers want to be able to serve a broad segment of
+ the population, including serious pilots, beginners, and even casual gamers.
+ In reality the result is always a compromise due to deadlines and funding.
+ As FlightGear is free and open, there is no need for such a compromise.
+ We have no publisher breathing down our necks, and we’re all volunteers
+ that make our own deadlines. We are also at liberty to support markets that
+ no commercial developer would consider viable, like the scientific research
+ community.
-
It is fun. Not only is it fun to write the code (. . . or documentation. . . ) but
- also to belong to that - temporarily changing - club of clever people on the
- net having discussed, struggled and finally succeeded in creating that project.
- Even reading the FlightGear mailing lists is informative and fun for itself.
-
The above-mentioned points make FlightGear superior to its competitors in several
-respect. FlightGear aims to be a civilian, multi-platform, open, user-supported,
-user-extensible platform.
+
Due to their closed-source nature, commercial simulators keep developers
+ with excellent ideas and skills from contributing to the products. With
+ FlightGear, developers of all skill levels and ideas have the potential to make
+ a huge impact on the project. Contributing to a project as large and complex
+ as FlightGear is very rewarding and provides the developers with a great
+ deal of pride in knowing that we are shaping the future of a great simulator.
+
+
Beyond everything else, it’s just plain fun! I suppose you could compare us
+ to real pilots that build kit-planes or scratch-builts. Sure, we can go out a
+ buy a pre-built aircraft, but there’s just something special about building one
+ yourself.
+
The points mentioned above form the basis of why we created FlightGear. With those
-
-
Fig. 1: FlightGear under UNIX: Bad approach to San Francisco International - by one of
-the authors of this manual. . .
+motivations in mind, we have set out to create a high-quality flight simulator that aims to
+be a civilian, multi-platform, open, user-supported, and user-extensible platform. Let us
+take a closer look at each of these characteristics:
Civilian: The project is primarily aimed at civilian flight simulation. It
+ name="dx5-5007"> The project is primarily aimed at civilian flight simulation. It
should be appropriate for simulating general aviation as well as civilian
- aircraft. It is not a shoot’m-up game. However, in keeping with the open
- concept of development, this naturally does not exclude someone taking the
- code and integrating say weapon systems, for instance.
+ aircraft. Our long-term goal is to have FlightGear FAA-approved as a flight
+ training device. To the disappointment of some users, it is currently not
+ a combat simulator; however, these features are not explicitly excluded.
+ We just have not had a developer that was seriously interested in systems
+ necessary for combat simulation.
Multi-platform: The developers are attempting to keep the code as
+ name="dx5-5008"> The developers are attempting to keep the code as
platform-independent as possible. This is based on their observation that people
interested in flight simulations run quite a variety of computer hardware and
operating systems. The present code supports the following Operating
Systems:
+ name="dx5-5009">:
Linux (any distribution and platform),
+ name="dx5-5010"> (any distribution and platform),
At present, there is no known flight simulator - commercial or free - supporting
+
At present, there is no known flight simulator - commercial or free - supporting
such a broad range of platforms.
Open: The project is not restricted to a static or elite cadre of developers. Anyone
- who feels he or she is able to contribute is most welcome. The code (including
- documentation) is copyrighted under the terms of the GPL (Gnu Public
- License).
-
The GPL is often misunderstood. In simple terms it states that you can copy and
- freely distribute the program(s) so licensed. You can modify them if you like. You
- are even allowed to charge as much money for the distribution of the modified or
- original program as you want. However, you must distribute it complete with the
- entire source code and it must retain the original copyrights. In short:
-
”You can do anything with the software except make it non-free”.
User-supported, user-extensible:Contrary to various commercial simulators
- available, scenery and aircraft format, internal variables, etc. are user
- accessible and documented from the beginning. Even without an explicit
- development documentation (which naturally has to be written at some
- point) this is guaranteed by supplying the source code. It is the goal of the
- developers to build a basic engine to which scenery designers, panel engineers,
- maybe adventure or ATC routine writers, sound artists, and others can (and
+ name="dx5-5016"> The project is not restricted to a static or elite cadre of developers. Anyone
+ who feels they are able to contribute is most welcome. The code (including
- are solicited to) add. It is our hope, that the project will benefit from the
+ documentation) is copyrighted under the terms of the GNU General Public License
+ (GPL).
+
The GPL is often misunderstood. In simple terms it states that you can copy and
+ freely distribute the program(s) so licensed. You can modify them if you like and
+ even charge as much money as want to for the distribution of the modified or
+ original program. However, you must freely provide the entire source code to
+ anyone who wants it, and it must retain the original copyrights. In short:
+
”You can do anything with the software except make it non-free”.
+
The full text of the GPL can be obtained from the FlightGear source code or from
+
User-supported and user-extensible:Unlike most commercial simulators,
+ FlightGear”s scenery and aircraft formats, internal variables, APIs, and everything
+ else are user accessible and documented from the beginning. Even without any
+ explicit development documentation (which naturally has to be written at
+ some point), one can always go to the source code to see how something
+ works. It is the goal of the developers to build a basic engine to which
+ scenery designers, panel engineers, maybe adventure or ATC routine
+ writers, sound artists, and others can build upon. It is our hope that the
+ project, including the developers and end users, will benefit from the
creativity and ideas of the hundreds of talented ”simmers” around the
world.
-
Without doubt, the success of the Linux project initiated by Linus Torvalds inspired
-several of the developers. Not only has it shown that distributed development of even
-highly sophisticated software projects over the Internet is possible.
+
Without doubt, the success of the Linux project, initiated by Linus Torvalds, inspired
+several of the developers. Not only has Linux shown that distributed development of
+highly sophisticated software projects over the Internet is possible, it has also proven that
+such an effort can surpass the level of quality of competing commercial products.
+
+
+
+
+
Fig. 1: FlightGear under UNIX: Bad approach to San Francisco International - by one of
+the authors of this manual. . .
In comparison to other recent flight simulators the system requirements
In comparison to other recent flight simulators, the system requirements for FlightGear
-are not extravagant. A decent PII/400 or something in that range should be sufficient,
-given you have a proper 3-D graphics card. On the other hand, any modern
+are not extravagant. A decent PIII/800, or something in that range, should be
+sufficient given you have a proper 3-D graphics card. Additionally, any modern
UNIX-type workstation with a 3D graphics card will handle
with a 3-D graphics card will handle FlightGear as
well.
-
One important prerequisite for running
One important prerequisite for running FlightGear is a graphics card whose driver
supports OpenGL. If you don’t know what OpenGL is, the overview given at the
-OpenGL web site
-
says it best: ”Since its introduction in 1992, OpenGL has become the industry’s most
+
says it best: “Since its introduction in 1992, OpenGL has become the industry’s most
widely used and supported 2-D and 3-D graphics application programming interface
(API)...”.
-
FlightGear does not run (and will never run) on a graphics board supporting
-Direct3D only. Contrary to openGL, Direct3D is a proprietary interface, being restricted
-to the Windows operating system.
-
You may be able to run
FlightGear does not run (and will never run) on a graphics board which only
+
+
+
+supports Direct3D. Contrary to OpenGL, Direct3D is a proprietary interface, being
+restricted to the Windows operating system.
+
You may be able to run FlightGear on a computer that features a 3-D video card
not supporting hardware accelerated OpenGL - and even on systems without
3-D graphics hardware at all. However, the absence of hardware accelerated
-OpenGL support can force even the fastest machine to its knees. The typical
+OpenGL support can bring even the fastest machine to its knees. The typical
signal for missing hardware acceleration are frame rates below 1 frame per
second.
-
Any more recent 3-D graphics featuring hardware OpenGL will do. For Windows
-video card drivers that support OpenGL, visit the home page of your video card
-manufacturer. You should note, that sometimes OpenGL drivers are provided by the
-manufacturers of the graphics chip instead of by the makers of the board. If you are
-going to buy a graphics card for running FlightGear, one based on a NVIDIA chip (TNT
-X/Geforce X) might be a good choice.
-
-
-
-
To install the executable and basic scenery, you will need around 50 MB of free disk
+
Any modern 3-D graphics featuring OpenGL support will do. For Windows video
+card drivers that support OpenGL, visit the home page of your video card manufacturer.
+You should note that sometimes OpenGL drivers are provided by the manufacturers of
+the graphics chip instead of by the makers of the board. If you are going to buy a
+graphics card for running FlightGear, one based on a NVIDIA chip (TNT X/Geforce X)
+might be a good choice.
+
To install the executable and basic scenery, you will need around 50 MB of free disk
space. In case you want/have to to compile the program yourself you will need additional
-about 500 MB for the source code and for temporary files created during compilation.
-This does not yet include the development environment, which possibly may have to be
-installed under Windows yet, and which amounts to additional around 300 MB,
-depending on the installed packages.
-
For the sound effects any capable sound card should suffice. Based on its flexible
-concept,
. In case you want/have to to compile the program yourself you will need about an
+additional 500 MB for the source code and for temporary files created during
+compilation. This does not include the development environment, which will vary in size
+depending on the operating system and environment being used. Windows users can
+expect to need approximately 300 MB of additional disk space for the development
+environment. Linux and other UNIX machines should have most of the development
+tools already installed, so there is likely to be little additional space needed on those
+platforms.
+
For the sound effects, any capable sound card should suffice. Due to its flexible
+design, FlightGear supports a wide range of joysticks or yokes as well esd rudder
-pedals under Linux as well as under Windows.
-
and yokes as well as rudder pedals
+under Linux and Windows. FlightGear can also provide interfaces to full-motion flight
+chairs.
+
FlightGear is being developed primarily under Linux, a free UNIX clone (together
with lots of GNU utilities) developed cooperatively over the Internet in much the same
@@ -250,80 +275,85 @@ class="ptmbi7t---109">FlightGear
itself. FlightGear also runs and is partly developed under several
flavors of Windows. Building FlightGear is possible on a Macintosh (OSX) and on
-several UNIX/X11 workstations, as well. Given you have a proper compilerFlightGear
is also possible on a Macintosh OSX and
+several different UNIX/X11 workstations. Given you have a proper compiler installed,
FlightGear can be built under all of these platforms. The primary compiler
-for all platforms is the free GNU C++ compiler (the Cygnus compiler under
+class="ptmbi7t---109">FlightGear
can be built under all of these platforms. The primary compiler for all
+platforms is the free GNU C++ compiler (the Cygnus Cygwin compiler under
Win32).
-
If you want to run FlightGear under Mac OS X we suggest a Power PC G3 300 MHz
+
If you want to run FlightGear under Mac OSX we suggest a Power PC G3 300 MHz
or better. As a graphics card we would suggest an ATI Rage 128 based card as a
minimum. Joysticks are supported under Mac OS 9.x only; there is no joystick support
-under Max OSX available (yet).
+under Max OSX at this time.
+
+
+
+href="getstart.html#QQ2-5-7" name="x5-70001.3">Choosing A Version
-
Concerning the FlightGear source code there exist two branches, a stable one and a
+
Concerning the FlightGear source code there exist two branches, a stable branch and a
developmental branch. Even version numbers like 0.6, 0.8, and (someday hopefully) 1.0
refer to stable releases, while odd numbers like 0.7, 0.9, and so on refer to developmental
releases. The policy is to only do bug fixes in the even versions, while new features are
generally added to odd-numbered versions which, after all things have stabilized, will
-become the next stable release with a version number calculated by adding 0.1.
-
To add to the confusion, there usually are several versions of the ”unstable” branch.
+become the next stable release with a version number calculated by adding
+0.1.
+
To add to the confusion, there usually are several versions of the ”unstable” branch.
First, there is a ”latest official release” which the pre-compiled binaries are based on. It is
available from
-
While theses are quite recent, they may still be sometimes a few days back behind
+
While theses are quite recent, they may still be sometimes a few days back behind
development. Thus, if you really want to get the very latest and greatest (and, at
times, buggiest) code, you can use a tool called anonymous cvs available from
-
Unfortunately, the system implemented above does not really work as it should. As a
+
Unfortunately, the system implemented above does not really work as it should. As a
matter of fact, the stable version is usually so much outdated, that it does not at all reflect
-thee stated of development FlightGear has reached. Given that the recent developmental
versions on the other hands may contain bugs (. . . undocumented features), we
recommend using the ”latest official (unstable) release” for the average user. This is the
latest version named at
-
Historically, FlightGear has been based on a flight model it inherited (together with the
Navion airplane) from LaRCsim. As this had several limitations (most important,
many characteristics were hard wired in contrast to using configuration files),
@@ -332,15 +362,12 @@ there were several attempts to develop or include alternative flight modelsFlightGear
supports several different flight models, to be chosen from at
runtime.
-
The most important one is the JSB flight model developed by Jon Berndt. Actually,
+
The most important one is the JSB flight model developed by Jon Berndt. Actually,
the JSB flight model is part of a stand-alone project called JSBSim, having its home at
-
As an interesting alternative, Christian Mayer developed a flight model of a hot air
-balloon. Moreover, Curt Olson integrated a special slew mode called Magic Carpet,
-which helps you to quickly fly from point A to point B.
-
Recently, Andrew Ross contributed another flight model called
As an interesting alternative, Christian Mayer developed a flight model of a hot air
+balloon. Moreover, Curt Olson integrated a special ”UFO” slew mode, which helps you
+to quickly fly from point A to point B.
+
Recently, Andrew Ross contributed another flight model called YASim for Yetanother simulator. At present, it sports another Cessna 172Another Simulator
. At present, it sports another Cessna 172, a Turbo 310, a fairly ggod
+ name="dx5-8010">
, a fairly good
DC-3 model, along with a Boeing 747, Harrier. YASim takes a fundamentally
different approach since it’s based on geometry information rather than aerodynamic
-coefficients. Where JSBSim will be exact for every situation that is known and flight
-tested, but may have odd and/or unrealistic behavior outside normal flight, YASim will
-be sensible and consistent in almost every flight situation, but is likely to differ in
+coefficients. Where JSBSim will be exact for every situation that is known and flight
+tested, but may have odd and/or unrealistic behavior outside normal flight, YASim will be
+sensible and consistent in almost every flight situation, but is likely to differ in
performance numbers.
-
As a further alternative, there is the UIUC flight model, developed by a team from the
-University of Illinois, independently from FlightGear in the beginning (while now using
-it for their simulations). This project aims at studying the simulation of aircraft icing. Its
-home is at
-
The UIUC provides a host of different aircraft including several Cessna C172, a Learjet
-24, a Twin Otter and much more. To get an idea, you may check the folder
-Aircraft-UIUC of the FlightGear path.
-
Please note, that the UIUC models do not have a working gear. So you might
-experience some difficulties when starting from a runway. At least the nose gear will be
-too weak and the airplane will fall on it’s nose. This can be circumvented by pulling the
-stick more than usual for a while.
-
It is even possible to drive FlightGear’s scene display using an external FDM running
+
As a further alternative, there is the UIUC flight model, developed by a team at the
+University of Illinois at Urbana-Champaign. This work was initially geared toward
+modeling aircraft in icing conditions together with a smart icing system to better enable
+pilots to fly safely in an icing encounter. While this research continues, the
+project has expanded to include modeling ”nonlinear” aerodynamics, which
+result in more realism in extreme attitudes, such as stall and high angle of attack
+flight. Two good examples that illustrate this capability are the Airwave Xtreme
+
+
+
+150 hang glider and the 1903 Wright Flyer. For the hang glider, throttle can
+be use to fly to gliding altitude or Ctrl-U can be used to jump up in 1000-ft
+increments. Try your hand at the unstable Wright Flyer and don’t stall the canard!
+Considerable up elevator trim will be required for level flight. In general, the
+aerodynamics are probably very close to the original Wright Flyer as they are
+partly based on experimental data taken on a replica tested recently at the NASA
+Ames Research Center. Also included are two more models, a Beech 99 and
+Marchetti S-211 jet trainer, which are older generation UIUC/FGFS models
+and based on simpler ”linear” aerodynamics. More details of the UIUC flight
+model and a list of aircraft soon to be upgraded can be found on their website at
+
It is even possible to drive FlightGear’s scene display using an external FDM running
on a different computer - although this might not be a setup recommended to people just
getting in touch with FlightGear.
There is little, if any, material in this Guide that is presented here exclusively. You could
+href="getstart.html#QQ2-5-9" name="x5-90001.5">About This Guide
+
There is little, if any, material in this Guide that is presented here exclusively. You could
even say with Montaigne that we ”merely gathered here a big bunch of other men’s
flowers, having furnished nothing of my own but the strip to hold them together”. Most
-(but fortunately not all) of the information can as well be obtained from the FlightGear
-web site located at:
-
-
-
-
Please, keep in mind that there are several mirrors to all FlightGear Web sites, being
-listed on this page. Sometimes it is preferred to download from them than from the
-original place.
-
However, a neatly printed manual is arguably preferable over loosely scattered Readme
-files by some people, and those people may acknowledge the effort.
-
This
Please, keep in mind that there are several mirrors of the FlightGear web sites, all
+of which are linked to from the FlightGear homepage listed above. You may
+prefer to download FlightGear from a mirror closer to you than from the main
+site.
+
This FlightGear Installation and Getting Started manual is intended to be a first step
-towards a more complete FlightGear documentation (with the other parts, hopefully, to
-be written by others). The target audience is the end-user who is not interested in
-the internal workings of OpenGL or in building his or her own scenery, for
-instance. It is our hope, that someday there will be an accompanying . The target audience is the end-user who
+is not interested in the internal workings of OpenGL or in building his or her own
+scenery. It is our hope, that someday there will be an accompanying FlightGearProgrammer’s Guide (which could be based on some of the documentation found at
-
which has a lot of supplementary information to (and, at times, more recent than) the
-present document.
-
We kindly ask you to help me refine this document by submitting corrections,
+
which has a lot of supplementary information that may not be included in this
+manual.
+
We kindly ask you to help us refine this document by submitting corrections,improvements, and more. Any user is invited to contribute descriptions of
+class="ptmb7t---109">improvements, and suggestions. All users is invited to contribute descriptions of
alternative setups (graphics cards, operating systems etc.). We will be more thanInstallation and Getting Started (ofcourse not without giving credit to the authors).
-
While we intend to continuously update this document at least for the foreseeable
-future, supposedly we will not be able to produce a new one for any single release of
-FlightGear. While we are watching the mailing lists, it would help if developers adding
-new functionality would send us a short note.
+
While we intend to continuously update this document, we may not be able to
+produce a new version for every single release of FlightGear. To do so would require
+more manpower that we have now, so please feel free to jump in and help out. We
+hope to produce documentation that measures up to the quality of FlightGear
+itself.
diff --git a/Docs/InstallGuide/html/getstartch2.html b/Docs/InstallGuide/html/getstartch2.html
index 7d7a2f04b..5c4c5a7cb 100644
--- a/Docs/InstallGuide/html/getstartch2.html
+++ b/Docs/InstallGuide/html/getstartch2.html
@@ -6,7 +6,7 @@
-
+
@@ -70,11 +70,11 @@ class="ptmbi7t---109">FlightGear on. Other compilers
The GNU compiler is free in the same sense of the GPL as FlightGear is.
You might want to check Section A, A, Missed approach, if anything fails during
compilation. In case this does not help we recommend sending a note to one of the
mailing lists (for hints on subscription see Chapter C).
+href="getstartap3.html#x14-80000C">C).
There are several Linux distributions on the market, and most of them should work.
Some come even bundled with (often outdated) versions of 2.1Getting a development environment under Windows
+href="getstart.html#QQ2-6-11" name="x6-110002.1">Preparing the development environment under Windows
There is a powerful development environment available for Windows and this
even for free: The Cygnus development tools, resp. FlightGear stuff lives under this directory. In add
select
Default text file type: Unix
-
You are free to install the compiler for all users or just for you.
-
As a final step you should include the binary directory (for instance:
-
In addition, you have the choice to install the compiler for all users or just for
+you.
+
The final window before installation gives you a selection of packages to install. It is
+hard, to provide a minimum selection of packages required for FlightGear and the
+accompanying libraries to install. We have observed the following (non minimum)
+combination to work:
+
+
Admin skip
+
+
Archive install
+
+
Base install
+
+
Database skip
+
+
Devel install
+
+
Doc install
+
+
Editors skip
+
+
Graphics install
+
+
Interpreters install
+
+
Libs install
+
+
+
+
+
Mail skip
+
+
Net skip
+
+
Shells install
+
+
Text install
+
+
Utils install
+
+
Web skip
+
+
XFree86 do not install!
+
Note XFree86 must be not installed for building FlightGear and the accompanying
+libraries. If it is installed you have to deinstall it first. Otherwise FlightGear’s
+configuration scripts will detect the XFree86 OpenGL libraries and link to them, while
+the code is not prepared to do so.
+
As a final step you should include the binary directory (for instance:
+ c:/Cygwin/bin) into your path by adding path=c:\Cygwin\bin in your
control
class="pcrr7t---109">panel
. There you’ll find a button Environment variables, where you can add
the named directory.
-
Now you are done. Fortunately, all this is required only once. At this point you have a
+
Now you are done. Fortunately, all this is required only once. At this point you have a
nearly UNIX-like (command line) development environment. Because of this, the
following steps are nearly identical under Windows and Linux/Unix.
A preliminary remark: For UNIX, make sure you have all necessary OpenGL libraries
-first. Fortunately on all recent Linux distributions (i.e. SuSE-7.1) these are already put on
-the right place. Be sure to install the proper package. Besides the basic X11
-stuff you want to have - SuSE as an example - the following packages: mesa,
-mesa-devel, mesasoft, xf86_glx, xf86glu, xf86glu-devel, mesaglut, mesaglut-devel and
-plib.
-
Also you are expected to have a bunch of tools installed that are usually required to
-compile the Linux kernel. So you may use the Linux kernel source package top
-determine the required dependencies. The following packages might prove to be useful
-when fiddling with the FlightGear sources: automake, autoconf, libtool, bison, flex and
-some more, that are not required to build a Linux kernel.
-
Please compare the release of the Plib library with the one that ships with your Linux
-distribution. It might be the case that FlightGear requires a newer one that is not yet
-provided by your vendor.
-
Under Windows, the required libraries should have been installed with the Cygwin
-installation above.
-
The following steps are identical under Linux/Unix and under Windows with minor
-modifications. Under Windows, just open the Cygwin icon from the Start menu or from
+href="getstart.html#QQ2-6-12" name="x6-120002.2">Preparing the development environment under Windows
+
Linux, like any UNIX, usually comes with a compiler pre-installed. On the other hand,
+you still have to make sure several required libraries being present.
+
First, make sure you have all necessary OpenGL libraries. Fortunately, most of the
+recent Linux distributions (i.e. SuSE-7.3) put these already into the right place. (There
+have been reports, though, that on Slackware you may have to copy the libraries to
+/usr/local/lib and the headers to /usr/local/include by hand after
+building glut-3.7). Be sure to install the proper packages: Besides the basic X11
+stuff you want to have - SuSE as an example - the following packages: mesa,
+mesa-devel, mesasoft, xf86_glx, xf86glu, xf86glu-devel, mesaglut, mesaglut-devel and
+plib.
+
Also you are expected to have a bunch of tools installed that are usually required to
+compile the Linux kernel. So you may use the Linux kernel source package top
+determine the required dependencies. The following packages might prove to be useful
+when fiddling with the FlightGear sources: automake, autoconf, libtool, bison, flex and
+some more, that are not required to build a Linux kernel.
+
Please compare the release of the Plib library with the one that ships with your
+Linux distribution. It might be the case that FlightGear requires a newer one that is not
+yet provided by your vendor.
+
There are a couple of 3rd party libraries which your Linux or Windows system may or
+may have not installed, i.e. the ZLIB library and the Metakit library. You can
+either check your list of installed packages or just try building SimGear: It
+should exit and spit an error message (observe this!) if one of these libraries is
+missing.
+
If you make this observation, install the missing libraries, which only is required
+once (unless you don’t re-install you development environment).
+
Both libraries come bundled with SimGear, which links to them, bus does not
+automatically install them. For installing either of them, get the most recent file
+SimGear-X.X.X.tar.gz from
+
The following steps are identical under Linux/Unix and under Windows with minor
+modifications. Under Windows, just open the Cygwin icon from the Start menu or from
the desktop to get a command line.
-
To begin with, the
To begin with, the FlightGear build process is based on four packages which you
need to built and installed in this order:
@@ -195,176 +353,204 @@ need to built and installed in this order:
SimGear
-
FlightGear Program
+
FlightGear, program
-
FlightGear base (data - no compilation required)
+
FlightGear, base (data - no compilation required)
+
+
+
First, choose an install directory for FlightGear. This will not be the one your
+ name="x6-16002x1">First, choose an install directory for FlightGear. This will not be the one your
binaries will live in but the one for your source code and compilation files.
We suggest
-
cd:/usr/local/
-
mkdir source
Now, you have to install a support library Now, you have to install a support library PLIB which is absolutely essential
+ name="dx6-16006"> which is absolutely essential
for the building process. PLIB contains most of the basic graphics rendering,
audio, and joystick routines. Download the latest stable version of PLIB
+ name="dx6-16007">
from
-
to /usr/local/source. Change to that directory and unpack PLIB
using
-
tar xvfz plib-X.X.X.tar.gz.
-
cd into plib-X.X.X and run
-
./configure make make install.
-
Under Linux, you have to become root for being able to
Under Linux, you have to become root for being able to make install,
for instance via the su command.
-
-
-
-
Confirm you now have PLIB’s header files (as ssg.h etc.) under
-
Confirm you now have PLIB’s header files (as ssg.h etc.) under
+ /usr/include/plib (and nowhere else).
Next, you have to install another library Next, you have to install another library SimGear containing the basic
+ name="dx6-16011"> containing the basic
simulation routines. Get the most recent file SimGear-X.X.X.tar.gz
+ name="dx6-16012">
from
-
Download it to /usr/local/source. Change to that directory and
unpack SimGear using
-
tar xvfz SimGear-X.X.X.tar.gz.
-
cd into SimGear-X.X.X and run
-
./configure make make install
-
Again, under Linux, you have to become root for being able to
Again, under Linux, you have to become root for being able to makeinstall, for instance via the su command.
Now, you’re prepared to
- build FlightGear itself, finally. Get Now, you’re prepared to build FlightGear itself, finally. Get
+ FlightGear-X.X.X.tar.gz from
-
and download it to /usr/local/source. Unpack FlightGear using
-
tar xvfz FlightGear-X.X.X.tar.gz.
-
cd into FlightGear-X.X.X and run
-
./configure
-
configure knows about numerous options, with the more relevant ones to be
+
configure knows about numerous options, with the more relevant ones to be
specified via switches as
--with-network-olk: Include Oliver Delise’s multi-pilot
networking support,
+ name="dx6-16017">,
+
+
--with-new-environment: Include new experimental
+ environment subsystem,
+
+
--with-weathercm: Use WeatherCM instead of FGEnvironment,
+
+
--with-plib=PREFIX: Specify the prefix path to PLIB,
+
+
--with-metakit=PREFIX: Specify the prefix path to Metakit,
+
+
--with-simgear=PREFIX: Specify the prefix path to SimGear,
+
+
--prefix=/XXX: Install FlightGear in the directory XXX.
--disable-network-olk: Disable Oliver Delise’s multi-pilot
- networking support,
+class="pcrr7t---109">--disable-jsbsim
: Disable JSBSimm FDM (in case of trouble
+ compiling it).
--with-old-weather: Include original/simple weather
- subsystem,
+class="pcrr7t---109">--disable-yasim
: Disable YASim FDM (in case of trouble
+ compiling it).
--with-x: Use the X Window system (Linux only)
-
+class="pcrr7t---109">--disable-larcsim
: Disable LaRCsim FDM (in case of trouble
+ compiling it).
--prefix=/XXX: Install FlightGear in the directory XXX.
-
A good choice would be --disable-uiuc: Disable UIUC FDM (in case of trouble
+ compiling it).
+
A good choice would be --prefix=/usr/local/FlightGear. In this case
FlightGear’s binaries will live under will live under /usr/local/FlightGear/bin. (If you
don’t specify a --prefix the binaries will go into /usr/local/bin while
the base package files are expected under /usr/local/lib/FlightGear.)
-
Assuming
Assuming configure finished successfully, run
-
make make install.
-
Again, under Linux, you have to become root for being able to
Again, under Linux, you have to become root for being able to make install,
for instance via the su command.
-
Note: You can save a significant amount of space by stripping all the debugging
+
Note: You can save a significant amount of space by stripping all the debugging
symbols off the executable. To do this, make a
-
cd /usr/local/FlightGear/bin
-
to the directory in the
to the directory in the install tree where your binaries live and run
-
strip *.
-
This completes building the executable and should result in a file
This completes building the executable and should result in a file fgfs (Unix) or
fgfs.exe (Windows) under /usr/local/FlightGear/bin
-
Mac OS 10.1 with 10.1 developer tools installed.
+
Mac X OS 10.1+ with developer tools installed.
-
500MB disk (conservative estimate, might be a little less).
+
500MB disk (minimum) free disk space.
Fearlessness of command line compiling.
-
This will need a bit more bravery than building under Windows or Linux. First, there are
+
This will need a bit more bravery than building under Windows or Linux. First, there are
less people who tested it under sometimes strange configurations. Second, the
-process as described here itself nees a touch more experience by using CVS
+process as described here itself needs a touch more experience by using CVS
repositories.
-
First, download the development files. They are intended to simplify the build
-process as much as possible:
-
Once you have this extracted, make sure you are using TCSH as your shell, since the
+setup script requires it.
+
Important for Jaguar users:
+
If you run Mac OS X 10.2 or later, gcc 3.1 is the default compiler. However, only
+version 2.95 works with FlightGear as of this writing. To change the default compiler,
+run this command (as root). You’ll only have to do this once and it will have a global
+effect on the system.
+
sudo gccselect 2
Setup the build environment:
+ name="x6-17002x1">Setup the build environment:
cd fgdev source bin/prepare.csh
Install automake/aclocal build tools
+ name="x6-17004x2">Install the latest versions of the automake and autoconf build tools:
cd $BUILDDIR/src/automake-1.4-p4
+class="pcrr7t---109">cd $BUILDDIR/src/automake-X.X.X
./configure --prefix=$BUILDDIR
- make install rehash
-
-
Build PLIB
- cd $BUILDDIR/src/plib-1.4.2
- aclocal
- automake
- ./configure --prefix=$BUILDDIR --with-GL=$BUILDDIR
- make install
+ make install
+ rehash
+
cd $BUILDDIR/src/autoconf-X.XX
+ ./configure --prefix=$BUILDDIR
+ make install
+ rehash
Get the SimGear sources
+ name="x6-17006x3">Download PLIB
+ cd $BUILDDIR/src
+ setenv CVSROOT :pserver:anonymous@cvs.plib.sf.net:
+ /cvsroot/plib (one line!)
+ cvs login
+ Press <enter> for password
+ cvs -z3 checkout plib
+
+
Build PLIB
+ cd $BUILDDIR/src/plib
+ ./autogen.sh
+ ./configure --prefix=$BUILDDIR
+ make install
+
+
Get the SimGear sources
cd $BUILDDIR/src setenv CVSROOT :pserver:cvs@cvs.simgear.org:
class="pcrr7t---109">/var/cvs/SimGear-0.0
(one line)
cvs login
- # Enter ”guest” for password
+ Enter <guest> for password
cvs -z3 checkout SimGear
Build Metakit
+ name="x6-17012x6">Build Metakit
cd $BUILDDIR/src/SimGear
+class="pcrr7t---109">cd $BUILDDIR/src/SimGear/src-libs
tar -zxvf metakit-X.X.X.tar.gz
+class="pcrr7t---109">tar -zxvf metakit-X.X.X-32.tar.gz
cd metakit-X.X.X/builds ../unix/configure --prefix=&BUILDDIR make
+class="pcrr7t---109">--enable-static --disable-dynamic
Get the FlightGear sources Get the FlightGear sources
+ cd $BUILDDIR/src setenv CVSROOT :pserver:cvs@cvs.flightgear.org: /var/cvs/FlightGear-0.7 (one line!)
+class="pcrr7t---109">/var/cvs/FlightGear-0.X (one line!)
cvs login
- #enter ”guest” for password
+ Enter <guest> for password
cvs -z3 checkout FlightGear
Get the base data files (if you don’t have them already)
+ name="x6-17020x10">Get the base data files (if you don’t have them already)
cd $BUILDDIR setenv CVSROOT :pserver:cvsguest@rockfish.net:
class="pcrr7t---109">/home/cvsroot
(one line)
cvs login
- #password is ”cvsguest”
+ Password is ”cvsguest”
cvs -z3 checkout fgfsbase
Move data files (if you have them already)
+ name="x6-17022x11">Move data files (if you have them already)
just make a symlink or copy data files to ”fgfsbase” in $BUILDDIR
+ alternatively adjust --fg-root=xxx parameter appropriately
+
+
+
Run FlightGear
+ name="x6-17024x12">Run FlightGear
cd $BUILDDIR src/FlightGear/src/Main/fgfs
Compiling on other UNIX systems - at least on IRIX and on Solaris, is pretty similar to
the procedure on Linux - given the presence of a working GNU C compiler. Especially
IRIX and also recent releases of Solaris come with the basic OpenGL libraries.
+ name="dx6-18004">
Unfortunately the ”glut” libraries are mostly missing and have to be installed separately
(see the introductory remark to this chapter). As compilation of the ”glut” sources is not
a trivial task to everyone, you might want to use a pre-built binary. Everything you need
@@ -547,103 +788,104 @@ usable is to place them into /usr/lib/ and /usr/include/GL/. In case you insist
on building the library yourself, you might want to have a look at FreeGLUT
-
Please note that you do not want to create 64 bit binaries in IRIX with GCC (even if your
+CPU is a R10/12/14k) because GCC produces a broken ”fgfs” binary (in case the
+compiler doesn’t stop with ”internal compiler error”). Things might look better if Eric
+Hofman manages to tweak the FlightGear sources for proper compiling with MIPSPro
+compiler (it’s already mostly done).
+
There should be a workplace for Microsoft Visual C++ (MSVC6) included in the
+official FlightGear distribution. Macintosh users find the required CodeWarrior files as a
+.bin archive at
+
Please note that you do not want to create 64 bit binaries in IRIX with GCC (even if your
-CPU is a R10/12/14k) because GCC produces a broken ”fgfs” binary (in case the
-compiler does’nt stop with ”internal compiler error”). Things might look better if Eric
-Hofman manages to tweak the FlightGear sources for proper compiling with MIPSPro
-compiler (it’s already mostly done).
-
There should be a workplace for Microsoft Visual C++ (MSVC6) included in the
-official FlightGear distribution. Macintosh users find the required CodeWarrior files as a
-.bin archive at
-
If you succeeded in performing the steps named above, you will have a directory holding
+
If you succeeded in performing the steps named above, you will have a directory holding
the executables for FlightGear. This is not yet sufficient for performing FlightGear,
though. Besides those, you will need a collection of support data files (scenery,
aircraft, sound) collected in the so-called base package. In case you compiled
the latest official release, the accompanying base package is available from
-
This package is usually quite large (around 25 MB), but must be installed for
+
This package is usually quite large (around 25 MB), but must be installed for
FlightGear to run. There is no compilation required for it. Just download it to
/usr/local and install it with
-
tar xvfz fgfs-base-X.X.X.tar.gz.
-
Now you should find all the
Now you should find all the FlightGear files under /usr/local/Flightgear in the
following directory structure::
-
as well. But be prepared: These are for development and may (and often do) contain
+
as well. But be prepared: These are for development and may (and often do) contain
bugs.
-
If you are using these CVS snapshots, the base package named above will usually not
+
If you are using these CVS snapshots, the base package named above will usually not
be in sync with the recent code and you have to download the most recent developer’s
version from
-
You can skip this Section if you built FlightGear along the lines described in the
previous Chapter. If you did not and you’re jumping in here, your first step will consist in
installing the binaries. At present, there are pre-compiled binaries available
+ name="dx7-21001">
+href="getstart.html#QQ2-7-23" name="x7-230003.2">Installing the binary distribution on a Macintosh system
+ name="dx7-23001">
If your Macintosh is running the conventional Mac OS 9 or earlier, there are versions up
+ name="dx7-23002"> is running the conventional Mac OS 9 or earlier, there are versions up
to FlightGear 0.7.6 available being provided courtesy Darrell Walisser). Download the
+ name="dx7-23004">. Download the
file FlightGear_Installer_0.X.X.sit from the corresponding subdirectory
under
-
This file contains the program as well as the required base package files (scenery etc.).
+
This file contains the program as well as the required base package files (scenery etc.).
For unpacking, use Stuffit Expander 5.0 or later.
-
The latest build available for Mac OS 9.x is 0.7.6, located in the same place.
+ name="dx7-23005">
or later.
+
The latest build available for Mac OS 9.x is 0.7.6, located in the same place.
The base package is part of the download for Mac OS 9.x, but not for Mac
OSX.
-
Alternatively, if you are running Mac OS X, download
Alternatively, if you are running Mac OS X, download fgfs-0.X.X.gz from the
same site named above. The Mac OS X builds are in a gzip file in the same
-directory. There is a readme file in the directory to help people identify what to
+directory. There is a Readme file in the directory to help people identify what to
download.
-
Mac OS X requires that you first download the base package. Then extract it
+
Mac OS X requires that you first download the base package. Then extract it
with
-
tar -zxvf fgfs-base-X.X.X.tar.gz gunzip fgfs-X.X.X.-date.gz
-
Note that there is no
Note that there is no runfgfs script for Mac OS X yet.
Like any Debian package, this can be installed via
-
Like any Debian package, this can be installed via
+
dpkg --install flightgear_0.7.6-6_i386.deb.
-
After installation, you will find the directory
After installation, you will find the directory /usr/local/Flightgear containing
the script runfgfs to start the program.
@@ -128,54 +128,73 @@ class="pcrr7t---109">runfgfs
There is a complete set of scenery files worldwide available created by Curt Olson which
-can be downloaded via a clickable map at
-
+
There are two complete sets of scenery files with worldwide coverage available, now,
+being based on different source data. One data set was created by Curt Olson and can be
+downloaded via a clickable map from
+
Moreover, Curt provides the complete set of US Scenery on CD-ROM for those who
+
Moreover, Curt provides the complete set of US Scenery on CD-ROM for those who
really would like to fly over all of the USA. For more detail, check the remarks on the
downloads page above.
-
For installing these files, you have to unpack them under /Flightgear/Scenery.
-Do not de-compress the numbered scenery files like 958402.gz! This will be done by
+
An alternative data set was produced by William Riley and is available from
+
While the first data set is based on the USGS data, the second one is based on the
+so-called VMap0 data set. While there may be more differences to discover, the first
+one has much better coast lines, while the latter sports world-wide coverage of
+streets, rivers, lakes, and more. Scenery provided in the base package is based
+on the second data set (though covering a small area around San Francisco,
+only).
+
Installation of both data sets is identical. You have to unpack them under
/Flightgear/Scenery. Do not de-compress the numbered scenery files like
+958402.gz! This will be done by FlightGear on the fly.
-
As an example, consider installation of the scenery package w120n30 containing the
+
As an example, consider installation of the scenery package w120n30 containing the
Grand Canyon Scenery.
-
After having installed the base package, you should have ended up with the following
+
+
+
+
After having installed the base package, you should have ended up with the following
directory structure:
-
with the directories w122n37 and w123n37m, resp. containing numerous *.gz files.
+
with the directories w122n37 and w123n37m, resp. containing numerous *.gz files.
Installation of the Grand Canyon scenery adds to this the directories
-
You can exploit the --fg-scenery=path command line option, if you want to
+install different scenery sets in parallel or want to have scenery sitting in another
+place.
Most of the packages named above include the complete
+
Most of the packages named above include the complete FlightGear documentation
including a .pdf version of this Installation and Getting Started Guide intended for pretty
printing using Adobe’s Acrobat Reader being available from
-
Moreover, if properly installed, the .html version can be accessed via
Moreover, if properly installed, the .html version can be accessed via FlightGear’s help
menu entry.
-
Besides, the source code contains a directory
Besides, the source code contains a directory docs-mini containing numerous
ideas on and solutions to special problems. This is also a good place for further
reading.
diff --git a/Docs/InstallGuide/html/getstartch4.html b/Docs/InstallGuide/html/getstartch4.html
index 6affaf6d1..1aebf5f51 100644
--- a/Docs/InstallGuide/html/getstartch4.html
+++ b/Docs/InstallGuide/html/getstartch4.html
@@ -6,7 +6,7 @@
-
+
+href="getstart.html#QQ2-9-30" name="x9-300004.1">Launching the simulator under Unix/Linux
+ name="dx9-30001">
+ name="dx9-30002">
Under Linux (or any other flavor of Unix), FlightGear will be invoked by
runfgfs --option1 --option2...,
where the options will be described in Section 4.4 below.
+href="#x9-330004.4">4.4 below.
If something strange happens while using this shell script, if you want to do some
debugging (i.e. using ”strace”) or if you just feel nice to be ”keen”, then you can start
FlightGear directly by executing the ”fgfs” binary. In this case you should at least add
one variable to your environment, which is needed to locate the (mostly) shared library
+ name="dx9-30003"> which is needed to locate the (mostly) shared library
built from the sources of the SimGear package. Please add the respective directory to
your
Besides this (used by the dynamic linker) ”fgfs” knows about the following environment
-variable
+variable:
FG_ROOT: root directory for the FlightGear base package; this corresponds to the
-FG_ROOT
: root directory for the FlightGear base package,
+
which corresponds to the --fg-root=path option as described in Sec. 4.4.1
+href="#x9-340004.4.1">4.4.1
+href="getstart.html#QQ2-9-31" name="x9-310004.2">Launching the simulator under Windows
+ name="dx9-31001">
-
Before starting the simulator, you may want to adapt the file webrun.bat situated in
-the main FlightGear directory. Open the file with an editor
-
In Windows explorer, change to the directory /FlightGear and double-click
+ name="dx9-31002">
+
For launching FlightGear from Windows explorer, change to the directory
runfgfs.bat.
+class="pcrr7t---109">/FlightGear
and double-click the file runfgfs.bat. You can also pass command
+line options from Sec. 4 to the batch file (if running it form a Command shell).
+However, you have to enclose them in double quotes in this case as follows:
+
Fig. 3: Ready for takeoff. Waiting at the default startup position at San Francisco Itl.,KSFO.
-
Alternatively, if for one or the other reason the batch file does not work or is missing,
-you can open an MS-DOS shell, change to the directory where your binary resides
-(typically something like c:/FlightGear/bin where you might have to substitute
-
Alternatively, if for one or the other reason the batch file above does not work or is
+missing, you can open a command shell, change to the directory where your binary
+resides (typically something like c:/FlightGear/bin where you might have to
+substitute c: in favor of your FlightGear directory), set the environment variable via (note the
-backslashes!)
-
via
+(note the backslashes!)
+
SET FG_ROOT=c:\FlightGear\bin
-
and invoke FlightGear (within the same MS-DOS shell, as environment settings are only
-valid locally within the same shell) via
-
\
+
and invoke FlightGear (within the same Command shell, as environment settings are
+only valid locally within the same shell) via
+
fgfs --option1 --option2....
-
Of course, you can create your own
Of course, you can create your own runfgfs.bat with Windows Editor using
the two lines above.
-
For getting maximum performance it is recommended to minimize (iconize) the text
+
For getting maximum performance it is recommended to minimize (iconize) the text
output window while running FlightGear.
+href="getstart.html#QQ2-9-33" name="x9-330004.4">Command line parameters
-
Following is a list and short description of the numerous command line options available
-for
+
Following is a complete list and short description of the numerous command line options
+available for FlightGear. If you are running FlightGear under Windows you can include these into
- you can include
+these into runfgfs.bat.
-
However, in case of options you want to re-use continually (like joystick settings)
-it is recommended to include them into a file called
However, in case of options you want to re-use continually it is recommended to
+include them into a file called .fgfsrc under Unix
-systems and under Unix systems and system.fgfsrc, resp. under Windows. This file has to be in
-the top FlightGear directory (for instance /usr/local/Flightgear). As it depends
-on your preferences, it is not delivered with FlightGear, but can be created
-with any text editor (notepad, emacs, vi, if you like). Examples for such a file
-(including a detailed description on the configuration of joysticks) can be found at
-
http://rockfish.net/shell/aboutjoy.txt.
+ name="dx9-33005">
+resp. under Windows. This file has to be in the top FlightGear directory (for instance
+/usr/local/Flightgear). As it depends on your preferences, it is not delivered with
+FlightGear, but can be created with any text editor (notepad, emacs, vi, if you
+like).
--help, -h: Gives a small help text, kind of a short version of this Section.
+class="pcrr7t---109">--help
: Shows the most relevant command line options only.
+
+
--help -verbose: Shows all command line options.
--fg-root=path: Tells FlightGear where to look for its data files if you
- didn’t compile it with the default settings.
+class="ptmbi7t---109">FlightGear
where to look for its root data files if
+ you didn’t compile it with the default settings.
+
--fg-scenery=path: Allows specification of a path to the base scenery
-
--fg-scenery=path: Allows specification of a path to the scenery
- directorypath , in case scenery is not at the default position under
+ path , in case scenery is not at the default position under
/Flightgear/Scenery; this might be especially useful in case you
- have scenery on a CD-ROM.
+class="pcrr7t---109">$FG
ROOT/Scenery; this might be especially useful in case you have
+ scenery on a CD-ROM.
--disable-game-mode: Disables full screen display.
+ name="dx9-34004">.
--enable-game-mode: Enables full screen display.
@@ -225,51 +229,59 @@ class="pcrr7t---109">--enable-intro-music
--enable-mouse-pointer: Enables mouse interface. Useful in full
- screen mode for old Voodoo/VoodooII based cards.
+class="pcrr7t---109">--enable-mouse-pointer
: Enables extra mouse pointer. Useful in
+ full screen mode for old Voodoo based cards.
+
+
--enable-random-objects: Include random scenery objects
+ (buildings/trees). This is the default.
+
+
--disable-random-objects: Exclude random scenery objects
+ (buildings/trees).
--disable-freeze: This will put you into FlightGear with the engine
running, ready for Take-Off.
+
+
+
--enable-freeze: Starts FlightGear in frozen state.
+ name="dx9-34007">.
--disable-fuel-freeze: Fuel is consumed normally.
-
-
-
--enable-fuel-freeze: Fuel tank quantity is forced to remain
constant.
--disable-tod-freeze: Time of day advances normally.
+class="pcrr7t---109">--disable-clock-freeze
: Time of day advances normally.
--enable-tod-freeze: Do not advance time of day.
+class="pcrr7t---109">--enable-clock-freeze
: Do not advance time of day.
--control-mode: Specify your control device (joystick, keyboard,
+ name="dx9-34008"> (joystick, keyboard,
mouse) Defaults to joystick (yoke).
+ name="dx9-34010"> (yoke).
--disable-auto-coordination: Switches auto coordination
+ name="dx9-34012">
between aileron/rudder off (default).
--prop:/consumables/fuels/tank[0]/level-gal=10 --prop:/consumables/fuels/tank[1]/level-gal=10 filles the Cessna for a short flight.
+
+
+
--config=path: Load additional properties from the given path.
@@ -313,30 +328,27 @@ class="pcrr7t---109">runfgfs --config=./Aircraft/X15-set.xml
--aircraft=name of
definition file Example: --aircraft=c310. For possible choices check
+
+
+
the directory /FlightGear/Aircraft. Do not include the extension
''-set.xml'' into the aircraft name but use the remaining beginning of
the respective file names for choosing an aircraft. This way flight model,
- panel etc. are all loaded in a consistent way.
+ panel etc. are all loaded in a consistent way. For a full list, see Sec. 4.6 below.
--show-aircraft: Print a list of the currently available aircraft types.
--fdm=abcd Select the core flight model. Options are . Options are jsb, larcsim,
-
-
-
yasim, magic, balloon, external, ada,null. Default value is jsb (JSBSim). larcsim is the flight model which
+ name="dx9-37003">. larcsim is the flight model which
FlightGear inherited from the LaRCSim simulator. yasim is Any Ross’ Yet
- Another Flight Dynamics Simulator. Magic is a slew mode. Balloon is a hot
- air balloon. External refers to remote control of the simulator. Null selects no
- flight dynamics model at all. The UIUC flight model is not chosen this way
- but via the next option! For further information on flight models cf. Section
- is not chosen this way but via the next option! For further
+ information on flight models cf. Section 1.4 and below.
--aero=abcd Specifies the aircraft model to load. Default is a Cessna c172.
+ name="dx9-37005"> to load. Default is a Cessna c172.
Alternatives available depend on the flight model chosen.
--on-ground: Start up at ground level (default).
--in-air: Start up in the air. Naturally, you have to specify an initial
altitude as below for this to make sense. This is a must for the X15.
+
+
+
--wind=DIR@SPEED: Specify wind coming from the direction DIR (in
- degrees) at speed SPEED (knots).
+ degrees) at speed SPEED (knots). Values may be specified as a range by
+ using a clon separator; e.g. 180:220@10:15
+
--aircraft-dir=path: Aircraft directory relative to the root-path,
- defined via $FG_ROOT or --fg-root.
-
Remark: The difference in the handling of UIUC models has historic reasons. These
-
-
-
-models use the LaRCsim FDM. As this FDM isn’t the default FDM any more you have
-to specify it manually. Also the airplane description needs manual interaction as you
-have to specify the directory by hand where the specific aircraft data resides. So you have
-to use the following for flying the ’TwinOtter’:
-
fgfs --fdm=larcsim --aero=uiuc
-
--aircraft-dir=Aircraft-uiuc/TwinOtter
-
Fortunately work has been done to simplificate this. At least those airplanes can be
-flown easily by using an appropriate ’--aircraft’-string. These are the following:
-
If time permits the remaining aircrafts will be adjusted soon. Please have a
-look at $FG_ROOT/Aircraft-uiuc for the avaliable aircrafts provided
-by the UIUC model collection. Also please read the notes in Section 1.4 on
-UIUC.
+class="pcrr7t---109">--random-wind
+href="getstartli1.html#QQ2-9-38" name="x9-380004.4.5">Initial Position and Orientation
--airport-id=ABCD: If you want to start directly at an airport, enter its
+ name="dx9-38003">, enter its
international code, i.e. KJFK for JFK airport in New York etc. A long/short
+ name="dx9-38004"> i.e. KJFK for JFK airport in New York etc. A long/short
list of the IDs of the airports being implemented can be found in /FlightGear/Airports. You only have to unpack one of the files with gunzip.
Keep in mind, you need the terrain data for the relevant region, though!
+ name="dx9-38005">
--offset-distance=deg: Here you can specify the heading to threshold
--lon=degrees: This is the startup longitude in degrees (west = -).
+ name="dx9-38006"> in degrees (west = -).
--lat=degrees: This is the startup latitude in degrees (south = -).
+ name="dx9-38007"> in degrees (south = -).
-
-
-
--altitude=feet: This is useful if you want to start in free flight in
@@ -516,17 +503,20 @@ class="pcrr7t---109">--units-meters
.
--heading=degrees: Sets the initial heading (yaw angle) in degrees.
+ name="dx9-38008"> (yaw angle) in degrees.
--roll=degrees: Sets the startup roll angle (roll angle) in degrees.
+ name="dx9-38009"> (roll angle) in degrees.
+
+
+
--pitch=degrees: Sets the startup pitch angle (pitch angle) in degrees.
+ name="dx9-38010"> (pitch angle) in degrees.
--uBody=--fdm=jsb).
class="pcrr7t---109">--mach=
num: Allows specifying the initial airspeed as Mach number (only
in connection with --fdm=jsb).
+class="pcrr7t---109">--fdm=jsb
).
+
+
--glideslope=degrees: Allows specifying the flight path angle (can be
+ positive).
+
+
--roc=fpm: Allows specifying the initial climb rate (can be negative).
--fog-disable: To cut down the rendering efforts, distant regions are
vanishing in fog by default. If you disable fogging, you’ll see farther but your
+ name="dx9-39001"> by default. If you disable fogging, you’ll see farther but your
frame rates will drop.
+
+
--fog-fastest: The scenery will not look very nice but frame rate will
+ increase.
-
-
--fog-fastest: The scenery will not look very nice but frame rate will
- increase.
--fog-nicest: This option will give you a fairly realistic view of flying
on a hazy day.
+ name="dx9-39004">
--clouds-asl=xxx: Specify altitude of cloud layer above sea level.
-
-
--fov=xx.x: Sets the field of view in degrees. Default is 55.0.
+class="ptmri7t---109">degrees
: Sets the field of view in degrees. Default is 55.0.
--disable-fullscreen: Disable full screen mode (default).
+ name="dx9-39007"> (default).
--enable-fullscreen: Enable full screen mode.
@@ -617,20 +612,17 @@ class="pcrr7t---109">--shading-smooth
: This is the recommended (and
--disable-skyblend: No fogging or haze, sky will be displayed using
+ name="dx9-39008">, sky will be displayed using
just one color. Fast but ugly!
--enable-skyblend: Fogging/haze is enabled, sky and terrain look
+ name="dx9-39009"> look
realistic. This is the default and recommended setting.
--disable-textures: Terrain details will be disabled. Looks ugly, but
might help if your video board is slow.
-
-
-
--enable-textures: Default and recommended.
@@ -639,7 +631,10 @@ class="pcrr7t---109">--enable-textures
: Default and recommended.
class="pcrr7t---109">--enable-wireframe: If you want to know how the world of
FlightGear looks like internally, try this!
+ name="dx9-39010">
+
+
+
--disable-wireframe: No wireframe. Default.
@@ -652,7 +647,7 @@ class="pcrr7t---109">WWWxHHH
can be 640x480, 800x600, or 1024x768.
+ name="dx9-39011">
--view-offset=xxx: Allows setting the default forward view direct
class="pcrr7t---109">LEFT, RIGHT,
CENTER, or a specific number of degrees. Useful for multi-window display.
+ name="dx9-39012">
--visibility=--visibility-miles=miles: You can specify the initial visibility in
miles here.
--wp=ID[@alt]: Allows specifying a waypoint for the GC autopilot; it is
possible to specify multiple waypoints (i.e. a route) via multiple instances of
this command.
-
-
-
--flight-plan=[file]: This is more comfortable if you have several
waypoints. You can specify a file to read them from.
-
These options are rather geared to the advanced user who knows what he is
+
+
+
+
Note: These options are rather geared to the advanced user who knows what he is
doing.
Could you imagine a pilot in his or her Cessna controlling
-the machine with a keyboard alone? For getting the proper feeling of flight you will
-need a joystick/yoke plus rudder pedals, right? However, the combination of
-numerous types of joysticks, flightsticks, yokes, pedals etc. on the market with the
-several target operating systems, makes joystick support a nontrivial task in
+
Could you imagine a pilot in his or her Cessna controlling the machine with a keyboard
+alone? For getting the proper feeling of flight you will need a joystick/yoke plus rudder
+pedals, right? However, the combination of numerous types of joysticks, flightsticks,
+yokes, pedals etc. on the market with the several target operating systems, makes joystick
+support a nontrivial task in FlightGear.
+
Beginning with version 0.8.0, FlightGear has a reworked integrated joystick support,
+which automatically detects any joystick, yoke, or pedals attached. Just try it! If this does
+work for you, lean back and be happy!
+
Unfortunately, given the several combinations of operating systems supported by
+FlightGear (possibly in foreign languages) and joysticks available, chances are your
+joystick does not work out of the box. Basically, there are two alternative approaches to
+get it going, with the first one being preferred.
+
In order for joystick auto-detection to work, a joystick bindings xml
+file must exist for each joystick. This file describes what axes and buttons are to
+be used to control which functions in FlightGear. The associations between
+functions and axes or buttons are called ”bindings”. This bindings file can have any
+name as long as a corresponding entry exists in the joysticks description file
+
/FlightGear/joysticks.xml
+
which tells FlightGear where to look for all the bindings files. We will look at examples
+later.
+
+
+
+
FlightGear includes several such bindings files for several joystick manufacturers in
+folders named for each manufacturer. For example, if you have a CH Products joystick,
+look in the folder
+
/FlightGear/Input/Joysticks/CH
+
for a file that might work for your joystick. If such a file exists and your joystick is
+working with other applications, then it should work with FlightGear the first time you
+run it. If such a file does not exist, then we will discuss in a later section how to create
+such a file by cutting and pasting bindings from the examples that are included with
FlightGear.
-
All of FlightGear’s joystick (as well as keyboard) properties are written in plain ASCII
-files, thus anyone can adapt them, if necessary. Fortunately, there is a tool available
-now, which takes most of the burden form the average user who, maybe, is
-not that experienced with XML, the language which these files arwe written
-in.
-
For configuring your joystick, open a command shell (command prompt(DOS shell
-under windows, to be found unter Start—All programs—Accessories). Change to the
-directory Verifying your joystick is working Does your computer see your joystick? One way
+to answer this question under Linux is to reboot your system and immediately enter on
+the command line
+
dmesg | grep Joystick
+
which pipes the boot message to grep which then prints every line in the boot message
+that contains the string ”Joystick”. When you do this with a Saitek joystick attached, you
+will see a line similar to this one:
+
input0: USB HID v1.00 Joystick [SAITEK CYBORG 3D USB] on
+usb2:3.0
+ This line tells us that a joystick has identified itself as SAITEK CYBORG 3D USB to
+the operating system. It does not tell us that the joystick driver sees your joystick. If you
+are working under Windows, the method above does not work, but you can still go on
+with the next paragraph.
+
FlightGear ships with a utility
+called jsdemo. It will report the number of joysticks attached to a system, their
+respective ”names”, and their capabilities. Under Linux, you can run jsdemo from the
+folder /FlightGear/bin as follows:
+
$ cd /usr/local/FlightGear/bin
+ $ ./jsdemo
+
Under Windows, open a command shell (StartAll ProgramsAccessories), go to the
+FlightGear binary folder and start the program as follows (given FlightGear is installed
+under c:\Flightgear)
+
+
+
+
cd \FlightGear\bin
+ jsdemo.exe
+
On our system, the first few lines of output are (stop the program with C if it is
+quickly scrolling past your window!) as follows:
+
Joystick test program.
+ Joystick 0: ''CH PRODUCTS CH FLIGHT SIM YOKE USB ''
+ Joystick 1: ''CH PRODUCTS CH PRO PEDALS USB''
+ Joystick 2 not detected
+ Joystick 3 not detected
+ Joystick 4 not detected
+ Joystick 5 not detected
+ Joystick 6 not detected
+ Joystick 7 not detected
+ +--------------------JS.0----------------------+--------------------JS.1----------------------+
+ | Btns Ax:0 Ax:1 Ax:2 Ax:3 Ax:4 Ax:5 Ax:6 | Btns Ax:0 Ax:1 Ax:2 |
+ +----------------------------------------------+----------------------------------------------+
+ | 0000 +0.0 +0.0 +1.0 -1.0 -1.0 +0.0 +0.0 . | 0000 -1.0 -1.0 -1.0 . . . . . |
+
+ First note that jsdemo reports which number is assigned to each joystick recognized
+by the driver. Also, note that the ”name” each joystick reports is also included between
+quotes. We will need the names for each bindings file when we begin writing the binding
+xml files for each joystick.
+
Axis and button numbers can be
+identified using jsdemo as follows. By observing the output of jsdemo while working
+your joystick axes and buttons you can determine what axis and button numbers are
+assigned to each joystick axis and button. It should be noted that numbering generally
+starts with zero.
+
The buttons are handled internally as a binary number in which bit 0 (the least significant
+bit) represents button 0, bit 1 represents button 1, etc., but this number is displayed on the
+screen in hexadecimal notation, so:
+
For Linux users, there is another option for identifying the ”name” and the numbers
+assigned to each axis and button. Most Linux distributions include a very handy program,
+”jstest”. With a CH Product Yoke plugged into the system, the following output lines are
+displayed by jstest:
+
jstest /dev/js3
+ Joystick (CH PRODUCTS CH FLIGHT SIM YOKE USB) has 7 axes and 12 buttons. Driver version is 2.1.0
+ Testing...(interrupt to exit)
+ Axes: 0: 0 1: 0 2: 0 3: 0 4: 0 5: 0 6: 0 Buttons: 0:off 1:off 2:off 3:on 4:off 5:off 6:off 7:off 8:off
+9:off 10:off 11:off
+
+ Note the ”name” between parentheses. This is the name the system associates with
+your joystick.
+
When you move any control, the numbers change after the axis number
+corresponding to that moving control and when you depress any button, the ”off” after
+the button number corresponding to the button pressed changes to ”on”. In this way, you
+can quickly write down the axes numbers and button numbers for each function without
+messing with binary.
+
At this point, you have confirmed that
+the operating system and the joystick driver both recognize your joystick(s). You also
+know of several ways to identify the joystick ”name” your joystick reports to
+the driver and operating system. You will need a written list of what control
+functions you wish to have assigned to which axis and button and the corresponding
+numbers.
+
Make the following table from what you learned from jsdemo or jstest above (pencil
+and paper is fine). Here we assume there are 5 axes including 2 axes associated with the
+hat.
+
+
+
+
Axis
Button
+
elevator = 0
view cycle = 0
+
rudder = 1
all brakes = 1
+
aileron = 2
up trim = 2
+
throttle = 3
down trim = 3
+
leftright hat = 4
extend flaps = 4
+
foreaft hat = 5
retract flaps = 5
+
decrease RPM = 6
+
increase RPM = 7
+
+
We will assume that our hypothetical joystick supplies the ”name” QUICK STICK 3D
+USB to the system and driver. With all the examples included with FlightGear,
+the easiest way to get a so far unsupported joystick to be auto detected, is to
+edit an existing binding xml file. Look at the xml files in the sub-folders of
+/FlightGear/Input/Joysticks/. After evaluating at several of the xml binding
+files supplied with FlightGear, we decide to edit the file
+
This file has all the axes functions above assigned to axes and all the button functions
+above assigned to buttons. This makes our editing almost trivial.
+
Before we begin to edit, we need to choose a name for our bindings xml file, create
+the folder for the QS joysticks, and copy the original xml file into this directory with this
+name.
+
$ cd /usr/local/FlightGear/Input/Joysticks
+ $ mkdir QS
+ $ cd QS
+ $ cp /usr/local/FlightGear/Input/Joysticks/Saitek/
+ Cyborg-Gold-3d-USB.xml QuickStick.xml
+ Here, we obviously have supposed a Linux/UNIX system with FlightGear being
+installed under /usr/local/FlightGear. For a similar procedure under Windows
+with FlightGear being installed under c:FlightGear, open a command shell and
+type
+
c:
+ cd /FlightGear/Input/Joysticks
+ mkdir QS
+ cd QS
+ copy /FlightGear/Input/Joysticks/Saitek/
+ Cyborg-Gold-3d-USB.xml QuickStick.xml
+
+
+
+ Next, open QuickStick.xml with your favorite editor. Before we forget to
+change the joystick name, search for the line containing <name>. You should find the
+line
+
<name>SAITEK CYBORG 3D USB</name>
+
and change it to
+
<name>QUICK STICK 3D USB</name>.
+
This line illustrates a key feature of xml statements. They begin with a <tag> and end
+with a </tag>.
+
You can now compare your table to the comment table at the top of your file copy.
+Note that the comments tell us that the Saitek elevator was assigned to axis 1. Search for
+the string
+
<axis n="2">
+
and change this to
+
<axis n="1">.
+
Next, note that the Saitek rudder was assigned to axis 2. Search for the string
+
<axis n="2">
+
<axis n="1">.
+
Continue comparing your table with the comment table for the Saitek and changing the
+axis numbers and button numbers accordingly. Since QUICKSTICK USB and the Saitek
+have the same number of axes but different number of buttons, you must delete the
+buttons left over. Just remember to double check that you have a closing tag for each
+opening tag or you will get an error using the file.
+
Finally, be good to yourself (and others when you submit your new binding file to a
+FlightGear developers or users archive!), take the time to change the comment table in
+the edited file to match your changed axis and button assignments. The new
+comments should match the table you made from the jsdemo output. Save your
+edits.
+
Before FlightGear can use
+your new xml file, you need to edit the file
+
/FlightGear/joysticks.xml,
+
adding a line that will include your new file if the ”name” you entered between the name
+tags matches the name supplied to the driver by your joystick. Add the following line to
+joysticks.xml.
+
+
+
+
Basically, the procedures described above should
+work for Windows as well. If your joystick/yoke/pedals work out of the box or if you get
+it to work using the methods above, fine. Unfortunately there may be a few
+problems.
+
The first one concerns users of non-US Windows versions. As stated above,
+you can get the name of the joystick from the program jsdemo. If you have a
+non-US version of Windows and the joystick .xml files named above do not
+contain that special name, just add it on top of the appropriate file in the style of
+
<name>Microsoft-PC-Joysticktreiber </name>
+
No new entry in the base joysticks.xml file is required.
+
Unfortunately, there is one more loophole with Windows joystick support. In case
+you have two USB devices attached (for instance a yoke plus pedals), there may be
+cases, where the same driver name is reported twice. In this case, you can get
+at least the yoke to work by assigning it number 0 (out of 0 and 1). For this
+purpose, rotate the yoke (aileron control) and observe the output of jsdemo. If
+figures in the first group of colons (for device 0) change, assignment is correct. If
+figures in the second group of colons (for device 1) change, you have to make
+the yoke the preferred device first. For doing so, enter the Windows ”Control
+panel”, open ”Game controllers” and select the ”Advanced” button. Here you
+can select the yoke as the ”Preferred” device. Afterward you can check that
+assignment by running jsdemo again. The yoke should now control the first group of
+figures.
+
Unfortunately, we did not find a way to get the pedals to work, too, that way. Thus, in
+cases like this one (and others) you may want to try an alternative method of assigning
+joystick controls.
+
Fortunately, there is a tool available now,
+which takes most of the burden from the average user who, maybe, is not that
+experienced with XML, the language which these files are written in.
+
For configuring your joystick using this approach, open a command shell (command
+prompt under windows, to be found under Start—All programs—Accessories). Change
+to the directory /FlightGear/bin via e.g. (modify to your path)
-
cd c:\FlightGear\bin
-
and invoke the tool fgjs via
-
fgjs
-
on a UNIX/Linux machine, or via
-
fgjs.exe
-
on a Windows machine. The program will tell you which joysticks, if any, where
-detected. Now follow the commands given on screen, i.e. move the axis and press the
-buttons as required. Be careful, a minor touch already ”counts” as a movement.
-Check the reports on screen. If you feel something went wrong, just re-start the
-program
-
After you are done with all the axis/switches, the directory above will hold a file
-called fgfsrc.js. If the FlightGear base directory FlighGear does not already
+
and invoke the tool fgjs via
+
./fgjs
+
on a UNIX/Linux machine, or via
+
fgjs
+
on a Windows machine. The program will tell you which joysticks, if any, were
+detected. Now follow the commands given on screen, i.e. move the axis and press the
+buttons as required. Be careful, a minor touch already ”counts” as a movement.
+Check the reports on screen. If you feel something went wrong, just re-start the
+program.
+
After you are done with all the axis and switches, the directory above will hold a file
+called fgfsrc.js. If the FlightGear base directory FlightGear does not already
contain an options file .fgfsrc (under UNIX)/system.fgfsrc (under Windows)
mentioned above, just copy
-
fgfsrc.js into .fgfsrc (UNIX)/system.fgfsrc (Windows)
-
and place it into the directory
and place it into the directory FlightGear base directory FlighGear. In case you
+class="pcrr7t---109">FlightGear
. In case you
already wrote an options file, just open it as well as fgfsrc.js with an editor and copy
the entries from .fgfsrc/system.fgfsrc. One hint: The output
of fgjs is UNIX formatted. As a result, Windows Editor may not display it the proper
-way. I suggest getting an editor being able to handle UNIX files as well. My favorite
-freeware file editor for that purpose, although somewhat dated, is PFE still, to be
-obtained from
-
The the axis/button assignment of fgjs should, at least, get the axis assignments
-right, its output may need some tweaking. There may be axis moving the opposite
-way the should, the dead zones may be too small etc. For instance, I had to
+right, its output may need some tweaking. There may be axes moving the opposite
+way they should, the dead zones may be too small etc. For instance, I had to
change
-
useful to avoid jittering for minor yoke movements
offset
=
offset
=
specifies, if device not centered in its neutral position
factor
=
factor
=
controls sensitivity of that axis; defaults to +1,
with a value of -1 reversing the behavior
-
You should be able to at least get your joystick working along these lines. Concerning all
+
You should be able to at least get your joystick working along these lines. Concerning all
the finer points, for instance, getting the joystick buttons working, John Check has
+ name="dx9-55003"> has
written a very useful README being included in the base package to be found
under FlightGear/Docs/Readme/Joystick.html. In case of any
trouble with your input device, it is highly recommended to have a look into this
document.
+
The following is a Table 1 of all the aircraft presently available for use with FlightGear.
+In the first column, you will find the name of the aircraft, the second one tells the start
+option, the third one names the FDM (flight dynamics management model, see Sec. 1.4),
+and the last column includes some remarks. Here, ”no exterior model” means, that there
+is no aircraft specific external model provided with the base package. As a result, you
+will see the default blue-yellow glider, when you change to the external view. However,
+you can download external views for these models from Wolfram Kuss’ site
+at
+
