Print

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

[Fnear]

I'm having two issues with this...
1) Dwarves are triggering the pressure plate, walking past it, but not dropping (or if they are, they're picking it back up).  They stay long enough for the hatch to close, walk across, and drop it past the hatch.
2) They're totally not drawing from the take-from stockpile if there's stray stone around.  Probably not a big deal.

Layout is the standard 5-squares (mine goes west to east):

Code: [Select]

####d#
t^shs#
####d#
stockpile A, pressure plate, stockpile B, hatch, stockpile B

And I have a set of 5 of them arranged N/S with doors connecting the special square (necessary since dwarves keep finding a way to drop stone on it).

I suspect I can solve it with a water delay of some sort where I have a second pressure plate that triggers on 3/7 water and untriggers on 1/7 with a pressure plate on the way out (the original plate would both trigger the hatch and drop the water; new plate (replacing t, the draw-from stockpile) would reset the water).

Code: [Select]

new undump...
####d#
^^shs#
####d#

water delay
z+1
#####
->wh#
#####

z
####
#^d ->water goes away
####

Has anyone else run into dwarves as clever and patient as mine?

[Nil Eyeglazed]

Dwarves are triggering the pressure plate, walking past it, but not dropping (or if they are, they're picking it back up).  They stay long enough for the hatch to close, walk across, and drop it past the hatch.

I saw something like this with heavy things-- ogres in cages, in particular.  It wasn't that the dwarves weren't dropping, it was that they were burdened heavily enough that the hatch actually closed before they realized that path was ever interrupted.

Adding in a delay would help, but if you're seeing what I think you're seeing, what you want is a delayed close signal, not a delayed open.  With a delayed open, fast dwarves can actually cross the hatch before it ever opens, breaking the undump.  What you've drawn looks like something that would work-- but I don't think I understand very well, because what you describe in words sounds like something completely different.

You could make a water-based delayed-close undump with something like this:

Code: [Select]


 Sh##
 #^b#
 ##_D

side view: S is a source of water, _ is floor (open space), h is hatch linked to undump pressure plate, # is wall, ^ is pressure plate set to trigger on 2+/7 water, linked to undump hatch and to this diagram's bridge, b is retracting bridge linked to this diagram's pressure plate, D is a drain for the water

[code]

So in this diagram, you still get a nearly instant open signal-- probably takes around 6-12 ticks for water to reach the pressure plate-- but once there, it holds the open signal for a little more than 100 ticks longer than it normally would, because the bridge permitting drain has 100 tick lag.  What it ought to do is hold the hatch open for a little over 200 ticks, rather than only for 100 ticks.  (This also slows throughput a little bit.)  If your source doesn't refill fast enough (at least 4/7 water in 100 ticks), you could get malfunctions, but 4/7 in 100 ticks doesn't strike me as particularly difficult flow.

[simonthedwarf]

Alternatively, never make stockpiles. Goods get left where they are made!

[Nan]

I believe that in .34 undump no longer works as originally designed. Dwarves now stop their task when their route is broken and thus drop their item on the pressure plate itself, which cannot be made a stockpile.

Not that it's an entirely bad thing. Now it's time to design the undump 2.0, using entirely different principles.

The basic principle is this: once the item has been dropped by a dwarf, push it using flowing water into the final "undump" tile.

I initially had some ideas on how to do this, but when I played around with it in game I found an even more elegant method.

Build a pump, have a floor in front of the pump, and then downstairs adjacent to the floor

There are counterpart upstairs on the level below, to allow the downstairs to function as drains. Make a stockpile covering the downstairs and adjacent tiles.

When the pump is operated, the water disappears straight down the downstairs, but the items are knocked off!


It works superbly. There is no pathfinding disruption, and the dwarves don't get pushed around by the water to a problematic degree. No announcement spam. Items are spread out so when it comes to mass-collect them there is no traffic jam. And it elegantly handles 5 or 6  undump" tiles (you can also use the pump outlet tile as undump tile, though dwarves might get pushed around more). Furthermore, it is unjammable, it cannot break down and never requires manual intervention to reset.

And while in this case I'm using an aquifer, it fully recycles water, no water leaves the system. Thus it should operate just as well with a cistern on the z-level below.

It DOES require either a dwarf operator (which isn't really a big deal, what with immigrants being so cheap) or a power source. If an aquifer is handy then aquifer flow can be exploited to power it.

Here's the two other configurations which work fine:

Spoiler (click to show/hide)

[Nil Eyeglazed]

That does look good.  Especially for transfer of materials between quarantined burrows (channels instead of stairways, build a grate over one to allow access).  Has Toady fixed the bug where things would sometimes disappear when pushed by flow?

[Tharwen]

That does look good.  Especially for transfer of materials between quarantined burrows (channels instead of stairways, build a grate over one to allow access).  Has Toady fixed the bug where things would sometimes disappear when pushed by flow?

Nope. That was happening to me a couple of days ago (in version 0.1).

[Nan]

Now I have a water-powered undump in a real fortress for bringing all my junk to the depot, at the moment it's used for prepared meals and lower quality mechanisms. It works superbly, very smooth.

If any objects are disappearing, they're disappearing cleanly. If I remove the stockpiles and items I can still build walls on the tiles so there are no stuck invisible items. I don't think it is erasing items. If it is sneakily erasing a few items from existence I don't think I'd mind. It's more a decluttering device than anything.

I have discovered one limitation though, the small volume of water involved seems to be unable to effectively move heavier items such as stones. Conventionally heavy items such as logs, mechanisms and anvils are fine. And it's capable of easily pushing stones off the pump outlet tile itself, it just can't (easily) do the "shunt" trick of pushing a stone off the downstairs onto the dry stockpile tiles. It seems that the weight limit is arbitrarily set at 100, items which weigh less than 100 are almost instantly shunted by the water, items weighing more than 100 take MUCH longer to be shunted, but it does seem to eventually happen. In any case, this only effects stones, corpses and possibly butchering products of large animals. Items which are only infrequently heavy, such as massive stacks of forgotten beast or even the corpses of most vanilla sieges would probably still be handled okay since the water seems to eventually move even heavy objects, it just doesn't work efficiently for mass-stockpiling stones.

[Will_Tuna]

I believe the defUKT IS 500k which is horses and such, you need to set it lower to 60,000 for dwarves.

it is 6000 for dwarves!

[Fnear]

I've done some additional analysis on the original undump, adding some delay mechanisms.  None of them is foolproof.  And my dwarves are ... well ... you get the point.

I built a chunk of obsidian on the top layer of a two layer aquifer and tried a few options for turning on a switch with water and then turning it off by draining into the lower aquifer.  The nice thing is the delay switches are pretty compact.

The delay pressure plate is set to trigger on water 2/7 - 7/7.  The undump pressure plate is set to trigger on dwarf or heavier, citizens trigger.

The undump.  ^ = pressure plate, X = wall, D = door(locked), p = stockpile, h = hatch.

Code: [Select]

XXXXDX
 ^phpX
XXXXDX
1) Undump plate opens delay door, delay plate opens undump hatch. (A = aquifer, D = door, ^ = pressure plate, v = channel to aquifer below).

Code: [Select]

XXXXXXX
A D^ vX
XXXXXXXThis one was the simplest, using the flow across the delay plate and the 100 tick delay on door closing to keep the hatch open at least 100 ticks longer.  I observed at least one instance of a dwarf getting to the lure tile in the undump before the hatch opened.

2) Undump plate opens delay door and undump hatch, delay plate opens undump hatch.  Same setup as above but the undump plate links to the undump hatch.

