Print

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

[Draco18s]

but double the RAM requirements of the game, which are already at a relatively "high" level as it is...

You already can't embark on a 16x16 area, as the RAM requirements for the terrain alone are enormous.

[Jay]

but double the RAM requirements of the game, which are already at a relatively "high" level as it is...

You already can't embark on a 16x16 area, as the RAM requirements for the terrain alone are enormous.

Rather, I'm pretty sure you can if you make the exe /LARGEADDRESSAWARE, otherwise you hit the 2 GB virtual limit on 32-bit applications (at least in Windows, I'm clueless as to how the Linux version operates in this regard).
It just, yeah, takes a ton of RAM (though RAM is becoming a non-issue today...  my next system will have a minimum of 16 GB)

[Draco18s]

my next system will have a minimum of 16 GB

Remember that you're going to need a 64 bit architecture and OS.

[Rafal99]

I don't see any point in saving without pause. Saving usually takes 10-20 seconds for me, and I don't have any top level hardware. If your DF takes longer, then next time generate smaller world.
But still saving without quitting the game would be very nice option. Now I have to save, go to saves folder, backup the save so the next one doesn't overwrite it, then load the game again.
It doesn't take long but is very distacting, I lose a feel of fluent gameplay, and can't get it back for a few minutes.

[Baughn]

my next system will have a minimum of 16 GB

Remember that you're going to need a 64 bit architecture and OS.

And game, but at least on Linux I think there's (a hack?) that'll let 32-bit applications such as DF use the entire 4GB address space.

[Baughn]

I don't see any point in saving without pause. Saving usually takes 10-20 seconds for me, and I don't have any top level hardware. If your DF takes longer, then next time generate smaller world.
But still saving without quitting the game would be very nice option. Now I have to save, go to saves folder, backup the save so the next one doesn't overwrite it, then load the game again.
It doesn't take long but is very distacting, I lose a feel of fluent gameplay, and can't get it back for a few minutes.

That's what the seasonal autosaves are for, if you're looking for crash protection.

If you're doing this for Fun-protection, you're doing it wrong.

[Draco18s]

And game, but at least on Linux I think there's (a hack?) that'll let 32-bit applications such as DF use the entire 4GB address space.

A 32 bit OS cannot run 64 bit applications.  Even 32 bit applications that are tricked into using a 64 bit addressing space.

The Operating System doesn't know how to deal with it.

I was talking hardware and OS, not applications.

[dirty foot]

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.

I can respect that, but some people like to relive the situation again in order to learn what would work in any given situation.

[Baughn]

And game, but at least on Linux I think there's (a hack?) that'll let 32-bit applications such as DF use the entire 4GB address space.

A 32 bit OS cannot run 64 bit applications.  Even 32 bit applications that are tricked into using a 64 bit addressing space.

The Operating System doesn't know how to deal with it.

I was talking hardware and OS, not applications.

I don't see how this statement is relevant in.. any way whatsoever, really. I mean, it's correct, but I don't think anyone's contradicted it..

Oh, and incidentally a 32-bit operating system can perfectly well use more than 4GB of physical memory, with PAE. Though it obviously won't be able to have a single process use more than 2-3GB or so at a time, and.. no let's just not get into segmentation again.

[Draco18s]

Oh, and incidentally a 32-bit operating system can perfectly well use more than 4GB of physical memory, with PAE. Though it obviously won't be able to have a single process use more than 2-3GB or so at a time, and.. no let's just not get into segmentation again.

Although, "client" versions of 32-bit Windows (Windows XP SP2 and later, Windows Vista, Windows 7) limit physical address space to the first 4 GB for driver compatibility and licensing reasons, even though these versions do run in PAE mode.

[tsirig]

Hi all,

Not sure I should be posting my question on this thread but it does seem like it is the most related thread of the ones I could find.

I am new to DF and I want to move my fortress to continue on another computer. I thought it would be enough to just copy my "data\save\region1" folder of the first computer to the "data\save" folder of the second one. The second computer already has a "region1" folder so I just renamed the folder to "region2" and copied it. However, when I start the game and select "continue game" my region2 game does not show up.

I looked at the contents of the "region1" and "region2" folders to make sure they contain similar files and I was surprised to find that the former contains a file named world.sav whereas the latter contains a file named world.dat. Renaming world.dat to world.sav causes the game to fail to start.

What's up with that? :-S Thanks in advance for any replies.

Dimitris

[Sizik]

Looking at a few of my saves, they have world.sav if there's a game in progress (fortress or adventurer), and world.dat if not. Did you accidentally abandon?

[tsirig]

Thank you, Sizik!
After reading your reply I realize I have probably foolishly copied the wrong region. 
It does show up when I start in adventurer mode.