Troubleshooting problems
| Troubleshooting |
|---|
This page will try to help you troubleshooting problems with your FlightGear installation, from the diagnosis to a possible solution, and if you can't find such a solution will tell you how you can provide the best information to the people who will try to help you on the forum.
Troubleshooting the old way
- To rule out some of the most common problems, see Frequently asked questions#Problems.
- If FlightGear runs slowly, please see Troubleshooting performance issues and Howto:Use the system monitor.
- If you're having graphics problems, please check the list of Problematic Video Cards and Troubleshooting graphics artifacts.
- If you're getting errors in the console (i.e. the black window), see Howto:Understand console output.
- If FlightGear is crashing, please see Troubleshooting crashes.
- If the whole system is crashing when running FlightGear, please read System Crashes.
- If you have control device issues (keyboard, joystick...) see Troubleshooting input devices.
Check out Hardware Recommendations for more information about video cards and other hardware that has been reported to work with FlightGear.
If all else fails...
Try Requesting Technical Help, but only after trying the other suggestions above!
Possible pitfalls when modifying base package files
At some point, most users will probably want to modify FlightGear in some way or another. Many interesting modifications can be done by editing base package resources, such as for example aircraft files, instrumentation files, GUI files, Nasal scripts etc.
However, once you do modify the base package, it is important to keep track of your changes and to make sure that files are modified properly. Here are some things to watch out for:
- When referencing file names or paths, always make sure that files and paths actually do exist
- When referencing file names or paths, make sure that they're used properly i.e. watch out for whitespaces, separators and case:
- On most modern operating systems, filenames and paths are indeed case sensitive, so make sure to watch out for this, as well
- Also, most modern multi-user operating systems feature support for file permissions, so that files and paths need to have the proper permissions set in order to be accessible
- Once you start editing XML files, you will want to ensure that your edits are valid and don't corrupt the XML syntax, that is make sure that tags are properly closed - if you are not sure whether your edits were properly done or not, you may want to use a so called "xml validator", there are numerous free/open source tools available to help you validating XML documents, under *nix you could for example simply use "xmllint". Invalid XML files cannot be used by FlightGear anymore (there are also various web-based validator available, where you can simply paste contents or upload files to be checked).
- Also, while the majority of FlightGear XML files follows the basic PropertyList format, the various individual FlightGear components support different functionality and features, so tags and attributes that may be available and usable in one type of files such as i.e. GUI files are usually not necessarily also available in files for different subsystems/components, as features are so far being individually implemented for each single component rather than globally. So, even if a certain syntax or feature is supported in a different part of FlightGear, it may simply not yet be available in other ones.
Please note that it is easily possible to corrupt your base package simply by modifying files in the wrong way, so that FlightGear may no longer work without getting a fresh base package, thus you may want to keep your modifications separate from the rest of the base package. Or at least consider using a Source Code Management system such as for example svn or git.
If you do encounter problems getting your modifications to work for you, you may want to run FlightGear with an increased log/warning level, so that you get to see more completely which parts of FlightGear could be successfully completed and which ones failed, this can be achieved by using the --log-level=bulk parameter.