Troubleshooting crashes: Difference between revisions

[[World Scenery]] 2.0 (the one with [[CORINE]] and [[OpenStreetMap]] data) highly raised memory requirements with respect to the previous version. Basically, with 4GB of RAM once you could safely use a visibility of a hundred kilometers; with Scenery 2.0, 4GB is barely enough for 10 km. A 32-bit machine can't use more than that memory, and simply kills FlightGear when it asks for more. To verify this, reduce your visibility (in-sim with ''View > Level of Detail adjustment'' and set ''Bare'' to 8000 m) and see if it stops crashing. You can also check memory consumption with the tools provided by your OS.

Sadly, the solution is keeping a low visibility, or moving to a 64-bit machine with at least 8GB of RAM. If you're feeling "hackish", you can try the solution reported at [[Unexpected Crashes with Scenery ver.2]].

It's just as well possible that the FlightGear default settings are not supported with your hardware/drivers, so that the process will be killed by the OS because it's trying to do something not supported by your computer. If you are experiencing full system crashes, you should see [[System Crashes]] instead.

By default, FlightGear 2.6+ will assume a certain runtime environment and certain GPU features which may not be suppported by most older cards (e.g. shader support), such as GeForce 6/7 generation hardware and most older hardware (older than 4-5 years), so that it can be expected that FG will probably not work on such computers "out of the box" and may get terminated by your operating system eventually, i.e. the default startup settings will need to be customized accordingly, to disable all unsupported default features. See [[Troubleshooting performance issues]], [[Problematic Video Cards]] and [[FlightGear Hardware Recommendations]] for more details.

Also, make sure you've got the newest driver for your video card installed and running without errors. A suggestion for a thorough updating procedure can be found [[Graphics drivers configuration|here]].

Before proceeding any further, please make sure that you are actually able to run other OpenGL-based software/simulators/games, unrelated to FlightGear!

The startup profile detailed below disables tons of features that are known to have a massive impact on frame rate and overall performance by making FG look plain bad and crude, as such, it gives you a rough idea of the maximum performance fgfs is able to achieve on your system - which in turn, allows you then to re-enable individual settings one-by-one, and see their impact on framerate/performance - so that you can determine which settings are particularly problematic - so that you can decide to come up with a custom profile to make the 60-100 fps goal for example - as you can see, on a 2009-era laptop, you could hope for ~790 fps and 3ms of frame spacing when in the "ugly" mode - so by hand-picking my settings and tweaking them as needed, you'll be getting beyond 50 fps, even with 75-85% of eye candy enabled, with fairly moderate GPU hardware

In such cases, it is important to start up FlightGear with minimum settings, and start re-enabling features step by step to see what settings are supported by your hardware. You may want to [[Flightgear debug log|raise the FlightGear log level]], so that you get to see where the program stops starting/working, and what it was doing before it got terminated.

 

 

* The [[Howto:Use the system monitor|built-in system monitor]] (can be inspected via telnet/http using [[Telnet usage|--telnet=5900]])

 

 

=== Performance targets ===

 

Thus, if you are not getting frame rates '''much''' higher than 100 fps with the minimal startup profile (without using frame throttling, i.e. locking the refresh rate at a certain frequency, obviously), then using complex aircraft (777,787) or scenery (KSFO, KLSV etc) will be next to impossible with your system.

 

=== Minimal Startup Profile ===

{{Note|If you find any other settings causing a massive improvement of performance/compatibility, please do feel free to add those below, so that others can benefit from your findings. That's the whole point of keeping this on the wiki, so that everybody can contribute. Eventually, we're hoping to use these findings to come up with a reliable subset of FlightGear that can be used to start up FlightGear in some form of "compatibility mode", that can be assumed to "just work" for the majority of FlightGear setups and users. This is going to be particularly important for efforts like [[FlightGear Headless]], [[FlightGear Benchmark]] and [[FGCanvas]].}}

 

Depending on the hardware specs of the target platform, adjusting the threading mode of FG/OSG may also help: [[Howto:Activate multi core and multi GPU support]].

You can directly use a custom [[Fgfsrc]] file for the following sections or parse the following lines to the console (separated by one empty character) after "FGFS" or set the respective options in [[Fgrun]] or in [[FlightGear configuration via XML|one of FlightGear's XML configuration files]].  

There's a trend to expose more and more information via the property tree, to make the simulator increasinly runtime-configurable, and to allow subsystems to be re-initialized at runtime, so being able to start up FlightGear in some form of "safe" mode is generally a good thing and useful for anybody helping with troubleshooting on the forums, because it helps us exclude many potential problems. In the long run, such a profile could also be used as the foundation for a [[FlightGear Benchmark]] or some scripted regression suite to run FlightGear in a [[FlightGear Headless|headless]] mode to help with release preparations.