Towards better troubleshooting: Difference between revisions
(Fixes for the {{cite web}} template changes - {{forum url}} should have been used instead of {{forum link}}.) |
|||
(One intermediate revision by the same user not shown) | |||
Line 3: | Line 3: | ||
These are some ideas '''towards better troubleshooting''' that we usually come up with after each release to improve the quality of end-user bug reports. 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... 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 [[CrashRpt|new crash reporting tool]] eventually. | These are some ideas '''towards better troubleshooting''' that we usually come up with after each release to improve the quality of end-user bug reports. 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... 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 [[CrashRpt|new crash reporting tool]] eventually. | ||
You may also want to check out this post on the forum: | You may also want to check out this post on the forum: {{forum link|p=203412|title=Re:Helping users in the long term}} | ||
== Background == | == Background == | ||
Line 72: | Line 72: | ||
{{FGCquote | {{FGCquote | ||
|we should absolutely stop telling anyone to edit preferences.xml in FG_ROOT; any documentation or advice which says to should be changes ASAP. | |we should absolutely stop telling anyone to edit preferences.xml in FG_ROOT; any documentation or advice which says to should be changes ASAP. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=192632}} | ||
|title=<nowiki>Re: NavCache:init failed:Sqlite error:Sqlite API abuse</nowiki> | |title=<nowiki>Re: NavCache:init failed:Sqlite error:Sqlite API abuse</nowiki> | ||
|author=<nowiki>zakalawe</nowiki> | |author=<nowiki>zakalawe</nowiki> | ||
Line 81: | Line 81: | ||
{{FGCquote | {{FGCquote | ||
|I'm interested in going through the entire fleet to create a new base level that all aircraft will be flyable. I'm not talking about fixing clunky FDMs or incomplete parts, but really basic maintenance - aircraft which start with tonnes of errors, and especially aircraft that cannot be started. If you had a list or could point out a few, that'd be awesome! I know there is tonnes of information in old forum posts about this, but for me it's quicker just to start each up one by one and test. If you do have a good list, maybe it would be good to start a new topic. | |I'm interested in going through the entire fleet to create a new base level that all aircraft will be flyable. I'm not talking about fixing clunky FDMs or incomplete parts, but really basic maintenance - aircraft which start with tonnes of errors, and especially aircraft that cannot be started. If you had a list or could point out a few, that'd be awesome! I know there is tonnes of information in old forum posts about this, but for me it's quicker just to start each up one by one and test. If you do have a good list, maybe it would be good to start a new topic. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=240500}} | ||
|title=<nowiki>Looking for aircraft with 'paper cut' bugs</nowiki> | |title=<nowiki>Looking for aircraft with 'paper cut' bugs</nowiki> | ||
|author=<nowiki>bugman</nowiki> | |author=<nowiki>bugman</nowiki> | ||
Line 99: | Line 99: | ||
* should show if fgfsrc is available/used | * should show if fgfsrc is available/used | ||
* use intel detection heuristics and adapt those to detect AMD/ATI cards and show a startup warning to inform the user that [[PUI]]/styling may interfere with effects/shaders | * use intel detection heuristics and adapt those to detect AMD/ATI cards and show a startup warning to inform the user that [[PUI]]/styling may interfere with effects/shaders | ||
* we keep seeing people who install mismatching versions of aircraft/fgfs - introduce a version-check property so that -set.xml files can encode version requirements, which are checked by a script in $FG_ROOT/Nasal | * we keep seeing people who install mismatching versions of aircraft/fgfs - introduce a version-check property so that -set.xml files can encode version requirements, which are checked by a script in $FG_ROOT/Nasal {{forum link|p=264788}} | ||
== Better version info == | == Better version info == | ||
Line 143: | Line 143: | ||
* provide a startup option/property to disable aicraft-set.xml Nasal code for troubleshooting purposes | * provide a startup option/property to disable aicraft-set.xml Nasal code for troubleshooting purposes | ||
* log frequency of Nasal callback invocation to the console to detect fdm coupled code ? | * log frequency of Nasal callback invocation to the console to detect fdm coupled code ? | ||
* dump node-specific osg camera stats to the console/log file (or even splash screen) during startup for the scenery/aircraft ROOT nodes | * dump node-specific osg camera stats to the console/log file (or even splash screen) during startup for the scenery/aircraft ROOT nodes {{forum link|p=264214}} | ||
* separate OpenGL/GLSL logging/log file for troubleshooting graphics related startup errors rendering FG useless (e.g. faulty drivers) | * separate OpenGL/GLSL logging/log file for troubleshooting graphics related startup errors rendering FG useless (e.g. faulty drivers) {{forum link|p=243876}} | ||
* case-sensitive path checking | * case-sensitive path checking {{forum link|p=243499}} | ||
* write the current pid (process ID) to the property tree, so that this can be used for debugging purposes (or even just for the suffix of log files) {{Not done}} | * write the current pid (process ID) to the property tree, so that this can be used for debugging purposes (or even just for the suffix of log files) {{Not done}} | ||
* add startup options to override/ignore startup files and trigger a navdb cache rebuild | * add startup options to override/ignore startup files and trigger a navdb cache rebuild {{forum link|p=217854}} {{Not done}} | ||
* expose number of active timers/listeners[http://sourceforge.net/p/flightgear/mailman/message/32774953/] {{Not done}} | * expose number of active timers/listeners[http://sourceforge.net/p/flightgear/mailman/message/32774953/] {{Not done}} | ||
* introduce a tag for FDM properties to optionally notice listeners being tied to FDM rate, as per | * introduce a tag for FDM properties to optionally notice listeners being tied to FDM rate, as per {{forum link|p=214714}} | ||
* provide support for an optional TRACECB (callback) mode where multiple identical callbacks are reported ? {{Not done}} | * provide support for an optional TRACECB (callback) mode where multiple identical callbacks are reported ? {{Not done}} | ||
* we could also provide a property and use it as a "soft limit" for the number of listeners per property before a warning is shown, e.g. ~20-50 ? {{Not done}} | * we could also provide a property and use it as a "soft limit" for the number of listeners per property before a warning is shown, e.g. ~20-50 ? {{Not done}} | ||
Line 164: | Line 164: | ||
* [[Subsystem-level Memory Tracking for FlightGear]] (RAM/VRAM, CPU/GPU utilization) {{Not done}} | * [[Subsystem-level Memory Tracking for FlightGear]] (RAM/VRAM, CPU/GPU utilization) {{Not done}} | ||
* For better diagnostics, and better [[Subsystem-level Memory Tracking for FlightGear|end-user bug reports]], we could consider exposing a cross-platform process and system utilities module via [[Nasal/CppBind]], such as e.g. [https://github.com/giampaolo/psutil psutil] (Windows, MacOS & BSD/Unix) {{Not done}} | * For better diagnostics, and better [[Subsystem-level Memory Tracking for FlightGear|end-user bug reports]], we could consider exposing a cross-platform process and system utilities module via [[Nasal/CppBind]], such as e.g. [https://github.com/giampaolo/psutil psutil] (Windows, MacOS & BSD/Unix) {{Not done}} | ||
* Nasal callback tracking (timers/listeners) | * Nasal callback tracking (timers/listeners) {{forum link|p=232018}} | ||
* Nasal callback tracing, i.e. identical callbacks being called more than once per frame ? | * Nasal callback tracing, i.e. identical callbacks being called more than once per frame ? | ||
* Expose scenery version info | * Expose scenery version info {{forum link|p=202503}} {{forum link|p=224553}} {{Not done}} | ||
* Expose all startup arguments (would just be copied to a single property) and log them to the log file [http://code.google.com/p/flightgear-bugs/issues/detail?id=1470#c15] {{Not done}} | * Expose all startup arguments (would just be copied to a single property) and log them to the log file [http://code.google.com/p/flightgear-bugs/issues/detail?id=1470#c15] {{Not done}} | ||
* Expose complete content of fgfsrc (could be read into the property tree) {{Not done}} | * Expose complete content of fgfsrc (could be read into the property tree) {{Not done}} | ||
* Expose cmake/compiler flags {{Not done}} | * Expose cmake/compiler flags {{Not done}} | ||
* Expose release/debug build info (osg,simgear & fg) {{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 | * Expose architecture (32bit/64 bit) e.g. via '''__i386__''' and '''__x86_64__''' on Intel or via cmake {{forum link|p=225542}} [https://github.com/petroules/solar-cmake/blob/master/TargetArch.cmake] {{Not done}} | ||
* Expose amount of physical RAM available{{Not done}} | * Expose amount of physical RAM available{{Not done}} | ||
* Expose amount of used RAM{{Not done}} | * Expose amount of used RAM{{Not done}} | ||
Line 177: | Line 177: | ||
* Provide some means to show GLSL errors in a dedicated place, i.e. the loglist ?{{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 ? | * 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" | * 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" {{forum link|t=21185}} | ||
* Investigate providing support for Nasal backtraces across timers/listeners as per Philosopher's posting | * Investigate providing support for Nasal backtraces across timers/listeners as per Philosopher's posting {{forum link|p=202736}} | ||
* Extend [[Initializing Nasal early]] to provide a startup mode where the Nasal engine will be fully shut-down at run-time for better troubleshooting | * Extend [[Initializing Nasal early]] to provide a startup mode where the Nasal engine will be fully shut-down at run-time for better troubleshooting | ||
Line 187: | Line 187: | ||
And other values are affected too - most of the environment in fact | And other values are affected too - most of the environment in fact | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum link|p=273052}} | ||
| title = <nowiki>Re: Property Browser: /environment/visibility</nowiki> | | title = <nowiki>Re: Property Browser: /environment/visibility</nowiki> | ||
| author = <nowiki>Thorsten</nowiki> | | author = <nowiki>Thorsten</nowiki> | ||
Line 200: | Line 200: | ||
|1= Is there a way to bypass, fool or add multiple version #'s to VERSION file in the data folder so one can start any version of FG without having to edit that file every time? | |1= Is there a way to bypass, fool or add multiple version #'s to VERSION file in the data folder so one can start any version of FG without having to edit that file every time? | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum link|p=203103}} | ||
| title = <nowiki> folder </nowiki> | | title = <nowiki> folder </nowiki> | ||
| author = <nowiki>wlbragg</nowiki> | | author = <nowiki>wlbragg</nowiki> | ||
Line 213: | Line 213: | ||
But I admit that it would be better to provide a --prop: option to disable the check optionally - it would be useful for people juggling many different branches of SG/FG/FGDATA (while still knowing what they're doing obviously) | But I admit that it would be better to provide a --prop: option to disable the check optionally - it would be useful for people juggling many different branches of SG/FG/FGDATA (while still knowing what they're doing obviously) | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum link|p=203104}} | ||
| title = <nowiki>Re: </nowiki> | | title = <nowiki>Re: </nowiki> | ||
| author = <nowiki>Hooray</nowiki> | | author = <nowiki>Hooray</nowiki> | ||
Line 225: | Line 225: | ||
|1= It works for people who know what they're doing - but providing it as an option could be problematic, because most people are unlikely to know what this entails, so it may be more trouble supporting this than requiring people to edit that file every time | |1= It works for people who know what they're doing - but providing it as an option could be problematic, because most people are unlikely to know what this entails, so it may be more trouble supporting this than requiring people to edit that file every time | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum link|p=203172}} | ||
| title = <nowiki>Re: </nowiki> | | title = <nowiki>Re: </nowiki> | ||
| author = <nowiki>Hooray</nowiki> | | author = <nowiki>Hooray</nowiki> | ||
Line 239: | Line 239: | ||
At any rate it is no big deal, just an annoyance that I now have the ability to change, at least in my version. | At any rate it is no big deal, just an annoyance that I now have the ability to change, at least in my version. | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum link|p=203259}} | ||
| title = <nowiki>Re: </nowiki> | | title = <nowiki>Re: </nowiki> | ||
| author = <nowiki>wlbragg</nowiki> | | author = <nowiki>wlbragg</nowiki> | ||
Line 253: | Line 253: | ||
It's a simple version check, no mystery, I for one bounce back and forth with different combinations. As for the "why" I guess I do things in 3.1 data that I want to check out using 3.0 binary. | It's a simple version check, no mystery, I for one bounce back and forth with different combinations. As for the "why" I guess I do things in 3.1 data that I want to check out using 3.0 binary. | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum link|p=203265}} | ||
| title = <nowiki>Re: </nowiki> | | title = <nowiki>Re: </nowiki> | ||
| author = <nowiki>wlbragg</nowiki> | | author = <nowiki>wlbragg</nowiki> | ||
Line 281: | Line 281: | ||
You will almost certainly end up seeing dozens of unnecessary callbacks being invoked by certain code - even though that may not necessarily be restricted to Nasal code, like I said. | You will almost certainly end up seeing dozens of unnecessary callbacks being invoked by certain code - even though that may not necessarily be restricted to Nasal code, like I said. | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum link|p=274633}} | ||
| title = <nowiki>Re: 777 freezes and FPS loss</nowiki> | | title = <nowiki>Re: 777 freezes and FPS loss</nowiki> | ||
| author = <nowiki>Hooray</nowiki> | | author = <nowiki>Hooray</nowiki> | ||
Line 291: | Line 291: | ||
=== Canvas === | === Canvas === | ||
* Canvas/Element baseclass: SGTimeStamp/PropertyObject for sampling the duration of each update step | * Canvas/Element baseclass: SGTimeStamp/PropertyObject for sampling the duration of each update step {{forum link|t=28745}} | ||
* make canvas optional | * make canvas optional {{forum link|p=265730}} | ||
* load Canvas/cppbind bindings on demand | * load Canvas/cppbind bindings on demand {{forum link|p=265730]}} | ||
* add draw masks for Canvas placements | * add draw masks for Canvas placements {{forum link|t=28086}} | ||
== Runtime stuff == | == Runtime stuff == | ||
* provide a switch to enable/disable updating of canvas/groups on/off (or placements?), to help with troubleshooting | * 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}} | * 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 | * Provide a means to list all running Nasal callbacks invoked via timers/listeners {{forum link|t=21185}} {{Not done}} | ||
* Extend FGStatsHandler to expose Nasal GC stats via osg::StatsHandler {{Not done}} | * Extend FGStatsHandler to expose Nasal GC stats via osg::StatsHandler {{Not done}} | ||
{{FGCquote | {{FGCquote | ||
Line 318: | Line 318: | ||
such things, but would still help different people identify slowness on their <br/> | such things, but would still help different people identify slowness on their <br/> | ||
setups.}} | setups.}} | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=201742}} | ||
|title=<nowiki>Re: New Aircraft: the Extra500</nowiki> | |title=<nowiki>Re: New Aircraft: the Extra500</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
Line 326: | Line 326: | ||
* 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 | * 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 {{forum link|t=22169}} {{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}} | * 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 | * 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 {{forum link|p=202754}} | ||
[[Category:Core development]] | [[Category:Core development]] |
Latest revision as of 12:39, 6 June 2019
Troubleshooting |
---|
These are some ideas towards better troubleshooting that we usually come up with after each release to improve the quality of end-user bug reports. 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... 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.
You may also want to check out this post on the forum: Re:Helping users in the long term post on the forum
Background
Whatever release plan we come up with, it will never be able to solve our issues with respect to bug reporting/fixing. We have all the required infrastructure to do better here: the bugtracker, a forum, a mailing list and we even send crash reports - at least on windows. What we do not have are the people dealing with that. We need:
|
whether we do frequent automated releases or single hand-picked releases, the Achilles heel for the whole process is going to be getting enough test data and processing it properly. — Thorsten Renk (Nov 19th, 2015). Re: [Flightgear-devel] Some thoughts about the release process.
(powered by Instant-Cquotes) |
Usually reports range from 'FG sucks' all the way to suggested C++ patches to fix an issue (with a strong bias towards the former). Ironically, we get at the same time too little and too much information - too little, because often people just write a frustrated post that FG version X crashes all the time and they reverted to the previous version - so we know there is an issue — Thorsten Renk (Nov 19th, 2015). Re: [Flightgear-devel] Some thoughts about the release process.
(powered by Instant-Cquotes) |
I feel that getting the information better organied and brought to the attention of the relevant maintainers would be the key to make better stable releases - but I am at a loss how to achieve that. — Thorsten Renk (Nov 19th, 2015). Re: [Flightgear-devel] Some thoughts about the release process.
(powered by Instant-Cquotes) |
however we do it in the future - this is what I see as the most pressing issue to solve - how to improve the flow of information from users to developers without making everyone unhappy in the process. — Thorsten Renk (Nov 19th, 2015). Re: [Flightgear-devel] Some thoughts about the release process.
(powered by Instant-Cquotes) |
Might sth like a bug-report (or maybe crash-report?) feature be of help? We got a lot of information in the property-tree, like GPU-drivers etc. For instance, do we have OS and stuff like that too? Might be fairly easy to put this important info into a tmp-file, and in the case we crash, add it to some kind of http-request to flightgear.org. An experience-report might be of help, what frequently asked questions do you pose all the time? + the red box... — chris (Nov 19th, 2015). Re: [Flightgear-devel] Some thoughts about the release process.
(powered by Instant-Cquotes) |
we should absolutely stop telling anyone to edit preferences.xml in FG_ROOT; any documentation or advice which says to should be changes ASAP.
— zakalawe (Sat Oct 26). Re: NavCache:init failed:Sqlite error:Sqlite API abuse.
(powered by Instant-Cquotes) |
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
- show location of $FG_HOME in help/about dialog as a button to open it via file explorer ?
- show checksum of preferences.xml using the md5() Nasal API in the About dialog to ensure that people didn't tamper with it
- consider adding the checksum of preferenfces.xml to the binary, so that startup code can identify if files were modified that should not be changed
- should show if fgfsrc is available/used
- use intel detection heuristics and adapt those to detect AMD/ATI cards and show a startup warning to inform the user that PUI/styling may interfere with effects/shaders
- we keep seeing people who install mismatching versions of aircraft/fgfs - introduce a version-check property so that -set.xml files can encode version requirements, which are checked by a script in $FG_ROOT/Nasal [1]
Better version info
- add boost version info to a property and show it in help/about dialog
More logging
Would it be possible to print the command line options FlightGear has been started with into the log file? At least from log-level "info" on upward. This would make helping users with issues a tad more easy. They would not have paste two files, the log plus the command line options. And the people trying to help would not need to explain how to gather the command line options. Which is not easy with with a bunch of launchers out there. It also would reduce the need for each of those said launchers to implement a feature to print the command line options. — Alex D-HUND (Jan 12th, 2016). [Flightgear-devel] Feature request - Logging / debugging.
(powered by Instant-Cquotes) |
This is a valid request, but there is complication in how various files and options are combined. There are two ways to do this:
— James Turner (Jan 12th, 2016). Re: [Flightgear-devel] Feature request - Logging / debugging.
(powered by Instant-Cquotes) |
Core changes
This article may require cleanup to meet the quality standards of the wiki. Please improve this article if you can. |
These will typically require changes on the C++ side, but would still be good to have whenever someone makes a bug report:
- provide a startup option/property to disable aicraft-set.xml Nasal code for troubleshooting purposes
- log frequency of Nasal callback invocation to the console to detect fdm coupled code ?
- dump node-specific osg camera stats to the console/log file (or even splash screen) during startup for the scenery/aircraft ROOT nodes [2]
- separate OpenGL/GLSL logging/log file for troubleshooting graphics related startup errors rendering FG useless (e.g. faulty drivers) [3]
- case-sensitive path checking [4]
- write the current pid (process ID) to the property tree, so that this can be used for debugging purposes (or even just for the suffix of log files) Not done
- add startup options to override/ignore startup files and trigger a navdb cache rebuild [5] Not done
- expose number of active timers/listeners[6] Not done
- introduce a tag for FDM properties to optionally notice listeners being tied to FDM rate, as per [7]
- provide support for an optional TRACECB (callback) mode where multiple identical callbacks are reported ? Not done
- we could also provide a property and use it as a "soft limit" for the number of listeners per property before a warning is shown, e.g. ~20-50 ? Not done
I used two places to check how many Uniforms are created. EDXH (Isle of Helgoland in the North Sea) - barely any scenery; And KSFO with AI Traffic enabled, you know the scenery complexity.At EDXH, the Effect system attaches approx. 1500 Listeners to the property tree but only to 17 unique properties. At KSFO, the Effect system attaches some 10000 Listeners to the property tree - but also only to 17 unique properties. That's with shader quality set to zero (all off).
On my old Laptop, (1.6GHz dual core, GeForce Go 7400, 3Gb RAM) FlightGear has becom barely usable over the last few years. Framerates of max 20 at EDXH and single digits at KSFO. — Torsten Dreyer (2014-09-04). Re: [Flightgear-devel] crash in SGPropertyNode::fireValueChanged.
(powered by Instant-Cquotes) |
- Subsystem-level Memory Tracking for FlightGear (RAM/VRAM, CPU/GPU utilization) Not done
- For better diagnostics, and better end-user bug reports, we could consider exposing a cross-platform process and system utilities module via Nasal/CppBind, such as e.g. psutil (Windows, MacOS & BSD/Unix) Not done
- Nasal callback tracking (timers/listeners) [8]
- Nasal callback tracing, i.e. identical callbacks being called more than once per frame ?
- Expose scenery version info [9] [10] Not done
- Expose all startup arguments (would just be copied to a single property) and log them to the log file [11] 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 [12] [13] 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" [14]
- Investigate providing support for Nasal backtraces across timers/listeners as per Philosopher's posting [15]
- Extend Initializing Nasal early to provide a startup mode where the Nasal engine will be fully shut-down at run-time for better troubleshooting
Property ownership
Need a way to register property ownership:
That's because the property is normally not under user control but set by the weather system. You have to stop the weather system before you can set it.
And other values are affected too - most of the environment in fact — Thorsten (Jan 16th, 2016). [[16] Re: Property Browser: /environment/visibility].
(powered by Instant-Cquotes) |
Version checking
Is there a way to bypass, fool or add multiple version #'s to VERSION file in the data folder so one can start any version of FG without having to edit that file every time? |
Nasal
it's relatively easy to do bad things unintentionally. Like tie a bit of code to an FDM property and run updates of a display 120 times per second rather than the 30 times you actually need. Like start a loop multiple times so that you update the same property 30 times per frame rather than the one time you actually need. It's actually pretty hard to catch these things, because the code is formally okay, does the right thing and just eats more performance than necessary, and there's no simple output telling you that you're running 30 loops rather than the one you expect. — Thorsten Renk (Feb 1st, 2016). Re: [Flightgear-devel] Designing a thread-safe property tree API.
(powered by Instant-Cquotes) |
Canvas
- Canvas/Element baseclass: SGTimeStamp/PropertyObject for sampling the duration of each update step [23]
- make canvas optional [24]
- load Canvas/cppbind bindings on demand [25]#p265730] ]
- add draw masks for Canvas placements [26]
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 [27] 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/src/Viewer/FGEventHandler.hxx#l14 (commit 130f581b18711b63138580d306a39c27b891178c) The class can be extended to add your own stats via osgViewer::StatsHandler::addUserStatsLine() |
- 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 [28] 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 [29]