When to save "stuff" in the engine

[Baker]

When an engine crashes, you lose a lot of things that you shouldn't.

If you have something like session to session command line history, that doesn't happen. You obviously lose config settings or whatever video mode you might have selected.

FlashQuake saved the config any time you exit the menu.

Maybe session to session command line history should be perpetually saved every time a command is entered from the console. I can imagine that would stress out the engine, although to some degree it makes you wonder whether or not file append isn't a better option than the way it is currently written.

I do know that when a gamedir command is issued, the engine should save the config immediately before the gamedir change takes effect, otherwise you tend to have the odd situation where configuration changes you made get "lost" in some gamedir that isn't where they were intended to be.

[Spike]

Alternatively, you could simply not crash the engine.

In a more realistic world, you could save the command buffer when it does actually crash (put a __try __catch thingie around your main loop). But then, what if the cause of the crash was the command history? You just started writing to the file then crashed again. Now the user has lost everything and not just what was meant to be saved.
Alternatively, you can faff about with writing to a different file and then delete+rename once you know the file was written okay. Its still possible that some of the commands were corrupted by an invalid memory write or something, but hey...

In an ideal world, you'd be able to save only when you quit. In a QuakeWorld world, you get users complaining if you ever automatically save a config. :P

If you save settings every time an option is changed, for example vid_mode, and the new setting causes the engine to crash... you probably just caused the newbie user to have to reinstall the entire thing (and woe betide if you saved the config in a hidden location, like in their profile).

Command history is unimportant. If they can type it once, they can find the same site to type it again. Its only engine developers who really care and are likely to be crashing it constantly (hopefully).

If performance is your issue, writing to disk doesn't normally take much cpu, the slowness is in waiting for the disk itself. You can safely use a separate thread to do the actual disk access. There are exceptions in the form of really old or f*cked disk drives/controllers/cables, but those should not be too common, and in general terms, users expect such computers to run like a terminally ill snail that thought superglue was part of a balanced diet.

[mh]

run like a terminally ill snail that thought superglue was part of a balanced diet.

Saved up for later use!