CrashReporter improvements: Full reporting system?

[Cervator]

This is a follow-up to #2577 which was completed by #2584

At this point you can launch the CrashReporter from inside the game without actually having crashed so you can easily access the game logs from the running session. However, this is still a bit awkward and looks funny since the CR was, well, designed specifically to handle crashes. There are some short term possibilities to tidy up the setup as well as some long term possibilities that could be GSOC scope for an overall problem reporting system..

Short term easy fixes:

• Rename the button to "Issue Reporter" (for the in-game context it isn't for reporting crashes)
• Add the button anywhere else needed / move it under Developer Tools? Rename that to "Extras" or so?
• At present the CrashReporter opens in a modal window mode locking up the game itself while open, until the user clicks the X to close it again. Could it perhaps be left non-modal, especially in a multiplayer situation? If a player is hosting a server it goes unresponsive if they open the CR. If non-modal stream log updates right into the log tabs?
• The Crash IssueReporter now opens in the background, which can be confusing (should go to the front, just not be modal)
• Improve the CrashReporter itself to adopt a larger scope beyond just crashes: Increase scope to also cover non-crash situations (more generic text and such) CrashReporter#35
• Clarify the -noCrashReporter command line argument. It now only matters for actual crashes - opening the CR via menu item is something totally different

Longer term possibilities (GSOC stuff):

• Relation to Improve visibility of missing resource / asset scenarios #1402 - steal @iojw's improvement from Added check for insufficient space TerasologyLauncher#392 to also apply in the engine (warning icon showing problems may be active). But could that actually be a new way of opening the CrashReporter in a non-modal mode, which could also be retrofitted to the launcher and elsewhere?
• Implement an outright back-end supported issue reporting system beyond just dumping logs on pastebin or a Google Drive. This would probably involve some existing framework - need to research what's available that could work for us (think a user support style system like ZenDesk, but naturally it has to be at least free and ideally open source. Bonus for integrating with GitHub)
• Implement some metrics gathering users could opt-in for to better understand how the game (or other projects) is being used. Could include how frequently certain warnings or error conditions happen. Could include a more full picture of the user's hardware and such (GPU driver versions?)

As a clarification vs #1402 this item should focus on the support for better reporting issues, not avoiding them in the first place via better visibility (the stated goal of #1402). However the two are quite close, especially if the CR becomes a more generic review tool you can access in-game.

[GabrielXia]

Hello !!! @Cervator
I would like to try the short term easy fixes at first. However I have some questions as follow :

1. I've pulled the code, I checked out in the branch develop. There are two fatal errors as follow :

20:16:49.564 [main] WARN o.t.rendering.nui.skin.UISkinFormat - Failed to resolve UIWidget class UIInputBindButton, skipping style information
20:16:49.695 [main] WARN o.t.engine.internal.TimeBase - Delta too great (9601), capping to 1000

There are several buttons in game with no text on it. Is that my setting problem ? I changed name "Crash Reporter" to "Issue Reporter", but I don't think it causes the problem(Should I open a new issue for this problem)

2. For fixes 3, is it possible to do fix it without changing the code in Repository CrashReporter ?

3. For repository CrashReporter, I'm not very clair how to test the code in CrashReporter, should I do something to connect CrashReporter and Terasology ? Are there any wiki documents about testing CrashReporter ?

4. For fixes 5, does it mean that we can disable all CrashReporter functions(including CR button in menu) using noCrashReporter argument ?

Thank you a lot :-)

[Cervator]

Heya @GabrielXia :-)

20:16:49.564 [main] WARN o.t.rendering.nui.skin.UISkinFormat - Failed to resolve UIWidget class UIInputBindButton, skipping style information
20:16:49.695 [main] WARN o.t.engine.internal.TimeBase - Delta too great (9601), capping to 1000

Those are not actually fatal, they are WARNings which indicate a possible problem but not necessarily an error, and most likely not anything at all fatal. Those two in particular have been around for ages.

