id,summary,reporter,owner,description,type,status,priority,milestone,component,resolution,keywords,cc
119,On-screen error display,jan,,"Motivation: error log works but isn't usually looked at (only when a problem has otherwise made itself apparent).
Solution: provide an on-screen display of errors to make sure they are seen.

Problems:
- we currently have lots of unsolved errors in the log; when display on screen, those would get annoying fast. Solution: solve all of them! :P More seriously, having them in our face should provide a nice incentive to investigate and solve them. However, if need be, we can also use the logging system's severity mechanism to avoid displaying some log messages on screen.
- how to deal with a flood of errors? Make sure each line gets (say) 30 seconds of face time, then scroll it off the screen. Only display a certain limit of lines to avoid scribbling on the entire screen.


Detailed Implementation Points:

- probably best to integrate into CLogger; that which is logged there also goes onto screen.

- text must be visible to user; whether scribbling directly on the screen (i.e. adding code to Render() ) or adding a GUI control of sorts is left open. The latter is preferable of course, but is a bit harder (needs a control to be made visible/invisible).

- need to maintain a buffer of errors awaiting display. This is because errors can come up before the GUI or graphics systems are initialized; we'd want to display them as soon as possible afterwards.

- proposal: std::deque of error-description lines. push new ones onto the end. as soon as GUI is ready, display the first MAXLINES of them on screen. maintain a count of when each line went on-screen. check every frame if the top lines have gotten more than FACETIME seconds; if so, pop them off the deque and remove them from the screen.
If deque is empty, no longer clutter up the screen; disappear from view.

- this error display should be available for developers and modders. add a config option that enables/disables it.

- prefer unicode-only strings (to allow easier localization)

Thanks to Philip for discussion+planning.",task,closed,Nice to Have,,Core engine,fixed,,
