Print

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

[Larix]

When i encounter this problem, it's either
a) forgot to restrict the bottom of the moat (yes, yes, you said _you_ did, i'm talking about the errors _i_ tend to make)
b) bridge too far out of the way - a tile of restricted designation adds 25 distance to the calculated path vs. 2 normally: if the path over the bridge is 100 steps vs. 7 through the moat, the moat is still considered shorter.
c) bridge doesn't connect properly
d) accidentally restricted the bridge, too

If you made none of these errors, i could only come up with e) edited pathing costs to something useless (parameters can be changed while looking at the designation menu via q/r or somesuch). Or f) it's actually some sort of scare effect you didn't notice (something scary near the bridge makes dwarfs flip out and jump into the moat; although it's more common to see them parkour or climb trees).

Dwarfs just won't walk through a restricted four-wide moat if there's an unrestricted bridge four steps to the side.

You can always remove the ramps inside the moat. Dwarfs won't normally jump/climb just to shave a few tiles off a path.

PS totally forgot - g) moat is part of an active alert burrow, while bridge isn't. Didn't occur to me, because i don't do burrows.

[Urist McWangchuck]

traffic designations really need an "infinite" option. Would makes things so much more intuitive.

I thought there was an infinite restriction - just suspend a construction over the site.

[GavJ]

traffic designations really need an "infinite" option. Would makes things so much more intuitive.

I thought there was an infinite restriction - just suspend a construction over the site.

That's really clever and I will use it, but it should be in the proper intuitive menu etc. For example ive played for three years and never thought of this...

[Larix]

How is this supposed to work? My miners happily walked through a moat "covered" by overlapping suspended bridges or floors and right through designated and suspended walls. These designations didn't affect their pathing in the slightest.

[Saiko Kila]

Is there a guide to explain how to edit that, and if so will effects of editing take place immediately in 40.10?

Look in data/init/d_init.txt for the PATH_COST setting. If you change this, the new values will be active when you next start DF and all future sessions.

Values are saved in the savegame though, so to change cost in existing fortresses you must do it manually in every each of them.

[Loci]

How is this supposed to work? My miners happily walked through a moat "covered" by overlapping suspended bridges or floors and right through designated and suspended walls. These designations didn't affect their pathing in the slightest.

It doesn't. It's based on an old v0.31 trick to get your dwarves to build walls from the "proper" side, which hasn't worked for years at this point. Ignore it.

[dwarf_reform]

Would it be terribly game-breaking if Toady changed traffic zones so that (sane) dwarves would never touch a restricted tile even if it meant death? I honestly thought this was already the case (and I should have ran that test where I made a restricted-zone maze and check if they ran it properly)..

So.. Say I'm running a reclaim of one of these new cavern-layer-piercing sprawling worldgen fortresses and I want my dwarves to live inside the big square surface room and not go down the staircase into the underground part of the fort for any reason!? With a burrow I'd basically want the entire map included except the fort entrance/staircase area.. Other than that all I can think of is walling it in to keep them 100% out of there :| And other than walling it off or locking it how would I stop random stray cats from wandering down there even if dwarves would fully respect a traffic restriction??

Anyway, there's something terrible at the bottom of the stairs, if you hadn't guessed by now

Off topic, a good quick way to explore those long worldgen fort's main stairwell safely is to hurl a cat down the shaft :> He reports back what he sees the moment before he splashes at the bottom..

[Miuramir]

Would it be terribly game-breaking if Toady changed traffic zones so that (sane) dwarves would never touch a restricted tile even if it meant death?

Well, it would break the system for all the people who are using it normally, so that's unlikely; also, it wouldn't actually do what you want.  The "traffic" system is *pathing hints* for the algorithm that figures out *how* dwarves get from A to B; it has no influence on *whether* dwarves are trying to get from A to B, nor should it.  If you turned the path cost up to crazy levels, it would just force the computer to search the whole fort before deciding, yep, that's the only practical route; slowing down calculation to no useful end. 

If you don't want your dwarves going someplace, install a door, hatch, grate, bars, floodgate, etc.; constuct a wall, etc.; place a blocking item like a statue, etc.; or use a burrow. 

[Loci]

If you don't want your dwarves going someplace ... use a burrow.

Again, burrows do not work like that. A burrow only restricts which jobs a dwarf may take, not where a dwarf may move.

