Are there any "common" error cases where R'n'D programmatically exits and rewrites "levelsetup.conf" where you think it should not? In this case, I would like to modify the error handling for such cases.
I don't know of specific cases; I do know the general method by which such things ought to be handled:
If a program crashes and has error handling which attempts to perform recovery by 'resetting to safe default values', it should always save aside a set of the settings it's overriding, and provide a path back to them.
A current egregious example I'm struggling with: the (current Chrome-based) Opera browser, when it crashes twice in a row, assumes it might be a problem with an extension. It therefore disables all extensions on the 2nd consecutive restart-after-crash.
My default configuration includes about 20 extensions, some of which are intentionally disabled. When they blunder in and disable everything, I lose my current intentional configuration. They should not modify the on-off switch of each extension; rather, they should start in a state in which each extension shows, in the extension manager, either 'off' or 'on, but currently disabled due to safe mode'.
Here, R'n'D should do one of these things:
A) Don't change the levelset in levelsetup.conf, but do write a 'crashed last time' indicator. On startup, query the user: 'You were playing [name of levelset] last time, and the game crashed. Do you want to return to that levelset or switch to a safe default?'
or
B) Rewrite `last_level_series` to a safe default, but save the prior value as e.g. `pre_crash_level_series`. Then provide a UI path to switch back to that pre-crash levelset; e.g. in the levelset browser, a button for 'levelset I was playing before crash'.
In either case, make sure not to commit the utterly commonplace bug in which this sequence forgets your levelset:
1. playing levelset xyz, game crashes
2. restart, game now knows that xyz is the pre-crash levelset but is on a safe default; crashes again anyway
3. now the pre-crash levelset has been set to 'safe default'
-- either by recognizing the 'safe default' and refusing to write it to the 'pre-crash' value, or some other sensible method.
'A' seems better to me, overall. The user is in control and overwrites the levelset info only if they choose to.
Also, 'A' can be implemented as a 'dead man switch'. On game startup, rewrite levelsetup.conf (or a new file) indicating game is currently running. On next startup, if that thing indicates 'running', it must have crashed last time; whether or not it had an opportunity to write out a crash log or do other cleanup. BUT: I often run 2x R'n'D (e.g. to better compare similar levels side-by-side, or to some someone else some other level while not disrupting the one I'm working on). So this also needs some trickery.