FlightGear FAQ

Most FlightGear documentation is linked to from http://flightgear.org/Docs/. Definitely check out the FlightGear Installation and Getting Started document available from the aforementioned location.

Also see the FlightGear/docs-mini/ directory in the source distribution for various other helpful documents.

The official download page is http://flightgear.org/Downloads/. Source code is our primary form of distribution, but precompiled binaries are available for Windows and SGI IRIX.

Alternatively, FlightGear is packaged for Linux by SuSE, Debian (sid), and Mandrake (Cooker) and can be directly installed through those distributions.

The FTP server uses standard anonymous login procedures. Login with the username "anonymous" and use your email address as the password. Most FTP clients and web browsers will do this automatically for you.

This generally means that the server is at it's capacity. You should receive a message saying such, but your FTP client may be hiding it from you. Your options are to keep trying until a slot opens up or try connecting to one of our FTP mirrors listed at http://flightgear.org/mirrors.html.

The latest development code is available for everyone through our CVS repository. See http://flightgear.org/cvsResources/ for details.

Otherwise, you can get relatively up-to-date snapshots of the development tree at ftp://flightgear.sourceforge.net/pub/flightgear/Devel/Snapshots/.

SimGear is a library of supporting code. SimGear is only needed if you plan on compiling FlightGear -- it is not needed to run precompiled binaries. For more information see http://www.simgear.org/.

While the base package only comes with scenery for the San Francisco Bay area, you can currently fly just about anywhere in the world. See the "Additional Scenery" section of http://flightgear.org/Downloads/ for more information or go directly to our graphical downloader at http://flightgear.org/Downloads/world-scenery.html.

