Display error messages prominently in game screen
Context: among TR quest devs openMW has gained the reputation of not being usable for playtesting - part of it is the few vanilla features that aren't implemented yet, but I believe the less obvious reason that won't go away even after those known features are added is the visibility of error messages.
The vanilla engine for most script errors (meaning those it manages to handle) pauses the game with a messagebox report that asks to keep running the executable, and choices "Yes" "No" and optional "Cancel" for yes to all. "No" is not useful in general (with the vanilla engine there are possible cases where you would know a specific error and prefer to close instead of incurring a bad crash with Windows OS); a message that pauses the game with at least an "ok" button would probably be enough.
Now obviously if a content tester doesn't check their log with the current setup it's their fault and not openMW's, but that doesn't mean keeping errors in the background is optimal, consider:
- if you don't have a large enough screen to test the game with the console log open next to it, you aren't able to check output at the same time as it comes up
- you can miss important messages amidst normal console output (loading files, loading cells, unloading, warnings for extra arguments in vanilla content, warnings for mesh properties...)
- because something isn't working as expected you know an error must have occurred at some point, but you can't tell "when" relative to what happened in the game
- you see an error was logged about dialogue results, but you can't tell from which dialogue entry it came if you're looking at the output later instead of the moment you see the dialogue
- you see an error about scripts and know where it came from, or can guess where a dialogue result error came from, but by looking later and not the moment it happened you still wasted time in a broken system
So for content devs, having to constantly check the background console log is inefficient or effectively reduces screen size. How about players?
Keeping errors in the background isn't good for players either, from experience with the vanilla engine. I say it isn't good, not that it isn't what they want; they do hate seeing error messages and are happy to ignore anything that isn't an immediate bright yellow exclamation mark missing mesh, as long as the issue hasn't started affecting them yet. For more context, "Bury your head in the sand" is a widespread bad practice among heavy mod users: it's adding "AllowYesToAll=1" to Morrowind.ini and ignoring all error messages on startup and later in the game, all by clicking Cancel once. When a user complains that their 200+ mods game ran well for a month before starting to permanently corrupt their saves, you know a lot of error messages have been ignored. I assume openMW strives to handle errors more gracefully and this isn't what you're concerned about, here's a more universal example:
a content file adds quests to Caius Cosades. Quest 1 is "go talk to Divayth Fyr", Quest 2 is "look for a pair of pants Caius lost in Suran". If Divayth Fyr is dead, the file uses a different dialogue entry that skips to quest 2. It's rare, but this player has a dead Fyr in their game. Unfortunately for them the skip entry has an error in dialogue results and the quest technically doesn't start. Even more unfortunately for them, they don't see that there's been an error and go to Suran, exit and go to lunch, restart the game, spend two hours in Suran looking for pants that don't exist, stealing any pants lying around in houses, going to jail, stealing pants again, hiking back to Caius with pants for which he has no response, and so on. Even if that player knew to look in Warnings.txt, there could be nothing relevant logged in the playing session during which they looked for pants. If that player is thorough enough to know something was wrong, and if they do report the issue before losing interest and going awol, their report will be "can't find lost pants in Suran". Player wastes time, dev gets a useless report and can't reproduce. I can tell you this is frequent because of how many players already ignore warnings with the vanilla engine. Even devs often don't realize that "Yes to all" means skipping messages not only on startup but during the whole time the executable runs, so they click Cancel to skip two warnings about file dates, then never check Warnings.txt for anything else, and immediately overwrite that file by starting the CS or the game again - of course that means their playtesting is useless: they don't know there were errors, or if they're lucky they saw symptoms but not the cause.
Transpose that quest example in openMW: in the best of cases, a player is not going to scan the full output log every time they close the program. In fact, even the background console is something players would hide entirely given the choice, see #2490 (closed). For most the error will be effectively silent. OpenMW player still wastes time, dev still gets useless report. So why is the vanilla engine currently superior in this regard? Because at least hiding error messages from the game window is opt-in. If a vanilla engine player is not savvy enough to edit the vanilla .ini file (or is knowledgeable enough to have a healthy mod setup and not skip all), they get an ugly error message the very moment Caius asks them to look for pants, and they know something isn't working right away. Player doesn't waste time, dev gets an accurate error report.
tl;dr: openMW keeps warnings and errors in the background, keeping warnings in the background is fine, keeping errors in the background eventually makes issues worse for all users.