Print

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

[Dragonunion]

I hope it is the right category(sorry when not)

1. What's your populationcap/strict population cap?
2. Which world generationsize do you recommend?
3. Which embarksize do you recommend?

reason for questions: My laptop is really bad and I want to know, how I get the best performance with these upper things
without game real game changes

computer data:
4gb Ram
2+ Intel pentium 2117(1.8Gh)
Intel hd graphics

thanks for answers!

[Canisaur]

I stick with a cap of about 80, but this is for gameplay reasons.  I feel like even at this number a lot of my Dwarves are often idling, and the more dwarves you have the more catastrophic a tantrum spiral is

I've never noticed worldgen sizing affecting FPS after the actual worldgen phase.  If you want 2000 years of worldgen, then obviously it's going to take awhile to make a huge world.
However, if you don't care about the stuff that worldgen adds (adventure mode destinations, historical figures) then feel free to gen a few pocket worlds until you have the biomes you want.

Embark size is is the biggest FPS hit of the three options you're asking about.  Unless you're making a sizable megaproject, 3x3 is more than enough to build a decent fortress.  After all, you can always expand vertically!  It's really only going to affect how much wood you have available (if you even have trees in your biome) and how large of caverns you need to worry about defending.  You can even experiment with a 1x1 embark if you're comfortable using DFHack.

And of course, the wiki has plenty to say about this: http://dwarffortresswiki.org/index.php/DF2014:Maximizing_framerate

EDIT: Oh, and since I notice you're not using a fantastic graphics chip: I got a big jump in FPS when my game window was large by lowering G_FPS_CAP to 8 in data/init/init.txt.  This value is how often your window redraws, and since this is a tile-based game anyway you're not going to notice a difference.

[Dragonunion]

thanks!
That with the graphic fps I've done some weeks ago and it helps a bit.

[Fleeting Frames]

1. However many is needed for what I'm currently doing.

Caniseur mentions 80, which is the level of megabeasts and goblin sieges if you don't mod them to attack at lower one(can be done in running world, but titans must be done in worldgen parameters).

I used 19/150? in Moonhome since 20 is the level for strange moods and first level siege trigger both (I think used for werebeasts) and I was breeding my way to mountainhome (requires 140 dwarves).

Outside of those things, I'd imagine I would be quite comfortable with 40-50 (half training at half time and 10x2 branches of experienced workers not training half time).

Each living creature on map will consume some fps (omniskill dwarves about ~20% more than animals for me in arena), so don't want to go overboard. Mind the visitor cap!!

2. I'm fond of painted pocket worlds - same principle as above, though, as much as you need and no more
(btw, like in inside fortress the main slowdown is in population, I think).

While Canisaur claims no slowdown, it keeps simulating each day in outside world with world activation - using same gen, on a 4200 year world with 162k civilized + about 50k in trolls/ogres/animal men population I get 550 FPS/30 GFPS on 1x1 embark right off the bat after enduring the slow 2 week crawl, while that same embark in year 2 (9 civs, so ~1300 population) flashes the two weeks by so fast I can't even catch them with my eye and runs at 700 FPS in same embark place.