Also visit our "Places to Fly" section of the website (http://flightgear.org/Places/) for some help navigating to some awesome locations.

While we are working toward building our own 3D models, we have been given permission by several people to convert their models (which where originally intended for use with Microsoft Flight Simulator) to use with FlightGear. See Wolfram's Hangar (http://home.t-online.de/home/Wolfram.Kuss/) for a list of what we currently have available as well as information on how to convert models yourself.

We use the same navaid and airport dataset that X-Plane uses. The current dataset can be found in the $FGROOT/Navaids/ and $FGROOT/Airports/ directories. If you have updates or corrections to the dataset, see http://flightgear.org/Docs/AirNav/AptNavFAQ.FlightGear.html for instructions on contacting the database maintainer.

A popular moving map display is avaliable under a separate project called Atlas. See http://atlas.sf.net/.

We could do that, since the initial download is about 25 megabytes. Especially for people who have to pay per-minute charges for internet access, buying a CD is a convenient and possibly cheaper option. Although we offer that service (see the website), we encourage other groups to redistribute it for their users, especially within an operating system distribution which makes installation even faster and easier for new users.

Well, that depends. First make sure you are using the appropriate versions of FlightGear, SimGear, plib, zlib. If any of the packages are out of sync with the others, compilation may fail.

The FlightGear Downloads page (http://flightgear.org/Downloads/) should tell you what versions you need if you are trying to compile the latest stable release. If you are using a development snapshot, make sure all three packages are up-to-date.

Also ensure that you have some implementation of OpenGL with glut support with the appropriate header files. Linux users with nVidia cards should make sure you have the latest drivers from nVidia. Other Linux users make sure you have Mesa3D (http://mesa3d.org/) and your X server installed correctly. Windows users see http://www.x-plane.com/SYSREQ/v5ibm.html, and Mac users see http://www.x-plane.com/SYSREQ/v5mac.html.

If your problems persist, subscribe to our FlightGear-Users mailing list and let us know what problem you're having. See http://flightgear.org/mail.html for help with this.

Update your gcc packages. See http://redhat.com/errata/ to fix it and http://www.gnu.org/software/gcc/gcc-2.96.html for an explanation why.

The scenery archive files (ie. w100n30.tar.gz) should be untarred into the Scenery/Terrain directory in your $FG_ROOT.

FlightGear should come with a helpful program called `fgjs` that can help configure your joystick. Run `fgjs` and then copy the dot file it created into your home directory or add its contents to your existing rc file.

Also, see the README.Joystick file located in the FlightGear/docs-mini/ directory of the source distribution. This document is mirrored at http://rockfish.net/fg/README.Joystick.

Your .fgfsrc file should simply be a list of command-line options with one option per line. The file is not an XML file.

If you would rather use an XML configuration file, you can add something like the following in your .fgfsrc

--config=/path/to/my/config.xml

Almost every option corresponds to a property, so you can choose to use whichever method best suits your needs.

With the default installation, libopenal.so.0 is installed into /usr/local/lib. You need to ensure that that path is listed in /etc/ld.so.conf, then run `ldconfig`as root.

In short, your GL libraries are broken. So far only Red Hat 7.x users have experienced this (see http://www.redhat.com/bugzilla/show_bug.cgi?id=18867). The only solutions are possibly complicated ones: you can either change distributions (most of us prefer Debian) or upgrade/downgrade your Mesa libs.

Why do some other GL applications work though? Well, Steve Baker (Mr. PLIB) has explained this on the plib-users list (http://www.geocrawler.com/lists/3/SourceForge/1867/0/6470648/).

The problem is almost certainly that your base package is out of sync with FlightGear. Many configurable parts of FlightGear are defined in XML files contained in the base package.

FlightGear (as of June 2001) uses the Portable Libraries (PLIB) for playing audio. The audio queue implementation of PLIB is far from optimal (in fact it's just wrong). This seems to work on other platforms quite well, but Irix expects things to be programmed properly.

There has been discussion about using OpenAL (http://www.openal.org/) for the next release of both PLIB and FlightGear. Tests show that the OpenAL audio implementation does the job right, meaning that these audio problems should be gone by then. In the mean time it is best to disable audio on Irix completely (by adding --disable-sound either on the command line or to your $HOME/.fgfsrc file).

FlightGear supports hardware acceleration, but it seems not to be activated. Make sure you have OpenGL libraries installed and configured properly and make sure you have the latest drivers for your video card.

Linux users: If you are an nVidia user, follow their directions on getting your card working. For most other users, make sure Mesa is installed property and ensure that you have the appropriate kernel device drivers for your card. Most people (and distributions) use modules for their video card device drivers; run `lsmod` as root to see what modules are loaded. You should also make sure that you are loading the appropriate modules in your XF86Config and that your video device section is correct. Now try running an OpenGL application (other than FlightGear) to see how it performs. You can try the gears demo from Mesa or something like Quake3.

First of all, one of the most common mistakes on SGI hardware is to forget to specify --fog-fastest. On most SGI machines the EXP2 shading model isn't hardware supported resulting in frame rates below 1 frame per second (fps).

FlightGear makes extensive use of the OpenGL z-buffer feature,which on most older SGI hardware is only supported in software. This means that the CPU has to do all the z-buffer calculations in addition to the other tasks FlightGear involves (flight dynamics, scenery tracking, pushing commands into the graphics queue, etc). The following features are software rendered on low-end SGI machines (like Indy and Indigo):

stencil and accumulation buffer
depth queuing and depth buffering
fogging, lighting, clipping and transforms
texturing

This means that running FlightGear with the following options may not even get the desired result:

./runfgfs --fog-disable --shading-flat --disable-skyblend \
--disable-textures --disable-clouds --disable-sound \
--disable-panel --enable-hud --disable-anti-alias-hud

I could even imagine that adding --enable-wireframe doesn't work on these machines (I would be happy to be proven wrong though).

On a machine like O2 the following options give an acceptable result:

./runfgfs --fog-fastest --disable-sound

Since I don't have access to other SGI hardware I can't tell which options would be appropriate for your situation.

There are two ways. One way is to hide the panel without the HUD showing. To hide the panel, use Shift+P; To make the HUD disappear, use H. The second way is to use the alternative HUD by Shift+I (Use I to switch back).

In his infinite wisdom the FlightGear Grand Master decided that planes were to valuable to allow them to be destroyed by novice pilots who seemed to crash a lot. The fact that nobody has bothered to model crashes may have something to do with it too. :-)

The result of this as you have noticed is that with a little practice an ingenuity you can trim the ship to fly inverted along the ground.

The quick answer is to hit Ctrl+U (with the default key bindings) to warp the plane up 1000ft.

For the stubborn people out there: The trick to learn is to roll back to normal (non inverted) do this by nursing the elevator to get to about 500 feet or so and use the ailerons to snap roll 180*. This is all good avionics except for the plane not destroying itself. Remember the controls work in reverse when you are inverted and keep that airspeed up!!!

This is probably caused by a line-ending problem in the timezone files. Win32 users can resolve the problem by downloading a DOS to UNIX conversion utility available at http://www.nottingham.ac.uk/~eazdluf/d2u.zip. Run as `d2u *.tab` from within the timezone directory to fix your timezone files.

Mostly C++ with some supporting C code that's primary contained within SimGear.

To define an aircraft for FlightGear's primary FDM (JSBSIM), see http://jsbsim.sf.net/.

If you want a simpler FDM to work with, try your hand at YASim, an alternative FDM. For an guide on creating a YASim aircraft, look in the FlightGear base package for Aircraft-yasim/README.yasim.

You can import the 3D model and textures, but the flight dynamics (the .AIR file) must be completely redone for FlightGear. See http://home.t-online.de/home/Wolfram.Kuss/ for help importing .MDL files and textures.

If you wish to import a model made with gmax, you will need to convert it to .MDL format using Microsoft's MakeMDL SDK which is available at http://zone.msn.com/flightsim/FS02DevDeskSDK08.asp.

See http://chiangt.virtualave.net/BGL/bgl_index.html.

See the README.xmlpanel file located in the FlightGear/docs-mini/ directory of the source distribution. This document is mirrored at http://rockfish.net/fg/README.xmlpanel.

First, ensure that you have v0.7.7 or later, the scenery files where you plan to place the object, the actual model, and the longitude and latitude where you plan to place the object.

Now get the altitude for your point. If you don't want to calculate this yourself, start FlightGear at your location and take note of the altitude. Here's an example command:

fgfs --lat=45.50 --lon=-75.73 2>&1 | tee fgfs.log

The altitude is probably in feet, so divide the starting altitude by 3.28.

Search the output log file for the first occurrence of the string "Loading tile" and take note of the filename. In the above example, the output line looks like:

Loading tile /usr/local/Scenery/w080n40/w076n45/1712601

Copy a 3D model in a format that Plib understands to the same directory as the tile file. Edit the text file in that directory consisting of the tile name with the extension ".stg". The file will already exist if there is an airport on the tile; otherwise, you can create it from scratch. In our example, the filename is:

/usr/local/Scenery/w080n40/w076n45/1712601.stg

At the end of the file, add a new entry for your object, consisting of the word "OBJECT_STATIC" followed by the model name, the longitude in degrees, the latitude in degrees, the altitude in meters, and the heading in degrees. In our example the line looks like:

OBJECT_STATIC Towerax.ac -75.73 45.40 60 0

Save the changes to the .stg file, restart FlightGear, and enjoy.

NOTE: The above information was taken from the following mailing list post: http://www.geocrawler.com/archives/3/11854/2001/6/0/5991409/. See that page if this one doesn't make sense.

An alternative approach using PPE is described at http://mail.flightgear.org/pipermail/flightgear-devel/2001-December/002239.html by Norman Vine.

Contributing to the 2D panel doesn't require any coding at all, just a minimal knowledge of XML syntax (i.e. five minutes' worth) and good skills with drawing and/or paint programs. Every instrument on the current panel, with the partial exception of the magnetic compass, is defined entirely in XML with no custom C++ code. If you want to get started, take a look at John Check's excellent intro (http://rockfish.net/fg/README.xmlpanel).

Likewise, if you want to create a 3D cockpit for FlightGear, or to create buildings, external aircraft models, etc., your help is *desperately* needed. The only rule is to go easy on the triangles -- a model with 50,000 triangles probably won't be usable in FlightGear, and one with 5,000 triangles, only marginally. If you can design a nice 3D cockpit interior for a Cessna 172 (for example) in a 3D design program such as ac3D or ppe, we have coders who will be happy to add the support code in the C++.

If, on the other hand, you really want to get your hands dirty with C++ coding, you'll have to buy a good OpenGL book eventually. However, FlightGear uses a high-level library, plib, that hides most of the details of OpenGL. To get started with 3D C++ coding, you can take a look at the plib documentation and learn only as much OpenGL as you need, when you need it.

You can add your airport to the $FGROOT/Airports/default.apt.gz file, but to get the airport to show up visually, you will have to rebuild the scenery around the airport. The format of the default.apt file is documented at http://flightgear.org/Docs/AirNav/AptNavFAQ.FlightGear.html.

Yes, though it can be a difficult task. FlightGear's scenery generation is handled by a sister project, TerraGear. For more details, see http://wiki.flightgear.org/TerraGear.

http://www.navfltsm.addr.com/ is a very good site for learning techniques for navigation. Also see http://www.monmouth.com/~jsd/how/.

There is a bit of info on aileron vs. rudder here: http://www.monmouth.com/~jsd/how/.

We have an initial stab at this that is incomplete and only seems to work under Linux. We'd love to find someone to pick up the slack here and develop this further. Specifically, plib now has some low level networking support for mult-player games. It would also be nice to develop support for the DIS protocol.

No, not at this time. Most of our developers are primarily interested and focused on civilian aviation. We aren't explicitly excluding these features -- we just haven't had anyone who seriously wanted to develop these areas.

This error cropped up after the release of v0.7.6. To fix the problem, add "#include <stdlib.h>" to the top of viewer.cxx.

FlightGear FAQ

Introduction

Table of Contents

1 - The FAQ

2 - Distribution

3 - Compiling

4 - Configuring

5 - Running

6 - Hacking

7 - Flying

8 - FlightGear v0.7.6