Bay 12 Games Forum

None of these utilities work with DF2010 yet. A new Stonesense should be released soon. Visual Fortress is not in active development right now, there was talk of someone else picking it up but they'll need to be better coders than I am. If you need a visualizer right now, then you should be playing 40d, probably 40d18, which I think is used in the last release of mayday before he switched to DF2010.

I got r49 compiled last night. It mostly works, but if anyone wants to work on getting it to read DF2010, r12 or r20 are probably better starting points.

EDIT] After playing with it a bit more and getting the textures to load the right way up, r49 is looking more attractive. But it still needs a fair bit of work before it looks good with shaders on, and its broken with shaders off. Is there an OpenGL guru in the house?

Does anyone have any comparative numbers for "I had X dwarves and everthing designated a normal traffic zone. When I changed the cost of the normal traffic zone from 2 to 1, my FPS changed from A to B."?

On a 4x4 embark with flowing water, I typically end up with 6-7 FPS in the late early game; I tend to have about 40 dwarves pathing at that point, and I can't figure out how to keep doing anything without producing a lot of hauling jobs. Any way to bump that up that doesn't involve buying a computer from this decade would help a lot.

Sounds like you're in an idea position to test it yourself. Find init.txt under data/init/ , and find the line which gives the costs for different tiles. The default numbers are 1,2,5,25 IIRC, change that to 1,1,5,25 and see if your framerate improves. Also, you might try setting traffic zones to guide pathfinding through the busier sections - if a room isnt often pathed into, then put a restricted zone in front of it so that pathfinding never even considers it.

Beyond that, people are reporting good results from setting partial print to yes.

Actually, no, I was wrong and they were right. The problem is that, while the heuristic is assuming a base cost of 1 (Which it must, or it becomes possible to return an 'optimal' path which takes no account of a high traffic zone) but most tiles cost at least 2, then the algorithm has to consider many more tiles than if the basic tile cost matched the heuristics expectations.  If the destination is to the west, then every tile to the west increases the path cost by two and the heuristic cost decreases by 1. The increased path cost will force the algorithm to search one square east for every two squares west, even before all paths to the west have been exhausted.

That should not make a difference. A grid of cost 2 squares should behave the same way as a grid of cost 1 squares. Its the interaction between different costs that makes the difference. Such is theory, anyway, if you have done any testing then let us know.

I'm also wondering if people have good ways to counter pathfiding slowdowns. I still can't get my head around the Traffic features (I know these are older then the new version). How does one use these effectively.

These features change the cost of pathing across a square. By default, a dwarf will pathfind 12 squares past a restricted zone before it attempts to path through it.

So, for instance, if you have a room just before a corner, normally dwarfs will attempt to path into the room to get round the corner. If there is no such shortcut,they will back up and path along the corridor. Putting a restricted zone in the door of the room will cause dwarves to first pathfind around the corner and only back up to the restricted zone when they have exhausted their attempt to enter the room from the far side.

This makes pathfinding into the room more expensive, but makes pathing around the corner cheaper. If the room is only occasionally visited and the corridor is heavily travelled, this will result in improved performance overall. On the down side, you need to do this throughout your fort for it to make a measurable difference.

In short, use restricted and high traffic zones to guide pathfinding towards the most common path through an area in cases where heading straight towards the destination won't get you there, forcing pathfinding to back up and try again. 

Stub template which redirects to the 40d page and places the DF2010 page in category:DF2010 articles in need of creation? Not a real fix to the problem, but it would be an improvement.

Under your scrap everything logic we may as well wait for the next version before making new pages so we don't have to scrap all the hard work again...

Scrap? The 40d namespace has lost nothing, except there are still a few links that need to be fixed. The bot, in retrospect, could have done a better job, if it had normalized links before the move this would have been a lot easier. And as always, if everyone who visited made just one fix, the problem would have lasted an hour at most. As it is, one week on and its still being fixed.

If you want to help solve the problem, you can add {{av}} templates to the stub/nonexistent articles you are complaining about. That will at add the links to the older version of the article. Obviously content needs to go into these articles as well but it has to be verified as you go, otherwise we wind up with a wiki full of information that everyone 'knows' is correct and there will be no procedure in place to check it for errors. That will take years to sort out completely.

Or if you just want to get straight to the 40d version of the article, then add '40d:' to the search string and you go straight there.

Not much. Df2010 currently lacks PNG support so you have to use an older version of Mayday. Can't remember which number you need, but someone already set it up. Theres a link to it on the wiki: http://df.magmawiki.com/index.php/Main_Page