Install Steam
login
|
language
简体中文 (Simplified Chinese)
繁體中文 (Traditional Chinese)
日本語 (Japanese)
한국어 (Korean)
ไทย (Thai)
Български (Bulgarian)
Čeština (Czech)
Dansk (Danish)
Deutsch (German)
Español - España (Spanish - Spain)
Español - Latinoamérica (Spanish - Latin America)
Ελληνικά (Greek)
Français (French)
Italiano (Italian)
Bahasa Indonesia (Indonesian)
Magyar (Hungarian)
Nederlands (Dutch)
Norsk (Norwegian)
Polski (Polish)
Português (Portuguese - Portugal)
Português - Brasil (Portuguese - Brazil)
Română (Romanian)
Русский (Russian)
Suomi (Finnish)
Svenska (Swedish)
Türkçe (Turkish)
Tiếng Việt (Vietnamese)
Українська (Ukrainian)
Report a translation problem
You may want to explore the community created Wiki on the subject, though it may be full of inaccuracies too: https://dwarffortresswiki.org/index.php/Maximizing_framerate
You can do your own !Science! -- save the game and try something, and record the FPS. Then go back to the original save and try something else and record the FPS...
It provides a way for the dwarves that might have built the wall from the wrong side and it also allows you to open it up later on if you left rock boulder there.
In most cases you don't need to fully mine entire levels since stone is plentiful (even if you want to use one specific type for its color) and ores on the default setting are in large amounts as well.
LOS improvements were released in v50.05 (back in January) -- but the code must do O(n^2) iterations in a nested loop (where N is the number of entities on the map). Just because A can see B does not mean that B can see A (hence why n^2) and not O(nlog(n)). This is begging to be parallelized to distribute that effort over all the available CPU cores :)
parallelize the outer loop for a cheap win -- all the logic inside the double nested loop must be made threadsafe though.
I do remember reading something about that specific for DF, but I can't speak to the current incarnation.
In general, though, providing more viable paths for something to pathfind through can cause unnecessary checks that would have otherwise not occurred had the large open space not been a large open space... It really depends on the type of pathfinding being used, how many actors there are and how often they're exposed to it.
I don't know how z-level changes work in that. Empty tiles that are not walkable by an actor should be culled, IMO.
There wouldn't be anything keeping your from clearing out a level then walling in the most efficient paths that you wanted dorfs to use, yourself. (I don't know what practical reason you'd want an entirely clear level for. World's Biggest Dance-floor? :))
It can be fun to build above ground every now and then, it's full of challenges that are much different from usual.
I don't remember the specifics but it's a combination of multi-threadings, updating the libraries, and general algorithm improvements. There is more details in the interview of Putnam by BlindIrl
You are right, it is (n^2+n)/2 -- when every unit must check every other unit.
The LOS code already has a distance limit, at least according to this post [www.bay12forums.com] . They say 17-25 tiles based on the observer skill -- but who knows? Without access to the source its hard to know for sure and whether that filter is done early enough in the computations.
There is also a sneaking skill that might factor in this as well.
Think of the real world: An eagle can see a mouse, but that doesn't mean the mouse can see the eagle -- I would suspect there is no symmetry due to things like that (or other reasons).
EDIT: @Fel and I said the same thing at the same time :)