Print

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

[Sowelu]

Nah, that's not gonna work.  There's a huge amount of noise in the length of time before a dwarf ATTEMPTS to path, and in any case, the noise in human measurement is way bigger than the time it takes to path.

I'm pretty sure FPS and lots of paths over a long period of time is the way to go here.

[Deathworks]

Hello!

Anyhow, regardless of whether the theories about the raw values hold or don't hold, there is one thing that people do seem to agree upon:

If you do put high traffic on the skeleton paths and surround them by less favorite traffic zones, you will get at least some level of FPS improvement.

I think that is not disputed by anyone. So, even if we don't agree on the other aspect, I think it should be fine to encourage people to use traffic zones to tell DF where they want their dwarves to go to and where not to.

Deathworks

[ZeroGravitas]

Here's a warning for you guys. If you've been changing path costs in init.txt, make sure they have changed once you load the save.

I'm observing behavior that seems to indicate that DF saves the path costs, though I have yet to confirm it.

Edit #1:

* I have confirmed that DF is saving path costs.
* Path costs internally are multiplied by 256 or 362, I'm not sure what differentiates the usage between them yet.

Hmm.  I noticed that when I changed to [1:1:5:25], the 'designate path cost' menu still DISPLAYED that it was 1, 2, 5, 25.  I wasn't sure if that was an interface issue or whether those four values were getting stored instead of taken from the init.  If they're stored on world gen, half my experiments are invalid...but I personally still didn't see any difference between high@1 and medium@2.

Thank you for your memory hacking!

Also, that multiplication is clearly a horizontal/vertical vs diagonal movement, since 362 = 256*1.414.

wow. wait. so diagonal movement IS more expensive than horizontal/vertical??

[Sowelu]

If Jifodus is accurate, then dwarves certainly think diagonal movement is slower than non-diagonal movement (which is really how it should be).  I remember Toady saying back when 3d was just coming in, that diagonal movement would cost more too.  So yeah.

[numerobis]

Nah, that's not gonna work.  There's a huge amount of noise in the length of time before a dwarf ATTEMPTS to path, and in any case, the noise in human measurement is way bigger than the time it takes to path.

When you have a lot of idle dwarves and you suddenly make a lot of hauling jobs, they seem to take them immediately.  My game always freezes up right away when I do that.

[Ampersand]

This would make a lot more sense if the calculation is more complex than we realize. If there is something being calculated that we're not seeing that involves division and fractions, then, yeah, that could potentially lead to a bit of slow down, similar to why calculating Pi makes CPUs die.

If there is a significant amount of rounding of numbers, that may also pose an issue. It all depends on the actual complexity of the program.

[numerobis]

My CPU has no trouble at all computing 3, and that's Gospel pi.

[Dareon Clearwater]

I have nothing constructive to offer on this topic, but let me just say this is one of the most entertaining threads I've read all month.

[LegoLord]

My CPU has no trouble at all computing 3, and that's Gospel pi.

That's not pi.  That is pi rounded down.  Which is no longer pi.  Just 3.  The real pie is 3.14 . . . I can't go farther than that.  But the digits go on forever, which is why calculating it is bad for computers.

[IndonesiaWarMinister]

Pi: 3.1428657....

3? Massive failure on the writer's part...

[Ignoro]

Note he said "Gospel" pi.

I'm going to have to grab some community forts and do some testing later when I have time, seeing as no-one else seems to have a spare hour.

[GetAssista]

Pi: 3.1428657....

3? Massive failure on the writer's part...

Pi: 3.14159265358979

3.1428? Massive ditto

PS. Very entertaining thread indeed! I'll certainly try some of the tricks

[LegacyCWAL]

Euler's Pi: NOM NOM NOM

Silliness momentarily aside, I tried designating the main thoroughfares of my fort as high-traffic, and many of the "they'll never bother going there anyways" areas (like dead ends of ore veins) as restricted traffic areas.  Most of the time,  I'm getting a boost of about 2 FPS (which is like 15% ).  However, I'm losing that much off of "normal" when I designate a bunch of jobs in outlying areas (such as when I designate a bunch of CS silk webs for destruction).

[numerobis]

Note he said "Gospel" pi.

Looks like everyone else here was sleeping in Sunday school...

I get about a 15% boost from putting locked doors at the head of each exploratory tunnel.  I'm not sure how much of that is pathfinding, and how much something else -- I noticed in one fortress that was typically on lockdown that when I opened the doors, everything went much slower.  I'm not entirely sure why: the dwarves shouldn't have been trying to path out the front door (it was very far away) even when they had a convoluted path within the fortress.

[Ignoro]

I get about a 15% boost from putting locked doors at the head of each exploratory tunnel.

HE'S A WITCH!