Each day is about 1200 frames, so you can say the increase above cost me 21% of initial day, or ~0,36 seconds per 1,71 second day. Obviously much greater cost than 0,36 seconds per 30 second day, though! (40 FPS) [Albeit I'm not sure how much does it change with time, and my world is heavily tweaked, besides.]

However, without lot of tweaks, I know some swear by 129x129 worlds, as in them the distances are great enough to cause multiple isolated pockets (siege range is 30 tiles) to help people survive the megabeasts (though megas are also isolated by water in world gen and able to cross it to reach your fort.)

3. As an aesthetic thing, I think it's nice to have an embark you don't have to scroll in and zoom around a lot.

For an embark that is roughly as big as your screen, the answer depends on your tileset and monitor size. (To calculate, beyond the 48x48 tiles per each local tile you need 33 extra tiles to have just the standard menu, and 2 additional ones for height.)

The default ascii 12x8 tilesize would take 1416x1176 on a 3x2 embark, for instance. A 14x14 will let you fully view 1x1 with menu (currently using, as bit of an experiment), or 2x1 without on 1366x768 frequently found on 15,6 inch screens. An 1x1 tileset could fit 16x16 embark on 801x770.

I could also echo the above, and say "however big you need" (Because bigger embark = more pathing, plants, tiles to check every game tick = more fps lost)

What needs may you have? Well...

 • Fortress space. Most forts fit easily in 1x1; a single max size stockpile will consume less than half the space on it. However, there are macros for designating fortresses that take up to 5x7, iirc.

 • You may want to access multiple features on different local map tiles. Maybe a volcano + river embark (2x1 at the very least, but likely more). Or a steep cliff to build your fort in. Or cave + other underground features. Or boundary of igneous extrusive and sedimentary.

 • You might want some additional runup(so siege doesn't arrive right on front door)/treecutting/herbalism space. Though neither of the last one needs much, with junglification and fruits - 1x1 is enough to provide for latter, and the second one you will run into "I have tens of thousands of logs" if doing 'default' 4x4 with all tiles being tree-bearing without expressly setting out to consume tons of logs.

When I started, I had some players recommend 2 tree-bearing local tiles. If you want more later, you can also get some through 1 to 3 caverns (however many you generated), plus however many tree farm levels you use besides those, but it's not present right away.

You can even experiment with a 1x1 embark if you're comfortable using DFHack.

Actually, this is vanilla feature.

[PatrikLundell]

I only recently found that the attack triggers for megabeasts are defined in their raws, so if you want them to visit and still have a lower pop cap than 80 you need to adjust the raws (same format as the world gen titan attack trigger).

You need a 3*3 embark to guarantee the presence of at least one candy spire on the embark, or a 2*2 aligned on even region tile boundaries (in which case you get exactly one). That is, if you make a 2*2 embark in one of the corners you're aligned, and everything that's flush with those is aligned, etc.

I've seen a report of candy spires being AWOL on a single cavern embark large enough to "guarantee" their presence.

[Fleeting Frames]

That was me (and few others). In my tests it was something like 38 miracle poles present in 16x16, instead of full 64. I love my easy-to-find keywords.

If you want to maximize candy spires in a given small area, doing 4 8x8 embarks, reveal and exporting the images of magma layer for each of them will help you locate one (even 4 in 2x2, perchance). For boosting a single spire, increasing the useless smr and magma tiles will do that (and maybe bit more useful 3rd cavern miracle poles will be boosted by increasing stone between it and sea.

[PatrikLundell]

I've investigated the missing candy spires (using the world in the link), and believe I've found (sort of) why they're missing: all the missing ones are specified to reach the 3:rd cavern, while all the present ones were limited to the magma sea. Hacking two missing cavern spires to only reach the magma sea prior to embark made all 4 spires present in an aligned 4*4 embark. This was done using 0.43.05, not .03 so the issue remains.

I couldn't find a bug report for it, so I wrote one: http://www.bay12games.com/dwarves/mantisbt/view.php?id=10267

[Fleeting Frames]

Hm, that would explain it. Unfortunate, but with report at least it may be fixed sometime.

[PatrikLundell]

Well, I certainly expected it to have been reported, but my (not particularly powerful) search abilities failed to find any. Anyway, it's possible to fix the issue somewhat (by reducing the size of the spires, so you still lose out on candy) pre embark. I wouldn't be surprised if such modifications didn't stick between save/reloads (embarks are locked in on embark so they should be fine, but any other modified spires in case of abandonment/retirement and re-embark).

[PatrikLundell]

OK, I believe I've found how to fix missing candy spires properly in worlds with less than 3 caverns.
Changing spires set to reach the 3:rd cavern in a single cavern world to instead reach the first one causes it to appear, and, similarly, changing one set to reach the 3:rd cavern in a dual cavern world to reach the second one causes it to reach the bottom one.
I made a pre embark script to fix it: candy_corrector.lua

Spoiler (click to show/hide)

function candy_corrector ()
  if not dfhack.isWorldLoaded () then
   dfhack.color (COLOR_RED)
    dfhack.print ("Error: This script requires a world to be loaded.")
   dfhack.color (COLOR_RESET)
   dfhack.println ()
   return
  end

  if dfhack.isMapLoaded() then
   dfhack.color (COLOR_RED)
    dfhack.print ("Error: This script requires a world to be loaded, but not a map.")
   dfhack.color (COLOR_RESET)
   dfhack.println ()
   return
  end
 
  if df.global.world.worldgen.worldgen_parms.cavern_layer_count == 3 then
    dfhack.println ("This world has three cavern layers, so there's no need to correct anything.")
   return
  end
 
  local screen = dfhack.gui.getCurViewscreen ()
  local dim_x = df.global.world.worldgen.worldgen_parms.dim_x
  local dim_y = df.global.world.worldgen.worldgen_parms.dim_y
  local caverns = df.global.world.worldgen.worldgen_parms.cavern_layer_count
  local count = 0
 
  for i = 0, 256 do
    screen:feed_key (df.interface_key.CURSOR_UPLEFT)
  end

  --  Populate the feature structure
  --
  for i = 0, dim_x - 1 do
    for k = 0, dim_y - 1 do
      screen:feed_key (df.interface_key.CURSOR_DOWN)    
   end
   
    for k = 0, dim_y - 1 do
      screen:feed_key (df.interface_key.CURSOR_UP)    
   end
   
    screen:feed_key (df.interface_key.CURSOR_RIGHT)    
  end
 
  for i = 0, (dim_x - 1) / 16 do
    for k = 0, (dim_y - 1) / 16 do
     for l = 0, 15 do    
        for m = 0, 15 do
        for n, feature in ipairs (df.global.world.world_data.feature_map :_displace (k).features.feature_init [l] [m]) do
          if feature._type == df.feature_init_deep_special_tubest then
           if feature.start_depth < 3 then  -- Above magma sea
             if caverns == 0 then
              feature.start_depth = 3
            
                count = count + 1
            elseif feature.start_depth > caverns - 1 then
               feature.start_depth = feature.start_depth - (3 - caverns)
             
              if feature.start_depth < 0 then  --  Don't know if DF can generate spires reaching too high, but fix it if it does.
                feature.start_depth = 0
              end
            
              count = count + 1
            end
           end
         end         
        end
      end
     end    
   end
  end
 
  dfhack.println ("Fixed " .. tostring (count) .. " spires")
end

candy_corrector ()

[Fleeting Frames]

Oh, nice! Workaround for a bug is always neat, though actual usage will have to wait for me, as it is only useful once per shallow embark.