From Dwarf Fortress Wiki
Jump to navigation Jump to search

The undump is a relatively simple machine that takes advantage of borg logic.


is a feeder stockpile. (both tiles) is a stockpile, with the same settings, set to take from stockpile . The northern one is referred to here as the "lure tile," whereas the southern one is referred to as the "accessible stockpile tile." ¢ is a hatch over open space, is a retracting bridge over open space, and ^ is a citizens-trigger pressure plate linked to both ¢ and . + is a door, typically locked and closed tightly, just in case a dwarf makes it to the lure tile. They will, every once in a while-- I would estimate that this design needs fixing roughly every two years. (You can reduce this risk, but it requires instituting a second delay circuit.)

Dwarves accept stockpiling jobs from the stockpile, but upon reaching the first stockpile square, they find themselves without path to the distant stockpile square, and drop their goods. This creates a customizable quantum stockpile that preserves existing dump functionality.

Dwarves drop quite a few goods on the pressure plate rather than on the stockpile square. If you're both drawing from and delivering to the undump, dwarves can leave goods strewn throughout your fortress, as they find themselves without path earlier. Using it with food is not recommended for this reason-- you'll run into rot. Also be careful of permitting any bins or barrels, as this can lead to dwarves becoming stuck in infinite hauling loops. Of course, be aware that this structure will lead to massive amounts of cancellation spam.

You may have problems with refuse stockpiles. Refuse attracts vermin, vermin attract cats, and cats don't set off pressure plates, leading to vermin remains occasionally blocking the lure tile.

Just a little bit of explanation of a few other things: because of the dropping of goods on pressure plates, your dwarves need the take-from stockpile so that they don't get into infinite hauling loops-- it gives them a reachable target for any goods that get dropped on the pressure plate. The bridge is a backup mechanism, as some slow dwarves with heavy items may move so slowly that they don't realize path is broken until after the hatch closes-- the bridge acts to extend the time that the final stockpile square is unreachable (from 100 ticks to 200 ticks).

Throughput is limited. Avoid the temptation for larger unreachable stockpiles, as this will create huge amounts of framerate slowdown. The best way to improve throughput is to make a larger take-from stockpile. That keeps many dwarves working, while keeping a steady reduction of the stockpile to the single stockpile square.

Tested as of 34.02.

Dropping Undump

You may also find a simple variation useful:

¢ ^ ¢ ^

In this version, each of the bottom ^ (which are also all weights, citizens-trigger) are linked to the ¢ immediately to its right. These ¢ are over open space. The ^ is also linked to the extra hatch-- the ¢ where the reachable stockpile square used to be. (I've color coded these to show what triggers what.) This keeps dwarves using the undump consistently from west-to-east (in this orientation), and rather than stockpiling the goods, the goods are dropped to the level below (where you might want to have a stockpile set up instead). This is particularly useful when using physically isolated burrows. Notice that it's not impossible for something to go wrong-- if another creature moves closely behind, it might get dropped. I have never observed this to happen, and with proper design, it's unlikely to affect anything other than pets, but it is a theoretical risk. Note that if this is in an isolated burrow containing only one dwarf, there is no risk. (It is possible to make a riskless dropping undump, but it is a much more complicated problem, and throughput rates are really really bad.)

The double passageway means that the correct direction to move through the undump is also the shortest path.

Latching Dropping Undump

Unfortunately, neither of the previous designs is perfect. Occasionally, dwarves, for whatever reason, fugue out on the accessible stockpile square, and then, when they have a path, deliver goods to the lure square, requiring degunking the undump. This irritates me. So I've designed a latching version.

¢ ¢ ^

Here's our undump.

z + 2
% %
z + 1
% % ^
z + 0

Here's our latch. By word of explanation, %% is a pump that pumps from east to west and %% is a pump that pumps from west to east. Those pumps, and the two gears that power them, and , are separated by floors, to prevent transfer of power, and of course, the system is attached to some power source, which only needs to be able to power one of the pumps. While there is no dwarf in the system, neither pump should be receiving power, so the two need to be pre-toggled.

What happens with this design is that the hatch blocking access to the lure tile never closes until the dwarf has left the system. The dwarf crosses the undump plate, which activates the latch, moving water on to the pressure plate, which opens the hatch blocking access to the lure tile, and it continues to keep that hatch open until the dwarf exits the system, which activates the drainage pump, allowing the hatch to close again. The hatch controlling access to the system also opens with the latch, preventing a dwarf from re-accessing the system until latch has been restored to its base (off) state.

As with the basic dropping undump, this is not foolproof when multiple creatures are allowed access to the system. Attempting to access from the wrong side can drop a dwarf, or lead to premature access to the lure tile. This can be rectified by use of an additional hatch-pressure plate. Also, creatures closely following a dwarf using the system are at risk of getting dropped. This can't be fixed.

This version is probably much more complicated than anybody (except me) wants. I designed it so that I could have a perfectly functioning eternal silk farm run by a vampire. So its built around the assumption of a solitary dwarf in a system where reliability is worth complexity.

Original discussion is at