The first one is an outdated config entry in a UI related file and the second happens any time the game loop ends up putting more than a second of work into a single round of processing. That's typical for right as you start the game as a ton of stuff all happens at once. Can also happen if your system is laggy.

The blank buttons are most likely caused by your edits in the language file somehow. It seems like some have broken or have been shuffled around since for some reason the "Exit Terasology" button is showing as "Terasology" for some reason. Not likely to be a bug - maybe upload your code somewhere if you'd like a hand identifying the problem :-)

If by "for fixes 3" you mean the modal window thing then I'm unsure where that is set. Some changes will definitely require altering the CrashReporter itself. You can embed it as source into a regular Terasology workspace to easily change both at once (gradlew fetchLibCrashReporter I think, then gradlew idea again)

At present the noCrashReporter is specifically for testing things around when you exit/crash out of the game, rather than load up the CR. So the functionality in the game menu should remain independent :-)

Hopefully that helped, sorry about the delay! Let me know if you have any follow-up questions.

[GabrielXia]

Hey @Cervator, I'm sorry that I still have a problem about noCrashReporter command. Does it mean that we should do at present is just to change the name of noCrashReporter command to clarify that the command is only for real crash ?

p.s. Since in PR I've added a new parameter in CrashReporter (to clarify the critical mode or the non-critical mode) : #2777 and MovingBlocks/CrashReporter#36, the code might only work when both CrashReporter code and Terasology code are updated. How do we deal with this problem ? Or it's better not to change the parameter in method of CrashReporter

[Cervator]

The command line argument for not enabling the CR should just be clarified in documentation, yep.

Terasology's engine + CR can be tested together with branches checked out for both in a single workspace. Did that earlier and your changes worked great :-)

When we make changes like that involving one of our frameworks we usually publish a release then immediately bump the engine's dependency on the framework up to use the new version. You don't need to worry about that part at all.

[GabrielXia]

Heya !! @Cervator
I searched a little about some potential ticket systems, like RT, OTRS, helpy and osTicket. I haven't tried them all yet, maybe later :D

A few questions :

• What might be the factors to choose the best frame ?
• Since we have already pastebin and Google Drive, plus, forum and Github, do we really need the ticket system ? I'm a little worry about that this topic will not be picked because it's not badly needed ...

[Cervator]

Best "frame"?

I don't think we need another standalone ticket system just to have one. It would have to be very specifically for linking to automated reports (and potentially then to one or more associated GitHub issues). Really more of a reporting & telemetry organizing system rather than an issue tracker, ideally with direct association to our existing issue tracker.

In other words the new system would have to provide a certain amount of unique value vs our existing systems. Otherwise yeah not badly needed :-)

[GabrielXia]

Hi @Cervator I made a prototype of the telemetry server. Please check it out in the forum. I wrote more detail in the repository : Client prototype and Serve prototype. I don't know whether I've made it clear and whether you like it. Please let me know your feeling :-)

Recently I have an idea about the implementation about "warning icon showing problems may be active"：Can we use LogBack FileAppender to log WARN and ERROR logs to a new log file named warn-log, and when the game detects that file exists, it will show the warning icon in game. Does it make sense ?

[Cervator]

Saw the forum thread @GabrielXia - looks awesome! Getting pretty exciting. Cool to see some of the same tools involved beyond Snowplow that I'm already somewhat familiar with from work (Logstash, Kibana, etc)

Using a dedicated warning log like that may make sense. Probably lets focus the discussion in the forum and drag @rzats into it sometime. He's going mentor for GSOC after all so maybe that'll be a good fit :-)

[Cervator]

Re-opening as a related PR only finished a couple items from the list, not the whole issue :-)

[Cervator]

Closing this now as completed as part of GSOC 2017 - woohoo! Thank you @GabrielXia along with mentors @rzats @msteiger @skaldarnar and @oniatus !

There are more ideas and possibilities, some noted in #3011 and even moved from here.

See the blog for updates and work done on this item: https://gabrielxia.github.io/telemetry.html