FlightGear Configuration Tips
last updated Monday, July 5th, 2010 @ 19:45 UTC

Disabling AI Traffic

Quite a few of the #QNAN errors and other unexpected crashes of FlightGear are related to the AI Traffic Manager -- the system that puts those "extra", non-human controlled aircraft out there in our FlightGear world. Not only do we have to worry about the system's code problems, but the planes themselves -- they're collidable objects, and they're sometimes in the way of where the "live" TGA controller tells us to go!

So, I recommend that you make your life easier, and limit your FG world to "human" traffic, by starting FG with the following properties included. For those using a command line, this is self-explanatory; for those starting from the "Launcher Wizard" AKA "FGRun", you'll want to look on the last page for a button called "Advanced", and then a category called "Properties"; then three times press "New" and type what appears below (leaving out --prop: and starting with the first slash):

... and as a side benefit, without all of those blocks of code generating and placing those AI models, you should pick up a couple extra frames per second as well!

NOTE: if you run the "Bombable" add-on AI scenario in FlightGear, you may have to remove these three properties again when starting with that scenario active. Initial reports are that these properties cause program aborts when trying to start that scenario.

Enabling Flight Data Logging

Mischka in the Atlas Virtual Airlines Forum had this suggestion for creating a flight log, which could be used to more easily resume a broken flight due to a program abort or other technical problem.

Adding the following properties to your command line or FGRun (see the tip on Disabling AI Traffic for help with how to add them):

... and the longitude, latitude, altitude, and heading will be logged once per minute in a file called fg_log.csv. In version 2.0.0 it shows up in the /bin/win32 directory; in older versions it appears somewhere in the /data structure, but a simple search of your FlightGear directory should turn it up.

Thanks, Mischka, for sharing that tip!

Reducing Stutter: Mitigating Frame-Rate Effects

An older tip previously suggested by AndersG in various places in the FlightGear Forums and Wiki recently came to light again, thanks to clrCoda.

When your sim's frame rate drops, this can affect the performance of the autopilot. Since NASAL-driven scripts are affected by frame rates and therefore run more slowly when frame rates are lower, certain autopilot functions that depend on NASAL routines can lose the ability to update and compensate quickly enough when there are temporary drops.

To combat this problem, there is a parameter which the sim uses to cut off the amount of elapsed sim time that can occur in a frame. The default is 1 second -- meaning that at a frame rate of 1, the sim will still run at full speed. Lowering this value to 0.1 means that if the frame rate drops below 10, the sim will actually slow down, so that from one frame to the next, no more than a tenth of a second in simulated movement will have elapsed. The trade-off is that when there are frame-rate dips, your plane will actually slow down -- the sim will, in effect, pause and un-pause itself. However, increased stability during these brief moments is usually worth it.

The property can be found in /data/preferences.xml and should be changed from

... to ...