This one was my response to the problem of dwarves making it across the hatch before the delay trigger fired.  It does seem to open instantly.  But eventually I still saw alunite on the lure tile, so they are making it across somehow.

3) Undump plate opens delay door, undump hatch, and delay floodgate, delay plate opens undump hatch. (F = floodgate)

Code: [Select]

XXXXXXX
A D^FvX
XXXXXXX
The floodgate was actually there from the start, but it got blocked by stone since I didn't clear out the delay after channeling it.  So I cleared it and tested with the floodgate - which should only add a trivial additional amount of time (since the door closes at about the same time the floodgate opens and draining from 7/7 vs like... 4/7 is not that significant).  Results were the same as without the floodgate - alunite still made it to the lure.

I'll try one more option.  No floodgate, but delay plate set to trigger from 1/7 - 7/7.  So evaporation will close it.  This will be a very slow undump, but that may be good enough to keep some amount of flow of stuff to multiple sorted stone/ore dump zones.

[MarcAFK]

I believe the defUKT IS 500k which is horses and such, you need to set it lower to 60,000 for dwarves.

it is 6000 for dwarves!

Actually according to the wiki dwarves are 60000, but on the pressure plate it'll show as only 600

"First of all, numbers are only showing their first four most significant digits; 500,000, the default minimum weight, will appear to be 5000 in-game. It is easy to double check what you want to set it to by using a lookup and reverse lookup on the list, to compare what the game says about a creature, and what the list says. "

