Print

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

[Footkerchief]

Footkerchief: I have a counterexample save to that. But it's presently tied up in competition. Conclusion: Ramps seem to not invoke this mistake.

Yeah, I'm trying to reproduce it now and I can't.  It's driving me nuts because I'm positive I've been able to reproduce it before. 

[madman]

Your floodfill idea is a good one, but the problem is that it's trying to do a straight-line distance check, a simple Euclidean distance, and is ignoring the (z₁ - z₂)² term.  As Draco18s mentioned in those linked threads, the game literally thinks that the distance from the trade depot to an item 20 z-levels directly below is ZERO.

I'm aware of that - that's why the quick and dirty fix would fix most of the problem.

What would bother me is to have a fix (such as 10*z penalty that one of the threads suggested) that breaks vertically designed fortresses. Not much point fixing one problem just to introduce another one. BTW, the correct distance metric (assuming stairs rather than ramps) would be max(|x₁-x₂|,|y₁-y₂|)+|z₁-z₂|. This is a mixture of Chebyshev and Manhattan distance. Floodfill would of course be 'as the dwarf walks'.

For my fortresses for instance (I started playing when it was already 3D, so I've never had the 2D influence on my play style), I tend to have a workshop cube (actually a rectangular prism) with _lots_ of connecting stairways, so the current situation doesn't hurt too badly, but a 1*z penalty would be the most accurate one. I make use of the fact that I mine another level down and my mason will empty it out for me (this is of course my design taking advantage of the current metric).

[Footkerchief]

BTW, the correct distance metric (assuming stairs rather than ramps) would be max(|x₁-x₂|,|y₁-y₂|)+|z₁-z₂|. This is a mixture of Chebyshev and Manhattan distance. Floodfill would of course be 'as the dwarf walks'.

I think we're arguing at cross purposes here.  Correct me if I'm wrong, but you're talking about using a better distance approximation and I'm talking about fixing a (hypothetical) bug with the current distance approximation, which aren't mutually exclusive.  Also, I'm not sure what makes your distance metric more correct -- Chebyshev distance doesn't seem to account for DF's different weighting of diagonal movement, and obviously the ramp assumption is unsound.

Anyway, I'm testing it now to see if this bug can be reproduced with depots.  Hopefully this is much ado about nothing.

e: yeah, it doesn't reproduce with depots either.  False alarm I guess, although that doesn't explain the Aug. 2008 bug report.

[madman]

I think we're arguing at cross purposes here.  Correct me if I'm wrong, but you're talking about using a better distance approximation and I'm talking about fixing a (hypothetical) bug with the current distance approximation, which aren't mutually exclusive.  Also, I'm not sure what makes your distance metric more correct -- Chebyshev distance doesn't seem to account for DF's different weighting of diagonal movement, and obviously the ramp assumption is unsound.

I stand corrected - I didn't know about a weighting for diagonal movement (that's what I get for being new to Dwarf Fortress). And, yes my comment was a side comment about a better approximation. Much better to fix the problem.

My understanding was that the problem wasn't about selecting stuff for the trade depot or building a workshop (that seems to be correct from what I've seen), but when someone at a workshop goes to grab some stuff to work on, which is somewhat harder to test.

[Footkerchief]

And, yes my comment was a side comment about a better approximation. Much better to fix the problem.

Yeah, a better approximation would be useful.  And I still like the idea of a short-range floodfill -- depending on the size of the item list and how it gets traversed, that could be beneficial.

My understanding was that the problem wasn't about selecting stuff for the trade depot or building a workshop (that seems to be correct from what I've seen), but when someone at a workshop goes to grab some stuff to work on, which is somewhat harder to test.

That's what I was mainly concerned about, yeah.  I couldn't reproduce that either though, so who knows.

[Logical2u]

LOGIC HATH SPOKEN.

Yes.
Yes I have.

Stop stealing my work wouldya.

All of the awesome updates on the bone and food work made me forget about all the work that had gone into workshops. Given that most of my problems in this game are due to rotting food and lazy butchers, the automation of various processes (Fish Cleaning? Yes please) will be awesome and hopefully save a lot of pausing and unpausing in the game.

The underground layers still slightly frighten me because of the shear prevalence they had in the demonstrative update. I seem to remember Toady saying there'd be an option for them - hopefully they won't intrude upon any massively complex designs I want to build (or that others actually build!).

I haven't been following burrows, but they are z-level dependent, yes? (like most other "definable" areas in the game) If so this will save me a lot of trouble in working out stockpile arrangement.

[smjjames]

