Aside from all this latest spoilerish stuff, I thought I was going to learn a good reason not to use auto-save. Which I do (seasonally, with "-aut-1055"-style copy suffix applied).
But I didn't. Even if save-scumming (something I rarely do[1]), auto-saves don't cause problems.
Except (which is not necessarily a disadvantage if this is accidental) that a seasonal auto-save with copy still (I think) saves the master-file, so if you're going to the trouble of hoping to reshape a mood that started just before the season, the season save means that the "kill -9" or Three Fingered Salute method of abort-without-save. Then you'd have to go and take the "-sum-1055" save and reply almost an entire season, and now not even get the same dwarf.
So make a save when you think things are about to be... interesting... make your own copy and then if/when you want a reply shuffle your own copy back into play one way or another.
And if your machine performance (and game-load is anything like mine), you can tell when something big happens. Immediately before a child is born, immigrants or siege arrive or (I surmise) a hidden raiding party arrive on the scene I get a definitely noticeable game-pause. When I get something like this and there's no child/immigration/siege announcement, it's a possible ambush precursor. Too late to change what arrives, as far as I can tell, but I might quickly rearrange anyone working on an external feature back onto jobs within the defences, and activate an additional (not already patrolling/stationed) military unit.
If you make your explicit save/copy at this point, then if you find you've made a bad choice (patrols/stationed troops in the wrong quadrant of the fortress walls, for example), you can redo from this point with a mysterious knowledge of where the ambush troops are most likely to be first encountered/intercepted. (Also, in reverse, you can ensure that your overlooking archers don't decimate (in the traditional sense) and scare off your goblinite-suppliers too early, and actually bring your military response back
behind the first lock-gate that you want to seal the invaders off with, before annihilating them completely and claiming their goods.)
Or you can go back to the saved season and get a possible new (but, again, reactable-against) version of the attack.
That's what you can accomplish if you
want to accomplish it. (That and more, but I won't go into every little trick I've stumbled across.) But this is in no way prevented from happening with auto-saves on if you are also prepared to make your own backup "trousers of time" points.
Whether you want to or not... that's for your conscience. The rules of the game are what you make them. Hence I'm comfortable to try a sub-megaproject aspect of a fort then revert to when it never happened, but I would never reshape a moodcraft product. (Also, I
would accept when a useful moodcraft product changed into a less useful moodcraft one, where I've rerun a short time for the prior 'legitimate' reason.) A military situation that provokes a rewind might happen if it's 'just unfair' and I've lost my main megaproject architect/manufacturer in a fort that is not (yet, at least) supposed to be dealing with hostiles on the level I've just encountered. (Because I consider turning off invasions in the Inits against my own personal rules, and
try to deal with enemies when they arrive, in such circumstances.) I rarely
use the seasonal save-copies, but their being there gives peace of mind. Hence that's what I activate, immediately, in any brand-new unpacked game's Inits. (That and screen width and height, and "water as values".)
So, that's what I think/do/imagine/etc. But YMMV, and on some details ICBW.
Now back to your other discussion.
[1] Sometimes after intentionally diverting to test some new construction method. Which might be as easily done by saving, making copy, running experiment on the copy. But saving and copying (or relying on auto-save) experimenting on the original and then deleting that and copying/renaming the copy/autosave back to the original is the less efficient way I'd do it. But it's when doing things like this that I've derived the above rules of "timeline mutability".
Author
Topic: reason not to use auto-save (Read 8203 times)