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:
https://wiki.flightgear.org/Frequently_asked_questions
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.
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 Git version of FlightGear, you may want to subscribe to the [Flightgear-Devel] list. Instructions for subscription can be found at:
https://wiki.flightgear.org/Mailing_lists
It is often the case that someone has already dealt with the issue you are dealing with, so it may be worth your time to search the mailing list archives at:
https://sourceforge.net/mailarchive/forum.php?forum_name=flightgear-devel
https://sourceforge.net/mailarchive/forum.php?forum_name=flightgear-users
You should also consider searching the FlightGear forums for help, instructions and archives at:
There are numerous developers and users reading those lists and forums, 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 consider including in your message when you report a problem:
In order to analyze what happened during the last FlightGear session, the following
command can be used (the ~/.fgfs path corresponds to $FG_HOME on Unix-type systems; it
needs to be adapted on other systems, or you can use option --log-dir to make FlightGear
write the log elsewhere):
less ~/.fgfs/fgfs.log
The default log level is alert; it corresponds to the fgfs option --log-level=alert. If you pass
option --log-level=debug to fgfs, FlightGear will write a lot more messages to its log
file.
Some messages, a priori originating from FlightGear’s dependencies, aren’t written to the log file. One way to capture all messages directly or indirectly coming from FlightGear, is to redirect its standard output and standard error streams:
fgfs --log-level=debug >log.txt 2>&1
One final remark: please avoid posting binaries to these lists or forums! 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.
When FlightGear indicates that it is running with something like 1-fps (frame
per second) or below you typically don’t have working hardware-OpenGL 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 additional OpenGL support drivers besides the “native” windows ones.
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.)
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 system. Lots of people have failed miserably to compile FlightGear just because of an outdated PLIB.
The executable refuses to run.
You may have tried to start the executable directly either by double-clicking fgfs.exe in Windows Explorer or by invoking it within a MS-DOS shell. Double-clicking via Explorer never works (unless you set the environment variable FG_ROOT in autoexec.bat or otherwise). Rather double-click fgrun. For more details, check Chapter 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 unpacking the .tar.gz. If you did, try it in the Cygnus shell with tar -xvzf instead.
FlightGear ignores the command line parameters.
There can be a problem with passing command line options containing a “=” on the command line. Instead create a batch job to include your options and run that instead.
I am unable to build FlightGear under MSVC/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 or MSC DevStudio have a look into:
https://wiki.flightgear.org/Building_using_CMake_-_Windows
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 Cygwin compiler. In case of doubt, start setup.exe anew and download and install the most recent versions of bundles as they possibly may have changed.