Towards better troubleshooting

Note  This place is supposed to keep track of all the ideas that we usually come up with after each release to improve the quality of end-user bug reports. It mostly boils down to showing additional information in the about dialog, or including it in the startup log file created in $FG_HOME, or maybe even making it available in the new crash reporting tool eventually. Most of these are fairly trivial to implement, it just seems that we don't typically have a need for them until someone shows up having a real problem who is not able to build from source...

You may also want to check out the Helping users in the long term

Trivial

These are already available in the property tree, i.e. just requires editing about.xml:

• expose threading mode Not done
• expose renderer mode (classic vs. rembrandt / osgEarth) Not done
• expose availability of Built-in Profiler Not done

Core changes

These will typically require changes on the C++ side, but would still be good to have whenever someone makes a bug report:

• expose scenery version info [1] Not done
• expose all startup arguments (would just be copied to a single property) Not done
• expose complete content of fgfsrc (could be read into the property tree) Not done
• expose cmake/compiler flags Not done
• expose release/debug build info (osg,simgear & fg) Not done
• expose architecture (32bit/64 bit) e.g. via __i386__ and __x86_64__ on Intel or via cmake [2] Not done
• expose amount of physical RAM available Not done
• expose amount of used RAM Not done
• expose degree of swapping Not done
• provide some means to show GLSL errors in a dedicated place, i.e. the loglist ? Not done
• maybe provide an option to attach the startup log file to a flight recorder "tape" so that people can more easily share reproducible flights ?
• keep track of Nasal callbacks running via timers/listeners and maintain a list of origin (FILE/LINE, handle/identifier) so that we can inspect a list of "Nasal processes" [3]
• investigate providing support for Nasal backtraces across timers/listeners as per Philosopher's posting [4]

Runtime stuff

• provide a switch to enable/disable updating of canvas/groups on/off (or placements?), to help with troubleshooting
• Investigate extending Canvas::Element to optionally keep track of memory required for each element (use/sub-class osg::ref_ptr), so that we can provide some runtime info Not done
• Provide a means to list all running Nasal callbacks invoked via timers/listeners[5] Not done
• Extend FGStatsHandler to expose Nasal GC stats via osg::StatsHandler Not done

The built-in osgviewer stats can be extended with custom stats, that works by subclassing osg::StatsHandler, this is already done in $FG_SRC/Viewer/FGEventHandler.?xx The class can be extended to add your own stats via osgViewer::StatsHandler::addUserStatsLine() You can even register totally custom stats via osg::Stats The main suspects in this case are probably 1) scenery, 2) cockpit, 3) Nasal (GC - bottleneck() function in simgear/nasal ) For the Nasal stats, you'll probably want to register them in FGNasalSys::FGNasalSys() by accessing globals->viewer-> That should give you a better idea about what's going on there, and it's been suggested by core developers, too: http://www.mail-archive.com/flightgear- ... 37823.html Another goal is to add more node bits (and a GUI dialog to control them) so various categories of objects can be disabled during the update pass. This will mean the direct hit of, say, AI models vs particles vs random trees can be measured. Of course it won't account for resources (memory, textures) burned by such things, but would still help different people identify slowness on their setups. — Hooray (Sun Feb 23). Re: New Aircraft: the Extra500. (powered by Instant-Cquotes)

• Canvas::Element/Canvas::Group should be extended to gather SGTimeStamp-based stats for each group/element, so that people can better tell what's going on behind the scenes [6] Not done
• use a separate draw mask for cockpit panels (e.g. via a corresponding XML attribute that serves as a marker), so that the impact of heavy cockpits can be better evaluated Not done
• whenever there's an exception while booting, we should try to re-init the sim and increase the log level to provide crashrpt with better info [7]