[Nil Eyeglazed]

The delay pressure plate is set to trigger on water 2/7 - 7/7.  The undump pressure plate is set to trigger on dwarf or heavier, citizens trigger...This one was the simplest, using the flow across the delay plate and the 100 tick delay on door closing to keep the hatch open at least 100 ticks longer.  I observed at least one instance of a dwarf getting to the lure tile in the undump before the hatch opened.

So it's adding an open+close delay set by the speed of flow.  In other words, it's probably opening ~10 ticks after step on to plate, and closing ~150 ticks (?) after step on to plate.  (Basic undump hatch is opening at 0 and closing at ~110.)  Fast dwarves can cover two tiles in that time.  You could extend the undump draw tiles, or orient it diagonally; the extra delayed close should help against slow dwarves.

Undump plate opens delay door, delay plate opens undump hatch. (A = aquifer, D = door, ^ = pressure plate, v = channel to aquifer below).

2) Undump plate opens delay door and undump hatch, delay plate opens undump hatch.  Same setup as above but the undump plate links to the undump hatch.[/quote]

I believe that, if you time this, you'll see it's behaving the same as a vanilla undump.  That is, dwarf steps onto tile plate at 0, assume he moves every 10 ticks:

0: Undump hatch opens.  Door opens.
~10: Dwarf steps off of hatch.
~15: Flow in delay circuit triggers undump hatch.  Since undump hatch is already open, this signal is ignored.
~110: Undump pressure plate sends close signal to undump hatch, which closes, and to the delay door, which also closes.
~150: Water has drained off of the delay plate, which sends a close to the undump hatch.  Since the undump hatch is already closed, this signal is ignored.

But eventually I still saw alunite on the lure tile, so they are making it across somehow.

Right-- it's working exactly like a vanilla undump.  The problem with these is that every once in a while, a very slow dwarf will accept a stockpile job, and will make it across the undump hatch after it closed.  This risk increases with the heaviness of the object.

3) Undump plate opens delay door, undump hatch, and delay floodgate, delay plate opens undump hatch. (F = floodgate)

This version is doing everything that version 2 did with one exception: it is delaying the drain of water from the pressure plate.  In other words-- everything that happened while time<=~110 is still happening the same way, but the events of time~150 are delayed to time~250.  Since these events are irrelevant, being the sending of a closing signal to a hatch that is already closed, this version behaves exactly like a vanilla undump.

Unfortunately, any relay of the undump pressure plate is going to involve a delayed open signal; and there is no way to override the close signal that occurs at time~110.  The fastest relay I know isn't fast enough to stop fast dwarves, unless you place the plate further back; but as you increase the distance between plate and device, you end up multiplying the difference in speed between fastest and slowest dwarves, such that you need a much larger delay.  Another thing you could try is sending a second open signal to the undump hatch JUST after it receives the close signal, but that won't work either, because the close signal can occur anywhere from ~105 (fast dwarves) to >150 (slowest dwarves).

Still, what about something like:

Code: [Select]


 #######
  ^phbp#
 #######

The only addition to this is a retracting bridge over empty space, linked to the pressure plate.  Let's time this out:

0: Hatch opens.
100: Bridge opens.
105-150: Hatch closes.
205-250: Bridge closes.

