Print

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

[Ralje]

I think there should be limits to the z-axis when your on a huge map. If your map is say 12x12 and your fortress is basically Z-levels straight line down, it may cause a ton of unnecessary lag (depending on when the game accounts for the extra z-levels). For large maps like this, maybe only 1 z-level down and 1 z-level up is all you need to make a great fortress.

[Tahin]

I compact fortress in a "cube" shape is infinitely more effective than one spread out across a huge area. There really is no reason to have bigger than a 5x5 area.

[Fedor]

quote:Originally posted by Tahin:
<STRONG>I compact fortress in a "cube" shape is infinitely more effective than one spread out across a huge area. There really is no reason to have bigger than a 5x5 area.</STRONG>

... except if Neat Fun Stuff can only be included in an area larger than this.

The OP's suggestion has possibilities.  If getting rid of sky layers can at all improve speed, I'd be glad to axe all but the first two or three (unless I wanted to build a tower).  I'd be more hesitant to delete underground layers because of the possible loss of all igneous intrusive rock, but it's certainly an option.

I'd actually love to know why mere empty rock or sky, in the absence of magma or water or critters, slows down the game.  What's being calculated here?  Is it necessary?  Can it be made more efficient?

For the present, my workaround is to stick with flatter maps.  Gentler slopes mean fewer z-levels.  I regret not being able to have fun with cliffs, but you get the play value you can with the computer you have....

And feel very grateful indeed to Toady for all his hard optimization work so far!

[Narvius]

I think Z-Axis levels shouldn't be loaded until you really need them (you don't need them if they are more than one level from a point you may reach using your legs or your picks.)

[Narvius]

(Damn, I still don't know where the edit button is.)

Something like...

code:

(Sideview)
(Unloaded)
SSSSSSSSS  ~ Sky
   D
#########  ~ Ground
(Unloaded)

and later...

code:

(Unloaded)
SSSSSSSSS  ~ Sky
  <        ~ Downwards stair
##X######  ~ Double stair
##> D####  ~ Upwards stair, dwarf
#########
(Unloaded)

...

[Pyro93735]

From what I've gleaned from other threads on the matter, any specific tile isn't entered into calculations and memory (and lag causing) until it has been discovered. This would be why chasms can increase lag - because it reveals tiles on what is sometimes 14 different levels, with hundreds of tiles revealed total. However, as I understand it, the major source of lag is from the AI calculations of the dwarves and animal/dwarven pathing. But if removing the sky cut down on lag, sure, I'd rip off all but a few layers. Maybe a .ini option?

[Nesoo]

quote:Originally posted by Narvius:
<STRONG>(Damn, I still don't know where the edit button is.)</STRONG>

The paper and pencil icon on your post.

If removing sky layers was an option (definitely one I would support; unless I'm making a tower, I don't need 15 layers of sky), I'd rather it be something that can be selected at embark so I don't have to fiddle with the init if I do decide I want them for a new fort. Same could be done with underground layers.

[Draco18s]

quote:Originally posted by Pyro93735:
<STRONG>From what I've gleaned from other threads on the matter, any specific tile isn't entered into calculations and memory (and lag causing) until it has been discovered. This would be why chasms can increase lag - because it reveals tiles on what is sometimes 14 different levels, with hundreds of tiles revealed total.</STRONG>

It doesn't load the whole level though, each z-level is cut into blocks and the chasm (underground river, magma vent/pool, etc.) only cause the ones that they pass through to load.