Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Yaotzin]

[rant]
DF is a fantastic, highly enjoyable game. It also has a dreadful save system that makes me want to stick forks in my eyes. It's slow to save, and quits the game - both interrupting flow and forcing a long loadtime on me. That makes it easy to forget to save, or just not bother.

This is not about savescumming. It is about crashing. Like several hours after you last saved.
[/rant]

Seriously though, the game needs a more sensible system - ingame save, preferably not even pausing the game. Yeah, it makes savescumming easy, but it's easy anyway and it's a single player game so who really cares anyway.

[Gatleos]

data/init/d_init.txt
Change [AUTOSAVE:NONE] to [AUTOSAVE:SEASONAL] or [AUTOSAVE:YEARLY]

Not much to do about the long save time, though.

[Yaotzin]

Other games no longer require pausing/waiting when saving. Use multiple cores I guess?

Anyway, thanks for that. Still be damn annoying if I made a big project at the start of the season then poof.

[Old Bones]

There are better reasons than faster saving to implement multithreading.

[Gatleos]

Another game might save the player's current level, equipment and location. DF saves the skills, equipment, location, hopes, dreams and personality of about a hundred units, the shape and composition of the landscape, literally thousands of individual items, fluid flows, weather conditions and historical records. That's probably why it takes a bit.

[Cruxador]

Other games no longer require pausing/waiting when saving. Use multiple cores I guess?

Nah, they're just much simpler games so they don't need to save as much data.

[Darekun]

Other games no longer require pausing/waiting when saving. Use multiple cores I guess?

Saving is a disk-bound operation - if you devote a whole core to the task, that core will spend most of its time waiting for the disk to complete a chunk. Instead, even a single-core game just checks back every fraction of a second to see if the disk is ready for another chunk, and after maybe a second of devoting 1% of one core to the task, it's done saving.

Perhaps the hardest part code-wise would be copy-on-modify; there's probably a canned solution out there. But given that, DF could make a copy-on-modify mapping of all that data(which is kept in RAM already last I saw), and check every tick or ten to see if the disk is ready for another chunk. Saving would be done in the background, in the same elapsed time, at the cost of 1% FPS during the process. (Or maybe as much as 10% if you've got rain or thermal rebalancing at the moment, or anything else that'll give the copy-on-modify a workout.)

(All this can break down as stated for a solid-state drive; however, worst-case, it just happens at HD speeds. Better would be an init switch, since foreground saving like DF uses can actually be appropriate on a fast enough SSD.)

[Baughn]

Disk write speeds are not actually terribly relevant, because the saves are still small enough the the OS will buffer the whole thing. What's more important is, as you said, the sheer size of the thing.

Doing it in the background would require copy-on-write mapping the entire data space. Which is fine, as such; there is indeed a canned solution for that, namely fork().

Yeah. Just one problem: fork only works on unix systems. Windows doesn't have an equivalent; trust me, people have looked. And while a COW-based clone would be unlikely to use much extra memory, the typical Windows solution of actually copying the entire program would of course double memory use during the save. I don't think that's very useful.

Well, the OS X and Linux versions could conceivably be improved to do this, though.

[Cruxador]

Just one problem: fork only works on unix systems. Windows doesn't have an equivalent; trust me, people have looked.

Well, it could happen in Windows 8. As far as I know, at least. Not that that would do any good for DF, since we're gonna want to maintain compatibility with older versions of Windows for the foreseeable future.

[Darekun]

Which is fine, as such; there is indeed a canned solution for that, namely fork().

Yeah.

Yow, I was imagining a shallower solution. Say attaching it like a debugger, whereupon it would use virtual memory debugging to function kind of like a mapper in NES/SNES emulators. That particular approach may interfere with development, but I guess you could use something actually like an emu mapper, only during the save operation… It shouldn't need something as deep as fork() if it's designed for it.

[peregarrett]

Quick solution, I guess this will work.
0) Install more memory in your system. More. And even more.
1) Create RAM disk partition. Copy DF there, set autosave seasonaly, with no pause
2) Launch DF from there and play
3) Either manally or automatically backup saves to HDD where DF actually located.
You get lighting-speed saving.

[Baughn]

Which is fine, as such; there is indeed a canned solution for that, namely fork().

Yeah.

Yow, I was imagining a shallower solution. Say attaching it like a debugger, whereupon it would use virtual memory debugging to function kind of like a mapper in NES/SNES emulators. That particular approach may interfere with development, but I guess you could use something actually like an emu mapper, only during the save operation… It shouldn't need something as deep as fork() if it's designed for it.

That would take far, far more work, and probably slow DF down, too. fork is the simple solution; I could probably implement that in an hour or two. (Not that I have the sorfe for that, mind.)

[Yaotzin]

I'm no expert on the technical side, I just know that pretty much every modern game has managed saving in the background. If it's a technical nightmare so a lone guy can't do it I understand.

My main issue is that it boots you to the main menu, so you have to go through the lengthy load as well. That's totally unneeded, surely.

[Draco18s]

I'm no expert on the technical side, I just know that pretty much every modern game has managed saving in the background.

Played Tropico 4 recently?

My main issue is that it boots you to the main menu, so you have to go through the lengthy load as well. That's totally unneeded, surely.

Hark back to old roguelike games.  No save-scumming.

[Jay]

I'm no expert on the technical side, I just know that pretty much every modern game has managed saving in the background.

Because pretty much every modern game doesn't save a tenth of the data that DF does.  Full stop.

Keep in mind that a lot of the stuff it is saving would already change by the time it gets to that point in the disk operations, if the game were left unpaused for the duration of the save thread.  That doesn't generally happen in games with background saving as you suggest.  How exactly would that be resolved?  Simply saving the state in RAM and then copying off in the background as the disk is ready for it would work, I guess, but double the RAM requirements of the game, which are already at a relatively "high" level as it is...