I haven't designed it, and I'm vulnerable to mistakes in conceptual design as much as anybody, but it seems to me that this design pretty much doubles the length of time that the lure tile is inaccessible-- that might not make any difference, after all, if a dwarf is slow enough that it doesn't step onto the hatch for 100 ticks, then waiting another 100 ticks to step onto the bridge might not stop it-- but it might make a good deal of difference, too, since I'm not sure exactly when dwarves evaluate path (they don't always seem to evaluate at the same time).

If it doesn't stop the slowest dwarves, then adding a second step at least allows you to control the delay, because you get more than 100 ticks during which to run your relay/delay, which you can design to even slower.  This would mean using a second hatch instead of the bridge, with a delay designed to keep it open for 200 ticks or longer.

[Kaos]

isn't the new version supposed to fix the "not able to see through grates/bars bug"??


In that case wouldn't a simpler setup with a scarecrowdorf work?:

Code: [Select]

top view

###
#e#
#o##
.xs#
####

# = wall
. = floor
o = wall grate/bar, window or even a fortification
e = enemy (scaredorf)
x = floor where the dump will occur
s = luring stockpileAlternatively instead of having the scaredorf on a wall, it could be placed on the ceiling
the "x" floor tile could be a stockpile for quantum storage or a grate/bar/hatch that can be opened to drop things like a garbage chute.

No need to step on plates, no need for timing... now tell me what am I doing wrong?

[Nan]

isn't the new version supposed to fix the "not able to see through grates/bars bug"??


In that case wouldn't a simpler setup with a scarecrowdorf work?:

Code: [Select]

top view

###
#e#
#o##
.xs#
####

# = wall
. = floor
o = wall grate/bar, window or even a fortification
e = enemy (scaredorf)
x = floor where the dump will occur
s = luring stockpileAlternatively instead of having the scaredorf on a wall, it could be placed on the ceiling
the "x" floor tile could be a stockpile for quantum storage or a grate/bar/hatch that can be opened to drop things like a garbage chute.

No need to step on plates, no need for timing... now tell me what am I doing wrong?

As hilarious as that is, it would present the problem of how dwarves are to get items from the stockpile, because the "getters" would trigger the scare just like the droppers and run off without having picked up the item.

[Nil Eyeglazed]

No need to step on plates, no need for timing... now tell me what am I doing wrong?

Well, one problem is that your dwarves are going to have a hard time accessing it.  For something like trade goods, you could put an additional bridge to block off sight to the scaredorf, but for other goods, it's harder to predict when you're going to want to access them.  There's also some worry if you have any marksdwarves, unless you can use windows.  (Another tiny problem comes from blind dwarves.)

But I think you're right that it could make a very good dropchute stockpile.  Does it work well?  I think you could make an autodropping design that worked well enough-- maybe even good enough for working over magma, to autodump garbage.

[Kaos]

As hilarious as that is, it would present the problem of how dwarves are to get items from the stockpile, because the "getters" would trigger the scare just like the droppers and run off without having picked up the item.

No need to step on plates, no need for timing... now tell me what am I doing wrong?

Well, one problem is that your dwarves are going to have a hard time accessing it.  For something like trade goods, you could put an additional bridge to block off sight to the scaredorf, but for other goods, it's harder to predict when you're going to want to access them.  There's also some worry if you have any marksdwarves, unless you can use windows.  (Another tiny problem comes from blind dwarves.)

But I think you're right that it could make a very good dropchute stockpile.  Does it work well?  I think you could make an autodropping design that worked well enough-- maybe even good enough for working over magma, to autodump garbage.

well, that's the beauty of it, the getters wouldn't be getting from that tile, they would get from the tile below, I haven't tested it yet, I guess what I really need is a way to get the dwarves to step on a plate that would open the chute (and drop the items to the pick-up stockpile/magma incinerator) only on their way out of the system...


maybe something like this:

Code: [Select]

top view
           ###
           #e#
          ##o####
--> entry d^xsd^ --> exit
          #######
# = wall
o = wall grate/bar, window or even a fortification
e = enemy (scaredorf)
x = floor where the dump will occur (drop zone)
s = luring stockpile
d = door/wall bar/wall grate/floor grate/floor bar/hatch
^ = plateShould work like this:
1) the leftmost (entry) door (or anything that interrupts that path) should start open while the rightmost (exit) door should start closed
2) dorf gets lured by the stockpile
3) crosses the open entry door
4) steps on the left (entry) plate
5) entry plate closes the entry door behind the dorf and opens the exit door in front of the dorf
6) dorf get to the drop zone (x)
7) gets scared by the scaredorf and drops the hauled item
8 ) runs away through the exit door (now open)
9) steps on the right (exit) plate, on his way out
10) exit plate opens entry door, closes exit door behind the dorf and opens (and closes) the chute on the drop zone, thus resetting the system
11) dropped item falls down where it can be quantum stockpiled/destroyed/whatever
12) Profit!? 


The differences in agility shouldn't interfere with this system, since there is nothing that requires timing, really, the plates's effects happen after the dorf is past the zone being affected, and the scaredorf is static.
The only thing I can think of right now is the area of vision for the scaredorf... the dorf seeing the scaredorf before he arrives on the drop zone... could be solved by placing the scaredorf 1 or more tiles behind, thus creating a tunnel vision effect... maybe observation skill affects this??

Let me know how it goes if you manage to test it before I do.