Since there seems to be ample confusion on this, here's a simple illustration:



The metalcrafter (circled in orange) is assigned to the burrow (outlined in yellow). After the metalcrafter pulled the left lever, the door was locked and the right lever was ordered pulled. Without a moment of hesitation, the metalcrafter marched right out of his burrow and around the "dangerous terrain" detour at the top of the image to pull the right lever. Being assigned to a burrow which excluded the "dangerous terrain" did nothing to prevent the dwarf from moving through it.

Would it be terribly game-breaking if Toady changed traffic zones so that (sane) dwarves would never touch a restricted tile even if it meant death? I honestly thought this was already the case (and I should have ran that test where I made a restricted-zone maze and check if they ran it properly)..

Back in v0.34.11 you could emulate this behavior when playing with temperature disabled. Any tile which contained magma/lava would be set to a high temperature; with temperature calculations disabled the tile remained blisteringly hot even after the magma/lava was gone. So hot, in fact, that a dwarf would voluntarily die of dehydration rather than path through it (as several of my miners were kind enough to demonstrate). This behavior probably still works in v0.40.x, though I haven't tested it. Theoretically, a dfhack plugin could automatically set the temperature of "restricted" tiles high enough that dwarves would never path through them, effectively making "restricted" tiles truly restricted. Unfortunately, it would probably also affect invader pathing (at least for combustible invaders).

[Trouserman]

Well, it would break the system for all the people who are using it normally, so that's unlikely;

That wouldn't be much of an issue if done at a major version update which breaks save compatibility, or otherwise makes starting a new fort the far better option to updating an old one. Adding a fifth designation instead of replacing one of the existing ones also comes to mind, but that itself would likely break save compatibility (and there are four presumably because it's two dedicated bits).

also, it wouldn't actually do what you want.  The "traffic" system is *pathing hints* for the algorithm that figures out *how* dwarves get from A to B; it has no influence on *whether* dwarves are trying to get from A to B, nor should it.  If you turned the path cost up to crazy levels, it would just force the computer to search the whole fort before deciding, yep, that's the only practical route; slowing down calculation to no useful end. 

If you don't want your dwarves going someplace, install a door, hatch, grate, bars, floodgate, etc.; constuct a wall, etc.; place a blocking item like a statue, etc.; or use a burrow.

Making the pathing cost infinite would have the same effect on pathing as placing a wall, door, etc. It would force the computer to search the whole fort before deciding, yep, there's no route there, slowing down calculation to a rather useful end. (Unless DF caches information about discontinuous regions, in which case infinitely restricted pathing could be made to benefit from the same quick accessibility checks.) A designation wins over a wall when you need the dwarves to avoid going through a certain area, but building walls would take too long, is impractical, or would block some non-dwarf activity you want to allow (eg, minecarts).

[Trouserman]

Look in data/init/d_init.txt for the PATH_COST setting. If you change this, the new values will be active when you next start DF and all future sessions.

Values are saved in the savegame though, so to change cost in existing fortresses you must do it manually in every each of them.

Are you sure about that? I know the raws are copied in the save directory, but I don't think any of the init settings are. Other changes to that file certainly take effect in the next session, which is trivial to verify for something like the VARIED_GROUND_TILES setting.

[Larix]

Look in data/init/d_init.txt for the PATH_COST setting. If you change this, the new values will be active when you next start DF and all future sessions.

Values are saved in the savegame though, so to change cost in existing fortresses you must do it manually in every each of them.

Are you sure about that? I know the raws are copied in the save directory, but I don't think any of the init settings are. Other changes to that file certainly take effect in the next session, which is trivial to verify for something like the VARIED_GROUND_TILES setting.

Quick test says that's how it works. Not surprising, really: the pathing cost values can be edited in an active game and are saved with the game. The settings in d_init just change the defaults for new games, they don't overwrite the saved values of already-existing regions.

Once again - to change the pathing settings for an active save, you must change the values in the designations menu: d-o -> move "active" highlight to the setting you want to change, qQwW to change pathing cost. This is the only way to change settings in an already-existing fort.

If you want changed values for all future games, go ahead and change the d_init settings; but that only affects worlds (forts?) created after the change.

