right, troubleshooting is a matter of presenting the steps required to reproduce/verify a certain issue, and that's usually a long-winded and tedious process unfortunately.
And it also doesn't scale particularly well. Which is why I tend to come up with wiki articles and simply post links that detail all steps and questions that people need to follow/answer.
Otherwise, I would not get anything done. Then again, I fully realize that most users (especially new ones, with primarily MSFS/FSX and XP experience) are unlikely to even respond to such enquiries. Admittedly, I also don't find this particularly intuitive or user friendly. But given our "manpower" there's only so much we can do about this. I think the recent addition of integrated crash reporting support is a good step - but as mentioned elsewhere, it doesn't scale too well as long as only a single developer has access to these reports, and as long as only a single guy actually knows how to process those reports. At the moment, that's our main bottleneck when it comes to troubleshooting crashes.
Then again, not all issues are necessarily segfaults/crashes - but for the time being, I'd consider those to be of primary importance, so personally I'd focus on those, rather than some obscure usability issues.
Now, when it comes to troubleshooting end-user crash reports, there's only so much that we can do, short of asking people to provide GDB back traces, and that alone isn't very appropriate for the majority of non-segfaults.
What I've been contemplating for a while is making things better reproducible by using FlightGear's existing support for replicating runtime settings via serialization (user-archive attribute). Basically, we could use the existing flight recorder/replay system and extend it to also plot additional properties, such as for example those that are relevant for rendering/shader settings. The main prerequisite for this to work would be that the corresponding properties are runtime-configurable, i.e. take effect without requiring a restart. For most rendering related settings this already seems to be the case.
Ultimately, that would allow us to ask people to provide a "replay tape" with their rendering settings, possibly even including a flight or other runtime settings, so that developers/contributors could more easily download such an XML file, and apply it to their own installation at runtime, to see if they can reproduce a problem. Personally, I would be much more likely to do something like this, instead of having to spend 2 weeks asking dozens of questions to "approach" the nature of the problem.
The replay/flight recorder subsystem is flexible to support most of this, even without modifying its C++ code - it's just some usability "glue" that needs to be added, i.e. GUI dialogs.
The good thing about this approach is that it would be very scalable as long as FlightGear primarily deals with settings in the form of properties - we could even log startup stuff to such a file, such as OpenGL/GLSL version info, operating system, amount of RAM, number of CPUs etc
The recent reset/re-init work makes this increasingly feasible, so we may want to reconsider this once all the building blocks are in place.
It would be a good project for someone interested mainly in XML and GUI dialogs, but most of us are already juggling too many other projects - so I'd rather not provide another "prototype" currently:
Subject: Mac 2.10 RC Atmospheric light scattering bugHooray wrote:we should add a menu item to dump the current position and all rendering/environment settings to an XML file, so that we can more easily reproduce such things, just by loading a config from a file.
Subject: Mac 2.10 RC Atmospheric light scattering bugHooray wrote:someguy wrote in Sun Feb 03, 2013 6:39 am:That's a super idea! It wouldn't surprise me if some of these glitches are peculiar to specific hardware configurations, either, so perhaps that might be part of the report as well.
Yes, even just knowing that certain issues only occur with some GPUs would be VERY good to know. But obviously we would need a sane way to easily reproduce a certain configuration, including all startup settings, but also the runtime rendering settings.
I'll paste XML into forum posts all day if it helps the devs fix bugs.
We could obviously use a pastebin, but probably using the issue tracker would be a better idea then.
After all, having an easy way to reproduce a certain configuration, could save us tons of time and question asking - so having such a feature would be really invaluable in my opinion.
We could add a dialog so that people could even describe the problem - so that the XML files would become self-contained and could be easily checked by different people without having to ask tons of tedious questions...
Thinking about it, the simplest option would seem to be using existing stuff. After all, this is just about recording and replaying properties. And that's exactly what the new flight recorder (replay tapes) system does. So we could simply abuse it a little to also provide a configuration to sample the various rendering properties (see rendering dialog), which should give us a way to reproduce settings fairly well.
Subject: Flightgear-specific benchmarkHooray wrote:Using a combination of prerecorded flights, the replay/flight recorder system and a Nasal script to change setting on the fly, it wouldn't necessarily be very difficult ....
ericolon wrote in Thu Feb 21, 2013 5:35 am:I could provide/specify a list of settings and record some flights (if said feature exists)
We do have a so called "flight recorder/replay" system that can save flights. The whole system is property-driven, and it is possible to provide custom sets of properties that should be recorded. In other words, it would be possible to create a custom "flight recorder" configuration that doesn't just record aircraft settings, but also rendering related settings:
New properties can be easily added by editing an XML file, see $FG_ROOT/Docs/README.flightrecorder (plain text file, can be opened using notepad or wordpad on Windows):
http://gitorious.org/fg/fgdata/blobs/ma ... htrecorder