Print

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

[immibis]

I just sped up my fortress from ~15 to ~25 fps by setting the normal traffic designation cost to 1 instead of 2 (inspired by shadow_slicer's post). I suggest everyone else does the same unless they rely on traffic designations too much.

[andrewas]

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.

[Goran]

How about using drawbridges to disable access( and pathfinding flood) to areas not needed at the time?

[Grax]

How about using drawbridges to disable access( and pathfinding flood) to areas not needed at the time?

Not bridges but locked doors.

[decius]

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.

With [PARTIAL_PRINT:NO] I get 0-1 FPS for the opening movie and title screen. I'll post my values when they get in, but it takes a lot of time for me to do anything notable on this system.

[Nabobalis]

What tileset is that used in the op?

[Thief^]

If the pathfinder guesses too low in its estimation of the distance to the end, it will attempt every path that its estimate thinks could lead to a shorter path. It can even try going exactly the wrong way!

At one point I fixed a rounding error in a pathfinder (diagonal was being costed as 1.4, but the return from the heuristic function was an integer, so the heuristic was rounded down and was almost always too low as a result) which was causing excessively bad performance even for straight diagonal paths across open space. The error in the heuristic was less than one tile, but it caused the pathfinder to search the entire bounding square between the two points!

If the DF pathfinder assumes a tile cost of 1 in its heuristic, but the real cost is 2 for nearly every tile, that would explain why the pathfinder's performance is so bad.

[Thief^]

Sorry for the double-post, but here's a demo of what happens if the a-star heuristic is too low:
This example uses a real cost per tile of 2, and a heuristic in the pathfinder of only 1 per tile. It's also only 2D, and based around 4-direction movement, instead of 8. Despite that, its point is valid.
In the squares in the images the first number is the distance travelled, and the second is the heuristic estimate to the end of the path. At each step, the tile with the lowest total of both numbers added together is expanded. In the case of a tie, the tile with the lowest heuristic to the end is expanded.

Start 5 squares away from end. 0 travelled, 5 heuristic Expand start square. Three of the squares around it increase the total cost (8), one is closer to the end, but still at a higher total cost than the original heuristic (6) Expand the 2,4 square. The squares around it have total costs of 7 and 9 Expand the 4,3 square. The squares around it have total costs of 8 and 10 Expand the 6,2 square (it ties total cost with the 2,6 squares, but has a lower heuristic, so takes priority). The squares around it have total costs of 9 and 11 Here's where it starts going wrong. The 8,1 square is the obvious next step in the path to us, but to the algorithm, the 2,6 squares have the lowest total cost, so they're all tried next. Then 8,1 And again mistakes, as the 4,5 squares have a total cost of 9, vs the 10 of the end itself. If the squares to the right of the 4,5 squares had costs of 1, it would indeed be a better path. But they don't. Finally, we get to the end. The end path is a perfect straight line, but even in such a small example, we search twice as many squares as we need to. This is a 10-square example, starting at green and ending at red. In this case the number of tiles searched balloons to over 4x what's necessary. And it only gets worse at longer distances and when obstacles are added...

So there you go. An explanation of why setting the normal path cost to 1 would help, assuming DF uses 1 as its heuristic.