Making the pathing cost infinite would have the same effect on pathing as placing a wall, door, etc. It would force the computer to search the whole fort before deciding, yep, there's no route there, slowing down calculation to a rather useful end

I don't think so. All numbers in a computer are finite, infinity can only be emulated by infinite loops, division through zero or other errors. I.e. either you have a figuratively infinite (extremely big finite) pathing cost, which would just waste calculation cycles and still path through your blocked area, or you have a truly infinite cost, in which case the program hangs and crashes when trying to calculate a path. You could also get wraparounds or data overflow.

I'd like it if we had a convenient means to specify "forbidden" zones, but i don't think throwing ludicrous values at the current pathing algorithm is the way to do it.

[Trouserman]

Quick test says that's how it works. Not surprising, really: the pathing cost values can be edited in an active game and are saved with the game. The settings in d_init just change the defaults for new games, they don't overwrite the saved values of already-existing regions.

Once again - to change the pathing settings for an active save, you must change the values in the designations menu: d-o -> move "active" highlight to the setting you want to change, qQwW to change pathing cost. This is the only way to change settings in an already-existing fort.

I stand corrected on this setting.

All numbers in a computer are finite, infinity can only be emulated by infinite loops, division through zero or other errors. I.e. either you have a figuratively infinite (extremely big finite) pathing cost, which would just waste calculation cycles and still path through your blocked area, or you have a truly infinite cost, in which case the program hangs and crashes when trying to calculate a path. You could also get wraparounds or data overflow.

I'd like it if we had a convenient means to specify "forbidden" zones, but i don't think throwing ludicrous values at the current pathing algorithm is the way to do it.

This wouldn't be accomplished by setting the pathing cost to some ridiculously high number and then using the algorithm unchanged. It would be accomplished by not considering those cells when building the path, exactly as is done with walls. In order to not cause problems for old forts, this could be done only when the cost is set to "infinity". There is no problem with representing infinity on a computer. Just choose some particular value outside the range of allowed finite values to represent it, and treat it as a special case. (For example, if the value is -1, treat it as infinite.)

[Larix]

It would be accomplished by not considering those cells when building the path, exactly as is done with walls. In order to not cause problems for old forts, this could be done only when the cost is set to "infinity". There is no problem with representing infinity on a computer. Just choose some particular value outside the range of allowed finite values to represent it, and treat it as a special case. (For example, if the value is -1, treat it as infinite.)

That's not "set to infinite", that's "ignore". -1 isn't infinite, and it's not treated as infinite by the pathing algorithm (spoiler: you can edit pathing cost to negative values, and the algorithm treats such tiles as having negative pathing cost). I can't speak with authority, but i strongly suspect you'll have to completely step outside of the pathing algorithm to forbid a location. The option could be added to the traffic designations menu, but it would need to use a different coding construct to work.

More than you'd ever want to know about pathing: http://www.bay12forums.com/smf/index.php?topic=128855.msg4421534#msg4421534
And i just gave it a whirl - negative pathing costs are still possible and still work in .40.11 - dwarfs will run laps in negative-cost areas until they've "worked off" the pathing costs incurred so far before they continue going to their destination.

[Trouserman]

That's not "set to infinite", that's "ignore". -1 isn't infinite, and it's not treated as infinite by the pathing algorithm (spoiler: you can edit pathing cost to -1, and the algorithm counts its tile cost as a proper -1). I can't speak with authority, but i strongly suspect you'll have to completely step outside of the pathing algorithm to forbid a location. The option could be added to the traffic designations menu, but it would need to use a different coding construct to work.

I clearly stated that the algorithm would have to be changed to treat the chosen value as a special case. The fact that -1 is finite is irrelevant; it's just choosing some particular bit sequence to represent the special "infinity" value, which would receive special treatment. Consider floating point numbers. http://en.wikipedia.org/wiki/IEEE_754-1985 This standard defines specific bit sequences to represent positive and negative infinity. Those bit sequences could have represented additional finite numbers, but it was more useful to define particular special values which behave differently from numbers in the available finite range.

The fact that -1 is currently permitted is also irrelevant. It's just an example, and you could choose any reasonable value to remove from the currently accepted range. -1 seems perfectly reasonable to me, as it's not really a useful value. In fact, it violates some assumptions made by the algorithm to ensure that a shortest path is chosen. (I notice this point is brought up in the post you linked, though I already knew it.)