Yea they are z-level dependent, we can't designate or define anything accross z-levels yet. The cursor for it works accross z-levels though, but thats different.

[Protactinium]

I'm still holding out for 11PM Eastern Time December 31, just so Toady can say he released it in 2009.

Debugging can suck it harder.

He actually has until Pacific Time, since he's near or in Seattle, eh?

[Footkerchief]

I haven't been following burrows, but they are z-level dependent, yes? (like most other "definable" areas in the game) If so this will save me a lot of trouble in working out stockpile arrangement.

Yea they are z-level dependent, we can't designate or define anything accross z-levels yet. The cursor for it works accross z-levels though, but thats different.

I'm not sure what Logical2u was getting at, but you definitely can designate burrows across z-levels:

You can make the burrow over rock and you can make it as large as you want.  If you get out of its bounds, you'll have to paint some more, but you can select an entire underground Z level with a simple rectangle command in advance if you want -- you can even move the cursor down to the lowest Z level so that the whole underground becomes one giant mining burrow at one command, if you find a reason for that.

[CobaltKobold]

Footkerchief: I have a counterexample save to that. But it's presently tied up in competition. Conclusion: Ramps seem to not invoke this mistake.

Yeah, I'm trying to reproduce it now and I can't.  It's driving me nuts because I'm positive I've been able to reproduce it before. 

My save merely was on the depot thing. Dunno about the construction- too much of all things to really say.

[Logical2u]

I'm not sure what Logical2u was getting at, but you definitely can designate burrows across z-levels:

My descriptive writing abilities have decreased substantially since focusing on pure physics/math, yes. My TAs are also aware of this.

Essentially I was asking if I could "stack" burrows. Which appears to be the case (and even better, I can stack them in groups of two, which means "Awesome work shop arrangement floor + big open stockpile floor" groupings (at least until caveins are turned on again) and hopefully the dwarfs won't go up or down twenty z-levels to grab some random trinket for their work rather than the gold studded platinum above them and to the side, because the platinum will be in their burrow rather than the other trinket). This means my workshop designs can become even more crazy and complex without sacrificing all ability to control what goes where.

However, there is probably a frame-rate cost for both of those extremes... *shrug*.

[smjjames]

I haven't been following burrows, but they are z-level dependent, yes? (like most other "definable" areas in the game) If so this will save me a lot of trouble in working out stockpile arrangement.

Yea they are z-level dependent, we can't designate or define anything accross z-levels yet. The cursor for it works accross z-levels though, but thats different.

I'm not sure what Logical2u was getting at, but you definitely can designate burrows across z-levels:

You can make the burrow over rock and you can make it as large as you want.  If you get out of its bounds, you'll have to paint some more, but you can select an entire underground Z level with a simple rectangle command in advance if you want -- you can even move the cursor down to the lowest Z level so that the whole underground becomes one giant mining burrow at one command, if you find a reason for that.

Oh, I had missed that. my bad.

Anyeays, yea its going to take some messing around with the burrows to figure out how to best use them.

[Greiger]

The idea might be a bit past but I kinda like the extra weight on grabbing items from closer z levels thought. 

I mean really, one rock 30 feet away and one rock 25 feet away but up a flight of stairs, which one would you grab first?

[Saber Cherry]

The idea might be a bit past but I kinda like the extra weight on grabbing items from closer z levels thought. 

I mean really, one rock 30 feet away and one rock 25 feet away but up a flight of stairs, which one would you grab first?

There's no reason to hard-code the number, either.  Something like this could lurk in the text files:

"Z_LEVEL_PATH_TRAVERSAL_COST:2"

...I'd set it to 5 or so, and people who like to drive their dwarves to death on stairs could set it to 0.  But realistically, non-crazy dwarves should prefer stuff on the same level.

Incidentally...  I don't think that using Euclidian distances is prudent inside, since square-grid maps lead to rectilinear fortresses.  It's fastest - and inside my fortresses, most accurate - to estimate distances with (|x2-x1|)+(|y2-y1|)+C*(|z2-z1|).

Also...  since long shafts are common for stairs...  it seems wise to apply a flat penalty for changing z-levels (the cost to find the stair-shaft) in addition to a per-level cost.  In other words:

(|x2-x1|)+(|y2-y1|)+C*(|z2-z1|)+(if(z2==z1),0,D)

...where C and D are constants, and the last term uses Excel conditional format: if(condition),then_value,else_value

[G-Flex]

I don't know if this is relevant or if you're aware, but DF actually *does* factor in the extra time required to move diagonally.

Of course, it only does this for horizontal travel, not for travel between z-levels, as stated in one of the REQs.