Dwarf Fortress Wiki - User contributions [en]

v0.34 Talk:Sally port

2014-03-05T05:47:52Z

Vasiln:

Kind of a poor choice of name. What makes something a sally port is that you can use it to escape your fortress-- to counterattack a besieging force. The described project doesn't do that. Should it be renamed? Maybe it should just be part of [[trap design]]? Maybe, instead, trap design should be a category with a bazillion subpages? --[[User:Vasiln|Vasiln]] ([[User talk:Vasiln|talk]]) 22:41, 2 March 2014 (UTC)

:Yes, sally ports were used to counterattack during a siege. Why a special sally port, instead of a normal door? Because sally ports were designed as heavily fortified entrances that would not compromise the security of the fortress when open. The design in the article indeed works that way--you can open the inner bridge, march in your military, then close the inner bridge and open the outer bridge--though the raid will either be victorious or suicidal since dwarves don't understand tactical retreat. But, beyond that, in current usage a [[wikipedia:sally port|sally port]] is an entranceway with multiple, independently (and, often, remotely) controlled doors. In my opinion, that fits the design in the article quite well; however, if you have an alternate name in mind we certainly can consider a name change. [[Trap design]] is already overlong, and generally doesn't go into the level of detail that this article does. A merge would mean scrapping much of the content.--[[User:Loci|Loci]] ([[User talk:Loci|talk]]) 20:15, 3 March 2014 (UTC)
::Is it your intention that this page be used to demonstrate the various techniques to design "heavily fortified entrances" that will "not compromise the security of the fortress when open"? If so, sally port is an appropriate title, but of course the page is far from complete, listing only a single example, and statements like "A sally port is a type of large and extremely effective trap" should be edited out. If, on the other hand, you want this to be a page about a single kind of trap, then "sally port" is not a great choice of name. Re: placing it in categories and such, I have nothing against creating pages for specific trap designs, but feel that if this trap deserves its own page, then so do many others, for the sake of parallelism at least.
::(Side discussions: Trap design is long because there are a lot of traps on there, but I think the categories make for easy browsing, and I like that people have felt so free to edit in their own traps. If you notice, there are frequently links to user pages and forum threads for when an idea needs more detail than can be provided in an overview page like [[trap design]]. I am not familiar with this modern usage of "sally port" and I recommend you check out the talk page of the wikipedia article you reference, or just ask google for a definition, to see how little consensus there is on this definition. As for what I'd name this-- I guess if I felt that the principle of bridge-based containment needed to be made explicit, I'd put a section in trap design about "containment" and discuss why bridges are better than doors, and what you can do after you get something into containment. Devices with two bridges, designed to make protected entrances, are typically referred to, on forums and on this wiki, as airlocks.)
::Anyhow, it's not a vitally important issue to me; would love to hear your thoughts on the best way to handle individual trap designs on the wiki. --[[User:Vasiln|Vasiln]] ([[User talk:Vasiln|talk]]) 05:47, 5 March 2014 (UTC)

v0.34 Talk:Sally port

2014-03-05T05:47:30Z

Vasiln:

Kind of a poor choice of name. What makes something a sally port is that you can use it to escape your fortress-- to counterattack a besieging force. The described project doesn't do that. Should it be renamed? Maybe it should just be part of [[trap design]]? Maybe, instead, trap design should be a category with a bazillion subpages? --[[User:Vasiln|Vasiln]] ([[User talk:Vasiln|talk]]) 22:41, 2 March 2014 (UTC)

:Yes, sally ports were used to counterattack during a siege. Why a special sally port, instead of a normal door? Because sally ports were designed as heavily fortified entrances that would not compromise the security of the fortress when open. The design in the article indeed works that way--you can open the inner bridge, march in your military, then close the inner bridge and open the outer bridge--though the raid will either be victorious or suicidal since dwarves don't understand tactical retreat. But, beyond that, in current usage a [[wikipedia:sally port|sally port]] is an entranceway with multiple, independently (and, often, remotely) controlled doors. In my opinion, that fits the design in the article quite well; however, if you have an alternate name in mind we certainly can consider a name change. [[Trap design]] is already overlong, and generally doesn't go into the level of detail that this article does. A merge would mean scrapping much of the content.--[[User:Loci|Loci]] ([[User talk:Loci|talk]]) 20:15, 3 March 2014 (UTC)
::Is it your intention that this page be used to demonstrate the various techniques to design "heavily fortified entrances" that will "not compromise the security of the fortress when open"? If so, sally port is an appropriate title, but of course the page is far from complete, listing only a single example, and statements like "A sally port is a type of large and extremely effective trap" should be edited out. If, on the other hand, you want this to be a page about a single kind of trap, then "sally port" is not a great choice of name. Re: placing it in categories and such, I have nothing against creating pages for specific trap designs, but feel that if this trap deserves its own page, then so do many others, for the sake of parallelism at least.
(Side discussions: Trap design is long because there are a lot of traps on there, but I think the categories make for easy browsing, and I like that people have felt so free to edit in their own traps. If you notice, there are frequently links to user pages and forum threads for when an idea needs more detail than can be provided in an overview page like [[trap design]]. I am not familiar with this modern usage of "sally port" and I recommend you check out the talk page of the wikipedia article you reference, or just ask google for a definition, to see how little consensus there is on this definition. As for what I'd name this-- I guess if I felt that the principle of bridge-based containment needed to be made explicit, I'd put a section in trap design about "containment" and discuss why bridges are better than doors, and what you can do after you get something into containment. Devices with two bridges, designed to make protected entrances, are typically referred to, on forums and on this wiki, as airlocks.)
Anyhow, it's not a vitally important issue to me; would love to hear your thoughts on the best way to handle individual trap designs on the wiki. --[[User:Vasiln|Vasiln]] ([[User talk:Vasiln|talk]]) 05:47, 5 March 2014 (UTC)

v0.34 Talk:Sally port

2014-03-02T22:41:42Z

Vasiln: Created page with "Kind of a poor choice of name. What makes something a sally port is that you can use it to escape your fortress-- to counterattack a besieging force. The described project d..."

v0.34:Garbage dump

2014-03-02T22:30:54Z

Vasiln: Changed quality rating from "Exceptional" to "Superior" using the rating script

{{Quality|Superior|22:30, 2 March 2014 (UTC)}}
{{projects}}{{av}}

[[File:Stockpile.png|thumb|350px|right|Garbage dumps are used most often for clearing out large areas of leftover stone - for instance, when constructing a [[stockpile]] (note that since the changes made in version 0.34.10, [[mining]] doesn't generate quite so many leftover stones, though the number is still significant).]]

Garbage dump zones are areas in which dwarves will throw items designated for dumping - either with by using {{k|k}}-{{k|d}} (one item at a time), or {{k|d}}-{{k|b}}-{{k|d}} (area dumping; note that this designates ''all'' items on the tiles for dumping, even placed [[furniture]]). Garbage dumps are ''not'' the same as [[Refuse#Refuse|refuse]] stockpiles, which can be designated to accept any specific type(s) of refuse, such as animal [[corpse]]s or [[bones]], and then are randomly filled by haulers whenever the items appear on the map.

The garbage dump may be inappropriately named, as it's more of a matter compression zone. The specifics are beyond human understanding, however, dwarves are in fact capable of compressing an infinite amount of matter into only one tile, as long as it is specified as a garbage dump. If for some reason Urist is yet again incapable of locating his favorite pair of cave troll leather socks, he should think to look among the black hole of matter that is the nearest garbage dump, as they could be snugly lodged between a few billion rocks.

Garbage dumps only accept items that have been marked for dumping, require dwarves to have [[refuse hauling]] [[labor]] enabled, and are subject to refuse [[standing orders]] ({{k|o}}-{{k|r}}). Most notably, dwarves will ''not'' dump items that are outside unless you allow them to ({{k|o}}->{{k|r}}->{{k|o}}). To place a garbage dump, trace a zone on either a relatively empty plot of land or adjacent to a cliff face or hole. If a garbage zone is designated beside a [[cliff]] or hole (both natural or dwarf made) garbage will be thrown off/in the z-space. Each ground tile within that zone is considered a garbage dump tile; thus, if you want to place a single-tile zone, place the zone onto a ground tile (optionally adjacent to a cliff or [[pit]]), not onto an [[open space]]. Items dumped into [[magma]] that are not [[magma safe]] will permanently disappear, which is useful for disposing of clutter and increasing [[FPS]]. Otherwise a single tile (either a dump zone, or the ground below the open space) will hold any number of dumped objects. Dumping items into [[magma]] can be [[fun|dangerous]] due to the [[magma mist]] generated when objects fall into magma. It is advised to dump items into magma from a hole several z-levels up to avoid [[Fire|!!Dwarves!!]] running around the fortress.

Dumped items are automatically marked as [[forbid]]den, preventing dwarves from touching them. If you wish to use dumped items, you need to reclaim them. Press {{k|k}} to view the item and {{k|f}} to toggle forbid status. You may also use the reclaim [[designation]] to reclaim simultaneously all of the items dumped by using {{k|d}}-{{k|b}}-{{k|c}} and tracing the designation over the objects in question. If you designate items for dumping, but forget to mark an active garbage dump, your dwarves will continue hauling / using the item, until an active garbage dump is marked.

If a garbage dump is located next to open space, dwarves will always stand on a garbage dump square when throwing ''into'' that open space, even if it could potentially be done more efficiently. If a garbage dump is located next to multiple tiles of open space, they seem to prefer the one farthest to the northwest. If a tile to the north and a tile to the west are the only tiles available, they will throw to the west. Such garbage dumps can be a very efficient method of moving materials to the lower levels of your fortress. However care must be taken to prevent dwarves and livestock from being struck by falling objects, perhaps with [[traffic]] designations. Dwarves usually throw dumped items in the nearest available garbage dump, although this is not an ironclad rule. If a nearer zone becomes available after they have already started the job they will ignore it. They also have a preference for open space dumps.

Probably due to a bug, dwarves occasionally ignore items that are meant to be dumped; viewing the item by pressing {{k|k}} then toggling forbid and dump status on, then off again ({{k|f}}-{{k|f}}-{{k|d}}-{{k|d}}) seems to correct this problem. Previously dumped items are regarded as 'refuse' and will not be recognized (or re-dumped) unless 'gather refuse from outside' is enabled in your orders.

Garbage dumps are great space savers because they can hold an infinite number of items on one tile; with some micromanagement they can even compress large, one-item-per-tile [[stockpile]]s into single-tile [[quantum stockpile]]s (although this requires additional work and is usually considered an [[exploit]]). The most common use for garbage dumps is for cleaning away loose stones left in your fortress by your [[miner]]s: mark them for dumping, wait for the jobs to be completed, and then reclaim them ({{k|d}}-{{k|b}}-{{k|c}}) for use by your stonemasons; bonus points if you do this next to a stoneworking workshop and then re-designate the tile as a stone stockpile. If the dump is designated inside a workshop, the workshop will not become cluttered. However, if you put a garbage dump inside a magma workshop with the intent of dumping ores there, make sure the zone does not overlap any open pits of magma you may have carelessly left around, or as per intended behavior, items will be dumped into the magma.

{{Category|Designations}}

v0.34:Creature logic

2014-02-26T23:40:43Z

Vasiln: demonstration of reversed computation

{{Quality|Exceptional|20:46, 30 April 2013 (UTC)}}
{{Computing}}
{{av}}

Creature logic is a form of dwarven [[computing]] that functions by taking advantage of creature's natural [[path]]-finding goals to trigger pressure plates. Creature logic is complete-- you can build memory, repeaters, or any sort of logical circuit.

==Creature logic vs other disciplines==
Pro:
* Creature logic requires no [[water|fluid]] or [[windmill|wind]]. In dry, windless environments, circuits are limited to creature logic or [[minecart logic]].
* Similarly, creature logic requires no infrastructure-- you can build your circuits anywhere, without worrying about bringing water or [[power]] from one end of your map to the other.
* All creature logic circuits can be designed with only [[stone]] and a pick-- although you're free to use [[wood]] or [[metal]] if you prefer!
* Creature logic doesn't need anything but creatures to send or receive signals. There's no need to translate signals as with with [[mechanical logic]].
* Creature logic can be very intuitive. Watching creatures physically travel through your logic pathways simplifies debugging.
* It's fun to watch the creatures run around!

Con:
* Reliable creature logic requires a ridiculous number of [[hatch]]es, [[door]]s, and [[mechanism]]s-- not to mention connections between pressure plates.
* Creature logic requires creatures-- sometimes, a great number of creatures. Sometimes, those creatures die or have babies. Sometimes, they interrupt your [[dwarf|dwarves]]. Sometimes, your dwarves fill them full of crossbow bolts.
* Creature logic is vulnerable (surprise) to the presence of unexpected creatures in the logic circuits. Because creature logic circuits require a path either to the map edge or to the [[Activity_zone#Meeting_Area|meeting hall]] (in most cases), this is a real possibility.
* Creature logic requires large amounts of space.

==Free range or one path==
There are two incompatible design philosophies associated with creature logic-- mostly, the creatures you use will determine which is appropriate.

Free range creature logic generally gives a path to creatures when certain criteria are met, and otherwise, lets them wander (in a constrained space). This simplifies design and permits constant evaluation of criteria, but any creature that paces in captivity can easily foul up your circuits-- for instance, a pacing creature may prevent a door from closing, causing an AND to evaluate as true even though both operands were never true at the same time. Additionally, it gives no clear indication that an evaluation has been completed-- if you want to evaluate your AND statement, you only ever know that it's been evaluated as true, never as false.

One path design constrains creatures to a single tile when they have no path available. Whenever the creature is permitted movement for evaluation of operands, the creature is guaranteed one and only one path. This requires explicit designation of 'else' paths, and requires that operands be evaluated at specific times rather than undergoing constant evaluation, but guarantees complete reliability, and allows the circuit to return both 'true' and 'false' evaluations, meaning that you can know for sure that a signal has been evaluated, rather than guessing if the creature has had sufficient time to path or not path.

==Animal logic==
[[Animal logic]] relies on a special case of free range creature logic that is specific to animals that are unable to open doors, by pathing them through tightly closed doors. Animal logic can be very space efficient and easy to build in comparison to most kinds of creature logic, but is somewhat unreliable.

==Gates==
Creature logic relies on the ability or inability of a creature to path through a specific area. "One path" design requires explicit 'else' arms. Because of that, the following logic gates are shown in complementary pairs to guarantee a path to the creature.

All of these gates can be easily altered to take more than two operands.

====Key====
In all of the following diagrams, the creature is assumed to start at {{Raw Tile|s|#0FF|#000}} (if given). {{Raw Tile|p|#F00|#000}} means that the square contains a path to the creature's pathing goal. Doors {{Raw Tile|┼|#FF0|#000}} and hatches {{Raw Tile|¢|#FF0|#000}} are displayed in the same color as the [[pressure plate]] {{Raw Tile|^|#FF0|#000}} that links to them. If no pressure plate exists for a color, furniture of that color is opened or closed from outside of the circuit pictured; if a hatch and a door are the same color, that means they receive signals from the same source. Output pressure plates are displayed in magenta {{Raw Tile|^|#F0F|#000}}, as is any furniture in the circuit that is linked with the output plate. In the rare case that part of a circuit is linked with multiple elements, it will be displayed with foreground and background colors and explained in text-- for instance, {{Raw Tile|^|#F0F|#0FF}} is linked both to cyan furniture and output.

===Identity with NOT gate===
{{diagram|spaces=yes|\
╔══╗
═╝[#0F0]┼[#F0F]^╚═
[#0FF]s+OO+[#F00]p
═╗[#0F0]¢+╔═
╚══╝ }}

This function takes a single operand. If the operand is true, the creature travels through the upper path (identity); otherwise, the creature takes the lower path (NOT). The pressure plate signals when the operand is true. This gate is the basis of all to follow.

Identity is also a simple delay. When the path receives a signal, it propagates it after a short period. That period depends on the speed of the creature moving through the gate.

===AND gate with NAND gate===
{{diagram|spaces=yes|\
╔═══╗
═╝[#0F0]┼[#FF0]┼[#F0F]^╚═
[#0FF]s+O═O+[#F00]p
═╗+[#0F0]¢+╔═
╚╗[#FF0]¢╔╝
╚═╝ }}

The doors at the top are both open if both operands are true (AND); the hatches at the bottom permit path if either operand is false (NAND). The pressure plate will signal when both operands are true.

===NOR gate with OR gate===
{{diagram|spaces=yes|\
╔═══╗
═╝[#0F0]¢[#FF0]¢[#F0F]^╚═
[#0FF]s+O═O+[#F00]p
═╗+[#0F0]┼+╔═
╚╗[#FF0]┼╔╝
╚═╝ }}

The hatches at the top permit path only if neither operand is true (NOR); the doors at the bottom permit path if either operand is true (OR). The pressure plate will signal when neither operand is true.

===XOR gate with expanded XNOR gate===
{{diagram|spaces=yes|\
╔═╦═╗
╔╝[#0F0]┼O[#0F0]¢╚╗
═╝+[#FF0]┼+[#FF0]¢[#F0F]^╚═
[#0FF]s+O═══O+[#F00]p
═╗+[#0F0]┼[#FF0]┼++╔═
║+OO+╔╝
╚╗[#0F0]¢[#FF0]¢╔╝
╚══╝ }}

As XOR is the intersection of OR and NAND, it is simply an OR followed by a NAND. The XNOR, as the union of AND and NOR, requires two arms. Each operand is linked to one door and one hatch in the XOR path, and to one door and one hatch in the XNOR path. The pressure plate will signal when either operand is true but not both are true. When modifying the XOR to take more than two operands, be careful to leave space between the doors and hatches as shown; this space is unnecessary for evaluation of two operands. Similarly, the expanded XNOR is appropriate when dealing with more than two operands, but a condensed version for taking only two operands exists.

===Multiple use===
The gates above are single use gates; the creatures will escape after pathing through each gate. Circuits which return the creature to the beginning of the path are possible via altering the path in-route.
{{diagram|spaces=yes|\
║[#F00]p║
══╝[#0F0]¢║
[#0FF]s[#0F0]¢[#0F0]^O╣
══╗[#0F0]┼║
║[#F00]p║}}

This is one such device for re-routing creatures mid-path. Upon stepping on the pressure plate, the creature opens two hatches, thus blocking retrograde motion as well as access to its pathing goal, and opens a door, giving access to a new pathing goal. This new pathing goal can lead back to the original position of the creature. This principle is demonstrated in the designs to follow. Because the creature is constrained on the pressure plate, the door can be opened by outside mechanisms rather than being linked to the pressure plate, permitting controlled movement of a creature through one or more arms of a circuit.

===Reversibility===
The reader may have noticed the near symmetry of the preceding gates. However, the output works as well when placed before the path-limiting furniture as after! While it's easier to visualize the effects of these circuits when displayed as above, it is often more effective to use a reversed design. When a single creature is used to traverse a large, compound circuit, reverse design can lead to reduced latency. A clever logician might wonder, "But if they can evaluate the signal before traversing the path, why traverse the path at all?" Consider the following XOR/XNOR gate, redesigned both for reuse and reversed operation:

{{diagram|spaces=yes|\
╔═╦═╗
╔╝[#0F0][#F0F]¢O[#0F0]┼╚╗
════╝[#F0F]^[#FF0][#F0F]¢+[#FF0]┼+╚═
[#F00]p[#F0F][#00F]┼[#0FF]¢[#0FF]^[#0FF]¢O═══O+[#F00]p
════╗[#00F]^[#00F][#0F0]¢[#FF0]¢++╔═
║[#00F]¢OO+╔╝
╚╗[#0F0]┼[#FF0]┼╔╝
╚══╝ }}
A creature waits at the start point, atop the cyan hatch, until evaluation is triggered by an '''off''' signal to the cyan hatches (typically following a redundant '''on''' signal). The creature, suddenly granted path to its goal, races toward either XOR or XNOR, but evaluation occurs earlier than in previous designs. Its original path is blocked upon evaluation and the creature is rerouted back to its start point. (Note that while the creature is reset in this design, furniture is not necessarily reset. Some circuits may require additional furniture to control path without altering operands.)

Whereas the creature needed to travel 8 tiles for evaluation in the previous design, this allows evaluation in 2 tiles, and the refractory period-- the time during which the circuit cannot be used to evaluate another operand-- is improved to an even larger extent.
==Creature memory==
{{diagram|spaces=yes|\
╔═╗
═══╝[#0F0]┼╚══
[#F00]p[#FF0]¢[#FF0]^[#FF0]¢[#00F]¢[#F0F][#00F]^[#00F]¢[#F00]p
══╗[#0FF]┼╔═══
╚═╝ }}

This is a low latency version (not the simplest version, not the most full-featured) of creature-based memory. Each pressure plate is linked to each adjacent hatch. Memory is set by sending an open (followed closely by a close) to either door.

Note that in this diagram, both ends need to lead to the pathing goal. The creature can enter by either side, but will be constrained to either pressure plate during normal operation.

==Clock generation, repeaters, and delay==
A high resolution borg-logic clock or delay can be designed around the rate with which creatures fall. A simpler, low resolution clock can be designed based around the military [[scheduling]] menu or [[minecart]] routes.

The memory design above, slightly modified, can make a decent (not perfectly regular) repeater.
{{diagram|spaces=yes|\
╔═╗
═══╝[#FF0]¢╚══
[#F00]p[#FF0]¢[#FF0]^[#FF0]¢[#00F]¢[#F0F][#00F]^[#00F]¢[#F00]p
══╗[#00F]¢╔═══
╚═╝ }}

Here, each pressure plate is linked to the two orthogonally adjacent hatches. The southern hatch is linked to the eastern pressure plate, while the northern hatch is linked to western pressure plate. This repeater tends to fire about every 250 ticks, with open and close signals offset by about 125 ticks, when built as shown. It's very effective at rapidly triggering any device with a refractory period of 100. Similar, non-repeating systems can be used to institute delay.

Linking both pressure plates to output doubles its rate, turning it into very effective spike repeater. The period can be increased by introducing floor space into the center of the design.

==Edge Detection==
{{diagram|spaces=yes|\
║[#F00]p║ ║[#F00]p║
║[#0F0]¢╚═══╝[#FF0]¢║
╠O[#0F0]^[#0FF]┼[#F0F]^[#FF0]¢[#FF0]^O╣
║[#0F0]¢O═══O[#0FF]¢║
╚╗++[#F0F]^++╔╝
╚═════╝ }}

North of the circuit is the pathing goal. The eastern and western pressure plates are linked to adjacent hatches. Input is linked to the hatch southeast of the eastern pressure plate and to the door. The central and southern pressure plates are linked to output. This circuit generates both an open and a close every time it is sent an open or a close signal from input -- that is, it generates two properly-ordered signals for every properly-ordered signal it is sent, allowing for ''edge triggered'' logic. Either output pressure plate can be removed to send an open and a close only upon receiving one kind of signal or the other kind of signal. Output can linked to the same device or to two different devices.

Note that the memory design forms a sort of inverse of this circuit, in that a single open-close cycle is translated into a single on or off signal.

==Alternative design==
Multiple choices of furniture are available for the doors or hatches in the above diagrams. Various reasons exist for substitution.

====Doorless design====
Of all alternative designs, doorless design is the most practical. All doors are replaced with hatches over [[stair]]s or [[ramp]]s, and the path continues one z-level down or up. This makes it more difficult to visualize the circuit, and some very efficient designs may require more significant changes, but every circuit possible can be created without doors. Use of hatches instead of doors protects against the effects of doors being blocked open by unexpected creatures or objects-- the original bug, after all, took the form of [[vermin]] remains. Retracting [[bridge]]s can be used the same way, but lead to problematic delays.

====Hatchless design====
Hatchless design is much more difficult and of very limited use. Signal inversion can make a door act like a hatch; a raising bridge acts like a hatch. Both of these institute delays in processing that require large expansion of logic circuits and limit the effectiveness of memory, but they may be necessary when using submerged logic or flyers-- bragging rights for a logic system submerged in [[magma]] that processes via [[fire imp]]s may be worth the headache.

====Bridge design====
Bridge design uses bridges instead of both doors and hatches. Doors are replaced with retracting bridges over ramps or staircases; hatches are replaced with raising bridges, or with retracting bridges over channels. Bridge design causes frustrating delays, but it is the only way to use [[building destroyer]]s in a logic circuit. The irony of making your [[minotaur]] run an impossible labyrinth may be worth the design headache. As an added bonus, bridges are nearly unobstructable-- offensive vermin remains in your logic circuits will be smashed from this plane.

==Creature choice==
Multiple choices exist for creatures to run logic circuits. Each has its own advantages and disadvantages.

====Domestic animals====
[[Domestic animal]]s are valid choices for creature logic, but come with a host of disadvantages. Many females are capable of giving birth inside of your logic gates; their [[child|children]] can block the closing of doors or set off pressure plates. [[pasture|Grazers]], of course, will starve inside most logic circuits, although some special designs may be capable of supporting a grazer. Some domestics are too small to set off pressure plates; some are capable of flight, requiring hatchless design. All unmodded domestic animals will die of old age, requiring periodic replacement. Most domestic animals have relatively short lifespans. Logic involving domestic animals must be built with pressure plates that can be triggered by citizens, and building these circuits may turn into a nightmare of job cancellations and stranded, starving dwarves. Domestic animals have one huge advantage, however: the location of their pathing goal can be altered with direct, unmediated action of the player, by placement of a meeting zone.

====Invaders====
[[Invader]]s are readily available on most maps, rarely or never give birth, and require no sustenance. Pressure plates don't need to be built triggerable by citizens. [[elf|Elves]] and [[goblin]]s will never die of old age. However, invaders cause their own problems. Invaders can cause job cancellations, and in some circuits may escape, wreaking havoc deep in your fortress. Dwarves armed with bolts and crossbows will take potshots at your computers periodically. Finally, invader-based logic must have a path to the map edge for predictable pathing. If your logic circuit is inside of your fortress, walling off, even through something as simple as raising a bridge at your entrance, will lead to unpredictable pathing.

====Dwarves====
Dwarves themselves can be used to run logic circuits, and are perhaps the most interesting choice; logic designs involving dwarves are generally referred to as borg logic. While longer-lived than most domestics, dwarves [[food|starve]] and [[alcohol|dehydrate]] easily, requiring frequent, careful maintenance. Idle dwarves path unpredictably, and dwarves are vulnerable to [[sleep|drowsiness]], leading to very high latency. Married female dwarves are fecund. At the same time, dwarves are excellent choices for logic circuits because of their varied pathing goals that can be altered through direct interaction by the player. Dwarves can trigger events both through the use of pressure plates and through the use of [[lever]]s, while their pathing goals can be controlled by many means-- most easily and predictably, by military scheduling or minecart routes. In fact, one can see the entire game of Dwarf Fortress as one big logic circuit with dwarves as the driving creature. The more philosophically oriented overseer may wonder what cyclopean, ineffable circuit he or she is traversing through the act of playing Dwarf Fortress....

===Undead===
[[Undead]] are an intriguing choice for creature logic choices. The absence of attribute rust opens up the possibility for a more consistent repeater. They can be used in fully submerged circuits-- even in magma-submerged systems. In some [[biome]]s, they are self-repairing. However, undead path like wildlife, which can make it difficult to set up a circuit for them. Without a clear target, they may not behave predictably. One way to work around this is to build a visible target to which the undead path, by walling the circuit with [[channel]]s instead of walls, and placing a captured invader in clear line-of-sight of the undead logician.

===Other choices===
There are a few things to stay away from, but in general, any sufficiently understood creature can be used for creature logic. Building destroyers are problematic, but full-bridge design is possible. Likewise, flyers and swimmers cause difficulty, but nothing that can't be worked around. Creatures with trapavoid are nearly useless, though [[gremlin]]s might be able to output via levers; stun-able creatures like [[kobold]]s can trigger pressure plates when dropped/stunned; and non-web-immune creatures trigger pressure plates that have been [[web]]bed. Creatures with a [[size]] less than 10000 are too small to set off pressure plates, thus requiring additional "hardware" (such as a tame creature that "flees" or "charges" over a pressure plate). The essence of creature logic, however, is predictable pathing. This may or may not exclude the use of certain types of wildlife.

{{Category|Computing}}
{{Category|Logic}}

v0.34:Minecart logic

2014-02-26T20:56:47Z

Vasiln: fixed NCM; -potential as independent, no longer appropriate to page; added links as appropriate; +other techniques and gates section; cyan->yellow for contrast; -unused key elements; edited wording here and there

{{Quality|Superior|20:51, 30 April 2013 (UTC)}}
{{Computing}}
{{av}}

The addition of [[minecart]]s to Dwarf Fortress has opened up new and exciting logic and computing options for the ambitious fortress manager. Minecart-based logic gates and memory cells are easy to build, quick to react, and can even be built without power, water, or creatures. The training your [[doctor]]s will receive is just one of many reasons to compute with minecarts!

==Techniques and Circuits==

There exist a great number of different techniques by which a minecart can receive input, compute, and deliver output. This article does not aim for a comprehensive list of techniques and circuits; the interested reader is encouraged to investigate further. The following examples were chosen to demonstrate both a variety of techniques and a few commonly used gates.

====Key====
Adequately diagramming minecart logic devices can be difficult; each tile on each z-level might need to display up to four slices (track, [[ramp]], [[furniture]], minecart) that can lay on top of each other. Ramps are displayed on the furniture layer for the sake of simplicity, and some slices may be omitted when unnecessary. Components of each lower slice are displayed on the higher slice when unchanged by new components to give the reader a sense of position. Wall {{Raw Tile|O|#FFF|#000}} is typically displayed only where it is essential to the operation of the circuit, and drawn only as sequences of pillars to avoid confusion with track. Unengraved floor {{Raw Tile|,|#FFF|#000}} is sometimes needed for other components, but of course can be smoothed as desired. Track direction is laid out with {{Raw Tile|║|#FFF|#000}}{{Raw Tile|═|#FFF|#000}}{{Raw Tile|╗|#FFF|#000}}{{Raw Tile|╝|#FFF|#000}}{{Raw Tile|╚|#FFF|#000}}{{Raw Tile|╔|#FFF|#000}}{{Raw Tile|╩|#FFF|#000}} and ends in a tile with {{Raw Tile|╨|#FFF|#000}}{{Raw Tile|╥|#FFF|#000}}{{Raw Tile|╡|#FFF|#000}}{{Raw Tile|╞|#FFF|#000}}. Minecarts {{Raw Tile|■|#FFF|#000}} are accelerated by rollers to the east {{Raw Tile|╟|#FFF|#000}} west {{Raw Tile|╢|#FFF|#000}} north {{Raw Tile|╧|#FFF|#000}} or south {{Raw Tile|╤|#FFF|#000}} and decelerated by track stops {{Raw Tile|≡|#FFF|#000}}. Rollers are controlled via [[Gear_assembly|gear assemblies]], either engaged {{Raw Tile|☼|#FFF|#000}} or disengaged {{Raw Tile|☼|#777|#000}}, typically connected to sufficient [[power]] {{Raw Tile|P|#0F0|#000}}. [[Pressure plate]]s {{Raw Tile|^|#FFF|#000}} provide output and, in some cases, modulate the circuit itself. Up {{Raw Tile|▲|#FFF|#000}} and down {{Raw Tile|▼|#FFF|#000}} ramps may be necessary to travel z-levels or alter minecart velocity; they may be roofed or covered with empty space {{Raw Tile|.|#0FF|#000}} in some views. [[Hatch]]es {{Raw Tile|¢|#FFF|#000}} and retractable [[bridge]]s {{Raw Tile|╬|#000|#CCC}} are commonly used to control the path of minecarts. Where necessary, clarification can be found in the descriptions of each circuit.

===Power to signal===
{{diagram|spaces=yes|\
O O
╥, ╤☼
║ [#F0F]^[#0F0]P
╨, ╧☼
O O
track furniture}}

In this, the simplest of all designs, the output plate sends an '''on''' signal when the gear assemblies {{Raw Tile|☼|#FFF|#000}} are powered {{Raw Tile|P|#0F0|#000}}. When power is lost, the minecart settles onto either the northern or southern roller spaces, and the output plate sends an '''off''' signal.

This device is very general purpose. Left as an exercise for the reader, alternate construction can result in edge detection or in a [[repeater]] design.

===Newton's Cradle Memory===
{{diagram|spaces=yes|\
O O O
╥, ╤[#0C0]☼[#0F0]P [#000][#0f0]■[#0C0]☼[#0F0]P
║ ║ ║
║ [#F0F]^ [#000][#ff0]■
╨, ╧[#CC0]☼[#0F0]P ╧[#CC0]☼[#0F0]P
O O O
track furniture minecart}}

[[User:TinyPirate|TinyPirate]]'s Newton's Cradle [[Memory_(computing)|memory]] cell is notable both for its small footprint and for demonstrating an important principle of minecarts. When the northern gear assembly {{Raw Tile|☼|#0C0|#000}} is briefly engaged, the northern roller {{Raw Tile|╤|#FFF|#000}} becomes powered, launching the northern minecart {{Raw Tile|■|#000|#0F0}} into the southern minecart {{Raw Tile|■|#000|#FF0}}. The southern minecart then leaves the output plate {{Raw Tile|^|#F0F|#000}} and settles on the southern (unpowered) roller. When the southern gear assembly is briefly engaged, the situation reverses: the southern minecart settles on the output plate, knocking the northern minecart onto the northern (unpowered) roller-- as in its original state.

===Continuous roller OR===
{{diagram|spaces=yes|\
╔═╗═╗ ╔═╗═╗
║ ║O║ ║ [#F0F]^O║
║ ║O║ ╤[#0F0]☼╧O║
║ ║O║ [#0F0]P╤[#FF0]☼╧O║
╚═╩═╝ ╚═╧═╝
track furniture}}
[http://www.bay12forums.com/smf/index.php?topic=114923.msg3891809#msg3891809 Veylon's] roller OR continuously evaluates two operands via a minecart traveling counter-clockwise using principles of power transmission through single tile rollers. Should either input {{Raw Tile|☼|#0F0|#000}} or {{Raw Tile|☼|#FF0|#000}} be engaged, power {{Raw Tile|P|#0F0|#000}} is transmitted to the southernmost, S->N roller {{Raw Tile|╧|#FFF|#000}}. Although the minecart is left with diagonal velocity, walls prevent derailment. When neither input is engaged, the minecart continues over the T-junction to the east, missing the output plate {{Raw Tile|^|#F0F|#000}}.

===Roller switched AND===
{{diagram|spaces=yes|\
║ ║
╔╗ [#0F0]P[#0F0]╧╗
║║ ║║
╔╗ [#0F0]P[#FF0]╧╗
║║ [#F0F]^║
╚╗ ╚╗
track furniture}}
[[User:Larix|Larix]]'s roller-switched AND takes advantage of the behavior of rollers to avoid troublesome diagonal velocity. It is potentially confusing both for the counter-intuitive direction of its rollers as well as the way that rollers respond to signals. When the minecart encounters either activated (that is, the last signal received was an '''off''') S->N roller {{Raw Tile|╧|#FF0|#000}} or {{Raw Tile|╧|#0F0|#000}}, its velocity is completely rewritten and reversed, sending it onto the alternate (clockwise) path. Should neither roller be activated (that is, the last signal received by both was an '''on'''), the track bends will be ignored and the minecart will travel directly south, over the output plate {{Raw Tile|^|#F0F|#000}}.

===Resetting bridge-derailment AND===
{{diagram|spaces=yes|\
O[#0FF].═[#0FF]. O▼═▼ O[#FF0]¢═▼

track ramp furniture
z+1
O╔O╗ O▲O▲ O▲O▲
╚═╚ ╚═▲ [#000][#0f0]╬[#F0F]^▲
╚═╝ ╚═╝ ╚═╝
track ramp furniture
z+0}}

When both the yellow hatch {{Raw Tile|¢|#FF0|#000}} and the green retractable bridge {{Raw Tile|╬|#000|#0F0}} are open, minecarts on this circuit make a continuous loop, triggering the output plate {{Raw Tile|^|#F0F|#000}}. If either is closed, the plate is never activated. If the bridge is closed, the minecart derails to the southern path, avoiding the plate. If the hatch is closed, the minecart is unable to drop into the northwest ramp, and so sits on the upper, northwestern tile until the hatch opens.

There are many concerns when using a gate like this. Minecarts can be flung when a bridge changes state underneath them, and unfortunately, hatch covers cannot provide the same derailment effect on flat track. Additionally, because your minecart never evaluates both operands at the exact same moment, it's possible for this gate to output when neither operand is actually true (ie, last received an '''on''' signal) at the same moment.

It's not always a problem, but this behavior is common to AND gates. Paradoxically, one solution is to moderate your inputs via an extra AND gate; this design shows how that can be done. When a large number of circuits such as that shown are created and the hatches of all of them are linked to a single lever, a quick flick (on and off) of that lever can guarantee that all of your circuits fire at the same time-- that is, that all of your inputs for the next computation change state simultaneously. The minecarts then return to their position atop the hatches, ready for another flick of your clock lever.

Worth noting, as well, is the central eastern impulse ramp that allows the minecart to maintain enough velocity to complete this circuit. Impulse ramps like this can be used to make unpowered gates. However, their behavior is unintuitive, and they should only be used with extreme caution. For example, in the diagram above, such a device used for continuous AND evaluation (rather than the resetting AND suggested in the text) is likely to accelerate the minecart on each pass, such that the minecart will stop moving after some number of circuits.

===MPL NOT===
{{diagram|spaces=yes|\

O, O,
track ramp
z+2
╔═╗ ╔═╗ ╔═╗
O══[#0FF].[#0FF].╝ O▲═▼▼╝ O▲[#F0F]^▼[#0F0]¢╝
track ramp furniture
z+1

OOO══O OOO▲▲O
track ramp
z+0
}}

Larix's [[User:Larix/MPL/2|powerless logic gates]] avoid the reliability and latency issues that plague many minecart designs through the use of paired impulse ramps and hatches that control not just path, but direction of movement. A minecart traveling the pictured circuit while the input hatch {{Raw Tile|¢|#0F0|#000}} is open will settle into a counter-clockwise path, regardless of the direction of its initial velocity. Yet when the hatch becomes closed, the minecart cannot travel counter-clockwise, but instead is accelerated in the clockwise direction, onto the output plate {{Raw Tile|^|#F0F|#000}}. It will then oscillate between the far east and far west ramps until the hatch is opened, at which point it will resume counter-clockwise motion.

Use of ramps with high-velocity minecarts may necessitate ceilings as demonstrated on z+2. The exact nature of the ceiling (floor, wall) is unimportant. Some diagrammed walls are unnecessary for the design and are drawn to help the reader in orientation.

===Other techniques and gates===
Any logic gate can be made with a combination of those shown. NAND, for instance, is NOT AND; XOR is OR AND (NOT AND). Clocks and edge detection are suggested and proven designs exist, if not on this page. But the examples above were chosen for the disparate techniques they demonstrate. The interested reader is encouraged to further research, or the design of his or her own gates.

Doors can be used to block the travel of a minecart through a circuit, or to prevent derailment, although for reliability's sake, care needs to be taken that the door cannot change state while the minecart is in motion, or it may jam on top of the minecart. [[Floodgate]]s won't jam in this fashion, although they do introduce some latency. Minecarts of multiple weights, with pressure plates that trigger only on the weight of one, may be used in certain designs; Bloodbeard's fantastically tiny [http://www.bay12forums.com/smf/index.php?topic=114923.msg3532411#msg3532411 load-adjusted memory cell] is a good example. Rollers can be used perpendicularly to a track to derail a cart and impart diagonal velocity. Switchable track stops can prevent or permit derailment. The possibilities are far from exhausted-- and that's assuming one is only interested in ''practical'' techniques.

==Integration with other disciplines==
There's no reason minecart logic needs to be used in isolation. Combining it with other logical disciplines allows one to use each where it is strong, and avoid each where it is weak.

===[[Mechanical logic]]===
This is the most obvious choice. Mechanical logic offers the potential for incredible speed, yet requires a medium to generate useful signals or to create delay (hence, to create repeaters), and it's hard to use gear assemblies as memory cells. Minecart logic excels at precisely these tasks. Minecart-based power-to-signal and memory are tiny and fast. Minecart-based delay is precisely tunable. The superiority of minecart logic has made water obsolete for these purposes.

===[[Creature logic]]===
Minecart logic, particularly Larix's powerless MPL logic, has replaced creature logic as the logic-of-last-resort (for when power and fluid are unavailable) or first-resort (for when computation is desired before power can be set up or fluid accessed). However, for the borg logic hobbyist, integration with minecarts suggests interesting possibilities. It is difficult to imagine a simpler clock than a minecart with a "push always after x days" condition, and guided minecarts offer unprecedented control over the path of [[dwarf|dwarves]].

===[[Fluid logic]]===
Minecart logic outperforms fluid logic sufficiently to have mostly replaced it. However, the problem of automated fluid delivery may be best solved through some fluid logic techniques, and may suggest some [[stupid dwarf trick]]s for those that want to use the fluid capacity of minecarts to compute.

== See Also ==
* BloodBeard's [http://www.bay12forums.com/smf/index.php?topic=114923.0 Minecart Dwarfputing Ideas] thread.
* TinyPirate's [http://www.youtube.com/watch?v=jrt9qRTWFmY Minecart Logic 101] instructional video.
* [[User:Larix/MPL|Powerless logic]] based on hatch-switched minecarts. [[User:Larix/MPL/2|Logic gates]] built under this design doctrine.

{{Category|Fortress mode}}
{{Category|Computing}}
{{Category|Logic}}

v0.34:Creature logic

2014-02-26T01:04:04Z

Vasiln: Reversibility + a bit of borg-logic fun

{{Quality|Exceptional|20:46, 30 April 2013 (UTC)}}
{{Computing}}
{{av}}

Creature logic is a form of dwarven [[computing]] that functions by taking advantage of creature's natural [[path]]-finding goals to trigger pressure plates. Creature logic is complete-- you can build memory, repeaters, or any sort of logical circuit.

==Creature logic vs other disciplines==
Pro:
* Creature logic requires no [[water|fluid]] or [[windmill|wind]]. In dry, windless environments, circuits are limited to creature logic or [[minecart logic]].
* Similarly, creature logic requires no infrastructure-- you can build your circuits anywhere, without worrying about bringing water or [[power]] from one end of your map to the other.
* All creature logic circuits can be designed with only [[stone]] and a pick-- although you're free to use [[wood]] or [[metal]] if you prefer!
* Creature logic doesn't need anything but creatures to send or receive signals. There's no need to translate signals as with with [[mechanical logic]].
* Creature logic can be very intuitive. Watching creatures physically travel through your logic pathways simplifies debugging.
* It's fun to watch the creatures run around!

Con:
* Reliable creature logic requires a ridiculous number of [[hatch]]es, [[door]]s, and [[mechanism]]s-- not to mention connections between pressure plates.
* Creature logic requires creatures-- sometimes, a great number of creatures. Sometimes, those creatures die or have babies. Sometimes, they interrupt your [[dwarf|dwarves]]. Sometimes, your dwarves fill them full of crossbow bolts.
* Creature logic is vulnerable (surprise) to the presence of unexpected creatures in the logic circuits. Because creature logic circuits require a path either to the map edge or to the [[Activity_zone#Meeting_Area|meeting hall]] (in most cases), this is a real possibility.
* Creature logic requires large amounts of space.

==Free range or one path==
There are two incompatible design philosophies associated with creature logic-- mostly, the creatures you use will determine which is appropriate.

Free range creature logic generally gives a path to creatures when certain criteria are met, and otherwise, lets them wander (in a constrained space). This simplifies design and permits constant evaluation of criteria, but any creature that paces in captivity can easily foul up your circuits-- for instance, a pacing creature may prevent a door from closing, causing an AND to evaluate as true even though both operands were never true at the same time. Additionally, it gives no clear indication that an evaluation has been completed-- if you want to evaluate your AND statement, you only ever know that it's been evaluated as true, never as false.

One path design constrains creatures to a single tile when they have no path available. Whenever the creature is permitted movement for evaluation of operands, the creature is guaranteed one and only one path. This requires explicit designation of 'else' paths, and requires that operands be evaluated at specific times rather than undergoing constant evaluation, but guarantees complete reliability, and allows the circuit to return both 'true' and 'false' evaluations, meaning that you can know for sure that a signal has been evaluated, rather than guessing if the creature has had sufficient time to path or not path.

==Animal logic==
[[Animal logic]] relies on a special case of free range creature logic that is specific to animals that are unable to open doors, by pathing them through tightly closed doors. Animal logic can be very space efficient and easy to build in comparison to most kinds of creature logic, but is somewhat unreliable.

==Gates==
Creature logic relies on the ability or inability of a creature to path through a specific area. "One path" design requires explicit 'else' arms. Because of that, the following logic gates are shown in complementary pairs to guarantee a path to the creature.

All of these gates can be easily altered to take more than two operands.

====Key====
In all of the following diagrams, the creature is assumed to start at {{Raw Tile|s|#0FF|#000}} (if given). {{Raw Tile|p|#F00|#000}} means that the square contains a path to the creature's pathing goal. Doors {{Raw Tile|┼|#FF0|#000}} and hatches {{Raw Tile|¢|#FF0|#000}} are displayed in the same color as the [[pressure plate]] {{Raw Tile|^|#FF0|#000}} that links to them. If no pressure plate exists for a color, furniture of that color is opened or closed from outside of the circuit pictured; if a hatch and a door are the same color, that means they receive signals from the same source. Output pressure plates are displayed in magenta {{Raw Tile|^|#F0F|#000}}, as is any furniture in the circuit that is linked with the output plate. In the rare case that part of a circuit is linked with multiple elements, it will be displayed with foreground and background colors and explained in text-- for instance, {{Raw Tile|^|#F0F|#0FF}} is linked both to cyan furniture and output.

===Identity with NOT gate===
{{diagram|spaces=yes|\
╔══╗
═╝[#0F0]┼[#F0F]^╚═
[#0FF]s+OO+[#F00]p
═╗[#0F0]¢+╔═
╚══╝ }}

This function takes a single operand. If the operand is true, the creature travels through the upper path (identity); otherwise, the creature takes the lower path (NOT). The pressure plate signals when the operand is true. This gate is the basis of all to follow.

Identity is also a simple delay. When the path receives a signal, it propagates it after a short period. That period depends on the speed of the creature moving through the gate.

===AND gate with NAND gate===
{{diagram|spaces=yes|\
╔═══╗
═╝[#0F0]┼[#FF0]┼[#F0F]^╚═
[#0FF]s+O═O+[#F00]p
═╗+[#0F0]¢+╔═
╚╗[#FF0]¢╔╝
╚═╝ }}

The doors at the top are both open if both operands are true (AND); the hatches at the bottom permit path if either operand is false (NAND). The pressure plate will signal when both operands are true.

===NOR gate with OR gate===
{{diagram|spaces=yes|\
╔═══╗
═╝[#0F0]¢[#FF0]¢[#F0F]^╚═
[#0FF]s+O═O+[#F00]p
═╗+[#0F0]┼+╔═
╚╗[#FF0]┼╔╝
╚═╝ }}

The hatches at the top permit path only if neither operand is true (NOR); the doors at the bottom permit path if either operand is true (OR). The pressure plate will signal when neither operand is true.

===XOR gate with expanded XNOR gate===
{{diagram|spaces=yes|\
╔═╦═╗
╔╝[#0F0]┼O[#0F0]¢╚╗
═╝+[#FF0]┼+[#FF0]¢[#F0F]^╚═
[#0FF]s+O═══O+[#F00]p
═╗+[#0F0]┼[#FF0]┼++╔═
║+OO+╔╝
╚╗[#0F0]¢[#FF0]¢╔╝
╚══╝ }}

As XOR is the intersection of OR and NAND, it is simply an OR followed by a NAND. The XNOR, as the union of AND and NOR, requires two arms. Each operand is linked to one door and one hatch in the XOR path, and to one door and one hatch in the XNOR path. The pressure plate will signal when either operand is true but not both are true. When modifying the XOR to take more than two operands, be careful to leave space between the doors and hatches as shown; this space is unnecessary for evaluation of two operands. Similarly, the expanded XNOR is appropriate when dealing with more than two operands, but a condensed version for taking only two operands exists.

===Multiple use===
The gates above are single use gates; the creatures will escape after pathing through each gate. Circuits which return the creature to the beginning of the path are possible via altering the path in-route.
{{diagram|spaces=yes|\
║[#F00]p║
══╝[#0F0]¢║
[#0FF]s[#0F0]¢[#0F0]^O╣
══╗[#0F0]┼║
║[#F00]p║}}

This is one such device for re-routing creatures mid-path. Upon stepping on the pressure plate, the creature opens two hatches, thus blocking retrograde motion as well as access to its pathing goal, and opens a door, giving access to a new pathing goal. This new pathing goal can lead back to the original position of the creature. This principle is demonstrated in the designs to follow. Because the creature is constrained on the pressure plate, the door can be opened by outside mechanisms rather than being linked to the pressure plate, permitting controlled movement of a creature through one or more arms of a circuit.

===Reversibility===
The reader may have noticed the ''near'' symmetry of the preceding gates. However, the output works as well when placed before the path-limiting furniture as after! While it's easier to visualize the effects of these circuits when displayed as above, it is often more effective to use a reversed design. When a single creature is used to traverse a large, compound circuit, reverse design can lead to reduced latency.

==Creature memory==
{{diagram|spaces=yes|\
╔═╗
═══╝[#0F0]┼╚══
[#F00]p[#FF0]¢[#FF0]^[#FF0]¢[#00F]¢[#F0F][#00F]^[#00F]¢[#F00]p
══╗[#0FF]┼╔═══
╚═╝ }}

This is a low latency version (not the simplest version, not the most full-featured) of creature-based memory. Each pressure plate is linked to each adjacent hatch. Memory is set by sending an open (followed closely by a close) to either door.

Note that in this diagram, both ends need to lead to the pathing goal. The creature can enter by either side, but will be constrained to either pressure plate during normal operation.

==Clock generation, repeaters, and delay==
A high resolution borg-logic clock or delay can be designed around the rate with which creatures fall. A simpler, low resolution clock can be designed based around the military [[scheduling]] menu or [[minecart]] routes.

The memory design above, slightly modified, can make a decent (not perfectly regular) repeater.
{{diagram|spaces=yes|\
╔═╗
═══╝[#FF0]¢╚══
[#F00]p[#FF0]¢[#FF0]^[#FF0]¢[#00F]¢[#F0F][#00F]^[#00F]¢[#F00]p
══╗[#00F]¢╔═══
╚═╝ }}

Here, each pressure plate is linked to the two orthogonally adjacent hatches. The southern hatch is linked to the eastern pressure plate, while the northern hatch is linked to western pressure plate. This repeater tends to fire about every 250 ticks, with open and close signals offset by about 125 ticks, when built as shown. It's very effective at rapidly triggering any device with a refractory period of 100. Similar, non-repeating systems can be used to institute delay.

Linking both pressure plates to output doubles its rate, turning it into very effective spike repeater. The period can be increased by introducing floor space into the center of the design.

==Edge Detection==
{{diagram|spaces=yes|\
║[#F00]p║ ║[#F00]p║
║[#0F0]¢╚═══╝[#FF0]¢║
╠O[#0F0]^[#0FF]┼[#F0F]^[#FF0]¢[#FF0]^O╣
║[#0F0]¢O═══O[#0FF]¢║
╚╗++[#F0F]^++╔╝
╚═════╝ }}

North of the circuit is the pathing goal. The eastern and western pressure plates are linked to adjacent hatches. Input is linked to the hatch southeast of the eastern pressure plate and to the door. The central and southern pressure plates are linked to output. This circuit generates both an open and a close every time it is sent an open or a close signal from input -- that is, it generates two properly-ordered signals for every properly-ordered signal it is sent, allowing for ''edge triggered'' logic. Either output pressure plate can be removed to send an open and a close only upon receiving one kind of signal or the other kind of signal. Output can linked to the same device or to two different devices.

Note that the memory design forms a sort of inverse of this circuit, in that a single open-close cycle is translated into a single on or off signal.

==Alternative design==
Multiple choices of furniture are available for the doors or hatches in the above diagrams. Various reasons exist for substitution.

====Doorless design====
Of all alternative designs, doorless design is the most practical. All doors are replaced with hatches over [[stair]]s or [[ramp]]s, and the path continues one z-level down or up. This makes it more difficult to visualize the circuit, and some very efficient designs may require more significant changes, but every circuit possible can be created without doors. Use of hatches instead of doors protects against the effects of doors being blocked open by unexpected creatures or objects-- the original bug, after all, took the form of [[vermin]] remains. Retracting [[bridge]]s can be used the same way, but lead to problematic delays.

====Hatchless design====
Hatchless design is much more difficult and of very limited use. Signal inversion can make a door act like a hatch; a raising bridge acts like a hatch. Both of these institute delays in processing that require large expansion of logic circuits and limit the effectiveness of memory, but they may be necessary when using submerged logic or flyers-- bragging rights for a logic system submerged in [[magma]] that processes via [[fire imp]]s may be worth the headache.

====Bridge design====
Bridge design uses bridges instead of both doors and hatches. Doors are replaced with retracting bridges over ramps or staircases; hatches are replaced with raising bridges, or with retracting bridges over channels. Bridge design causes frustrating delays, but it is the only way to use [[building destroyer]]s in a logic circuit. The irony of making your [[minotaur]] run an impossible labyrinth may be worth the design headache. As an added bonus, bridges are nearly unobstructable-- offensive vermin remains in your logic circuits will be smashed from this plane.

==Creature choice==
Multiple choices exist for creatures to run logic circuits. Each has its own advantages and disadvantages.

====Domestic animals====
[[Domestic animal]]s are valid choices for creature logic, but come with a host of disadvantages. Many females are capable of giving birth inside of your logic gates; their [[child|children]] can block the closing of doors or set off pressure plates. [[pasture|Grazers]], of course, will starve inside most logic circuits, although some special designs may be capable of supporting a grazer. Some domestics are too small to set off pressure plates; some are capable of flight, requiring hatchless design. All unmodded domestic animals will die of old age, requiring periodic replacement. Most domestic animals have relatively short lifespans. Logic involving domestic animals must be built with pressure plates that can be triggered by citizens, and building these circuits may turn into a nightmare of job cancellations and stranded, starving dwarves. Domestic animals have one huge advantage, however: the location of their pathing goal can be altered with direct, unmediated action of the player, by placement of a meeting zone.

====Invaders====
[[Invader]]s are readily available on most maps, rarely or never give birth, and require no sustenance. Pressure plates don't need to be built triggerable by citizens. [[elf|Elves]] and [[goblin]]s will never die of old age. However, invaders cause their own problems. Invaders can cause job cancellations, and in some circuits may escape, wreaking havoc deep in your fortress. Dwarves armed with bolts and crossbows will take potshots at your computers periodically. Finally, invader-based logic must have a path to the map edge for predictable pathing. If your logic circuit is inside of your fortress, walling off, even through something as simple as raising a bridge at your entrance, will lead to unpredictable pathing.

====Dwarves====
Dwarves themselves can be used to run logic circuits, and are perhaps the most interesting choice; logic designs involving dwarves are generally referred to as borg logic. While longer-lived than most domestics, dwarves [[food|starve]] and [[alcohol|dehydrate]] easily, requiring frequent, careful maintenance. Idle dwarves path unpredictably, and dwarves are vulnerable to [[sleep|drowsiness]], leading to very high latency. Married female dwarves are fecund. At the same time, dwarves are excellent choices for logic circuits because of their varied pathing goals that can be altered through direct interaction by the player. Dwarves can trigger events both through the use of pressure plates and through the use of [[lever]]s, while their pathing goals can be controlled by many means-- most easily and predictably, by military scheduling or minecart routes. In fact, one can see the entire game of Dwarf Fortress as one big logic circuit with dwarves as the driving creature. The more philosophically oriented overseer may wonder what cyclopean, ineffable circuit he or she is traversing through the act of playing Dwarf Fortress....

===Undead===
[[Undead]] are an intriguing choice for creature logic choices. The absence of attribute rust opens up the possibility for a more consistent repeater. They can be used in fully submerged circuits-- even in magma-submerged systems. In some [[biome]]s, they are self-repairing. However, undead path like wildlife, which can make it difficult to set up a circuit for them. Without a clear target, they may not behave predictably. One way to work around this is to build a visible target to which the undead path, by walling the circuit with [[channel]]s instead of walls, and placing a captured invader in clear line-of-sight of the undead logician.

===Other choices===
There are a few things to stay away from, but in general, any sufficiently understood creature can be used for creature logic. Building destroyers are problematic, but full-bridge design is possible. Likewise, flyers and swimmers cause difficulty, but nothing that can't be worked around. Creatures with trapavoid are nearly useless, though [[gremlin]]s might be able to output via levers; stun-able creatures like [[kobold]]s can trigger pressure plates when dropped/stunned; and non-web-immune creatures trigger pressure plates that have been [[web]]bed. Creatures with a [[size]] less than 10000 are too small to set off pressure plates, thus requiring additional "hardware" (such as a tame creature that "flees" or "charges" over a pressure plate). The essence of creature logic, however, is predictable pathing. This may or may not exclude the use of certain types of wildlife.

{{Category|Computing}}
{{Category|Logic}}

v0.34 Talk:Minecart logic

2014-02-25T22:27:12Z

Vasiln: /* Examples */

==Double-carted power-to-signal converter==
"The light green gear is still engaged but no power is being sent to it because the dark green is off." - Why is this the case? Is the pressure plate linked to the dark green gear assembly in addition to the intended output machines? If so, why is this not stated in the article? --[[User:Quietust|Quietust]] 10:52, 7 September 2012 (UTC)

** Power is coming in on the bottom gear, so when it is disengaged by the pressure plate it doesn't matter that the top gear is engaged, or not, no power can be transmitted up the axel to activate the roller. It made sense to me... but that whole area needs re-writing to remove the personal voice anyway, I guess. --[[User:TinyPirate|TinyPirate]] 10:57, 7 September 2012 (UTC)

::: Isn't this more of a latch? If i understand it correctly, it must be switched off with a signal and won't turn off when power to the gear is cut. --[[User:Larix|Larix]] ([[User talk:Larix|talk]]) 17:57, 18 October 2013 (UTC)
::: PS: if i haven't got it completely wrong, it's simply a NOT gate, but this fact is obscured by the complicated operation. The proof of a Power-to-Signal generator is ''deconstructing'' an axle or other powered component so power connection is lost without signals: this should turn the device off. --[[User:Larix|Larix]] ([[User talk:Larix|talk]]) 01:55, 18 February 2014 (UTC)

== MPL ==

I added a mention of the stuff i've worked on and added a link to my user page. Edits and suggestions for improvement are welcome.--[[User:Larix|Larix]] ([[User talk:Larix|talk]]) 17:59, 18 October 2013 (UTC)

==ASCII diagrams==
Planning a bit of a redesign, including implementing ASCII diagrams (which I believe are preferred? but correct me if mistaken). Problem: anybody know where I can find that minecart character? better yet, anybody willing to just paste it into a response for me? [[User:Vasiln|Vasiln]] ([[User talk:Vasiln|talk]]) 04:50, 20 February 2014 (UTC)
:It's at [[character table]] somewhere (the variable-width font makes it hard to tell, especially on mobile, so I'm not sure exactly what it is).
:Also, I've been working on a diagram replacement, which will hopefully be up soon once Briess gets a chance to deploy it. It has more syntax features and actually displays things in the DF font. :) (feel free go ahead and set up diagrams, though - I feel like diagrams are more efficient than a series of small pictures). —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 12:50, 20 February 2014 (UTC)
:Okay, according to the raws it's 254, which looks like a square to me on the table (and here): <code>{{char|254}}</code>
:{{diagram|■}} also looks like a square, so I'm not really sure if that's right or not. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 13:01, 20 February 2014 (UTC)
:Never mind, it has [INVERTED_TILE]. Just change the colors and it should work. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 13:04, 20 February 2014 (UTC)
::Thank you very much!

:::I should have mentioned how to do background colors - currently they work like this: <code>[fg][bg]x</code>
:::So a minecart would be <code>[#000][#ccc]{{#char:254}}</code>, which produces:
{{diagram|spaces=yes|minecart: [#000][#ccc]{{#char:254}} (extra padding)}}
:::(Minecarts don't display very well with the diagram font, unfortunately.)
:::I also made a new parser function: {{<nowiki/>#char}}. It converts a number into the corresponding character, so <nowiki>{{#char:254}}</nowiki> produces {{#char:254}}. Hopefully it's easier than copying things from the character table individually. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 19:49, 21 February 2014 (UTC)
::Will get it nicer over next few days. Iterative process :)[[User:Vasiln|Vasiln]] ([[User talk:Vasiln|talk]]) 01:45, 22 February 2014 (UTC)

== Examples ==

I agree that the examples were a bit lengthy, but maybe we could move them to a subpage (e.g. [[DF2012:Minecart logic/Examples]]) instead of removing them entirely. I think some people would still prefer to have examples available somewhere, even if they're not on this page. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 00:47, 22 February 2014 (UTC)
:The examples I got rid of were all on bloodbeard's thread, which is still linked at the bottom of the page. Other logic pages handle the potential for variation similarly: linking to threads and user pages. Of course, that doesn't mean it's ideal. I believe that when this page is fleshed out a bit more (which I will do over the next week) it won't seem as severe. Summary: that might be a good idea, but I think we should wait a bit before deciding?[[User:Vasiln|Vasiln]] ([[User talk:Vasiln|talk]]) 01:45, 22 February 2014 (UTC)

::That's fine with me (I must have missed the links at the bottom). I did think this page needed reworking, so go right ahead. :) —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 02:56, 22 February 2014 (UTC)

:::Coming along nicely. I think the examples give a good impression of the basic doctrines of minecart logic. I'd suggest a better design for the powered Path-Switch example:

:::===Roller-switched NOR===
{{diagram|spaces=yes|\
║ ║
╔╗ [#0F0]P[#0F0]╧╗
║║ ║║
╔╗ [#0F0]P[#0FF]╧╗
║║ [#F0F]^║
╚╗ ╚╗
track furniture}}

:::Using your basic design, but without causing derailing/rerailing (diagonal movement forced by perpendicular rollers) and thus cutting out the need for restricting walls to the east. Rollers working against the cart's movement direction instantly revert it, and corners, even on the same tile as the roller, redirect the cart without issue.

:::When the rollers are off, the cart will still pass in a straight line without any complications. This switch design is somewhat unintuitive, since it uses a roller direction apparently opposed to any desired output directions, but it's the most compact and well-behaved switch design.--[[User:Larix|Larix]] ([[User talk:Larix|talk]]) 05:16, 25 February 2014 (UTC)
Thanks, I've put it in. It looks like an AND to me, although it is a bit of a puzzle, thanks to easily conflated power/signal and the weird behavior of rollers (deactivate-on-open). I'm not perfectly confident, so if I'm mistaken, feel free to correct the page. And as a further comment, there are still a few principles that may need demonstration. I am unsure if any more belong. Increasingly, I say to myself, "You could do that, but why?" about further techniques. [[User:Vasiln|Vasiln]] ([[User talk:Vasiln|talk]]) 22:27, 25 February 2014 (UTC)

v0.34:Minecart logic

2014-02-25T22:20:32Z

Vasiln: roller derailer NOR->roller swtiched AND; +continuous roller OR; bridge derailer AND->resettable bridge derailer AND; +MPL NOT; +integration; cleanup as always; not quite done with it yet

{{Quality|Superior|20:51, 30 April 2013 (UTC)}}
{{Computing}}
{{av}}

The addition of [[minecart]]s to Dwarf Fortress has opened up new and exciting logic and computing options for the ambitious fortress manager. Minecart-based logic gates and memory cells are easy to build (arguably easier than [[fluid logic]] systems), they are easy to reconfigure, and react quickly.

==Techniques and Circuits==

There exist a great number of different techniques by which a minecart can receive input, compute, and deliver output. This article does not aim for a comprehensive list of techniques and circuits; the interested reader is encouraged to investigate further. The following examples were chosen to demonstrate both a variety of techniques and a few commonly used gates.

====Key====
Adequately diagramming minecart logic devices can be difficult; each tile on each z-level might need to display up to four slices (track, ramp, furniture, minecart) that can lay on top of each other. Ramps are displayed on the furniture layer for the sake of simplicity, and some slices may be omitted when unnecessary. Components of each lower slice are displayed on the higher slice when unchanged by new components to give the reader a sense of placement. Wall {{Raw Tile|O|#FFF|#000}} is typically displayed only where it is essential to the operation of the circuit. Unengraved floor {{Raw Tile|,|#FFF|#000}} is sometimes needed for other components, but of course can be smoothed as desired. Track direction is laid out with {{Raw Tile|║|#FFF|#000}}{{Raw Tile|═|#FFF|#000}}{{Raw Tile|╗|#FFF|#000}}{{Raw Tile|╝|#FFF|#000}}{{Raw Tile|╚|#FFF|#000}}{{Raw Tile|╔|#FFF|#000}} and ends in a tile with {{Raw Tile|╨|#FFF|#000}}{{Raw Tile|╥|#FFF|#000}}{{Raw Tile|╡|#FFF|#000}}{{Raw Tile|╞|#FFF|#000}}. Minecarts {{Raw Tile|■|#FFF|#000}} are accelerated by rollers to the east {{Raw Tile|╟|#FFF|#000}} west {{Raw Tile|╢|#FFF|#000}} north {{Raw Tile|╧|#FFF|#000}} or south {{Raw Tile|╤|#FFF|#000}} and decelerated by track stops {{Raw Tile|≡|#FFF|#000}}. Rollers are controlled via gear assemblies, either engaged {{Raw Tile|☼|#FFF|#000}} or disengaged {{Raw Tile|☼|#777|#000}}, typically connected to sufficient power {{Raw Tile|P|#0F0|#000}}. Pressure plates {{Raw Tile|^|#FFF|#000}} provide output and, in some cases, modulate the circuit itself; in such cases, they are typically colored to make it clear to which components they are linked. Up {{Raw Tile|▲|#FFF|#000}} and down {{Raw Tile|▼|#FFF|#000}} ramps may be necessary to travel z-levels or alter minecart velocity; they may be roofed or covered with empty space {{Raw Tile|.|#0FF|#000}} in some views. Doors {{Raw Tile|┼|#FFF|#000}}, hatches {{Raw Tile|¢|#FFF|#000}}, and retractable bridges {{Raw Tile|╬|#000|#CCC}} are commonly used to control the path of minecarts. Where necessary, clarification can be found in the descriptions of each circuit.

===Power to signal===
{{diagram|spaces=yes|\
O O
╥, ╤☼
║ [#F0F]^[#0F0]P
╨, ╧☼
O O
track furniture}}

In this simplest of all designs, the output plate sends an '''on''' signal when the gear assemblies {{Raw Tile|☼|#FFF|#000}} are powered {{Raw Tile|P|#0F0|#000}}. When power is lost, the minecart settles onto either the northern or southern roller spaces, and the output plate sends an '''off''' signal.

This device is very general purpose. Left as an exercise for the reader, alternate construction can result in a [[repeater]] or edge detection.

===Newton's Cradle Memory===
{{diagram|spaces=yes|\
O O O
╥, ╤[#0C0]☼[#0F0]P ╤[#0C0]☼[#0F0]P
║ ║ ║
║ [#F0F]^ [#000][#0f0]■
╨, ╧[#0CC]☼[#0F0]P [#000][#0ff]■[#0CC]☼[#0F0]P
O O O
track furniture minecart}}

TinyPirate's Newton's Cradle [[Memory_(computing)|memory]] cell is notable both for its small footprint and for demonstrating an important principle of minecarts. When the southern gear assembly {{Raw Tile|☼|#0CC|#000}} is briefly engaged, the southern roller {{Raw Tile|╧|#FFF|#000}} becomes powered, launching the southern minecart {{Raw Tile|■|#000|#0FF}} into the northern minecart {{Raw Tile|■|#000|#0F0}}. The northern minecart then leaves the pressure plate and settles on the northern (unpowered) roller. When the northern gear assembly is briefly engaged, the situation reverses: the northern minecart knocks the southern minecart off of the output plate.

===Continuous roller OR===
{{diagram|spaces=yes|\
╔═╗═╗ ╔═╗═╗
║ ║O║ ║ [#F0F]^O║
║ ║O║ ╤[#0F0]☼╧O║
║ ║O║ [#0F0]P╤[#0FF]☼╧O║
╚═╩═╝ ╚═╧═╝
track furniture}}
Veylon's roller OR continuously evaluates two operands via a minecart traveling counter-clockwise using principles of power transmission through single tile rollers. Should either input {{Raw Tile|☼|#0F0|#000}} or {{Raw Tile|☼|#0FF|#000}} be engaged, power {{Raw Tile|P|#0F0|#000}} is transmitted to the southernmost, S->N roller {{Raw Tile|╧|#FFF|#000}}. Although the minecart is left with diagonal velocity, walls prevent derailment. When neither input is engaged, the minecart continues over the T-junction to the east, missing the output plate {{Raw Tile|^|#F0F|#000}}.

===Roller switched AND===
{{diagram|spaces=yes|\
║ ║
╔╗ [#0F0]P[#0F0]╧╗
║║ ║║
╔╗ [#0F0]P[#0FF]╧╗
║║ [#F0F]^║
╚╗ ╚╗
track furniture}}
Larix's roller-switched AND takes advantage of the behavior of rollers to avoid troublesome diagonal velocity, but is confusing both for the counter-intuitive direction of its rollers as well as the way that rollers respond to signals. When the minecart encounters either activated (that is, the last signal received was an '''off''') S->N roller {{Raw Tile|╧|#0FF|#000}} or {{Raw Tile|╧|#0F0|#000}}, its velocity is completely rewritten and reversed, sending it onto the alternate (clockwise) path. Should neither roller be activated (that is, the last signal received by both was an '''on'''), the track bends will be ignored and the minecart will travel directly south, over the output plate {{Raw Tile|^|#F0F|#000}}.

===Resetting bridge-derailment AND===
{{diagram|spaces=yes|\
O[#0FF].═[#0FF]. O▼═▼ O[#0FF]¢═▼

track ramp furniture
z+1
O╔O╗ O▲O▲ O▲O▲
╚═╚ ╚═▲ [#000][#0f0]╬[#F0F]^▲
╚═╝ ╚═╝ ╚═╝
track ramp furniture
z+0}}

When both the cyan hatch {{Raw Tile|¢|#0FF|#000}} and the green retractable bridge {{Raw Tile|╬|#000|#0F0}} are open, minecarts on this circuit make a continuous loop, triggering the output plate {{Raw Tile|^|#F0F|#000}}. If either is closed, the plate is never activated. If the bridge is closed, the minecart derails to the southern path, avoiding the plate. If the hatch is closed, the minecart is unable to drop into the northwest ramp, and so sits on the upper, northwestern tile until the hatch opens.

There are many concerns when using a gate like this. Minecarts can be flung when a bridge changes state underneath them. Additionally, because your minecart never evaluates both operands at the exact same moment, it's possible for this gate to output when neither operand is actually true at the same moment.

It's not always a problem, but this behavior is common to AND gates. Paradoxically, one solution is to moderate your inputs via an extra AND gate; this design shows how that can be done. When a large number of circuits such as that shown are created and the hatches of all of them are linked to a single lever, a quick flick (on and off) of that lever can guarantee that all of your circuits fire at the same time-- that is, that all of your inputs for the next computation change state simultaneously. The minecarts then return to their position atop the hatches, ready for another flick of your clock lever.

Worth noting, as well, is the central eastern impulse ramp that allows the minecart to maintain enough velocity to complete this circuit. Impulse ramps like this can be used to make unpowered gates. However, their behavior is unintuitive, and they should only be used with extreme caution. For example, in the diagram above, such a device used for continuous AND evaluation (rather than the resetting AND suggested in the text) is likely to accelerate the minecart on each pass, such that the minecart will stop moving after some number of circuits.

===MPL NOT===
{{diagram|spaces=yes|\

O, O,
track ramp
z+2
╔═╗ ╔═╗ ╔═╗
O══[#0FF].[#0FF].╝ O▲═▼▼╝ O▲[#F0F]^▼[#0F0]¢╝
track ramp furniture
z+1

OOO══O OOO▲▲O
track ramp
z+0
}}

Larix's powerless logic gates avoid the reliability and latency issues that plague many minecart designs through the use of paired impulse ramps and hatches that control not just path, but direction of movement. A minecart traveling the pictured circuit while the input hatch {{Raw Tile|¢|#0F0|#000}} is open will settle into a counter-clockwise path, regardless of the direction of its initial velocity. Yet when the hatch becomes closed, the minecart cannot travel counter-clockwise, but instead is accelerated in the clockwise direction, onto the output plate {{Raw Tile|^|#F0F|#000}}. It will then oscillate between the far east and far west ramps until the hatch is opened, at which point it will resume counter-clockwise motion.

Use of ramps with high-velocity minecarts may necessitate ceilings as demonstrated on z+2. The exact nature of the ceiling (floor, wall) is unimportant. Some diagrammed walls are unnecessary for the design and are drawn to help the reader in orientation.

==Potential as an independent logic discipline==

Minecarts can also be set in motion by ramps and switched between different paths by buildings, opening the path for a powerless logic discipline. The basic binary logic gates can be built in this fashion and combined to perform other operations like counting or basic algebra. The circuits tend to look quite complicated, especially if they stretch over multiple levels.

[[File:Äquivalenz-Differenz.png]]

This kind of minecart logic is primarily an alternative to [[creature logic]]. Since minecarts move relatively quickly and completely deterministically, simple minecart logic gates can be relatively small and quick. Since a minecart only reacts to the conditions of its current tile and the tile it tries to move into, creature logic will have an advantage when looking at multiple and long logic paths, where a creature instantly detects and chooses the open path, while the minecart has to check every tile and building separately.

For signal generation, memory cells, repeaters and adders, this kind of minecart logic offers a variety of options.

==Integration with other disciplines==

There's no reason minecart logic needs to be used in isolation. Integration of disciplines allows one to use each where it is strong, and avoid each where it is weak.

===Mechanical logic===
This is the most obvious choice. Mechanical logic offers the potential for incredible speed, yet requires integration to generate useful signals or to create delay (hence repeaters and clocks), and has trouble creating usable memory cells without integration. Minecart logic excels at precisely these tasks. Minecart power-to-signal cells and latches are tiny and fast. Minecart repeaters are precisely tunable. The superiority of minecart logic has made water obsolete for these purposes.

===Creature logic===
Minecart logic, particularly Larix's powerless MPL logic, has replaced creature logic as the logic-of-last-resort (for when power and fluid are unavailable) or first-resort (for when computation is desired before power can be set up or fluid accessed). However, for the borg logic hobbyist, integration with minecarts suggests interesting possibilities. It is difficult to imagine a simpler clock or repeater than a minecart with a "push always after x days" condition, and guided minecarts offer unprecedented control over the path of dwarves.

===Fluid logic===
Minecart logic outperforms fluid logic sufficiently to have mostly replaced it. However, the problem of automated fluid delivery may be best solved through some fluid logic integration, and may suggest some stupid dwarf tricks for those that want to use the fluid capacity of minecarts to compute.

== See Also ==
* BloodBeard's [http://www.bay12forums.com/smf/index.php?topic=114923.0 Minecart Dwarfputing Ideas] thread.
* TinyPirate's [http://www.youtube.com/watch?v=jrt9qRTWFmY Minecart Logic 101] instructional video.
* [[User:Larix/MPL|Powerless logic]] based on hatch-switched minecarts. [[User:Larix/MPL/2|Logic gates]] built under this design doctrine.

{{Category|Fortress mode}}
{{Category|Computing}}
{{Category|Logic}}

v0.34:Minecart logic

2014-02-23T23:55:48Z

Vasiln: oops

v0.34:Minecart logic

2014-02-23T23:50:28Z

Vasiln: bridge-based AND, more clean up

User:Vasiln/sandbox

2014-02-23T23:03:03Z

Vasiln: Created page with "{{Quality|Superior|20:51, 30 April 2013 (UTC)}} {{Computing}} {{av}} The addition of minecarts to Dwarf Fortress has opened up new and exciting logic and computing option..."

User:Vasiln

2014-02-23T23:02:38Z

Vasiln:

My principal interest these days (in DF) is creature logic. I figure I might as well save some of my techniques here in case anybody stumbles over them.

* [[User:Vasiln/Goblin Logic 1]]: Where I deal with some basic gates and the infrastructure needed to make goblin logic work
* [[User:Vasiln/Goblin Logic 2]]: Where I go into advanced logic problems, memory addressing, adder optimization, and start writing some programs
* [[User:Vasiln/Goblin Logic 3]]: Where we deal with practical problems associated with building a programmable goblin logic computer, talk about input and output, and get to multiplexing

I think I'm done with creature logic now. I just feel as if I've solved it, and don't know what to think about next. Feel free to contact me if you've got any questions or problems. There is no logic problem that cannot be solved with a sufficient number of goblins, mechanisms, doors, and hatches.

Here are my designs for the [[User:Vasiln/Undump|undump]].

Toward a comprehensive theory of [[User:Vasiln/Build_order|build order]].

[[User:Vasiln/Adamantine_factory|Live fire bolt recovery]].

The practically useless but technologically interesting [[User:Vasiln/150_tick_repeater|150-tick repeater]].

[[User:Vasiln/minecarts|Experiments in minecarts]]

[[User:Vasiln/sandbox|Sandbox page, currently holding WIP on minecart logic]]

v0.34:Minecart logic

2014-02-23T23:00:42Z

Vasiln: roller derailer OR, some cleanup

Dwarf Fortress Wiki:Administrative intervention against vandalism

2014-02-22T06:48:46Z

Vasiln:

<div style="text-align:left;">
{| class="infobox plainlinks" id="" style="background-color: #eef5ff; border: 1px solid #0088CC; font-size: 90%; margin: 1em 0em 0em; padding: 2px; text-align: left; width: 100%; border-top-left-radius:8px; -moz-border-radius-topleft:8px; -webkit-border-top-left-radius:8px; border-bottom-right-radius:8px; -moz-border-radius-bottomright:8px; -webkit-border-bottom-right-radius:8px;"
! colspan="2" style="border: 1px solid #0088CC; font-weight:bold; background-color: #8ce; padding-left: 1em; padding-right: 1em; border-top-left-radius:4px; -moz-border-radius-topleft:4px; -webkit-border-top-left-radius:4px; border-bottom-right-radius:4px; -moz-border-radius-bottomright:4px; -webkit-border-bottom-right-radius:4px;" |'''Instructions'''
|-
|
#Reported edits must constitute vandalism.
#Link to both an example of the user's vandalism (the revision, not the current page — you can use the "Permanent link") and the user's talk page (which is included with {{tl|User}}).
#Add new reports to the top of the list. Use format: <nowiki>#Reporting user {{User|Briess}} for edits [link], [link] and [link] ~~~~ </nowiki>
#Please remember to sign the report with <code>~~</code><code>~~</code>
#If a report has remained here for more than 24 hours and no action has been taken, please leave a message on an [http://dwarffortresswiki.org/index.php?title=Special%3AListUsers&username=&group=sysop&limit=50 admin's] talk page.
|}
</div>
==Reports==

*reverted edits from IP editor {{User|174.51.109.169}} selling e-cigs at [[Mist]]; "reviewed content and references" lol who does that [[User:Vasiln|Vasiln]] ([[User talk:Vasiln|talk]]) 06:48, 22 February 2014 (UTC)
*godlysockpuppet here, never used a wiki but just reporting that the df2012 page on security design and df2012 page on Maul has been turned to a spam advertising page. Feel free to clean this up or something. //edit I undid the spam. Im the random IP address.
* Reporting {{user|Bancream}} for [http://dwarffortresswiki.org/index.php?title=40d:Pressure&curid=11219&diff=189434&oldid=156802 this edit] on [[40d:Pressure]]. --[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 13:16, 3 July 2013 (UTC)
* Reporting {{user|Pingping111}} for [http://dwarffortresswiki.org/index.php?title=Talk:Main_Page&oldid=185468 this revision] on [[Talk:Main Page]] (12 separate edits). --{{User:Lethosor/sig}} 17:32, 8 May 2013 (UTC)
* More IP spam from {{User|180.194.171.229}}: [http://dwarffortresswiki.org/index.php?title=Bloodline:Succession_League&diff=prev&oldid=183274 here]. --{{User:Lethosor/sig}} 19:28, 5 April 2013 (UTC)
* IP Spam: [http://dwarffortresswiki.org/index.php?title=Bloodline:Succession_League&curid=6982&diff=183202&oldid=180867 this edit] by {{User|180.194.169.157}} --{{User:Lethosor/sig}} 16:36, 4 April 2013 (UTC)
: This report and the one following it both come from the 180.194.*.* block of IP addresses. Perhaps this should be looked into. --{{User:Lethosor/sig}} 16:36, 4 April 2013 (UTC)
*IP Spam http://dwarffortresswiki.org/index.php?title=Dwarf_Fortress_Wiki:Centralized_Discussion&curid=14457&diff=182911&oldid=180865 – [[template:unsigned|unsigned]] comment by [[User:Old Ancient|Old Ancient]]

* <s>Not sure how to report this, but [[User:71.118.242.47|71.118.242.47]] [http://dwarffortresswiki.org/index.php?title=Bloodline%3ASuccession_League_Games&action=historysubmit&diff=182554&oldid=73455 added over 50000 g's] on [[Bloodline:Succession League Games|this page]]. This doesn't seem like the type of spam we normally see, so I'm not sure if it's a bot, but I wouldn't exactly say it's useful information to have in an article. It also doesn't seem like an automated DOS-type attack, but it definitely isn't a normal edit so I thought I'd post it here. --{{User:Lethosor/sig}} 21:19, 12 March 2013 (UTC)</s>
: Considering the lack of spam from this IP since, I don't see any reason to act on this incident now. --{{User:Lethosor/sig}} 20:11, 2 April 2013 (UTC)

* Reporting [[User:Annaferry]], a user who registered about 10 minutes ago and promptly [http://dwarffortresswiki.org/index.php?title=User_talk:GhostDwemer&oldid=182179 posted spam on GhostDwemer's talk page]. --{{User:Lethosor/sig}} 02:36, 7 March 2013 (UTC)

* Reporting [[User:Wingramo]] for [http://dwarffortresswiki.org/index.php?title=ASCII_Art_Reward&diff=prev&oldid=179328 this edit]. It supposedly links to the Bay12 Support page but links to downloadranking.com instead. --[[User:Chronotab|Chronotab]] 18:46, 23 February 2013 (UTC)
:Wingramo's [[Special:Contributions/Wingramo|contributions]], also include an edit on [http://dwarffortresswiki.org/index.php?title=Dwarf_Fortress_RPG&diff=prev&oldid=179721 Dwarf Fortress RPG] and [http://dwarffortresswiki.org/index.php?title=History_of_Dwarf_Fortress&action=historysubmit&diff=179417&oldid=177987 History of Dwarf Fortress], which I reverted. They seem to be from December, so I'm surprised they went unnoticed. Strangely, Wingramo hasn't made any edits since then. --{{User:Lethosor/sig}}) 19:49, 23 February 2013 (UTC)

* Reporting [[User:Alloy7memory]] for [http://dwarffortresswiki.org/index.php?title=Architecture&curid=1583&diff=181412&oldid=181411 this edit], which [[Special:Contributions/174.239.35.25|174.239.35.25]] reverted. It's not exactly "link spam", but the username looks similar to most spambots (although strangely it actually contains real words). --{{User:Lethosor/sig}} 18:06, 23 February 2013 (UTC)

*Reporting IP [[Special:Contributions/180.194.171.159|180.194.171.159]] for an unrelated link to [http://fosamaxlawsuit12.altervista.org/ something about alcohol abuse] on both [[Bloodline:Succession_League]] and [[Dwarf_Fortress_Wiki:Centralized_Discussion]].
*Reporting IP [[Special:Contributions/80.218.59.174|80.218.59.174]] for an [http://dwarffortresswiki.org/index.php?title=Dwarf_Fortress_Wiki:Administrative_intervention_against_vandalism&curid=19125&diff=175408&oldid=174954 edit] made to this page itself. --[[User:Cali|Cali]] 01:51, 17 July 2012 (UTC)
*Reporting IP [[Special:Contributions/112.202.121.89|112.202.121.89]] for its "contributions" of spam links. 21:19, 8 July 2012 (UTC)
::Those "contributions" were from a year ago. Considering that there hasn't been any spam from that IP address since then, there's no point in banning it now. I removed the spam. -- [[User:HiEv|Hi]][[User talk:HiEv|Ev]] 20:50, 8 July 2012 (UTC)
*Reporting new user [[User_talk:Puravida|Puravida]] for a spam link on his(?) user talk page [[User_talk:Puravida]]. --[[User:MathFox|MathFox]] 18:20, 8 May 2012 (UTC)
*Reporting new user [[User_talk:BLT111|BLT111]] for placing a link to an "adult tool site" on his(?) user talk page [[User_talk:BLT111]]. --[[User:MathFox|MathFox]] 16:20, 7 May 2012 (UTC)
**Already got that one - somehow, I didn't see the website link, but the rest of the page looked suspicious enough that I banned it anyways. --[[User:Quietust|Quietust]] 16:34, 7 May 2012 (UTC)
***Yes, I edited the url out before posting here... Compliments with the reaction speed! --[[User:MathFox|MathFox]] 16:36, 7 May 2012 (UTC)
****In the future, '''don't do that''' - if a bot puts spam on its talk page, '''blank the entire page''' so it's clear that it needs to be deleted. --[[User:Quietust|Quietust]] 19:45, 7 May 2012 (UTC)
Reporting [[User talk:Celery‎|Celery]] for all of its "contributions" [[Special:Contributions/Celery|Celery]] [[Special:Contributions/71.75.99.199|71.75.99.199]] 02:50, 20 March 2012 (UTC)

Reporting [[Special:Contributions/63.248.241.226|63.248.241.226]] for this [http://dwarffortresswiki.org/index.php?title=Dwarf_Fortress:About&curid=2&diff=166777&oldid=144963 edit] --[[User:Cali|Cali]] 22:04, 10 March 2012 (UTC)

Reporting [[User talk:Casinostars‎|Casinostars]] for spam linking in [[Talk:Main Page]]. [[User:Knight Otu|Knight Otu]] 16:00, 25 January 2012 (UTC)

#Reporting new user [[User_talk:Neystec1753|Neystec1753]] for placing an advertorial on his(?) user talk page [[User_talk:Neystec1753]]. --[[User:MathFox|MathFox]] 11:00, 22 January 2012 (UTC)
#Reporting user [[User_talk:Cry1313|Cry1313]] for edits [http://df.magmawiki.com/index.php?title=History_of_Dwarf_Fortress&curid=5008&diff=159499&oldid=153841] and [http://df.magmawiki.com/index.php?title=History_of_Dwarf_Fortress&curid=5008&diff=159500&oldid=159499] [[User:Calc|Calc]] 12:02, 21 January 2012 (UTC)

Reporting [[User talk:Neucent1742‎|Neucent1742]] for talk page spam, too. [[User:Knight Otu|Knight Otu]] 16:10, 13 January 2012 (UTC)

Reporing [[User talk:Giome1861‎|Giome1861]] for talk page spam. [[User:Knight Otu|Knight Otu]] 13:39, 13 January 2012 (UTC)

#Reporting new user [[User_talk:Suco1260|Suco1260]] for placing an advertorial on his(?) user talk page [[User_talk:Suco1260]]. --[[User:MathFox|MathFox]] 19:13, 10 January 2012 (UTC)
#Reporting new user [[User_talk:Detoxdietgirl‎|Detoxdietgirl‎]] for placing an advertorial on her(?) user talk page [[User_talk:Detoxdietgirl‎]]. --[[User:MathFox|MathFox]] 12:25, 8 January 2012 (UTC)
#Reporting new user [[User_talk:Exto1871|Exto1871]] for placing an advertorial on his(?) user talk page [[User_talk:Exto1871]]. --[[User:MathFox|MathFox]] 18:04, 5 January 2012 (UTC)
#Reporting new user [[User_talk:Rueti1215|Rueti1215]] for placing an advertorial on his user talk page [[User_talk:Rueti1215]]. --[[User:MathFox|MathFox]] 14:23, 30 December 2011 (UTC)

#Reporting user [[User_talk:Lethuphuong89|Lethuphuong89]] for two (already reverted) edits [[Special:Contributions/Lethuphuong89]] [[Special:Contributions/84.134.6.29|84.134.6.29]] 13:32, 28 December 2011 (UTC)

#Reporting user [[User talk:Tari1388|Tari1388]] for (reverted) talk page spam. [[Special:Contributions/84.134.6.29|84.134.6.29]] 13:32, 28 December 2011 (UTC)

#Reporting IP 167.128.19.234 for vandalizing [[Talk:Main Page]] [http://df.magmawiki.com/index.php?title=Talk:Main_Page&oldid=158314]
--[[User:MathFox|MathFox]] 17:12, 9 December 2011 (UTC)
#Reporting IP 94.122.66.247 for inserting spam links into [[Talk:Main Page]] and [[Talk:Main Page/Quote]]
--[[User:MathFox|MathFox]] 13:47, 7 December 2011 (UTC)
#Reporting user [[User_talk:DMundell|DMundell]] for a bunch of spammy links - see [[Yeti]], [[Badger]], etc. I've reverted the edits and removed the spam.
-- [[Special:Contributions/194.200.65.239|194.200.65.239]] 11:34, 30 November 2011 (UTC)

Um, I don't actually have an account here, but I've just noticed a few things:

- Clicking on some page links results in downloading a .rar file, named with the name of the page you were trying to go to. There's a blank file inside. Also, the main page is encountering database error. It's like the entire site is having a stroke, so I assume some kind of DDOS-like attack is being carried out.
Reporting user [[User:DivinaLittlefield|DivinaLittlefield]] for a number of edits. - [[User:Knight Otu|Knight Otu]] 20:46, 7 November 2011 (UTC)
:Concur, 3 more edits by [[User:DivinaLittlefield|DivinaLittlefield]] around 21:00 today. Invisible direct and redirection links to a site hawking weight control. —[[User:0x517A5D|0x517A5D]] 21:42, 7 November 2011 (UTC)

Reporting users [[User:Shushu|Shushu]], [[User:Liliyuan|Liliyuan]], [[User:Smalltrees|Smalltrees]], and [[User:Bingbingyuan|Bingbingyuan]] for user tallk page spam. - [[User:Knight Otu|Knight Otu]] 09:07, 11 October 2011 (UTC)

Reporting user Ameriplan - bunch of spammy stuff in User talk:Ameriplan
[[Special:Contributions/194.200.65.239|194.200.65.239]] 11:25, 30 September 2011 (UTC)

Reporting user [[User talk:Aiai00125|Aiai00125]] for [http://df.magmawiki.com/index.php?title=Dwarf_Fortress_Wiki:Centralized_Discussion&curid=14457&diff=153375&oldid=153097 this edit to the Centralized discussion page]. The user's talk page also contains linkage spam. -- [[User:Khym Chanur|Khym Chanur]] 03:45, 27 September 2011 (UTC)
:Also on [http://df.magmawiki.com/index.php?title=23a:Creature_small_mammals.txt&curid=15135&diff=153376&oldid=102951 23a:Creature_small_mammals.txt]. Both vandalized pages are reverted.
:[[User:Knight Otu|Knight Otu]] 11:22, 27 September 2011 (UTC)

Reporting user [[User:AWurth93|AWurth93]] for this [http://df.magmawiki.com/index.php?title=Consolidated_Development:_Arcs,_core-items,_bloats,_Reqs_and_Powergoals&curid=17308&diff=153356&oldid=149506]. Yep, there's at least one link in that mess. - [[User:Knight Otu|Knight Otu]] 16:17, 26 September 2011 (UTC)

Reporting user [[User:JBinkley89|JBinkley89]] for this [http://df.magmawiki.com/index.php/DF2010:Strange_mood] wait. I think this list is actually the same as Sgragg88's. -- [[User:RedHerring|Redherring]] 7:59 23/09/2011 GMT+2 (First time editing, sorry for the mess)
:I would suggest looking into users [[User:AWurth93|AWurth93]] and [[User:EKruse55|EKruse55]]. Their names follow the same pattern as Binkley and Gragg - if they are spam accounts then like those, they are probably to lie dormant for a few days before they start their spam.
:[[User:Knight Otu|Knight Otu]] 12:40, 23 September 2011 (UTC)

Reporting user [[User:SGragg88|SGragg88]] for this [http://df.magmawiki.com/index.php?title=DF2010:Water_wheel&diff=153193&oldid=prev edit], this [http://df.magmawiki.com/index.php?title=40d:String_dump&diff=153194&oldid=prev edit], this [http://df.magmawiki.com/index.php?title=40d:Weapon_token&diff=153195&oldid=prev edit], and this [http://df.magmawiki.com/index.php?title=DF2010:Creature_token&diff=153196&oldid=prev edit]. I'd be remiss to not include this [http://df.magmawiki.com/index.php?title=40d:Lead&diff=153197&oldid=prev edit], this [http://df.magmawiki.com/index.php?title=40d:Advanced_world_generation&diff=153198&oldid=prev edit], this [http://df.magmawiki.com/index.php?title=23a:Weapon_token&diff=153199&oldid=prev edit], or this [http://df.magmawiki.com/index.php?title=40d:Armor&diff=153200&oldid=prev edit]. And who could forget such classics as this [http://df.magmawiki.com/index.php?title=40d:Strange_mood&diff=153201&oldid=prev edit], this [http://df.magmawiki.com/index.php?title=40d:Armor_user&diff=153202&oldid=prev edit], this [http://df.magmawiki.com/index.php?title=DF2010:Release_information&diff=153203&oldid=prev edit], and everbody's favorite: this [http://df.magmawiki.com/index.php?title=Caravans&diff=153204&oldid=prev edit]? But wait! There's more! This [http://df.magmawiki.com/index.php?title=DF2010:Strange_mood&diff=153205&oldid=152796 edit] free with purchase! --[[User:Jwest23|Jwest23]] 21:00, 21 September 2011 (UTC)

Reporting user [[Special:Contributions/75.163.224.80|75.163.224.80]] for this [http://df.magmawiki.com/index.php?title=DF2010:Adventure_mode_quick_start&curid=18784&diff=152872&oldid=152303 edit] --[[User:Cali|Cali]] 04:20, 6 September 2011 (UTC)
:At Wikipedia we'd call that a "test edit" - most likely the first ever wiki edit by a young person who didn't quite believe they could change the internet. My bet is that there won't be any further disruption from that IP address, so no administrator action is required. [[User:Bognor|Bognor]] 14:56, 6 September 2011 (UTC)
:: I tend to agree here. --[[User:Briess|Briess]] 07:06, 9 September 2011 (UTC)

Pre-emptive, but I'm guessing the following are not genuine new-user registrations... 
(User creation log); 09:14 . . Download Love That Girl! - Season One 1080p movie New user account 
(User creation log); 08:44 . . Download 60 Minutes Australia - 2011 Full movie New user account 
[[Special:Contributions/194.200.65.239|194.200.65.239]] 10:29, 10 August 2011 (UTC) 
#Reporting IP Address 124.6.181.189 for an [http://df.magmawiki.com/index.php?title=DF2010:Soil&oldid=152086 edit] which I have reverted. --[[User:Jwest23|Jwest23]] 16:03, 4 August 2011 (UTC)
#Reporting IP Address 124.6.181.183 for an [http://df.magmawiki.com/index.php?title=DF2010:Soil&diff=prev&oldid=151941 edit] which I have reverted. --[[User:Jwest23|Jwest23]] 19:05, 31 July 2011 (UTC)
#Reporting user [[User_talk:Jose|Jose]] for an [http://df.magmawiki.com/index.php?title=DF2010:Nail&oldid=151747 edit] which I have reverted. --[[User:Jwest23|Jwest23]] 18:06, 25 July 2011 (UTC)

There was a link insertion at [[Talk:Main_Page/Quote/archive1]] by an anonymous IP. I undid it, not sure if other measures need to be taken.
[[User:Knight Otu|Knight Otu]] 19:10, 18 June 2011 (UTC)

There was a vandalism at "http://df.magmawiki.com/index.php/DF2010:Ruin". -- Dragongutz
:No there wasn't - the article history clearly indicates that the article has '''never''' had any content. --[[User:Quietust|Quietust]] 21:41, 11 April 2011 (UTC)

reporting user [[User:Jalohear]] [[http://df.magmawiki.com/index.php?title=Main_Page&oldid=135938 link]]
:Interestingly, that user (and 2 others) signed up over a week ago and sat dormant this entire time. The bastards are trying to get sneaky... --[[User:Quietust|Quietust]] 21:50, 11 February 2011 (UTC)
::I've seen vandalized main pages like that on the other wikis under attack. I'm not sure, but I think they start doing that only after they've "burrowed" into the site for an extended period of time. I believe the goal is to keep their spam links a part of the wiki for as long as possible. [[User:Uristocrat|Uristocrat]] 08:18, 12 February 2011 (UTC)
:::I suspect they were remaining dormant in order to get past the "new user" stage and gain the ability to edit semi-protected pages. --[[User:Quietust|Quietust]] 17:21, 12 February 2011 (UTC)
::::I've modified new user stage so that you have to have made 10 edits before you can edit semiprotected articles or create new articles, in addition to the 3 day wait period. --[[User:Briess|Briess]] 17:30, 12 February 2011 (UTC)
:::::I'm glad. Sounds like that should help. Although, I just tried to create my user profile ([[User:Thundercraft|Thundercraft]]) and it gave me a '''Permission error''', it said "You do not have permission to create new pages." (I do not have 10 edits yet.) Perhaps you should make user profiles exempt from this rule? Also, I would recommend mentioning to new members about these requirements. Otherwise, it could mean a lot of confused new members at a lot of complaints. You would not have to be specific, however. You could just say that "several edits" are required before that privilege is granted. --[[User:Thundercraft|Thundercraft]] 23:01:23, 12 February 2011 (UTC)
::::::I made your user profile page for you. An admin will have to do anything else. Also, I have confirmation now that the webspam team at Google is taking a look at this. They're interested because it's not just this wiki, there are thousands of others being vandalized by spammers and their real goal is to get their crap into the search engines. That probably won't stop the spambots from vandalizing things, but it will help keep them from profiting from this. [[User:Uristocrat|Uristocrat]] 08:39, 13 February 2011 (UTC)
::::::I'll look into permissions today and see if I can get user page creation working for newly registered users. Also, you're probably right about needing a notice of some sort for this change. --[[User:Briess|Briess]] 16:56, 13 February 2011 (UTC)

Both [[User_talk:DaisyBarrett DaisyBarrett]] ([http://df.magmawiki.com/index.php?title=DF2010:Soil&diff=prev&oldid=151347 example]) and [[User_talk:SunshineMcfadden SunshineMcfadden]] ([http://df.magmawiki.com/index.php?title=DF2010:Sand&diff=prev&oldid=151343 example]) have added link-spam marked as minor edits. Link spam is the only edits these two users have done. -- [[User:Khym Chanur|Khym Chanur]] 20:44, 15 July 2011 (UTC)
:Did you not notice that their edits were undone and '''I banned both of them 9 hours ago'''? --[[User:Quietust|Quietust]] 21:15, 15 July 2011 (UTC)

There was a single spam edit by 124.6.181.171, which I've reverted. [[User:Bognor|Bognor]] 07:21, 22 July 2011 (UTC)
:^Same story for DScheer82. [[User:Bognor|Bognor]] 10:41, 2 November 2011 (UTC)

v0.34:Mist

2014-02-22T06:43:56Z

Vasiln: Undo revision 196828 by 174.51.109.169 (talk) advertising bot

{{av}} {{Quality|Fine}}
Mist is created by [[water]] [[Waterfall|falling]] from one [[Z-level]] to another, from ocean waves, and from items or creatures skipping across water. The mist is generated on levels below the top level (from which the water drops), but spreads out similar to miasma and therefore can appear even on the top level. Walking through mist generates a happy [[thought]] for a dwarf. 

Do <s>not</s> confuse mist with [[magma mist]].

==Generating Mist==
AncientEnemy [http://www.bay12games.com/forum/index.php?topic=34407.0] devised a convenient way to generate mist. This method relies on the fact that [[screw pump|screw pumps]] pump [[water]] faster than water spreads out.

Simply put, screw pumps are daisy chained (output to input) in a circle and then water is added to the system. Water is typically added by designating one of the inputs to the pump a [[Pond]] and having dwarves fill it up. Once water is dropped from the floor above it is immediately sucked up by the next pump. Since there is falling water, mist is generated. Ahh, lovely waterfalls!

Below is an example of a simple mist generator. The Z=0 level can be anything, a booze stockpile, barracks or even your [[Dwarven_atom_smasher|atom smasher]].

Pump Floor (z=1)
▒▒▒▒▒▒
▒.÷÷.▒
▒÷ ÷▒ The water can go clockwise or counter clockwise.
▒÷ ÷▒ Make sure your pumps are correctly aligned.
▒.÷÷.▒
▒▒▒▒▒▒
Some important considerations:[[Image:newmist.jpg|thumb|AncientEnemy's original simple mist generator.]]

*Evaporation is nonexistent as long as the pumps are working and the water is moving even above ground.{{Verify}}
*Job cancellation spam is possible if the water is filled to greater than 4/7 and a dwarf walks where the water falls. Even then, this can be prevented by blocking access to these tiles without blocking the water, such as by placing a [[statue]] underneath or greatly reduced by setting them as [[traffic#Setting Traffic Areas|restricted traffic]] areas.
*Mud will form where ever the water falls. Subterranean [[tree]]s can sprout up and clog the system. Solutions to this problem include: [[statue]]s, [[road|paved roads]], constructed floors or [[fortification]]s, or to simply channel out the space once the mist generator is running.
*The z=-1 layer can also be identical to the z=0 level. Mist will also be generated there. Because the water never touches the floor there, you don't have to worry about muddy tiles.
*This system is generally only capable of maintaining a single 7/7 square of water, due to the way water descends z-levels. Any additional water put into the system will quickly overflow into the pump chamber (z=1).
*Automated mist generators may significantly lower your [[Frames per second|FPS]], particularly if multiple generators are used.{{Verify}} This might be remedied by triggering via a [[repeater]] with a long delay or by one or more [[pressure plate]]s (perhaps set to activate by a passing dwarf).{{Verify}}
A movie [http://mkv25.net/dfma/movie-1292-ubermistgenerator] best illustrates the operation.
 
 
 
{{Category|Thoughts}}
{{Category|World}}
{{Category|Physics}}

User:Vasiln/minecarts

2014-02-22T05:54:30Z

Vasiln:

==Impulse Ramps==
*'''Do you need to connect the track on the higher z-level, or can all designations be done on the lower?'''

No designations are needed higher up.
*'''Can you cover the ramp up with a hatch? Bridge? Flooring?'''

Impulse ramp continues to work when covered with hatch cover, floor, or bridge.
*'''Do you even need empty space one z level up?'''

No. Cover it all up, it still works.
*'''Will pushing onto an impulse ramp give it impulse?'''

Yes.
*'''How far will a single ramp push a minecart?'''

Far. At least 30 tiles. At least 79 tiles.
*'''How many impulse ramps does it take to reach derailing speed?'''
Having two impulse ramps in three tiles will do it. '''Correction: that's what older testing told me, but I needed 3 ramps in a row later.'''

More than one.
*'''Does an obstructed minecart sitting on an impulse ramp maintain impulse?'''

A little bit. To clarify the situation: obstruct the exit from impulse ramp tile with a door; send the minecart around; wait a sec; open the door. What happens? Minecart moves exactly one tile.
*'''Can you build furniture on top of an impulse ramp?'''

Nope-- counts as blocked. Nevermind. That's only for doors (and similar). Floor based constructions are allowed-- bridges, hatches, floor grates. That will take some testing...
*'''What happens when you rebound into a hatch cover? Can you get enough velocity to reverse course?'''

Yeah, it rebounds. Hard to predict how far. Seems to accelerate, but then ended in middle of course.
*'''Is there a way to build two impulse ramps directly adjacent?'''

Not that I can see. Might be some weird things you can do with constructions, but otherwise, ends up making t-junctions. '''Correction: fairly easy, either with constructions, or smoothing.'''
*'''Can you get impulse by dropping (via hatch) onto a ramp?'''

Yeah, works fine.
*'''How many impulse ramps do I need to climb one z-level?'''

Two does the trick, one isn't enough.
*'''Can you build a raising drawbridge on top of an impulse ramp and in front of an impulse ramp to automate circuit running and stopping?'''

No. Drawbridge cannot be built such that raised, it blocks the impulse ramp.

===Things built on top of an impulse ramp===
*Retracting bridge, open: impulse ramp works as normal
*Retracting bridge, closed: appears to work just as if bridge wasn't there
*Hatch cover, closed: just as if hatch cover wasn't there
*Floor bars, closed: ditto
*Floor grate, closed: ditto
*Raising bridge, closed (off), based on adjacent tile: keep in mind "closed" here means flat rather than raised. Ditto anyways.

Oh well, that's the way it goes. '''Correction: my design wasn't actually testing this. However, re-testing suggests the same.'''

==Intentional derailment==
*Derail onto track running perpendicular to velocity: doesn't appear to slow cart
*Retracting bridge over corner: derails cart when closed, not when open
*Raising bridge over corner: ditto
*Hatch over corner: does NOT derail carts in either state, suckoid
*Diagonal velocity, basically a guarantee of derail whenever possible?

===Bridge over tracked ramp===
Deserves its own section. Works the same as without ramp-- that is, bridge at corner derails cart. Impulse still granted by ramp in open case, apparently not in closed case. (Compare to impulse ramp NOT at corner, which appears to give impulse regardless of status? But that was flawed testing, don't be so sure.) Note that to do it with a raising bridge, the raising bridge has to be based in the direction of derail-- but doesn't have to be a 2x1 bridge, base could lie 10 tiles from corner. Testing was done with constructed ramps, which lay on top of track, in case we have trouble recreating....

v0.34 Talk:Minecart logic

2014-02-22T01:45:47Z

Vasiln:

v0.34:Minecart logic

2014-02-21T20:53:15Z

Vasiln: Removed many examples, added diagrams and key; WIP

v0.34 Talk:Minecart logic

2014-02-21T19:37:55Z

Vasiln:

Dwarf Fortress Wiki:Sandbox

2014-02-21T19:37:09Z

Vasiln:

{{sandbox}}

{{#strcount:Welcome to this Sandbox page, which allows you to carry out experiments. To edit, make your changes and click the Save page button when finished. Content will not stay permanently; this page may be cleaned and/or overwritten by other testing users.|t}}
{{#stricount:Welcome to this Sandbox page, which allows you to carry out experiments. To edit, make your changes and click the Save page button when finished. Content will not stay permanently; this page may be cleaned and/or overwritten by other testing users.|t}}
Hello World!!!
Beware it's deadly dust!

{{diagram|spaces=yes|\
O O O
╥; ╤[#0F0]☼ ╤[#0F0]☼
║ ║ [#FF0]■
║ [#FF0]^ [#FF0]^
╨; ╧[#0FF]☼ [#FF0]■[#0FF]☼
O O O
track furniture minecart
}}

Dwarf Fortress Wiki:Sandbox

2014-02-21T19:34:17Z

Vasiln:

{{sandbox}}

{{#strcount:Welcome to this Sandbox page, which allows you to carry out experiments. To edit, make your changes and click the Save page button when finished. Content will not stay permanently; this page may be cleaned and/or overwritten by other testing users.|t}}
{{#stricount:Welcome to this Sandbox page, which allows you to carry out experiments. To edit, make your changes and click the Save page button when finished. Content will not stay permanently; this page may be cleaned and/or overwritten by other testing users.|t}}
Hello World!!!
Beware it's deadly dust!

{{diagram|spaces=yes|\
O O O
╥; ╤☼ ╤☼
║ ║ ■
║ ^ ^
╨; ╧☼ ■☼
O O O
track furniture minecart
}}

Dwarf Fortress Wiki:Sandbox

2014-02-21T19:33:47Z

Vasiln:

{{sandbox}}

{{#strcount:Welcome to this Sandbox page, which allows you to carry out experiments. To edit, make your changes and click the Save page button when finished. Content will not stay permanently; this page may be cleaned and/or overwritten by other testing users.|t}}
{{#stricount:Welcome to this Sandbox page, which allows you to carry out experiments. To edit, make your changes and click the Save page button when finished. Content will not stay permanently; this page may be cleaned and/or overwritten by other testing users.|t}}
Hello World!!!
Beware it's deadly dust!

{{diagram|spaces=yes|\
O O O
╥; ╤☼ ╤☼
║ ║ ■
║ ^ ^
╨; ╧☼ ■☼
O O O
track furniture minecart
}}

User:Vasiln/minecarts

2014-02-20T23:47:45Z

Vasiln:

v0.34 Talk:Minecart logic

2014-02-20T04:50:26Z

Vasiln:

User:Vasiln/minecarts

2014-02-20T01:45:02Z

Vasiln: Created page with "==Impulse Ramps== *'''Do you need to connect the track on the higher z-level, or can all designations be done on the lower?''' No designations are needed higher up. *'''Can y..."

User:Vasiln

2014-02-19T23:52:11Z

Vasiln:

v0.34:Mechanical logic

2014-02-18T04:47:03Z

Vasiln: load-based unfairly maligned; minecart based PTS renders hydromechanical PTS obsolete, example given

{{Quality|Superior|20:47, 30 April 2013 (UTC)}}
{{Computing}}

{{av}}

Mechanical logic is one discipline of [[computing]] using mechanical [[power]] to perform logical operations. In this case powered or unpowered [[machine component|machine components]] represent the binary information.

The principles of mechanical logic are simple. [[Gear assembly|Gear assemblies]] linked to [[lever]]s or [[pressure plate]]s will be toggled between disengaged and engaged when they receive an on/off signal. In this manner, you can conditionally attach power supply from [[windmill]]s or [[water wheel]]s to specially arranged gears to build logic gates.

== Mechanical logic compared with other logic disciplines ==
* Mechanical logic is very fast. Gears don't have a reaction delay like many components used by [[fluid logic]]. If a gear is toggled the flow of power will change immediately, there will be no added delay introduced by the movement of creatures, fluids or minecarts.
* Mechanical logic is very flexible. Gears can toggle, so inverting signals is easy and you don't have to deal with different machine components.
* Mechanical logic is very reconfigurable. You don't have to deal with [[creature|creatures]] or fluid before changing anything.

* Mechanical logic needs a substantial amount of wood to create and transmit power.
* Mechanical logic still needs converters to trigger something else than machine components, either by applying [[minecart logic]] or by using [[water|fluid]].
* Mechanical logic needs a substantial amount of mechanisms, particularly if you stick to [[mechanical logic#Load based|load based mechanical logic]].

== General concepts ==
There are two general concepts. The older and less popular one is the so called load-based mechanical logic. The other one is the so called toggle-based mechanical logic. Note that the two can be integrated, however.

=== Load based ===
Load based mechanical logic uses logic gates with a defined amount of power. They have an additional amount of load in terms of mechanism or other machine components, consuming all of the power if connected. The gates are designed in a way that the load is disconnected while the output is true, and connected while the output is false. Every circuit has to have its own power supply. Compact complex circuits are very difficult to design, because power and load need to be controlled for each circuit, and each gate in a circuit needs to be connected to others it interacts with. However, the advantage is that load-based mechanical logic computes instantly.

=== Toggle based ===
Toggle based mechanical logic works more like [[fluid logic]], not controlling the flow of fluid but the flow of power. It uses the fact that gears don't have a defined state when receiving an on or an off signal, but toggle between connected and disengaged, independent of the type of signal. It normally uses a central power supply. It is quite easy to create very complex gates with multiple output signals such as, for example, a binary to decimal converter. The cost of this ease of use and design, however, is that toggle based circuits need to be converted not just for output, but sometimes also for further processing.

=== Example ===
The first example shows a load based XOR gate. It takes input signals from two different triggers. Its output gear (O) is powered when exactly one of the two input triggers is on and the other one is off. This is done as follows: The power will be connected to the gear with the P (from the bottom of the diagram or another z-level). One input is linked to gear 1 the other to gear 2. This way power will flow from P to O if either one of the input signals is off. The power input is linked directly to the load L which must be calibrated precisely so that the power provided can move the output and load and ''one'' of the input-toggled gears, but not ''both''. You can build this on top of a [[Mechanical logic#Power to signal converter|power to signal converter]] as shown on this page. As you can see, this gate is complicated to construct. You will need four gears and four more to connect the input in addition to all the components needed for the converter and the load, and your load assembly will need to be precisely calibrated and can only be used for this circuit. When using a common load (shared with other circuits), the gate would have to be linked to it through two signal-driven gears put in line. This would increase the parts count by two installed and four link gears.
<div style="width:1px; white-space:nowrap;">
'''load based XOR'''
{| cellpadding="0" cellspacing="0" style="border-spacing:0; border-style:solid; border-width:thin; border-color:#000000;"
|
{| cellpadding="0" cellspacing="0" style="border-spacing:0; padding:0; margin:0; vertical-align:middle;"
|-
|{{RTL|#FFF}}
|{{RTL|#FFF}}
|{{RTL|#FFF}}
|{{RTL|#FFF}}
|{{RTL|#FFF}}
|{{RTL|#FFF}}
|-
|{{RTL|#FFF}}
|{{RTL|#FFF}}
|{{RTL|#444|*|#DDD||||1|#F4F|right}}
|{{RTL|#222|*|#BBB||||O|#FF4|right}}
|{{RTL|#FFF}}
|{{RTL|#FFF}}
|-
|{{RTL|#FFF}}
|{{RTL|#FFF| |#FFF|L|#F44|right}}
|{{RTL|#444|*|#DDD||||P|#4F4|right}}
|{{RTL|#444|*|#DDD||||2|#D4D|right}}
|{{RTL|#FFF}}
|{{RTL|#FFF}}
|}
|}
</div>
 A toggle based XOR gate looks much simpler:
<div style="width:1px; white-space:nowrap;">
'''toggle based XOR'''
{| cellpadding="0" cellspacing="0" style="border-spacing:0; border-style:solid; border-width:thin; border-color:#000000;"
|
{| cellpadding="0" cellspacing="0" style="border-spacing:0; padding:0; margin:0; vertical-align:middle;"
|-
|{{RTL|#FFF}}
|{{RTL|#FFF}}
|{{RTL|#FFF}}
|{{RTL|#FFF}}
|{{RTL|#FFF}}
|{{RTL|#FFF}}
|-
|{{RTL|#FFF}}
|{{RTL|#FFF}}
|{{RTL|#FFF}}
|{{RTL|#222|*|#BBB}}
|{{RTL|#FFF}}
|{{RTL|#FFF}}
|-
|{{RTL|#FFF}}
|{{RTL|#FFF}}
|{{RTL|#FFF}}
|{{RTL|#FFF}}
|{{RTL|#FFF}}
|{{RTL|#FFF}}
|}
|}
</div>
In stark contrast to the load-based XOR, it consists of a single gear. While it requires a power source and an output, it can accept power from an axle and serve as output gear by itself. This is how it works: Connect it to your source of power, and link it to one of your input triggers. Build a temporary lever anywhere and connect it, too. Pull the lever once. You can deconstruct the temporary lever now. Now the gear is disengaged, and you link the second input trigger to it. Since gears toggle, every time your trigger changes state and sends a signal the gear will change state. Initially both triggers are off, and the gear is disengaged. When one trigger changes state, it will activate the gear. Independent of which trigger changes next, both will have the same state afterwards, and the gear will be disengaged again. So the gear will transport power when both input triggers are at different state: XOR. You can build this on top of a [[Mechanical logic#Power to signal converter|power to signal converter]] as shown on this page. As you can see, you won't need many mechanisms to build this gate. 1 for the gear, 4 to connect to the input and 1 will be lost after disconnecting the temporary lever (that needs 3 temporarily). And of course you will need all the components for the converter, but no load. 

'''toggle based XNOR'''
* Use a single gear as for the XOR, but omit the temporary lever step.

'''toggle based NOR'''
* Multiple gears in series, with one (and only one) input connected to each gear. Any single ON(signal) input will produce an OFF(power) output.
* Can be converted to OR by adding an [[inverter]] to the output
* No temporary levers, so it uses fewer mechanisms.

'''toggle based AND'''
* Same as the NOR except use temporary levers to pre-toggle each input gear. For large logic arrays it is probably best to convert your Boolean equations to NOR logic, as that is the quickest simplest and least expensive (in mechanisms) to implement. With the added benefit that all mechanisms can be recovered from gears.

'''toggle based NAND'''
* A 3x1 gear assembly for each input. Input goes to the center (signal) gear. Power goes to either one of the other gears (the power gear), output is the other outer gear (output gear). Can be expanded indefinitely by adding additional 3x1 arrays in parallel (i.e. 3x2 for a 2 input, 3x5 for 5 input). The theory is that power is transmitted across all of the power gears (which are all connected to each other in parallel. Any single signal gear which has an OFF state (gear engaged) will allow power through to the output gears. It requires every input gear to be disengaged (ON signal) in order to produce an OFF (unpowered) output.

'''toggle based OR'''
* Same as the NAND except pre-toggle each signal gear.

== Power to signal converter ==
When you are dealing with mechanical logic, you'll finally want or have to trigger something else than machine components like doors or bridges (or, with toggle-based mechanical logic, another gear assembly). Currently, there exists no trigger in dwarf fortress that reacts on the working state of machine components, that is, the presence or absence of power. The traditional solution to this was to use a hydromechanical power-to-signal converter, remarkably similar to hydromechanical [[Memory_(computing)|memory]].
<div style="width:1px; white-space:nowrap;">
'''Z 0'''
{| cellpadding="0" cellspacing="0" style="border-spacing:0; border-style:solid; border-width:thin; border-color:#000000;"
|
{| cellpadding="0" cellspacing="0" style="border-spacing:0; padding:0; margin:0; vertical-align:middle;"
|-
|{{RTL|#DDD}}
|{{RTL|#DDD}}
|{{RTL|#DDD}}
|{{RTL|#222}}
|{{RTL|#222}}
|{{RTL|#222}}
|-
|{{RTL|#DDD}}
|{{RTL|#222|·|#BBB}}
|{{RTL|#444|÷|#DDD}}
|{{RTL|#444|÷|#DDD|►|#00A|center|►|#00A|center}}
|{{RTL|#222|·|#BBB}}
|{{RTL|#222}}
|-
|{{RTL|#DDD}}
|{{RTL|#DDD}}
|{{RTL|#DDD}}
|{{RTL|#222}}
|{{RTL|#222}}
|{{RTL|#222}}
|}
|}
</div>
<div style="width:1px; white-space:nowrap;">
'''Z-1'''
{| cellpadding="0" cellspacing="0" style="border-spacing:0; border-style:solid; border-width:thin; border-color:#000000;"
|
{| cellpadding="0" cellspacing="0" style="border-spacing:0; padding:0; margin:0; vertical-align:middle;"
|-
|{{RTL|#222}}
|{{RTL|#222}}
|{{RTL|#222}}
|{{RTL|#222}}
|{{RTL|#222}}
|{{RTL|#222}}
|-
|{{RTL|#222}}
|{{RTL|#00A|^|#DDD||||7|#88F|left}}
|{{RTL|#DDD||||||7|#88F|left}}
|{{RTL|#DDD||||||7|#88F|left}}
|{{RTL|#DDD||||||7|#88F|left}}
|{{RTL|#222}}
|-
|{{RTL|#222}}
|{{RTL|#222}}
|{{RTL|#222}}
|{{RTL|#222}}
|{{RTL|#222}}
|{{RTL|#222}}
|-
|}
|}
</div>
 
When the pump is connected to power, it will suck water from the pressure plate and pump it to the right. The water level on the pressure plate will fall to 0. The plate can be constructed to react on 0…3 water. You can invert it to get an off signal instead setting it to 4…7. In both cases the ''off signal'' will have a delay of about 100 steps. This gate is fluid conserving.

However, the introduction of minecarts have created alternatives that are more compact and don't require water, largely rendering the hydromechanical PTS device obsolete. The following minecart-based PTS converter is fast, easy to build, and extraordinarily compact:

[[File:2x2pts.png]]

[http://www.bay12forums.com/smf/index.php?topic=114923.0 Bloodbeard's Minecart Dwarfputing Ideas thread] on the DF forums has other examples of minecart-based PTS.

==Load based Mechanical signal-input power-output gates==
* These gates can be used either by adding a power -> link signal converter (also known as a "rotation sensor"), or directly used to control pumps, such as in other logic gates (the unsourced fluid logic gates use these, for instance). The conventional "rotation sensor" consists of a pump powered by the gate's OUTPUT gear, pumping an infinite supply of water onto a water-sensing pressure plate with an infinite drain.
* There are certain things important to all the gates:
* Each gate has an OUTPUT gear, which will be placed next to a pump which the gate will control.
* In diagrams, the OUTPUT gear is below the 'O' gear, connected to it by gears or vertical axles. The P indicates where you should hook power up, and L indicates where load (gears or pumps that don't have a water source) should be connected, and ¦ and - are horizontal axles. The Is are gears linked to INPUTs (some gates have one input, but most have two).
* Gates which incorporate a NOT will have the power network branch off from the 'O' gear, and have a train of power-draining stuff connected to the input gears, whereas gates which do not incorporate a NOT will have the power connected to the input gears instead. The principle behind normal gates is that when the INPUTs are ON, power is connected. The principle behind the NOT gates is that power is always connected, but when the INPUTs are ON, a large enough power requirement is connected to send the power requirements above the power supply, shutting down the system.
* If your windmills produce no power, you'll have to come up with some way to use water wheels for power instead.
* You should build only enough windmills (or water wheels) to power the system, and should not connect the network for one gate to another gate's network, since the load would shut everything down or nothing at all.
* The gates' instructions will explain how much load and power you need to have at each P and L in the more complicated gates.

===Legend===
{| class="wikitable" border="1"
|-
! Symbol
! Meaning
|-
| {{diagram|[#ff0]O}}
| A gear which connects to your OUTPUT gear, which outputs power when the gate is producing an ON output.
|-
| {{diagram|[#aaf]I}}
| A gear connected to an INPUT. In most gates you will have two Is, with each one connected to a different input.
|-
| {{diagram|-}} and {{diagram|¦}}
| Horizontal axles
|-
| {{diagram|[#0f0]P}}
| Power goes here
|-
| {{diagram|[#aaf]i}}
| Two more gears, each connected to the two different inputs.
|-
| {{diagram|[#f00]L}}
| a chain of gears or pumps which serve to add load to the system, generally shutting it off when connected.
|-
| {{diagram|*}}
| A gear which isn't linked to any inputs or outputs and just serves to connect the power or whatever.
|}

===Mechanical identity gate ===
{{diagram|
[#ff0]O[#aaf]I--[#0f0]P}}

* This takes an linked input signal and converts it to power without changing it.
* Connected to the input gear, such that they will only be connected to the system if the input gear is receiving an ON signal, are gears with windmills on top of them. Build only enough windmills to power the devices that the gate's OUTPUT gear are connected to (and the gears/axles).
* When the INPUT is ON, the INPUT gear will be active, and the network will provide power to the OUTPUT. When the INPUT is OFF, it will not provide power to the OUTPUT.

===Mechanical NOT gate===
{{diagram|
[#ff0]O[#aaf]I[#f00]L
¦
¦
[#0f0]P}}

* When the INPUT is ON, the INPUT gear will be active, and the network should need more power than is available. The devices connected to OUTPUT should shut down. When INPUT is OFF, the devices should have power since the INPUT gear will be disconnected.

===Mechanical NAND gate===
{{diagram|
[#ff0]O[#aaf]I[#aaf]I[#f00]L
¦
¦
[#0f0]P}}

* This works just like the NOT gate, except that there are two inputs and both have to be active to shut down the system instead of one. Make sure you have enough power to run the system when one of the input gears is active.

===Mechanical AND gate===
{{diagram|
[#ff0]O[#aaf]I[#aaf]I[#0f0]P}}

* This works like the identity gate, except that there are two inputs and both have to be active for the system to get power.

===Mechanical OR gate===
{{diagram|
[#ff0]O[#aaf]I
[#aaf]I*[#0f0]P}}

* This works like the identity gate, except that there are two inputs, and if either is active, the system receives power. Note that the entire power network is connected to both inputs, such that if either input is active the entire power network is powering the system.

===Mechanical NOR gate===
{{diagram|
[#aaf]I*[#f00]L
[#ff0]O[#aaf]I
¦
¦
[#0f0]P}}

* This works like the NOT gate, except that there are two inputs, and if either is active, the gear train or pump stack signified by the 'L' will be connected to the system. You need to have enough load to push power requirements above the amount of power produced by the power supply, shutting the system down.

===Mechanical XOR gate===
{{diagram|
[#ff0]O[#aaf]I
[#aaf]I*-[#0f0]P
[#000].[#aaf]i
[#000].[#aaf]i
[#000].[#f00]L}}

* Except for the 'i's and 'L', this gate is identical to the OR gate. The additional components add the 'exclusive' part of the 'XOR' to the gate.
*The 'i's are additional gears connected to each of your inputs, and the L is additional load (large enough to stop the system, of course).

===Mechanical XNOR gate===
{{diagram|
[#000].[#000].[#aaf]I*[#f00]L
[#000].[#000].[#ff0]O[#aaf]I
[#000].[#000].¦
[#0f0]P[#aaf]-*
[#000].[#000].[#aaf]i
[#000].[#000].[#aaf]i
[#000].[#000].[#0f0]P}}

{| class="wikitable" border="1"
|-
! A
! B
! Drain
! Power
! Extra Power
! Result
|-
| 0
| 0
| No
| Yes
| No
| 1
|-
| 0
| 1
| Yes
| Yes
| No
| 0
|-
| 1
| 0
| Yes
| Yes
| No
| 0
|-
| 1
| 1
| Yes
| Yes
| Yes
| 1
|}

* The XNOR gate is an equality gate: The output is ON when both inputs are equal, and OFF when they are not equal.
* This gate may be '''even more complicated''' to build than the XOR gate!
* First, your 'i's are again gears connected to your two inputs. The extra P below them is additional power source, ideally only one windmill.
* Here's where it gets complicated. The load has to be sufficient to shut down the system when additional power supply is disconnected. However, when BOTH inputs are on, there needs to be enough power from additional P to bring the system back online.
* Thus our gate does what it is supposed to: Produce enough power to have the OUTPUT gear be ON when both A and B are either 0 or 1, but not when they are not equal.

{{Category|Computing}}
{{Category|Logic}}

v0.34:Memory (computing)

2014-02-16T22:01:39Z

Vasiln: Section on flip flop memory, minecart memory example, power-to-signal vs memory; electronics peeps, feel welcome to correct terminology lol i don't even

{{Quality|Exceptional|21:39, 4 April 2012 (UTC)}}
{{Computing}}
{{av}}

Memory is used for storing values and states in dwarven [[computing]]. Typically, binary memory is used, but this isn't strictly necessary. There are multiple ways to set up a memory cell, depending on whether one is using [[mechanical logic|mechanical]], [[fluid logic|fluid]], [[creature logic]], or [[minecart logic]]. With binary memory, each cell has two possible states, generally referred to as 0 and 1, or true and false.

===Flip-flops versus latches===
The most basic characteristic of memory in Dwarf Fortress is that it acts as a signal splitter: given a series of on-off signal cycles, it outputs a series of alternating on or off signals. Memory that does this, and only this, acts like a flip-flop: every time you trigger the memory, it changes state. Such memory is perfect for devices such as [[Adder (Computing)|counters]]. However, it's common to desire the ability to write state directly to your memory, rather than toggling it-- that is, to write either '''true''' or '''false''' to memory directly, without knowing the current state of the memory. This can be described with a chart where the memory value feeds back into itself:
{| class="wikitable" border=1
|-
! input
! latch state
! output
! new latch state
|-
| 0
| 0
| none
| 0
|-
| 0
| 1
| off
| 0
|-
| 1
| 0
| on
| 1
|-
| 1
| 1
| none
| 1
|} 
===Performance===
Memory systems in dwarf fortress, thankfully, are very good at maintaining their value (in the absence of any [[troll]]s), but they are still plagued by problems with latency and long refractory periods. Latency refers to the length of time before which a change in value will register, and the refractory period refers to the period after writing to memory during which one cannot reliably write to it a second time. Because of the delays involved with [[pressure plate]]s, latency and refractory period for a given memory cell often depend on which state the memory is being changed to. For instance, the mechanical hybrid cell below has nearly no latency when being written as true, but around 100 ticks of latency when being written as false.

Some designs can trade simplicity or material needs for costs in performance.

==Fluid Logic==
The simplest fluid logic latch relies on an infinite source and infinite drain, storing information in the form of the presence or absence of water in a particular location.

{{diagram|spaces=yes|
═════
[#0F0]~[#FF0]X[#F0F]^[#FF0]╬[#0FF]~
═════}}

In this design, water flows from an infinite source {{Raw Tile|~|#0F0|#000}} over an output [[pressure plate]] {{Raw Tile|^|#F0F|#000}} toward an infinite drain {{Raw Tile|~|#0FF|#000}}. Its flow is controlled by a [[floodgate]], {{Raw Tile|X|#FF0|#000}}, and a raising [[bridge]], {{Raw Tile|╬|#FF0|#000}}, both linked to the same input. When {{Raw Tile|X|#FF0|#000}} and {{Raw Tile|╬|#FF0|#000}} are open, water will cover {{Raw Tile|^|#F0F|#000}}; when they are closed, there will be no water. Thus, the input source toggles the state of the memory cell, and the state of the memory cell is reflected in the output of {{Raw Tile|^|#F0F|#000}}.

This is an example of flip-flop memory. The state of the memory can be toggled, but it's not possible to write one particular state (that is, for instance, true) to the memory without first examining the memory. This can be altered by replacing the bridge and floodgate with independently triggered doors. This design has relatively high latency, because of the flow rate of water, and a refractory period of 100 ticks, representing the delay associated with bridges and floodgates. Given careful enough design and sufficient water pressure, the latency of a write to true can approach 100, with the latency of a write to false around 120.

==Creature Logic==
{{diagram|spaces=yes|\
╔═╗
═══╝[#0F0]┼╚══
[#F00]p[#FF0]¢[#FF0]^[#FF0]¢[#00F]¢[#F0F][#00F]^[#00F]¢[#F00]p
══╗[#0FF]┼╔═══
╚═╝ }}

In this circuit, a creature placed between in the middle seeks its [[path|pathing]] goal {{Raw Tile|p|#F00|#000}} but is constrained by the [[hatch cover|hatch]]es {{Raw Tile|¢|#FF0|#000}} and {{Raw Tile|¢|#00F|#000}}, each linked to the pressure plate {{Raw Tile|^|#FFF|#000}} of the same color. When the door {{Raw Tile|+|#0F0|#000}} is opened, the creature can move to the left (false) {{Raw Tile|^|#FF0|#000}}, and when the door {{Raw Tile|+|#0FF|#000}} is opened, the creature can move to the right (true) {{Raw Tile|^|#F0F|#00F}}, thus outputting to anything linked to that pressure plate. This is an example of memory for which it is possible to write a particular state, rather than just toggling, which allows for simpler design for some applications. Note also that rather than writing on a single on or off signal, it depends on an on-off cycle.

This design has good latency for creature logic systems, resulting in on signals around 40 ticks after writes and off signals around 150 ticks after writes. It has a 110 tick refractory period, representing the time necessary for the hatch covers to close.

==Mechanical Logic==
A [[gear assembly]] can function all on its own as a memory cell, being either active or disengaged. However, some complicated applications suggest the use of hybrid mechanical-fluid memory.

{{diagram|spaces=yes|\
z+2
╔═[#0F0]☼╔═╗
║ [#0F0]%[#0A0]% ║
╚═╝╚═╝}}
{{diagram|spaces=yes|\
z+1
╔═[#FF0]☼╔═╗
║ [#AA0]%[#FF0]%[#F0F]^║
╚═╝╚═╝}}
{{diagram|spaces=yes|\
z+0
╔═╗
║[#00F]~║
╚═╝}}

In this design, two separately powered [[pump stack]]s, {{Raw Tile|%|#0F0|#000}}{{Raw Tile|%|#0A0|#000}} and {{Raw Tile|%|#AA0|#000}}{{Raw Tile|%|#FF0|#000}}, are placed over each other-- the lower one, pumping to the right, and the higher one pumping to the left. When the water {{Raw Tile|~|#00F|#000}} is lying in the rightmost (true) cell, it activates a pressure plate {{Raw Tile|^|#F0F|#000}}. To write true to the memory, one triggers the lower gear assembly {{Raw Tile|☼|#FF0|#000}}, activating the lower pump, and to write false, one activates the higher gear assembly {{Raw Tile|☼|#0F0|#000}} and pump stack. Like the creature logic memory above, this cell can be written as specifically true or false, and depends on an on-off cycle as input.

This design has very good latency (from almost nothing for a write as true to 100 ticks for a write as false) and no real refractory period-- it can be written to immediately following a previous write, although it does depend on the completion of the previous write signal (receiving the off component of the signal) before writing again.

===Memory versus Power-to-signal===
It can be tricky to differentiate memory from [[Mechanical_logic#Power_to_signal_converter|power to signal]] conversion. Through feedback, power-to-signal devices can often be changed into memory cells, and powered memory devices can be adapted into power-to-signal. Previous to the introduction of minecarts, the most common power-to-signal device bore strong resemblance to the memory cell described above. There is, however, a large difference between memory and power-to-signal. While memory designs receive on-off signal cycles and output discrete '''on''' or '''off''' signals in return, power-to-signal converters return exactly what they're given. That is, a signalling device that receives then loses power should return a full on-off signal cycle.

==Minecart Logic==
There are numerous ways for minecarts to hold information. Some memory designs use movement or the absence of movement; others use just the position of a minecart. Advanced designs could use the weight or direction of movement of a minecart. The following powered minecart design by Bloodbeard is the smallest memory circuit currently known to dwarvenkind:

[[File:3tdcbm.png]]

The diagram shows the minecart layer at the top, the roller/furniture layer in the middle, and finally the track layer at the bottom.
When the northern gear assembly is activated, powering the northern roller, a heavy minecart (copper, in this example) is pushed southwards. This pushes a lighter minecart (iron here) south, and triggers a pressure plate that is built to only signal on the weight of a copper minecart, and not on the weight of the lighter iron minecart.
With the activation of the southern gear assembly, the situation reverses. The iron minecart pushes on to the pressure plate, and an '''off''' signal is sent.

==Memory addressing==
In complicated designs, one may wish to use a memory cell abstractly-- to represent any number of different values. To use multiple such abstract cells, it's necessary to specify exactly which memory cell one wishes to read from or write to at any given moment.

This is simplest in mechanical logic. A grid of gear assemblies can represent rows and columns, and by disengaging control gears for all but the cell that lies at that particular row/column intersection, one can easily refer to a specific cell. Strict fluid logic can do something similar, by controlling the input of water to memory cells, although this involves long delays. With the creature logic design, one can use additional doors to restrict writes to any cells not referenced.

==Alternate design==
Because most memory is used for a specific application, there is no single best design. It is not uncommon to see functionality built into memory circuits-- a simple circuit that increments contains its own memory. Alternate designs are important when memory needs to be written to in various ways (toggle versus specific value) or when latency and refractory period are unimportant compared to resource requirements such as space.

{{Category|Computing}}

v0.34:Creature logic

2014-02-15T01:41:03Z

Vasiln: Updated in light of minecart logic, altered falling rates, couple of typos fixed

{{Quality|Exceptional|20:46, 30 April 2013 (UTC)}}
{{Computing}}
{{av}}

Creature logic is a form of dwarven [[computing]] that functions by taking advantage of creature's natural [[path]]-finding goals to trigger pressure plates. Creature logic is complete-- you can build memory, repeaters, or any sort of logical circuit.

==Creature logic vs other disciplines==
Pro:
* Creature logic requires no [[water|fluid]] or [[windmill|wind]]. In dry, windless environments, circuits are limited to creature logic or [[minecart logic]].
* Similarly, creature logic requires no infrastructure-- you can build your circuits anywhere, without worrying about bringing water or [[power]] from one end of your map to the other.
* All creature logic circuits can be designed with only [[stone]] and a pick-- although you're free to use [[wood]] or [[metal]] if you prefer!
* Creature logic doesn't need anything but creatures to send or receive signals. There's no need to translate signals as with with [[mechanical logic]].
* Creature logic can be very intuitive. Watching creatures physically travel through your logic pathways simplifies debugging.
* It's fun to watch the creatures run around!

Con:
* Reliable creature logic requires a ridiculous number of [[hatch]]es, [[door]]s, and [[mechanism]]s-- not to mention connections between pressure plates.
* Creature logic requires creatures-- sometimes, a great number of creatures. Sometimes, those creatures die or have babies. Sometimes, they interrupt your [[dwarf|dwarves]]. Sometimes, your dwarves fill them full of crossbow bolts.
* Creature logic is vulnerable (surprise) to the presence of unexpected creatures in the logic circuits. Because creature logic circuits require a path either to the map edge or to the [[Activity_zone#Meeting_Area|meeting hall]] (in most cases), this is a real possibility.
* Creature logic requires large amounts of space.

==Free range or one path==
There are two incompatible design philosophies associated with creature logic-- mostly, the creatures you use will determine which is appropriate.

Free range creature logic generally gives a path to creatures when certain criteria are met, and otherwise, lets them wander (in a constrained space). This simplifies design and permits constant evaluation of criteria, but any creature that paces in captivity can easily foul up your circuits-- for instance, a pacing creature may prevent a door from closing, causing an AND to evaluate as true even though both operands were never true at the same time. Additionally, it gives no clear indication that an evaluation has been completed-- if you want to evaluate your AND statement, you only ever know that it's been evaluated as true, never as false.

One path design constrains creatures to a single tile when they have no path available. Whenever the creature is permitted movement for evaluation of operands, the creature is guaranteed one and only one path. This requires explicit designation of 'else' paths, and requires that operands be evaluated at specific times rather than undergoing constant evaluation, but guarantees complete reliability, and allows the circuit to return both 'true' and 'false' evaluations, meaning that you can know for sure that a signal has been evaluated, rather than guessing if the creature has had sufficient time to path or not path.

==Animal logic==
[[Animal logic]] relies on a special case of free range creature logic that is specific to animals that are unable to open doors, by pathing them through tightly closed doors. Animal logic can be very space efficient and easy to build in comparison to most kinds of creature logic, but is somewhat unreliable.

==Gates==
Creature logic relies on the ability or inability of a creature to path through a specific area. "One path" design requires explicit 'else' arms. Because of that, the following logic gates are shown in complementary pairs to guarantee a path to the creature.

All of these gates can be easily altered to take more than two operands.

====Key====
In all of the following diagrams, the creature is assumed to start at {{Raw Tile|s|#0FF|#000}} (if given). {{Raw Tile|p|#F00|#000}} means that the square contains a path to the creature's pathing goal. Doors {{Raw Tile|┼|#FF0|#000}} and hatches {{Raw Tile|¢|#FF0|#000}} are displayed in the same color as the [[pressure plate]] {{Raw Tile|^|#FF0|#000}} that links to them. If no pressure plate exists for a color, furniture of that color is opened or closed from outside of the circuit pictured; if a hatch and a door are the same color, that means they receive signals from the same source. Output pressure plates are displayed in magenta {{Raw Tile|^|#F0F|#000}}, as is any furniture in the circuit that is linked with the output plate. In the rare case that part of a circuit is linked with multiple elements, it will be displayed with foreground and background colors and explained in text-- for instance, {{Raw Tile|^|#F0F|#0FF}} is linked both to cyan furniture and output.

===Identity with NOT gate===
{{diagram|spaces=yes|\
╔══╗
═╝[#0F0]┼[#F0F]^╚═
[#0FF]s+OO+[#F00]p
═╗[#0F0]¢+╔═
╚══╝ }}

This function takes a single operand. If the operand is true, the creature travels through the upper path (identity); otherwise, the creature takes the lower path (NOT). The pressure plate signals when the operand is true. This gate is the basis of all to follow.

Identity is also a simple delay. When the path receives a signal, it propagates it after a short period. That period depends on the speed of the creature moving through the gate.

===AND gate with NAND gate===
{{diagram|spaces=yes|\
╔═══╗
═╝[#0F0]┼[#FF0]┼[#F0F]^╚═
[#0FF]s+O═O+[#F00]p
═╗+[#0F0]¢+╔═
╚╗[#FF0]¢╔╝
╚═╝ }}

The doors at the top are both open if both operands are true (AND); the hatches at the bottom permit path if either operand is false (NAND). The pressure plate will signal when both operands are true.

===NOR gate with OR gate===
{{diagram|spaces=yes|\
╔═══╗
═╝[#0F0]¢[#FF0]¢[#F0F]^╚═
[#0FF]s+O═O+[#F00]p
═╗+[#0F0]┼+╔═
╚╗[#FF0]┼╔╝
╚═╝ }}

The hatches at the top permit path only if neither operand is true (NOR); the doors at the bottom permit path if either operand is true (OR). The pressure plate will signal when neither operand is true.

===XOR gate with expanded XNOR gate===
{{diagram|spaces=yes|\
╔═╦═╗
╔╝[#0F0]┼O[#0F0]¢╚╗
═╝+[#FF0]┼+[#FF0]¢[#F0F]^╚═
[#0FF]s+O═══O+[#F00]p
═╗+[#0F0]┼[#FF0]┼++╔═
║+OO+╔╝
╚╗[#0F0]¢[#FF0]¢╔╝
╚══╝ }}

As XOR is the intersection of OR and NAND, it is simply an OR followed by a NAND. The XNOR, as the union of AND and NOR, requires two arms. Each operand is linked to one door and one hatch in the XOR path, and to one door and one hatch in the XNOR path. The pressure plate will signal when either operand is true but not both are true. When modifying the XOR to take more than two operands, be careful to leave space between the doors and hatches as shown; this space is unnecessary for evaluation of two operands. Similarly, the expanded XNOR is appropriate when dealing with more than two operands, but a condensed version for taking only two operands exists.

===Multiple use===
The gates above are single use gates; the creatures will escape after pathing through each gate. Circuits which return the creature to the beginning of the path are possible via altering the path in-route.
{{diagram|spaces=yes|\
║[#F00]p║
══╝[#0F0]¢║
[#0FF]s[#0F0]¢[#0F0]^O╣
══╗[#0F0]┼║
║[#F00]p║}}

This is one such device for re-routing creatures mid-path. Upon stepping on the pressure plate, the creature opens two hatches, thus blocking retrograde motion as well as access to its pathing goal, and opens a door, giving access to a new pathing goal. This new pathing goal can lead back to the original position of the creature. This principle is demonstrated in the designs to follow. Because the creature is constrained on the pressure plate, the door can be opened by outside mechanisms rather than being linked to the pressure plate, permitting controlled movement of a creature through one or more arms of a circuit.

==Creature memory==
{{diagram|spaces=yes|\
╔═╗
═══╝[#0F0]┼╚══
[#F00]p[#FF0]¢[#FF0]^[#FF0]¢[#00F]¢[#F0F][#00F]^[#00F]¢[#F00]p
══╗[#0FF]┼╔═══
╚═╝ }}

This is a low latency version (not the simplest version, not the most full-featured) of creature-based memory. Each pressure plate is linked to each adjacent hatch. Memory is set by sending an open (followed closely by a close) to either door.

Note that in this diagram, both ends need to lead to the pathing goal. The creature can enter by either side, but will be constrained to either pressure plate during normal operation.

==Clock generation, repeaters, and delay==
A high resolution borg-logic clock or delay can be designed around the rate with which creatures fall. A simpler, low resolution clock can be designed based around the military [[scheduling]] menu.

The memory design above, slightly modified, can make a decent (not perfectly regular) repeater.
{{diagram|spaces=yes|\
╔═╗
═══╝[#FF0]¢╚══
[#F00]p[#FF0]¢[#FF0]^[#FF0]¢[#00F]¢[#F0F][#00F]^[#00F]¢[#F00]p
══╗[#00F]¢╔═══
╚═╝ }}

Here, each pressure plate is linked to the two orthogonally adjacent hatches. The southern hatch is linked to the eastern pressure plate, while the northern hatch is linked to western pressure plate. This repeater tends to fire about every 250 ticks, with open and close signals offset by about 125 ticks, when built as shown. It's very effective at rapidly triggering any device with a refractory period of 100. Similar, non-repeating systems can be used to institute delay.

Linking both pressure plates to output doubles its rate, turning it into very effective spike repeater. The period can be increased by introducing floor space into the center of the design.

==Edge Detection==
{{diagram|spaces=yes|\
║[#F00]p║ ║[#F00]p║
║[#0F0]¢╚═══╝[#FF0]¢║
╠O[#0F0]^[#0FF]┼[#F0F]^[#FF0]¢[#FF0]^O╣
║[#0F0]¢O═══O[#0FF]¢║
╚╗++[#F0F]^++╔╝
╚═════╝ }}

North of the circuit is the pathing goal. The eastern and western pressure plates are linked to adjacent hatches. Input is linked to the hatch southeast of the eastern pressure plate and to the door. The central and southern pressure plates are linked to output. This circuit generates both an open and a close every time it is sent an open or a close signal from input -- that is, it generates two properly-ordered signals for every properly-ordered signal it is sent, allowing for ''edge triggered'' logic. Either output pressure plate can be removed to send an open and a close only upon receiving one kind of signal or the other kind of signal. Output can linked to the same device or to two different devices.

Note that the memory design forms a sort of inverse of this circuit, in that a single open-close cycle is translated into a single on or off signal.

==Alternative design==
Multiple choices of furniture are available for the doors or hatches in the above diagrams. Various reasons exist for substitution.

====Doorless design====
Of all alternative designs, doorless design is the most practical. All doors are replaced with hatches over [[stair]]s or [[ramp]]s, and the path continues one z-level down or up. This makes it more difficult to visualize the circuit, and some very efficient designs may require more significant changes, but every circuit possible can be created without doors. Use of hatches instead of doors protects against the effects of doors being blocked open by unexpected creatures or objects-- the original bug, after all, took the form of [[vermin]] remains. Retracting [[bridge]]s can be used the same way, but lead to problematic delays.

====Hatchless design====
Hatchless design is much more difficult and of very limited use. Signal inversion can make a door act like a hatch; a raising bridge acts like a hatch. Both of these institute delays in processing that require large expansion of logic circuits and limit the effectiveness of memory, but they may be necessary when using submerged logic or flyers-- bragging rights for a logic system submerged in [[magma]] that processes via [[fire imp]]s may be worth the headache.

====Bridge design====
Bridge design uses bridges instead of both doors and hatches. Doors are replaced with retracting bridges over ramps or staircases; hatches are replaced with raising bridges, or with retracting bridges over channels. Bridge design causes frustrating delays, but it is the only way to use [[building destroyer]]s in a logic circuit. The irony of making your [[minotaur]] run an impossible labyrinth may be worth the design headache. As an added bonus, bridges are nearly unobstructable-- offensive vermin remains in your logic circuits will be smashed from this plane.

==Creature choice==
Multiple choices exist for creatures to run logic circuits. Each has its own advantages and disadvantages.

====Domestic animals====
[[Domestic animal]]s are valid choices for creature logic, but come with a host of disadvantages. Many females are capable of giving birth inside of your logic gates; their [[child|children]] can block the closing of doors or set off pressure plates. [[pasture|Grazers]], of course, will starve inside most logic circuits, although some special designs may be capable of supporting a grazer. Some domestics are too small to set off pressure plates; some are capable of flight, requiring hatchless design. All unmodded domestic animals will die of old age, requiring periodic replacement. Most domestic animals have relatively short lifespans. Logic involving domestic animals must be built with pressure plates that can be triggered by citizens, and building these circuits may turn into a nightmare of job cancellations and stranded, starving dwarves. Domestic animals have one huge advantage, however: the location of their pathing goal can be altered with direct, unmediated action of the player, by placement of a meeting zone.

====Invaders====
[[Invader]]s are readily available on most maps, rarely or never give birth, and require no sustenance. Pressure plates don't need to be built triggerable by citizens. [[elf|Elves]] and [[goblin]]s will never die of old age. However, invaders cause their own problems. Invaders can cause job cancellations, and in some circuits may escape, wreaking havoc deep in your fortress. Dwarves armed with bolts and crossbows will take potshots at your computers periodically. Finally, invader-based logic must have a path to the map edge for predictable pathing. If your logic circuit is inside of your fortress, walling off, even through something as simple as raising a bridge at your entrance, will lead to unpredictable pathing.

====Dwarves====
Dwarves themselves can be used to run logic circuits, and are perhaps the most interesting choice; logic designs involving dwarves are generally referred to as borg logic. While longer-lived than most domestics, dwarves [[food|starve]] and [[alcohol|dehydrate]] easily, requiring frequent, careful maintenance. Idle dwarves path unpredictably, and dwarves are vulnerable to [[sleep|drowsiness]], leading to very high latency. Married female dwarves are fecund. At the same time, dwarves are excellent choices for logic circuits because of their varied pathing goals that can be altered through direct interaction by the player. Dwarves can trigger events both through the use of pressure plates and through the use of [[lever]]s, while their pathing goals can be controlled by many means-- most easily and predictably, by military scheduling. In fact, one can see the entire game of Dwarf Fortress as one big logic circuit with dwarves as the driving creature.

The addition of [[vampire]]s to the game opens up many possibilities for borg logic-- the simplest implementation being placing one in a room full of levers.

===Undead===
[[Undead]] are an intriguing choice for creature logic choices. The absence of attribute rust opens up the possibility for a more consistent repeater. They can be used in fully submerged circuits-- even in magma-submerged systems. In some [[biome]]s, they are self-repairing. However, undead path like wildlife, which can make it difficult to set up a circuit for them. Without a clear target, they may not behave predictably. One way to work around this is to build a visible target to which the undead path, by walling the circuit with [[channel]]s instead of walls, and placing a captured invader in clear line-of-sight of the undead logician.

===Other choices===
There are a few things to stay away from, but in general, any sufficiently understood creature can be used for creature logic. Building destroyers are problematic, but full-bridge design is possible. Likewise, flyers and swimmers cause difficulty, but nothing that can't be worked around. Creatures with trapavoid are nearly useless, though [[gremlin]]s might be able to output via levers; stun-able creatures like [[kobold]]s can trigger pressure plates when dropped/stunned; and non-web-immune creatures trigger pressure plates that have been [[web]]bed. Creatures with a [[size]] less than 10000 are too small to set off pressure plates, thus requiring additional "hardware" (such as a tame creature that "flees" or "charges" over a pressure plate). The essence of creature logic, however, is predictable pathing. This may or may not exclude the use of certain types of wildlife.

{{Category|Computing}}
{{Category|Logic}}

v0.34:Computing

2014-02-14T23:06:08Z

Vasiln: oops

{{Quality|Exceptional}}
{{Computing}}
{{av}}

Computing in Dwarf Fortress is the practice of setting up complex constructions to perform logical operations and calculations; ideally, to control some functionality of your fortress. Even if it isn't a young concept anymore, there is still much room for improvement and development. One reason is that there are many ways to solve one problem. Innovation and invention are encouraged.
=== Binary information ===
Binary information can have one of two possible states: true or false, respectively 1 or 0. In dwarf fortress they can be represented by different entities:
* on/off state or signal of a trigger ([[pressure plate]] or [[lever]])
* power or connection state of a [[machine component]]
* open or closed state of a [[door]] or similar buildings
* [[pressure plate|low/high]] or [[flow|flowing/standing]] [[water|fluid]]
* present [[creature]]s and [[dwarf|borgs]]

Electronic devices and computers base on this elementary form of information, and if you want to go into computing, you’ll have to familiarize yourself with it. [http://en.wikipedia.org/wiki/Propositional_calculus propositional calculus]
=== Input/Output ===
Input can be any device which can be linked to another device with mechanisms, such as [[lever|levers]] or [[pressure plate|pressure plates]]. Pressure plates can measure water, magma, or creature weight, and can be set to react to your own dwarves if measuring creature weight. If measuring water or magma you specify the minimum and maximum levels at which it should output 'on', and at all other levels it will output an 'off' signal. Regardless of the actual amount of water, magma, or creature weight on your pressure plate, the plate can only output an 'on' or 'off' signal (1 or 0) to whatever devices it is linked to. So everything you build will have a binary base.

====Input elements====
* manual: [[lever]] -> binary on/off signal
* triggered: [[pressure plate]] -> binary on/off signal

According to input, output can be anything that is able to react to an on/off signal. This can be doors, bridges, floodgates allowing or stopping flow, gears controlling pumps and much more. In some special configurations - when [[mechanical logic]] is involved - output may not be a on/off signal but power, thus running or not running a machine component.

Currently to convert from power to an on/off signal, the only way is to use a kind of [[Mechanical_logic#Power_to_signal_converter|power to signal converter]], a screw pump connected to that power source, and a pressure plate to measure whether water is being pumped.


====Output elements====
* signal: [[pressure plate]] -> binary on/off signal -> linkable Object(s)
* power: [[gear assembly]] -> binary power on/power off -> machine

=== Binary logic ===
Basic binary logic takes one or two input bits and creates an output based on them. The devices that perform these operations are commonly called '''logic gates'''. 
* NOT - takes one input and returns the opposite of the input 
{| class="wikitable" border=1
|-
! input A
! NOT
|-
| 0
| 1
|-
| 1
| 0
|} 
* AND - takes two inputs and returns true if both inputs are true
* OR - takes two inputs and returns true if at least one input is true
* XOR - takes two inputs and returns true if exactly one input is true
* NAND - takes two inputs and returns true if either input is false
* NOR - takes two inputs and returns true if both inputs are false
* XNOR - takes two inputs and returns true if both inputs are identical 
{| class="wikitable" border=1
|-
! input A
! input B
! AND
! OR
! XOR
! NAND
! NOR
! NXOR
|-
| 0
| 0
| 0
| 0
| 0
| 1
| 1
| 1
|-
| 0
| 1
| 0
| 1
| 1
| 1
| 0
| 0
|-
| 1
| 0
| 0
| 1
| 1
| 1
| 0
| 0
|-
| 1
| 1
| 1
| 1
| 0
| 0
| 0
| 1
|} 
The most human-understandable logic system requires NOT, AND and OR gates, but having a design for either a NAND or a NOR gate is enough to build any of the other gates. Some gates are easier to create or need fewer components than others depending on what discipline your logic relies on. Designing each individual gate that you will need (or using designs that had each individual gate designed) rather than building a gate out of multiple NAND gates or the like will generally result in your dorfputer reacting faster and using less resources (power, water, kittens, construction materials, what-have-you).

=== Complex gates ===
* [[Latch]] - storing and reading a single binary value
* [[Repeater]] - sending a repeating signal
* [[Adder (Computing)|Counter/Adder]] - binary calculation

== Disciplines ==
There are 4 main disciplines of dwarfputing, depending on what would drive the dwarfputer. Each of them has its assets and drawbacks.

The four disciplines are:
=== Fluid logic ===
[[Fluid logic]] is controlling the ''flow of fluid'' over different pressure plates. Fluid logic can be easily constructed and every known logic gate in dwarf fortress has already been built with it. On the other hand this discipline depends on a somehow unlimited source of the used fluid to deal with its [[evaporation]] and [[Water#Water in Fortress Mode|destruction]].

=== Mechanical logic ===
[[Mechanical logic]] uses systems of axles and [[gear assembly|gear assemblies]] to build logical gates. Mechanical logic reacts very fast and can be easily constructed. If you need a signal as output, either to control signal-operated buildings like doors or bridges or to perform further logical operations, you will still need power->signal converters. Since every gear can itself be linked to a trigger (or multiple triggers), and automatically connects to adjacent gears for transferring either power or load, mechanical logic gates are very flexible and don't require anywhere near the number of different devices that tend to be used in fluid logic gates. On the negative side, this discipline uses a LOT of mechanical power and the power->signal converters (needed in most gates not used specifically to activate a pump or roller) come with their own complications. There is, however, a fully functional fluid preserving "rotation sensor" design. Along with advanced techniques to construct logic gates by "pre-toggling" a gear assembly (see [[Pre-Toggled Mechanical Logic]]), any logical circuit can be built, given enough space in the game to do it. For a long time, power could only be converted into a signal through pump-based [[fluid logic]] signal generators. Consequently, mechanical logic was often labelled mechanical-fluid hybrid logic. With the advent of [[Minecart]]s, compact fluid-less power->signal converters have become available, making [[Minecart logic]] an attractive alternative for deploying mechanical logic in your fortress.

=== Creature logic ===
[[Creature logic]] uses pressure plates and constraints on creatures' movement through buildings such as doors and [[hatch cover|hatches]], in conjunction with their [[path]]ing behavior, to build logical gates. Creature logic is very space intensive, but requires no power, fluid, or valuable materials. Every kind of logical circuit can built with creature logic.

[[Animal logic]] is a special kind of creature logic that relies on animals attempting to path through tightly closed doors. Animal logic circuits can be much more space efficient than other forms of creature logic, but are somewhat unreliable.

=== Minecart Logic ===
[[Minecart logic]] involves the control of the paths of [[minecart]]s over pressure plates to build logical gates. Minecart integrates easily with mechanical logic. Power, perhaps surprisingly, is optional. Minecart logic is complete and compact. It lacks the brute speed of which mechanical circuits are capable, but minecart circuit design may be much simpler and more intuitive to some architects.

===Examples of things you could do with logic gates===
* Repeater: Repeatedly toggling hatches open and closed, or spikes up and down.
* Latch: Making resettable one-use pressure plates which are reset by a lever.
* NOT gate: Reversing the effect of a switch or creature-sensing pressure plate, generally linked to a latch device. You can, of course, mod the latch device to send the opposite signal instead of using a NOT gate.
* AND gate: Requiring more than one condition to be true for something to occur. For instance, you could have a group of AND gates, with a system on/off switch, and and other triggers, with each trigger linked to a different AND gate with the system on/off switch linked to the the second input on all the AND gates, so that when the system on/off switch is OFF the output will be OFF on all the AND gates.
* OR gate: You could link two 1-7 water sensors to an OR gate, and link that to a NOT gate, and link that to some floodgates or doors which act as emergency bulkheads, closing when water is detected in the area. Or, link the OR gate to bridges which raise instead (but you may crush things, and bridges are slower than doors).
* XOR gate: You could use pressure plates hooked to latches at different points in your fort to detect enemy intrusion, and set them up to seal off the area with both an interior and exterior bulkhead when the intrusion occurs, but hook your latches up with an XOR gate and hook the output to the interior bulkhead to unseal that one if your pressure plates have detected that the enemy has gotten past it.
* NOR gate: A NOR gate returns TRUE (ON) only if both inputs are FALSE. Instead of using the OR gate example with a NOT gate, you could use a NOR gate linked to two 1-7 water sensors, whose output goes to doors or floodgates. When the pressure plates are both waterless, the floodgates will be open. When one detects water, the floodgates close. (If you used 0-0 pressure plates with an OR, you would get an OFF signal if both plates detected water, or an ON signal otherwise (which is the same as 1-7 NAND 1-7))
* NAND gate: A NAND gate returns TRUE (ON) whenever both inputs are not both TRUE (e.g. ON NAND ON is OFF, but every other combination is ON). Instead of the OR NOT or NOR example, you could link two 0-0 water sensors to a NAND gate, and link the NAND gate's output to raising bridges. 0-0 NAND 0-0 is the same as 1-7 OR 1-7. If there is no water on both pressure plates, the NAND gate will output an OFF signal. If, however, either has water, it will output an ON signal.

* And here's a more complicated example, omitting the details of what gates to use: An automated swimming training room, where you pull a lever to close exit doors and open hatches to drop water into it, then pressure plates detect when there's enough water and close the hatches, and after a certain amount of time (using a very slow repeater, for instance), drains and exit doors open and the system resets until you pull the lever again. Or, the lever could be taken out entirely and the system could be made fully automatic (with dwarves set to train in the room, for instance) using the repeater.

== Examples ==
There are few examples of a really useful dwarfputer and some concepts which have the potential to become useful for others. But in most cases they are made just for fun. What doesn't mean to diminish their designers achievements, because these are in general the more complex ones. At the moment there are no known examples of animal or borg logic.
=== Useful ===
* Magma trap
** This is an example of a useful dwarfputer controlling a magma trap. It automatically floods an area with lava, cleans up and resets afterwards. The timing is perfectly adjusted to let the victims vanish only leaving their valuable metal behind. video: http://mkv25.net/dfma/movie-1808-perfectmagmatrap design: http://i576.photobucket.com/albums/ss208/kanddak/magmatrap.png

=== Concepts ===
* repeater
** mechanical logic http://mkv25.net/dfma/movie-1370-pump-basedautorepeater
* adding machine
** mechanical logic, 6-bit: http://mkv25.net/dfma/movie-1561-addingmachine
** fluid logic, 8-bit: http://mkv25.net/dfma/movie-1084-numberabbeydemonstration
=== Such a doddle ===
* decimal display for 4-bit binary input
** mechanical logic, decimal with overflow-bit: http://mkv25.net/dfma/movie-1745-dwarfputerv01
** probably fluid logic: http://mkv25.net/dfma/movie-1657-7segmentlcddisplay
** fluid logic, hexadecimal: http://mkv25.net/dfma/movie-1092-7-segmentdisplaydemonstration
* tic tac toe
** mechanical logic http://mkv25.net/dfma/movie-1813-tictactoev10simple

== Related user pages ==
*[[User:BaronW]] - The Almighty Dwarven Calculator
*[[User:Jong/Dwarven_Computer]] - The first fully programmable digital Dwarven Computer
*[[User:SL/Logic Gates]] - These use mechanisms for connecting gates and devices and so forth, but fluid for logic. They're built on top of a body of water, and require power (for a pump or two per gate).
*[[User:Kyace/Adder]] - A full adder built using fluid logic, with a video of a rough prototype. Trivial to combine 8 of these to make a fluid device capable of adding two 8 bit numbers together.
*[[User:Soundandfury#Logic_Gates]] - These have a water supply reservoir above and a drain below. The drained water can be pumped back to the supply reservoir.
*[[User:Bidok]] - Animal logic with all gates, memory, repeater and counter. All powered by kittens.
*[[User:LordOOTFD#Animal_Logic]] - Animal logic with fast complex gates, building upon Bidok's kitten powered systems.
*[[User:Hussell#Assorted_Devices]] - Fluid logic
*[[User:Gammon]] - Fluid logic. Very detailed CMOS gates.
*[[User:Root Infinity]] - Misc. logic gates.
*[[User:Vasiln/Goblin Logic 1]] - Theory and practice of invader-based creature logic.
*[[User:Larix/MPL]] - A thorough treatment of minecart logic from first principles.

{{buildings}}
{{Category|Computing}}

v0.34:Computing

2014-02-14T23:05:03Z

Vasiln: Added minecart logic, plus links to Larix's user pages which are awesome

{{Quality|Exceptional}}
{{Computing}}
{{av}}

Computing in Dwarf Fortress is the practice of setting up complex constructions to perform logical operations and calculations; ideally, to control some functionality of your fortress. Even if it isn't a young concept anymore, there is still much room for improvement and development. One reason is that there are many ways to solve one problem. Innovation and invention are encouraged.
=== Binary information ===
Binary information can have one of two possible states: true or false, respectively 1 or 0. In dwarf fortress they can be represented by different entities:
* on/off state or signal of a trigger ([[pressure plate]] or [[lever]])
* power or connection state of a [[machine component]]
* open or closed state of a [[door]] or similar buildings
* [[pressure plate|low/high]] or [[flow|flowing/standing]] [[water|fluid]]
* present [[creature]]s and [[dwarf|borgs]]

Electronic devices and computers base on this elementary form of information, and if you want to go into computing, you’ll have to familiarize yourself with it. [http://en.wikipedia.org/wiki/Propositional_calculus propositional calculus]
=== Input/Output ===
Input can be any device which can be linked to another device with mechanisms, such as [[lever|levers]] or [[pressure plate|pressure plates]]. Pressure plates can measure water, magma, or creature weight, and can be set to react to your own dwarves if measuring creature weight. If measuring water or magma you specify the minimum and maximum levels at which it should output 'on', and at all other levels it will output an 'off' signal. Regardless of the actual amount of water, magma, or creature weight on your pressure plate, the plate can only output an 'on' or 'off' signal (1 or 0) to whatever devices it is linked to. So everything you build will have a binary base.

====Input elements====
* manual: [[lever]] -> binary on/off signal
* triggered: [[pressure plate]] -> binary on/off signal

According to input, output can be anything that is able to react to an on/off signal. This can be doors, bridges, floodgates allowing or stopping flow, gears controlling pumps and much more. In some special configurations - when [[mechanical logic]] is involved - output may not be a on/off signal but power, thus running or not running a machine component.

Currently to convert from power to an on/off signal, the only way is to use a kind of [[Mechanical_logic#Power_to_signal_converter|power to signal converter]], a screw pump connected to that power source, and a pressure plate to measure whether water is being pumped.


====Output elements====
* signal: [[pressure plate]] -> binary on/off signal -> linkable Object(s)
* power: [[gear assembly]] -> binary power on/power off -> machine

=== Binary logic ===
Basic binary logic takes one or two input bits and creates an output based on them. The devices that perform these operations are commonly called '''logic gates'''. 
* NOT - takes one input and returns the opposite of the input 
{| class="wikitable" border=1
|-
! input A
! NOT
|-
| 0
| 1
|-
| 1
| 0
|} 
* AND - takes two inputs and returns true if both inputs are true
* OR - takes two inputs and returns true if at least one input is true
* XOR - takes two inputs and returns true if exactly one input is true
* NAND - takes two inputs and returns true if either input is false
* NOR - takes two inputs and returns true if both inputs are false
* XNOR - takes two inputs and returns true if both inputs are identical 
{| class="wikitable" border=1
|-
! input A
! input B
! AND
! OR
! XOR
! NAND
! NOR
! NXOR
|-
| 0
| 0
| 0
| 0
| 0
| 1
| 1
| 1
|-
| 0
| 1
| 0
| 1
| 1
| 1
| 0
| 0
|-
| 1
| 0
| 0
| 1
| 1
| 1
| 0
| 0
|-
| 1
| 1
| 1
| 1
| 0
| 0
| 0
| 1
|} 
The most human-understandable logic system requires NOT, AND and OR gates, but having a design for either a NAND or a NOR gate is enough to build any of the other gates. Some gates are easier to create or need fewer components than others depending on what discipline your logic relies on. Designing each individual gate that you will need (or using designs that had each individual gate designed) rather than building a gate out of multiple NAND gates or the like will generally result in your dorfputer reacting faster and using less resources (power, water, kittens, construction materials, what-have-you).

=== Complex gates ===
* [[Latch]] - storing and reading a single binary value
* [[Repeater]] - sending a repeating signal
* [[Adder (Computing)|Counter/Adder]] - binary calculation

== Disciplines ==
There are 4 main disciplines of dwarfputing, depending on what would drive the dwarfputer. Each of them has its assets and drawbacks.

The four disciplines are:
=== Fluid logic ===
[[Fluid logic]] is controlling the ''flow of fluid'' over different pressure plates. Fluid logic can be easily constructed and every known logic gate in dwarf fortress has already been built with it. On the other hand this discipline depends on a somehow unlimited source of the used fluid to deal with its [[evaporation]] and [[Water#Water in Fortress Mode|destruction]].

=== Mechanical logic ===
[[Mechanical logic]] uses systems of axles and [[gear assembly|gear assemblies]] to build logical gates. Mechanical logic reacts very fast and can be easily constructed. If you need a signal as output, either to control signal-operated buildings like doors or bridges or to perform further logical operations, you will still need power->signal converters. Since every gear can itself be linked to a trigger (or multiple triggers), and automatically connects to adjacent gears for transferring either power or load, mechanical logic gates are very flexible and don't require anywhere near the number of different devices that tend to be used in fluid logic gates. On the negative side, this discipline uses a LOT of mechanical power and the power->signal converters (needed in most gates not used specifically to activate a pump or roller) come with their own complications. There is, however, a fully functional fluid preserving "rotation sensor" design. Along with advanced techniques to construct logic gates by "pre-toggling" a gear assembly (see [[Pre-Toggled Mechanical Logic]]), any logical circuit can be built, given enough space in the game to do it. For a long time, power could only be converted into a signal through pump-based [[fluid logic]] signal generators. Consequently, mechanical logic was often labelled mechanical-fluid hybrid logic. With the advent of [[Minecart]]s, compact fluid-less power->signal converters have become available, making [[Minecart logic]] an attractive alternative for deploying mechanical logic in your fortress.

=== Creature logic ===
[[Creature logic]] uses pressure plates and constraints on creatures' movement through buildings such as doors and [[hatch cover|hatches]], in conjunction with their [[path]]ing behavior, to build logical gates. Creature logic is very space intensive, but requires no power, fluid, or valuable materials. Every kind of logical circuit can built with creature logic.

[[Animal logic]] is a special kind of creature logic that relies on animals attempting to path through tightly closed doors. Animal logic circuits can be much more space efficient than other forms of creature logic, but are somewhat unreliable.

=== Minecart Logic ===
[[Minecart logic]] involves the control of the paths of [[minecart]]s over pressure plates to build logical gates. Minecart integrates easily with mechanical logic. Power, perhaps surprisingly, is optional. Minecart logic is complete and compact. It lacks the brute speed of which mechanical circuits are capable, but minecart circuit design may be much simpler and more intuitive to some architects.

===Examples of things you could do with logic gates===
* Repeater: Repeatedly toggling hatches open and closed, or spikes up and down.
* Latch: Making resettable one-use pressure plates which are reset by a lever.
* NOT gate: Reversing the effect of a switch or creature-sensing pressure plate, generally linked to a latch device. You can, of course, mod the latch device to send the opposite signal instead of using a NOT gate.
* AND gate: Requiring more than one condition to be true for something to occur. For instance, you could have a group of AND gates, with a system on/off switch, and and other triggers, with each trigger linked to a different AND gate with the system on/off switch linked to the the second input on all the AND gates, so that when the system on/off switch is OFF the output will be OFF on all the AND gates.
* OR gate: You could link two 1-7 water sensors to an OR gate, and link that to a NOT gate, and link that to some floodgates or doors which act as emergency bulkheads, closing when water is detected in the area. Or, link the OR gate to bridges which raise instead (but you may crush things, and bridges are slower than doors).
* XOR gate: You could use pressure plates hooked to latches at different points in your fort to detect enemy intrusion, and set them up to seal off the area with both an interior and exterior bulkhead when the intrusion occurs, but hook your latches up with an XOR gate and hook the output to the interior bulkhead to unseal that one if your pressure plates have detected that the enemy has gotten past it.
* NOR gate: A NOR gate returns TRUE (ON) only if both inputs are FALSE. Instead of using the OR gate example with a NOT gate, you could use a NOR gate linked to two 1-7 water sensors, whose output goes to doors or floodgates. When the pressure plates are both waterless, the floodgates will be open. When one detects water, the floodgates close. (If you used 0-0 pressure plates with an OR, you would get an OFF signal if both plates detected water, or an ON signal otherwise (which is the same as 1-7 NAND 1-7))
* NAND gate: A NAND gate returns TRUE (ON) whenever both inputs are not both TRUE (e.g. ON NAND ON is OFF, but every other combination is ON). Instead of the OR NOT or NOR example, you could link two 0-0 water sensors to a NAND gate, and link the NAND gate's output to raising bridges. 0-0 NAND 0-0 is the same as 1-7 OR 1-7. If there is no water on both pressure plates, the NAND gate will output an OFF signal. If, however, either has water, it will output an ON signal.

* And here's a more complicated example, omitting the details of what gates to use: An automated swimming training room, where you pull a lever to close exit doors and open hatches to drop water into it, then pressure plates detect when there's enough water and close the hatches, and after a certain amount of time (using a very slow repeater, for instance), drains and exit doors open and the system resets until you pull the lever again. Or, the lever could be taken out entirely and the system could be made fully automatic (with dwarves set to train in the room, for instance) using the repeater.

== Examples ==
There are few examples of a really useful dwarfputer and some concepts which have the potential to become useful for others. But in most cases they are made just for fun. What doesn't mean to diminish their designers achievements, because these are in general the more complex ones. At the moment there are no known examples of animal or borg logic.
=== Useful ===
* Magma trap
** This is an example of a useful dwarfputer controlling a magma trap. It automatically floods an area with lava, cleans up and resets afterwards. The timing is perfectly adjusted to let the victims vanish only leaving their valuable metal behind. video: http://mkv25.net/dfma/movie-1808-perfectmagmatrap design: http://i576.photobucket.com/albums/ss208/kanddak/magmatrap.png

=== Concepts ===
* repeater
** mechanical logic http://mkv25.net/dfma/movie-1370-pump-basedautorepeater
* adding machine
** mechanical logic, 6-bit: http://mkv25.net/dfma/movie-1561-addingmachine
** fluid logic, 8-bit: http://mkv25.net/dfma/movie-1084-numberabbeydemonstration
=== Such a doddle ===
* decimal display for 4-bit binary input
** mechanical logic, decimal with overflow-bit: http://mkv25.net/dfma/movie-1745-dwarfputerv01
** probably fluid logic: http://mkv25.net/dfma/movie-1657-7segmentlcddisplay
** fluid logic, hexadecimal: http://mkv25.net/dfma/movie-1092-7-segmentdisplaydemonstration
* tic tac toe
** mechanical logic http://mkv25.net/dfma/movie-1813-tictactoev10simple

== Related user pages ==
*[[User:BaronW]] - The Almighty Dwarven Calculator
*[[User:Jong/Dwarven_Computer]] - The first fully programmable digital Dwarven Computer
*[[User:SL/Logic Gates]] - These use mechanisms for connecting gates and devices and so forth, but fluid for logic. They're built on top of a body of water, and require power (for a pump or two per gate).
*[[User:Kyace/Adder]] - A full adder built using fluid logic, with a video of a rough prototype. Trivial to combine 8 of these to make a fluid device capable of adding two 8 bit numbers together.
*[[User:Soundandfury#Logic_Gates]] - These have a water supply reservoir above and a drain below. The drained water can be pumped back to the supply reservoir.
*[[User:Bidok]] - Animal logic with all gates, memory, repeater and counter. All powered by kittens.
*[[User:LordOOTFD#Animal_Logic]] - Animal logic with fast complex gates, building upon Bidok's kitten powered systems.
*[[User:Hussell#Assorted_Devices]] - Fluid logic
*[[User:Gammon]] - Fluid logic. Very detailed CMOS gates.
*[[User:Root Infinity]] - Misc. logic gates.
*[[User:Vasiln/Goblin Logic 1]] - Theory and practice of invader-based creature logic.
*[[http://dwarffortresswiki.org/index.php/User:Larix/MPL]] - A thorough treatment of minecart logic from first principles.

{{buildings}}
{{Category|Computing}}

v0.34 Talk:Mechanical logic

2012-06-28T19:14:18Z

Vasiln: /* Combing Load Based Mechanics */

<div style="position:relative; float:none;">
'''Cart-based power-to-signal converter (cross-section)'''
{| cellpadding="0" cellspacing="0" style="border-spacing:0; border-style:solid; border-width:thin; border-color:#000000;"
|
{| cellpadding="0" cellspacing="0" style="border-spacing:0; padding:0; margin:0; vertical-align:middle;"
|-
|{{RTL|#222}}
|{{RTL|#222}}
|{{RTL|#222}}
|{{RTL|#222}}
|{{RTL|#222}}
|{{RTL|#222}}
|-
|{{RTL|#222|.|}}
|{{RTL|#FFF||}}
|{{RTL|#FFF||}}
|{{RTL|#FFF||}}
|{{RTL|#A0A|^|}}
|{{RTL|#222|▲|}}
|-
|{{RTL|#222||}}
|{{RTL|#222|▲|}}
|{{RTL|#222|r|}}
|{{RTL|#222|▲|}}
|{{RTL|#222||}}
|{{RTL|#222}}
|-
|{{RTL|#222}}
|{{RTL|#222}}
|{{RTL|#222}}
|{{RTL|#222}}
|{{RTL|#222}}
|{{RTL|#222}}
|}
|}
</div>

Where ▲ is E/W (N/S) track ramp 
^ is a pressure plate, 
r is a roller (highest speed) 
. is E/W (N/S) track 

Power feeds in beside the roller on the lower level.
Rollers can not be powered from above.

A cart is fed into the system with a little push from the upper-level track. Ramps hold it in place over the roller. When powered, cart travels rapidly back and forth over pressure plate, maintaining 'on' state. This can then be used to power doors, bridges, etc.

--[[User:TerryDactyl|TerryDactyl]] 02:07, 21 May 2012 (UTC)

== Miniaturized cart-based power-to-signal converter (overhead) ==

{| cellpadding="0" cellspacing="0" style="border-spacing:0; border-style:solid; border-width:thin; border-color:#000000;"
|
{| cellpadding="0" cellspacing="0" style="border-spacing:0; padding:0; margin:0; vertical-align:middle;"
|-
|{{RTL|#222||}}
|{{RTL|#222|a|}}
|{{RTL|#222|↓|}}
|-
|{{RTL|#222|P|}}
|{{RTL|#222|a|}}
|{{RTL|#222|^|}}
|-
|{{RTL|#222||}}
|{{RTL|#222|a|}}
|{{RTL|#222|↑|}}
|-
|}
|}

where P is power source 
a are each gear assemblies 
arrows represent rollers and direction of force 
^ represents a pressure plate.

Be careful priming this machine. I'm not entirely sure, but I doubt it should be loaded in the active state.

Delay is ~10 or 11 ticks to trigger the plate.
--[[User:TerryDactyl|TerryDactyl]] 04:16, 25 May 2012 (UTC)

== Combing Load Based Mechanics ==

If I'm reading this correctly, for load based mechanics, won't a 'off' state (which connects the Power Line to the Load) will essentially "short" out the system, making all outputs negative? This is ok for simple systems, but you'll want to avoid that for more complex logic... -- [[User:IdeaHat|IdeaHat]] 19:32, 24 June 2012 (UTC)
:You are reading it correctly. Individual gates in load-based systems require independent power sources. [[User:Vasiln|Vasiln]] 19:14, 28 June 2012 (UTC)

v0.34:Dwarf cancels task: Dangerous terrain

2012-04-06T17:56:10Z

Vasiln: Standing on furniture is also dangerous terrain; no path to job gives a different cancellation message

{{quality|Fine|06:48, 6 April 2012 (UTC)}}
{{av}}

This message means that the path a dwarf has chosen has become occupied with deep [[water]] or [[magma]]. In the case of water, dwarves will path through water at depths of [3/7] or shallower. Dwarves cancel their task if confronted with water that is [4/7] or deeper. This often happens when players are slowly filling accessible pools or moats or what have you. As the dwarves attempt to cross the body of water during the filling, they will be interrupted by any tiles of [4/7] water sloshing around.

Solid furniture without a floor also counts as dangerous terrain. For instance, a dwarf standing on the top of a raised [[bridge]] will cancel its job, with this cancellation message.

Magma of course can also flow across a dwarf's path and cause a cancellation, but for magma it only requires a depth of [1/7].

New to v0.31, [[Channel|channeling]] is more difficult for dwarves, and a lot more likely to cause a dwarf to step down into a hole just as its filling up with water (or magma!).

Fortresses with [[waterfall]]s near high traffic areas or meeting areas can generate these messages with annoying frequency, though it can be amusing to see "Dwarf cancels Attend [[Party]]: Dangerous terrain" when a partygoer steps underneath the waterfall in your dining room or sculpture garden.

It can also mean the dwarf is currently in dangerous terrain, and is canceling a job on the other side of the map or that the dwarf requires building materials that are at the bottom of a lake or river.

If there is a river on your map with treacherous [[carp]], this is often the message which heralds yet another of your dwarves drowning due to being yanked in by fish. Fun.

{{Errors FAQ}}

User talk:Reilwin

2012-04-05T18:00:54Z

Vasiln:

You can talk to me here.

== Discussion ==

===Thanks===
Hey, just wanted to say thanks for all the work you've been doing. --[[User:Vasiln|Vasiln]] 18:00, 5 April 2012 (UTC)

v0.34 Talk:Hatch cover

2012-04-05T06:32:13Z

Vasiln:

Sorry for my hasty edit. I was on the way to correct myself for special pathing circumstances when a conflicting better edit was made. The original article was still factually incorrect and that confused me.
--[[User:Another|Another]] 21:50, 4 April 2012 (UTC)

:The original article probably did need some clarification, but I strongly believe that you're mistaken. (I just want to make something clear: the only way to prevent building destruction is to use a LOCKED hatch; otherwise they'll just move up to the level of the hatch, and then destroy it.) To confirm, I just released a caged troll into a chamber from which he could only exit up through a forbidden hatch-- a season later, he's still just running around without path. Every great once in a while, people report hatches being destroyed from below. Either there is inconsistent behavior (with forbidden hatches being only very occasionally destructible from below) or, more likely, people have forgotten to forbid their hatches. If anybody could catch a movie of a building destroyer destroying a locked hatch from below, there would be clear evidence that the consensus on hatches in incorrect, and it would justify a wiki edit-- so if you can catch on film the behavior you're describing, I'll be forced to eat my hat. I'm going to undo your edits, and try to introduce more specific and clear language into both this article and the building destroyer article. --[[User:Vasiln|Vasiln]] 22:34, 4 April 2012 (UTC)
:Okay, Timrem's edits are great, I didn't change anything here, I just added a couple of diagrams to the BD page. Hopefully this is useful for you Another? --[[User:Vasiln|Vasiln]] 23:03, 4 April 2012 (UTC)
::The only disagreement I still have with you is that I definitely saw a badly damaged hatch and 2 FB directly below it not moving and not attacking a hunter that was firing at them from the same z level as the hatch. After I made the hatch forbidden - the FBs immediately lost interest and wandered away. They try to path to the same level as the hatch and then attack if the path is found but they do not need to actually walk the whole path and can attack buildings from below in contradiction with what the article originally said. I suspect that a remote potential path is enough to start destroying even a forbidden hatch from below but that should be verified. --[[User:Another|Another]] 03:22, 5 April 2012 (UTC)
:::Yeah, that's consistent with my understanding. Do you feel that this page and the BD page now describes this behavior accurately? --[[User:Vasiln|Vasiln]] 06:32, 5 April 2012 (UTC)

v0.34:Building destroyer

2012-04-04T23:41:55Z

Vasiln:

{{quality|Fine|18:02, 18 October 2010 (UTC)}}{{av}}

Creatures with the [[Creature token#B|BUILDINGDESTROYER token]] will actively seek out various [[furniture|furnishings]], [[workshop]]s and other [[building]]s and topple or destroy them. They come in two varieties, the first being annoying, and the second dangerous. Buildings made from raw materials will be toppled, leaving the materials on the ground, while buildings made from furniture will be destroyed, not leaving behind any items.

Creatures with this tag are gifted with an incredible ability to sense exactly where your buildings are. Underground creatures such as the [[Blind cave ogre]] or [[Voracious cave crawler]] will charge your fort immediately after spawning at the edge of the map. Plan your [[defense guide|defenses]] accordingly. Building destroyers still prefer to attack creatures, and if a valid creature target for their aggression is or becomes visible to them, they will abandon building destruction in favor of classic creature destruction.

The time it takes for a building destroyer to destroy a building depends on the [[quality]] of the the building. [[Artifact]] quality furniture can never be damaged or destroyed, but some kinds of artifact furniture will be deconstructed by a building destroyer, given enough time: for instance, artifact statues will eventually be deconstructed; artifact hatch covers never will.

Building destroyers will destroy [[door]]s, [[floodgate]]s, [[hatch]] covers, vertical [[bars]], horizontal bars, [[chest]]s, [[cabinet]]s, [[bed]]s, [[chair]]s, [[table]]s, [[coffin]]s, [[armor stand]]s, [[weapon rack]]s, floor or wall [[grate]]s, [[statue]]s, and [[workshop]]s. They will not path to or destroy [[lever]]s, [[support]]s, [[restraint]]s, [[bridge]]s, or [[construction]]s such as walls. While they can destroy most furniture and buildings from a lower [[z-level]] when a valid path exists to that furniture, they cannot destroy hatches or grates from below. They can only destroy things orthogonally. Building destroyers will path to and destroy even opened (or stuck open) doors, hatches, floodgates, or vertical bars. They will cause damage to any attached mechanisms during building destruction, sometimes leading to the unlinking of furniture to a lever before the furniture in question is fully destroyed.

==Destroying from underneath==

Building destroyers cannot destroy buildings unless their path to the building passes through the building's z-level. This means that building destroyers cannot destroy, for instance, a forbidden hatch above them (note that non-forbidden, i.e. passable, hatches are vulnerable!), or a magma forge from the magma underneath it.

Building destroyers can destroy buildings from the z-level below while standing on a ramp or stairs that leads up to the building's z-level.

Building destroyers cannot destroy closed floodgates or locked doors from a ramp leading up to the level of those buildings unless there is an open path to the same level. This was tested with trolls, in an entrance-way accessed by both lever-controlled floodgates and a manually locked door. Ramps led up to the floodgates and the door. When both were closed, the trolls showed no interest. When the door was unlocked, a troll began to destroy it. When the door was locked again, the troll went away. When the floodgates were opened, a troll returned and destroyed the locked door from the ramp outside, while the open floodgates were also apparently being destroyed from the ramps by other trolls. This may be related to the bug where Dwarves appear to be building diagonally as long as they can access the spot orthogonally. It is unknown whether this applies to an open path extending through the full length of a fortress, rather than just a few steps away through open floodgates.

Consider the following diagrams, as viewed from the side:

{{diagram|spaces=yes|\

╔════
═╝ [#0FF]+
[#F00]B▲╔══
═══╝
}}

Here, the {{Raw Tile|B|#F00|#000}}uilding destroyer cannot pass through the cyan door while it is forbidden, but the instant the door becomes unforbidden, the building destroyer will destroy the door-- from the tile on which it stands.

{{diagram|spaces=yes|\

╔════
═╝[#0FF]¢
[#F00]B▲╔══
═══╝
}}

Here, the cyan hatch cannot be destroyed while it is forbidden, but when it is unforbidden, the {{Raw Tile|B|#F00|#000}}uilding destroyer will destroy it.

{{diagram|spaces=yes|\

╔════
═╝ [#0FF]+
[#F00]B▲╔══
═══╝
}}

Here, the {{Raw Tile|B|#F00|#000}}uilding destroyer will stand on the ramp and destroy the door (or any other furniture), regardless of whether the door is forbidden.

{{diagram|spaces=yes|\

╔═══╗
═╝ [#0FF]+ ╚
[#F00]B▲║▲
═══╩══
}}

Here, the {{Raw Tile|B|#F00|#000}}uilding destroyer will be unable to pass the door if it's forbidden; should it become unforbidden, the building destroyer will ignore the door (probably passing through in order to target a different piece of furniture).

{{diagram|spaces=yes|\

╔══════
═╝ [#0FF]+ >
[#F00]B>▲╔═╗X╔
╗X═╩═╝X║
║< <║
╚══════╝
}}

Here, the {{Raw Tile|B|#F00|#000}}uilding destroyer has path to a square from which it can destroy the cyan door-- thus, '''it can destroy the door, even if forbidden, from the tile directly in front of it.'''

==Annoying Variety==
When the value is '''1''', the creature will go after wooden [[hatch]]es, wooden [[door]]s, [[support]]s, [[statue]]s, [[window]]s and [[archery target]]s only. They can't destroy homes during world gen as (semi)megabeasts.

'''[BUILDINGDESTROYER:1] creatures:'''
*[[Cave crocodile]]
*[[Giant cave spider]]
*[[Giant desert scorpion]]
*[[Giant olm]]
*[[Giant toad]]

==Dangerous Variety==
When the value is '''2''' the creature will actively seek out [[building]]s and destroy them. They can also destroy buildings during world-gen with this tag. Megabeasts rely on this token for their pathing when attacking your fort. [[Construction]]s (walls, staircase, floors, etc.) are still safe, since they're processed the same way natural terrain is for most situations.

The simplest way to keep building destroyer 2's from targets is with walls or channels. The outside of a raised [[bridge|drawbridge]] will act like a constructed wall, blocking building destroyer 2's without that danger of being destroyed. {{Verify}}

Tame animals still carry their building destroyer tokens.

'''[BUILDINGDESTROYER:2] creatures:'''
*[[Amethyst man]]
*[[Blind cave ogre]]
*[[Bronze colossus]]
*[[Cave dragon]]
*[[Cyclops]]
*[[Dragon]]
*[[Ettin]]
*[[Fire man]]
*[[Gabbro man]]
*[[Giant]]
*[[Hydra]]
*[[Iron man]]
*[[Magma man]]
*[[Minotaur]]
*[[Mud man]]
*[[Ogre]]
*[[Sasquatch]]
*[[Troll]]
*[[Voracious cave crawler]]
*[[Yeti]]
*All [[forgotten beast]]s, [[titan]]s, and [[demon]]s
*[[Werebeast]]s (in werebeast form only)

See the [[Modding guide]] for more information on creature tokens.

==Bugs==
* Building destroyers can destroy buildings even if there's one tile of empty space between them and the building. {{Bug|4585}} In fact, they cannot destroy immediately adjacent buildings, although that's only relevant when releasing them from cages.

v0.34:Building destroyer

2012-04-04T23:38:30Z

Vasiln: one more special case diagram

{{quality|Fine|18:02, 18 October 2010 (UTC)}}{{av}}

Creatures with the [[Creature token#B|BUILDINGDESTROYER token]] will actively seek out various [[furniture|furnishings]], [[workshop]]s and other [[building]]s and topple or destroy them. They come in two varieties, the first being annoying, and the second dangerous. Buildings made from raw materials will be toppled, leaving the materials on the ground, while buildings made from furniture will be destroyed, not leaving behind any items.

Creatures with this tag are gifted with an incredible ability to sense exactly where your buildings are. Underground creatures such as the [[Blind cave ogre]] or [[Voracious cave crawler]] will charge your fort immediately after spawning at the edge of the map. Plan your [[defense guide|defenses]] accordingly. Building destroyers still prefer to attack creatures, and if a valid creature target for their aggression is or becomes visible to them, they will abandon building destruction in favor of classic creature destruction.

The time it takes for a building destroyer to destroy a building depends on the [[quality]] of the the building. [[Artifact]] quality furniture can never be damaged or destroyed, but some kinds of artifact furniture will be deconstructed by a building destroyer, given enough time: for instance, artifact statues will eventually be deconstructed; artifact hatch covers never will.

Building destroyers will destroy [[door]]s, [[floodgate]]s, [[hatch]] covers, vertical [[bars]], horizontal bars, [[chest]]s, [[cabinet]]s, [[bed]]s, [[chair]]s, [[table]]s, [[coffin]]s, [[armor stand]]s, [[weapon rack]]s, floor or wall [[grate]]s, [[statue]]s, and [[workshop]]s. They will not path to or destroy [[lever]]s, [[support]]s, [[restraint]]s, [[bridge]]s, or [[construction]]s such as walls. While they can destroy most furniture and buildings from a lower [[z-level]] when a valid path exists to that furniture, they cannot destroy hatches or grates from below. They can only destroy things orthogonally. Building destroyers will path to and destroy even opened (or stuck open) doors, hatches, floodgates, or vertical bars. They will cause damage to any attached mechanisms during building destruction, sometimes leading to the unlinking of furniture to a lever before the furniture in question is fully destroyed.

==Destroying from underneath==

Building destroyers cannot destroy buildings unless their path to the building passes through the building's z-level. This means that building destroyers cannot destroy, for instance, a forbidden hatch above them (note that non-forbidden, i.e. passable, hatches are vulnerable!), or a magma forge from the magma underneath it.

Building destroyers can destroy buildings from the z-level below while standing on a ramp or stairs that leads up to the building's z-level.

Building destroyers cannot destroy closed floodgates or locked doors from a ramp leading up to the level of those buildings unless there is an open path to the same level. This was tested with trolls, in an entrance-way accessed by both lever-controlled floodgates and a manually locked door. Ramps led up to the floodgates and the door. When both were closed, the trolls showed no interest. When the door was unlocked, a troll began to destroy it. When the door was locked again, the troll went away. When the floodgates were opened, a troll returned and destroyed the locked door from the ramp outside, while the open floodgates were also apparently being destroyed from the ramps by other trolls. This may be related to the bug where Dwarves appear to be building diagonally as long as they can access the spot orthogonally. It is unknown whether this applies to an open path extending through the full length of a fortress, rather than just a few steps away through open floodgates.

Consider the following diagrams, as viewed from the side:

{{diagram|spaces=yes|\

╔════
═╝ [#0FF]+
[#F00]B▲╔══
═══╝
}}

Here, the {{Raw Tile|B|#F00|#000}}uilding destroyer cannot pass through the cyan door while it is forbidden, but the instant the door becomes unforbidden, the building destroyer will destroy the door-- from the tile on which it stands.

{{diagram|spaces=yes|\

╔════
═╝[#0FF]¢
[#F00]B▲╔══
═══╝
}}

Here, the cyan hatch cannot be destroyed while it is forbidden, but when it is unforbidden, the {{Raw Tile|B|#F00|#000}}uilding destroyer will destroy it.

{{diagram|spaces=yes|\

╔════
═╝ [#0FF]+
[#F00]B▲╔══
═══╝
}}

Here, the {{Raw Tile|B|#F00|#000}}uilding destroyer will stand on the ramp and destroy the door (or any other furniture), regardless of whether the door is forbidden.

{{diagram|spaces=yes|\

╔═══╗
═╝ [#0FF]+ ╚
[#F00]B▲║▲
═══╩══
}}

Here, the {{Raw Tile|B|#F00|#000}}uilding destroyer will be unable to pass the door if it's forbidden; should it become unforbidden, the building destroyer will ignore the door (probably passing through in order to target a different piece of furniture).

{{diagram|spaces=yes|\

╔══════
═╝ [#0FF]+ <
[#F00]B>▲╔═╗X╔
╗X═╩═╝X║
║< <║
╚══════╝
}}

Here, the {{Raw Tile|B|#F00|#000}}uilding destroyer has path to a square from which it can destroy the cyan door-- thus, '''it can destroy the door, even if forbidden, from the tile directly in front of it.'''

==Annoying Variety==
When the value is '''1''', the creature will go after wooden [[hatch]]es, wooden [[door]]s, [[support]]s, [[statue]]s, [[window]]s and [[archery target]]s only. They can't destroy homes during world gen as (semi)megabeasts.

'''[BUILDINGDESTROYER:1] creatures:'''
*[[Cave crocodile]]
*[[Giant cave spider]]
*[[Giant desert scorpion]]
*[[Giant olm]]
*[[Giant toad]]

==Dangerous Variety==
When the value is '''2''' the creature will actively seek out [[building]]s and destroy them. They can also destroy buildings during world-gen with this tag. Megabeasts rely on this token for their pathing when attacking your fort. [[Construction]]s (walls, staircase, floors, etc.) are still safe, since they're processed the same way natural terrain is for most situations.

The simplest way to keep building destroyer 2's from targets is with walls or channels. The outside of a raised [[bridge|drawbridge]] will act like a constructed wall, blocking building destroyer 2's without that danger of being destroyed. {{Verify}}

Tame animals still carry their building destroyer tokens.

'''[BUILDINGDESTROYER:2] creatures:'''
*[[Amethyst man]]
*[[Blind cave ogre]]
*[[Bronze colossus]]
*[[Cave dragon]]
*[[Cyclops]]
*[[Dragon]]
*[[Ettin]]
*[[Fire man]]
*[[Gabbro man]]
*[[Giant]]
*[[Hydra]]
*[[Iron man]]
*[[Magma man]]
*[[Minotaur]]
*[[Mud man]]
*[[Ogre]]
*[[Sasquatch]]
*[[Troll]]
*[[Voracious cave crawler]]
*[[Yeti]]
*All [[forgotten beast]]s, [[titan]]s, and [[demon]]s
*[[Werebeast]]s (in werebeast form only)

See the [[Modding guide]] for more information on creature tokens.

==Bugs==
* Building destroyers can destroy buildings even if there's one tile of empty space between them and the building. {{Bug|4585}} In fact, they cannot destroy immediately adjacent buildings, although that's only relevant when releasing them from cages.

v0.34 Talk:Hatch cover

2012-04-04T23:03:30Z

Vasiln:

v0.34:Building destroyer

2012-04-04T23:01:14Z

Vasiln: added some diagrams to clarify specific "destroying from underneath" conditions

{{quality|Fine|18:02, 18 October 2010 (UTC)}}{{av}}

Creatures with the [[Creature token#B|BUILDINGDESTROYER token]] will actively seek out various [[furniture|furnishings]], [[workshop]]s and other [[building]]s and topple or destroy them. They come in two varieties, the first being annoying, and the second dangerous. Buildings made from raw materials will be toppled, leaving the materials on the ground, while buildings made from furniture will be destroyed, not leaving behind any items.

Creatures with this tag are gifted with an incredible ability to sense exactly where your buildings are. Underground creatures such as the [[Blind cave ogre]] or [[Voracious cave crawler]] will charge your fort immediately after spawning at the edge of the map. Plan your [[defense guide|defenses]] accordingly. Building destroyers still prefer to attack creatures, and if a valid creature target for their aggression is or becomes visible to them, they will abandon building destruction in favor of classic creature destruction.

The time it takes for a building destroyer to destroy a building depends on the [[quality]] of the the building. [[Artifact]] quality furniture can never be damaged or destroyed, but some kinds of artifact furniture will be deconstructed by a building destroyer, given enough time: for instance, artifact statues will eventually be deconstructed; artifact hatch covers never will.

Building destroyers will destroy [[door]]s, [[floodgate]]s, [[hatch]] covers, vertical [[bars]], horizontal bars, [[chest]]s, [[cabinet]]s, [[bed]]s, [[chair]]s, [[table]]s, [[coffin]]s, [[armor stand]]s, [[weapon rack]]s, floor or wall [[grate]]s, [[statue]]s, and [[workshop]]s. They will not path to or destroy [[lever]]s, [[support]]s, [[restraint]]s, [[bridge]]s, or [[construction]]s such as walls. While they can destroy most furniture and buildings from a lower [[z-level]] when a valid path exists to that furniture, they cannot destroy hatches or grates from below. They can only destroy things orthogonally. Building destroyers will path to and destroy even opened (or stuck open) doors, hatches, floodgates, or vertical bars. They will cause damage to any attached mechanisms during building destruction, sometimes leading to the unlinking of furniture to a lever before the furniture in question is fully destroyed.

==Destroying from underneath==

Building destroyers cannot destroy buildings unless their path to the building passes through the building's z-level. This means that building destroyers cannot destroy, for instance, a forbidden hatch above them (note that non-forbidden, i.e. passable, hatches are vulnerable!), or a magma forge from the magma underneath it.

Building destroyers can destroy buildings from the z-level below while standing on a ramp or stairs that leads up to the building's z-level.

Building destroyers cannot destroy closed floodgates or locked doors from a ramp leading up to the level of those buildings unless there is an open path to the same level. This was tested with trolls, in an entrance-way accessed by both lever-controlled floodgates and a manually locked door. Ramps led up to the floodgates and the door. When both were closed, the trolls showed no interest. When the door was unlocked, a troll began to destroy it. When the door was locked again, the troll went away. When the floodgates were opened, a troll returned and destroyed the locked door from the ramp outside, while the open floodgates were also apparently being destroyed from the ramps by other trolls. This may be related to the bug where Dwarves appear to be building diagonally as long as they can access the spot orthogonally. It is unknown whether this applies to an open path extending through the full length of a fortress, rather than just a few steps away through open floodgates.

Consider the following diagrams, as viewed from the side:

{{diagram|spaces=yes|\

╔════
═╝ [#0FF]+
[#F00]B▲╔══
═══╝
}}

Here, the {{Raw Tile|B|#F00|#000}}uilding destroyer cannot pass through the cyan door while it is forbidden, but the instant the door becomes unforbidden, the building destroyer will destroy the door-- from the tile on which it stands.

{{diagram|spaces=yes|\

╔════
═╝[#0FF]¢
[#F00]B▲╔══
═══╝
}}

Here, the cyan hatch cannot be destroyed while it is forbidden, but when it is unforbidden, the building destroyer will travel to the space next to the hatch and destroy it.

{{diagram|spaces=yes|\

╔════
═╝ [#0FF]+
[#F00]B▲╔══
═══╝
}}

Here, the building destroyer will stand on the ramp and destroy the door (or any other furniture), regardless of whether the door is forbidden.

{{diagram|spaces=yes|\

╔═══╗
═╝ [#0FF]+ ╚
[#F00]B▲║▲
═══╩══
}}

Here, the building destroyer will be unable to pass the door if it's forbidden; should it become unforbidden, the building destroyer will ignore the door (probably passing through in order to target a different piece of furniture).

==Annoying Variety==
When the value is '''1''', the creature will go after wooden [[hatch]]es, wooden [[door]]s, [[support]]s, [[statue]]s, [[window]]s and [[archery target]]s only. They can't destroy homes during world gen as (semi)megabeasts.

'''[BUILDINGDESTROYER:1] creatures:'''
*[[Cave crocodile]]
*[[Giant cave spider]]
*[[Giant desert scorpion]]
*[[Giant olm]]
*[[Giant toad]]

==Dangerous Variety==
When the value is '''2''' the creature will actively seek out [[building]]s and destroy them. They can also destroy buildings during world-gen with this tag. Megabeasts rely on this token for their pathing when attacking your fort. [[Construction]]s (walls, staircase, floors, etc.) are still safe, since they're processed the same way natural terrain is for most situations.

The simplest way to keep building destroyer 2's from targets is with walls or channels. The outside of a raised [[bridge|drawbridge]] will act like a constructed wall, blocking building destroyer 2's without that danger of being destroyed. {{Verify}}

Tame animals still carry their building destroyer tokens.

'''[BUILDINGDESTROYER:2] creatures:'''
*[[Amethyst man]]
*[[Blind cave ogre]]
*[[Bronze colossus]]
*[[Cave dragon]]
*[[Cyclops]]
*[[Dragon]]
*[[Ettin]]
*[[Fire man]]
*[[Gabbro man]]
*[[Giant]]
*[[Hydra]]
*[[Iron man]]
*[[Magma man]]
*[[Minotaur]]
*[[Mud man]]
*[[Ogre]]
*[[Sasquatch]]
*[[Troll]]
*[[Voracious cave crawler]]
*[[Yeti]]
*All [[forgotten beast]]s, [[titan]]s, and [[demon]]s
*[[Werebeast]]s (in werebeast form only)

See the [[Modding guide]] for more information on creature tokens.

==Bugs==
* Building destroyers can destroy buildings even if there's one tile of empty space between them and the building. {{Bug|4585}} In fact, they cannot destroy immediately adjacent buildings, although that's only relevant when releasing them from cages.

v0.34 Talk:Hatch cover

2012-04-04T22:34:48Z

Vasiln:

v0.34:Werebeast

2012-04-04T22:10:51Z

Vasiln: There are no non-werebeast werewolves in this version of DF. They have been replaced.

{{quality|Fine|18:41, 24 March 2012 (UTC)}}{{av}}

'''Werebeasts''' are a variant of [[night creature]] that are procedurally created during worldgen. [[Deity|Deities]] may curse sentient creatures to transform into an animal form on the night of a full moon. Creatures bitten by werebeasts are cursed to become werebeasts themselves.

The behaviour of vanilla werebeasts in worldgen (i.e. fleeing town upon being cursed and conducting raids from their new lair) appears to be caused by the cursed individual's beast form having the [NIGHT_CREATURE_HUNTER] tag; removal of this tag from a generated werebeast extracted from a world.dat file and jimmied into the standard raws caused those cursed to behave no differently from any other unnaturally-immortal individual.

==Werebeasts in Fortresses==

In some regions, the full moon will herald the attack of werebeasts upon your fortress, or instead the unwilling transformation of your own citizens into their bestial forms. The cursed will attack anyone they can find for the duration of the full moon, spreading their affliction even further.
Werebeasts of the same species will cooperate with each other and not normally fight, but those of different species will treat each other no differently than enemies.

==Werebeasts Abroad==

In adventurer mode, werebeasts are usually found living in small lairs on the edges of civilization. Young adventurers will often be called upon to slay them, with instructions along the line of 'he assumes a bestial form' along with a description of what type of metal they are vulnerable to. However, as long as they are not visited on the night of their transformation, they are just common peasants, and can be dispatched easily. It would behoove these individuals to hide themselves among townsfolk, but what can ya do?

The transformation to a Werebeast seems to only affect physical attributes, mental attributes are not changed. After transforming, the Werebeast has regrown all missing limbs and healed every injury, but all carried items will be dropped as soon as the beast enters a fight, making only the natural abilities of the creature available for combat. These abilities differ from creature to creature (Claws/Hooves/venomous Bite etc.)

User:Vasiln/150 tick repeater

2012-04-04T21:31:08Z

Vasiln:

{{diagram|spaces=yes|\
[#F00]P Power source
╔═╦[#F0F]*═╗ Return power
║ [#AAA]%[#FFF]%[#00F]7║ Return pump
║[#00F]7[#FFF]%[#AAA]%[#F0F]^║ Feed pump, output plate
║[#00F]7╠[#F0F]*═╝ Feed choke
╚═╝[#F0F]☼[#F00]P Feed power, power source}}

Keep in mind that this is a simplified side view for diagramming purposes. Actual build needs to take into account that the feed pump cannot be supported by the feed choke gear when that gear becomes disengaged. A floor must exist between the two pumps to prevent power transfer between the two. Use of pressurized water complicates the supply of power to the lower pump-- if having trouble, remember that screw pumps contain an impassable tile that can transmit power to adjacent structures.

Build order: Feed choke, return pump, return power, feed pump, feed power, output plate.

Linkages: Output plate to return power, feed power, feed choke.

Initial gear state: Feed power engaged, feed choke disengaged, return power disengaged.

At T=0, water falls onto the output plate.

T= 0: Output plate sends ''open'', feed power disengaged, feed doesn't pump, return power engaged, return pumps right-to-left, feed choke engaged.
T= 1: Output plans ''close'' for T=100, feed power disengaged, feed doesn't pump, return power engaged, return pumps but dry, feed choke engaged.
T=100: Output sends ''close'', feed power engaged, feed pumps, return power disengaged, return unpowered but pumping through T=148, feed choke disengaged.
T=101: No water on output, feed power engaged, feed unpowered but pumping through T=149, return power disengaged, return pumps through T=148, feed choke disengaged.
T=149: No water on output, feed power engaged, feed pumping through T=149, return power disengaged, return doesn't pump, feed choke disengaged.
T=150: Output sends ''open'', feed power disengaged, feed doesn't pump, return power engaged, return pumps, feed choke engaged. '''Same as T=0.'''

There are several interesting characteristics of this design.

* It utilizes build order to run water over a pressure plate without triggering that pressure plate.
* It takes advantage of the interval during which an unpowered screw pump will pump to create a 49 tick offset.
* It uses a gear combination that supplies power for exactly one tick when triggered with a ''close''-- and does precisely nothing when triggered with an ''open''.

Note that the last feature isn't necessary to the functioning of this repeater: simply running the lower pump continuously would garner you the same effect. However, for other designs (for example, a tripartite 50 tick repeater), being able to supply power for exactly one tick may be important.

User:Vasiln

2012-04-04T21:16:50Z

Vasiln:

User:Vasiln/150 tick repeater

2012-04-04T21:16:47Z

Vasiln: Created page with "{{diagram|spaces=yes|\ [#F00]P Power source ╔═╦[#F0F]*═╗ Return power ║ [#AAA]%[#FFF]%[#00F]7║ Return pump ║[#00F]7[#FFF]%[#AAA]%[#F0F]^..."

v0.34:Tracker

2012-04-03T23:05:21Z

Vasiln:

{{Quality|Fine|21:55, 30 December 2010 (UTC)}}
{{Skill
| color = 3:0
| skill = Tracker
| profession = Unknown
| job name = None
| tasks = None
| attributes =
* Unknown
}}
{{av}}

Tracker is a [[skill]] that, like [[Military tactics|military tactics]], is seemingly only used during [[world generation]]. It is not uncommon for historical [[migrant|immigrants]] to arrive with some level in the skill.

v0.34:Repeater

2012-04-03T19:53:17Z

Vasiln: other consistent delays for clock gen

{{quality|Exceptional|11:18, 8 March 2011 (UTC)}}{{av}}

A '''repeater''' is a device which creates a never-ending cyclic on/off signal-- more technically known as an oscillator. The simplest repeater design is simply a [[dwarf]] pulling a [[lever]] on [[repeat]]-- [[vampire]]s don't even need to take breaks from such a task. However, several automated designs are possible, and they can be made to operate at varying rates. They (usually) use fluid or creatures to trigger [[pressure plate]]s cyclically.

As a general warning, always have a way to turn off the repeater, and/or allow your dwarves later access for repairs or modifications.

===Wave repeater===
The simplest (non-borg) repeater is simply a wave traveling through a channel, as described in this [http://www.bay12forums.com/smf/index.php?topic=68659.0 forum] post.
{{diagram|spaces=yes|\
╔══════╗ ╔══════╗
║[#F0F]^.....║-->║[#0FF]7[#0FF]7[#0FF]7[#0FF]7[#0FF]7[#0FF]6║
╚══════╝ ╚══════╝
}}

A single 6/7 water tile flows through the channel, occasionally triggering a pressure plate set to trigger on 0-6/7 water. To get the right amount of water in it, it's simplest to fill it all the way, then designate it as a [[Activity_zone#Water_source|water source]] (and perhaps another location as a [[Activity_zone#Pit/pond|pond]]) until a dwarf takes away a single [[bucket]] full of water.

As designed (5 tiles of non-triggering water, 1 tile of triggering water), this setup triggers rapidly, on par with the repeaters described below. Counter-intuitively, making it smaller, or removing more water, slows the action of the repeater. This is because the pressure plate never gets a chance to recover from its triggering, for which it needs 100 ticks.

It's possible to make a design that can be easily started and stopped, even one that conserves water, but such systems are complex, when the beauty of this design is its simplicity. If it needs to be stopped for maintenance, one is probably best off simply dropping another bucket of water in it.

===Fluid logic repeater===
The traditional repeater design is probably this [[fluid logic|fluid]]-based one, described on the [http://www.bay12games.com/forum/index.php?topic=33563.msg495183#msg495183 forum] by [http://www.bay12games.com/forum/index.php?action=profile;u=16168 AncientEnemy]):

≈≈≈≈≈ - infinite source of water
═╗≈╔═ - wall to channel out after construction
╠F╣ - shutoff floodgate ''(linked to exterior lever)''
║#║ - 1-tile drawbridge (linked to pressure plate)
║p┼ - pressure plate (set to 7-7 water), and access door
╠F╣ - floodgate (linked to pressure plate)
╚═╝

So long as the shutoff [[floodgate]] isn't closed, [[water]] from an infinite source flows on to the pressure plate, causing the raising [[bridge]] to block access to the water source and destroy water in the circuit, while the opening of the southern floodgate compensates for the space taken up by this bridge. This water destruction mechanic means that, unlike many fluid logic circuits, this repeater needs no drainage. The single pressure plate works both to regulate the repeater, and as output.

This repeater toggles fairly slowly, about once every 300 steps, making it suitable for operating repeating bridges, floodgates, and [[Trap#Upright Spear/Spike|upright spikes]]. Off signals tend to follow on signals about 200 ticks later. As an added bonus, the southern wall can be removed and connected to a [[reservoir|cistern]] whose water level will be automatically maintained at a level between 3 and 4 deep-- perfect for [[swimmer|swimming]]!

For an alternate water-based repeater, consider the design at [[User:SL/Logic_Gates#Repeater]] which demonstrates a two level, hybrid repeater.

===Goblin repeater===
Designs based on [[creature logic]] are also possible. The following example is compact, reliable, and fairly predictable.

{{diagram|spaces=yes|\
╔═╗
═══╝[#FF0]¢╚══
[#F00]p[#FF0]¢[#FF0]^[#FF0]¢[#00F]¢[#F0F][#00F]^[#00F]¢[#F00]p
══╗[#00F]¢╔═══
╚═╝ }}

A captured goblin placed between the two pressure plates drives this system in his attempts to reach map edge through paths {{Raw Tile|¢p|#F00|#000}}. {{Raw Tile|^|#FF0|#000}} is linked to all {{Raw Tile|¢|#FF0|#000}}, and {{Raw Tile|^|#F0F|#00F}} is linked to all {{Raw Tile|¢|#00F|#000}}, as well as to output. This gives the goblin a path away from his constrained tile every 100 ticks. Delays in picking up path tend to make it run a cycle every 250 ticks. with on and off signals separated by about 120 ticks. Its rate of repetition can be doubled by hooking both {{Raw Tile|^|#FFF|#000}} to output, although this leads to close placement of on and off signals.

==Clock Generation==
Although the law of big numbers means that, over large enough intervals, the preceding irregular repeaters can be used to run a clock, designs that generate perfect clock signals are also possible.

This [[mechanical logic|mechanical]]-fluid hybrid repeater will send regular signals at a frequency determined by the speed of pressure plate recovery. The basic design consists of 4 [[screw pump]]s and 4 pressure plates but other versions are possible, depending on the number of separate steps you need.

{|
|-
|Level 0
|Level -1
|Level -2
|-
|{{diagram|color=#808080|
██████
██[#ff0]☼███
█[#00f]☼[#c0c0c0]☼[#c0c0c0]☼[#808000]═[#808000]═
███[#c0c0c0]☼[#f00]☼█
███[#0f0]☼██
██████}}
|{{diagram|color=#808080|
██████
█[#000]█[#0f0]÷[#008000]÷[#000]██
█[#008000]÷██[#0f0]÷█
█[#0f0]÷██[#008000]÷█
█[#000]█[#008000]÷[#0f0]÷[#000]██
██████}}
|{{diagram|color=#808080|
██████
█[#f00]^██[#0f0]^█
██████
██████
█[#ff0]^██[#00f]^█
██████}}
|}

{{Raw Tile|÷|#0f0|#000}}{{Raw Tile|÷|#008000|#000}} is a screw pump which pumps from the light side to the dark side. {{Raw Tile|^|#f00|#000}} is a pressure plate which disengages gear {{Raw Tile|☼|#f00|#000}} when water of depth 1-7 lands on it. The red, green, blue, and yellow pressure plates and gears are color coded only to show which is linked to which. In the game they'll all look like {{Raw Tile|^|#f0f|#000}} and {{Raw Tile|☼|#c0c0c0|#000}}. Building a pump after the gear which powers it or a gear after the pressure plate which disengages it will introduce a 1-step delay; so, depending on build order, the repeater might have a period between 400 and 408 steps. If the pumps, gears, and pressure plates are built in that order, then this system will repeat every 400 steps, exactly. Start the repeater by using a pond zone to dump 2 buckets of water onto any one of the plates.

The device as depicted uses 47-62 power during operation, and requires 62 power for startup. Drive train to power may, of course, lead to higher requirements. Once the two units of water are introduced to the system, water is conserved perfectly.

See [[User:MrFake/NStepCyclicRepeater]] for generalizable n-step clock generator instructions.

[[User:Hash/SelfPoweredHaltableRepeater]] demonstrates clock generation with integrated water [[water_wheel#perpetual_motion|reactor]].

[http://www.bay12games.com/forum/index.php?topic=34407.msg572324#msg572324 Forum thread] has more description and explanations.

[http://mkv25.net/dfma/movie-1370-pump-basedautorepeater DFMA movie] shows the action of pump-based clock generation.

===Delay===
Clock generation is closely related to the concept of delay: making a signal reach a target a certain amount of time after it is created. Any non-mechanical circuit introduces delay in a signal-- the simplest form of delay is an identity gate. The clock signal generator described above is unique in that it introduces a consistent delay. Any consistent delay can be used for clock generation. There are three known consistent intervals in Dwarf Fortress with which to fashion a clock signal generator: the reset delay associated with a pressure plate sending a ''close'' signal; the rate with which a creature [[gravity|falls]]; and the amount of time that a screw pump will continue to pump after losing power. Any (or all) of these delays can be involved in a clock signal generator.

{{Category|Constructions}}
{{Category|Computing}}

v0.34:Screw pump

2012-04-03T19:49:16Z

Vasiln: screw pumps pump after becoming unpowered

{{quality|Masterwork|21:05, 26 April 2011 (UTC)}}
{{Machine_component|name=Screw pump|key=s|job=[[Pump operator]]
|construction=
* [[Block]]
* [[Trap component#Enormous corkscrew|Enormous corkscrew]]
* [[Pipe section]]
|construction_job=
* [[Architecture]]
* 1 of
** [[Carpentry]]
** [[Masonry]]
** [[Metalsmithing]]
|power=Needs 10 power.
}}
{{av}}

A '''screw pump''' is a small [[building]] that can lift liquids ([[water]] or [[magma]]) from one level below onto the same [[Z-level]] as the pump. It is two tiles by one tile in size, and it can be either manually operated by a [[dwarf]] with the [[pump operator]] job or by being [[power]]ed by [[water wheel]]s and/or [[windmill]]s.

The direction you want the fluid to travel must be chosen at the time of construction. Pumping only occurs in a straight line, and involves a total of 4 tiles in a row - the liquid source, two for the pump, and the output. The "rise" in levels occurs on the first tile, the intake side, from one level below up to the level of the pump*. Pumped fluids can and will flow immediately after being pumped, as normal for that fluid. Pumped fluids will have a [[pressure]] equal to the exit [[z-level]] - a pump never "forces" water to a higher [[z-level]] than the output tile.

:''(* A DF pump can best be imagined as a simple [http://en.wikipedia.org/wiki/Archimedes%27_screw archimedes screw].)''

[[Water#Salt Water|Salt water]] pumped through a pump will desalinate and become drinkable, but only if the cistern has never contained salty water. [[Water#Stagnant Water|Stagnant water]] pumped through a pump will become clean, letting dwarves drink it without getting an unhappy [[thought]] and letting [[doctor]]s clean [[wound]]s without causing an [[Health care#Infection|infection]]. As with desalination, this only works if the cistern has never contained stagnant water.

''For a basic overview of how the different machine parts work and work together, see [[machine component|machinery]].''

== Construction ==

Building a screw pump requires an [[Trap component#Enormous corkscrew|enormous corkscrew]], a [[block]], and a [[pipe section]]. The construction itself is completed in two stages. First a dwarf with the [[architect]] labor must design it. Then a dwarf (the same or a different one) with the appropriate labor must complete the building. This could be [[carpentry]], [[metalsmithing]], or [[masonry]], depending on the material of the block.

To select pump, use keys {{k|b}}-{{k|M}}-{{k|s}}. It's important to choose the proper orientation for your pump, where it will draw water from and where it will deliver the water. This is determined before placement with the {{k|u}}, {{k|m}}, {{k|k}}, or {{k|h}} keys, and the text at the top of the sub-menu will change to confirm your choice. The default (as shown above in the sidebar), "pumps from the north" (top). The ''light'' green X must be next to the liquid source and the ''dark'' green X is where the liquid exits the pump.

[[Image:Small pump.jpg|thumb|right|300px|'''Basic Side View of a Pump'''. This pump "pumps from the west", from left to right. The area to the right may fill to the top of that level, but no more (See [[pressure]]; see [[Screw pump#Pump Stack|Pump stack]]). Note that the entire space required is 4 tiles long by 1 tile wide, not including any retaining walls for the outflow. If pumped manually, the [[pump operator]] stands in the light-colored area, as the dark-colored is impassable to both fluid and movement. ''(Although the "liquid" is shown as blue, this can work for [[magma]] as well, with the [[magma-safe|appropriate precautions]].)'']]

The example shown in the infobox above "pumps from the north" (top) to the south (bottom). If pumped manually, the dwarf stands on the light-colored tile, as the dark-colored is impassable.

The orientation is visible after placement by using {{k|q}}uery over or near that pump or during placement, using UMKH to select the direction of input. Orientation of a pump cannot be changed after being constructed, but, as with any building, it can be deconstructed into its component parts and rebuilt as and where desired.

Having specified the direction of travel, you must ensure that the source side of the pump is placed adjacent to and above (in the [[z-axis]]) a liquid. The screw pump will draw the liquid up from below its level, and distribute it out of the other side of the pump.

== Notes ==

* The source of the pump must be directionally adjacent to "Open Space" that is directly above a source of liquid. The adjacent space cannot be a floor, stairway or wall suspended over water. Screw pumps can pull water through a [[grate]], floor [[bars]], or a [[construction|constructed]] [[fortification]] on the Z-level below.
* The light pump tile is where a pump operator will stand (if the pump is not powered mechanically). Liquids to be pumped must be 1 level below the (empty) area adjacent to this tile.
* Dwarves must be able to access and stand on the light tile of the pump in order to build the pump and then to be able to operate the pump manually.
* The dark pump tile is on the output side. Liquids will appear in the tile adjacent to this.
* The dark pump tile blocks liquids flow and creature movement, and can be built between wall segments to create a solid barrier. The light tile of the pump does not block flow or movement.
* Pumps can also be used in conjunction with a [[water wheel]] or a [[windmill]] to become self-powered.
* Active mechanisms connected to the pump will automatically start the pump; to prevent this either restrict liquid flow using floodgates or hatches, or put in a [[gear assembly]] linked to a [[lever]] to disconnect the [[power]].
* Adjacent pumps ''automatically'' transfer mechanical power to any other adjacent pump(s); no [[axle]] or [[mechanism]] is required. If too many pumps are adjacent, there may be insufficient power to power them.
* Dwarves operating pumps do '''NOT''' generate power. Thus, one cannot use a single [[pump operator]] to power an entire pump stack.
* A hatch above the input tile (on the same level as the pump) that is linked to a trigger (a [[lever]] or [[pressure plate]]) makes an effective on/off switch for that pump.
* In order to build pumps in a "hanging" state, as in the stacked screw pump example (below), one of its tiles must be able to connect to a nearby machine, either already existing or designated to be built. If, when the screw pump's construction is completed, the supporting mechanism has not yet been completed, it will promptly collapse into its component parts.
* Pumps do '''not''' push liquids '''up''' additional Z-levels above them. They only deliver water to their own level. That is, if you direct the output of a screw pump into a 1-square space surrounded by walls, the water will not "overflow" the walls. Consequently, a pump will refuse to move liquid if the level it is pumping to is completely filled. Higher levels can be achieved using a "pump stack" (below). (See [[Pressure]])
* In order to safely pump magma, you must use [[magma-safe]] materials, though magma-unsafe metals have been observed to be safe unless the open tile is going to be submerged in magma. Wooden parts (except for [[nether-cap]]s) will burst into flames the instant the pump is activated, and magma-unsafe stone [[block]]s melt after a short time. Despite the requirement for magma-safe materials, the exterior of the pump does not heat up, and dwarves do not mind operating a magma pump directly.
* Magma, which normally has no pressure, will behave as though pressurized when pumped. For example, when pumped into an U-turn, magma will come out at the other end. Normal (non-pumped) magma would just pool at the lowest level. This may be either very useful (can be used to build pressure towers for magma) or deadly (forge level flooded with magma, because someone tried to pump magma into a volcano).
* Pump's pseudo-pressure doesn't work across diagonals. If there is a diagonal-only passage in your tunnel, liquids will seep slowly through it, instead of bursting through above their normal maximal speed, like they would if there was good passage.
* The liquid in a pump's intake tile must have a depth of at least 2/7 for the pump to be able to remove any amount of liquid from it.
* If a pump's intake tile on the z-level below the pump becomes blocked (e.g. cave-in, magma cooling into obsidian, or a sapling maturing into a [[tree]]) the pump will still run but not pump any fluid.
* If a pump's output tile contains magma and the pump is pumping water or vice versa, the output tile will be turned into [[obsidian]].
* Pumps operate in the reverse order in which they were built-- the most recently built will try to pump, then the next recent, and so on. You can use this to your advantage for [[mist]] generation, to maximize fluid throughput, or for advanced [[repeater]] design.
* Screw pumps continue to operate for a short period (49 ticks) after losing power-- that is, a screw pump supplied power for exactly 1 tick will actually pump for 50 ticks.

====Common mistakes====
* Orienting a pump incorrectly, and/or not having a proper open liquid source.
* Pumping water into an area with a path to other parts of your fortress. (The pump may work perfectly - the fortress quickly [[flood]]s.)
* Expecting water to rise up above the same level of a pump.
* Building a wall attached only to the light tile - this leaves a diagonal leak between the wall and the dark tile unless sealed there. (If that's not a problem, don't worry about it.)
* Having stairs as input tile. Stairs block input tile, thus rendering the pump useless, even though liquids usually ignore stairs. Output tile can be any liquid-passable tile.
* Not channeling below the impassable tile of an individual pump in a pump stack. This is how power is transmitted to the pump below.
* Pumping magma into a lower z-level (same as the source) and then being surprised it is forced back up to the pump's z-level further down the line (where you were planning your magma forges, for example.)

== Example layouts ==
=== Single pump ===

[[Image:jt_screwpump.png|frame|left|A screw pump delivers from the level below to the tile in front. This pump pumps from the right to the left. The "dark tile" would be on the left - that entire tile is impassible to movement and fluids.]] 
=== Pump stack ===
[[File:PumpStack2010.png|thumb|right|300px|'''Illustrated Side View of a Pump Stack.''']]
[[File:PumpStackTopView.png|thumb|right|300px|'''Illustrated Top View of a Pump Stack Layer.''']]
[[File:Pumpstack.gif|thumb|right|'''Animation showing the general construction using an isometric projection.''']]

A Pump stack is a method used to draw water or magma vertically across multiple z-levels requiring a minimum of parts. The basic functionality is possible because the Output (dark) side of the pump can be built over open space with a machine component located directly below, in this case another Screw Pump. Note that for power to properly transfer the intake (light) side of the pump must line up with the output (dark) side of the pump on the floor above it through a space in the floor, as in the illustration.

A pump stack minimizes the amount of machinery required to lift water or magma by allowing for power to be supplied directly to only the most accessible pump (typically the topmost) which in turn allows the player to operate a stack limited only by how many windmills/water wheels they can fit into the area. The price of optimal parts density is fragility: each pump relies on the pump below it for support. If [[forgotten beast|anything]] breaks a pump in your stack, every pump above it will be disassembled. This means that a single pump accidentally assembled with non-[[magma-safe]] parts can cause an entire magma pump stack to spontaneously disassemble.

Typical applications for a pump stack include moving magma from a lower level (often the [[magma sea]]) up to a convenient level for forges and furnaces, extracting water from a flooded fort, raising water for a decorative [[waterfall]] (and extracting it afterwards), or any other purpose that requires water/magma on a z-level significantly above its current location.

The Illustrated Top View of a Pump Stack Layer shows a basic section of a pump stack. Only the door (or a floodgate) on the Containment side is strictly necessary in order to prevent flooding. Two doorways are used here, each lining up with the solid ground within the pump assembly, in order to prevent workers from trapping themselves after digging channels or assembling the pump.

Be warned: pump stacks move water '''fast.''' If you are pumping from a large reservoir into an open area, be prepared for a huge outflow, roughly akin to the kind of water dump you'd get if the whole reservoir was balanced above the pump output and then released. If you are using pumps to empty a large underground reservoir (or, say, a flooded fortress) onto open land, use an aqueduct or some other method to make sure the pump system outlet is a good distance away from anything you wouldn't want to get drenched.

As an alternative to a large reservoir, it is also possible to combine a [[Dwarven Atom Smasher]] with the top layer of the Pump Stack to create a "vacuum cleaner" of sorts.

====Tips====

* Ramps can be used in place of channeling. Liquids will transmit through ramps, unlike stairs, and when pumps are constructed they annihilate the ramp they're built on much as walls do. Power will still be transmitted, so they don't need to be removed by miners prior to pump construction. Ramps make it virtually impossible to strand your miners and allow the stack to be dug out using only access doorways on the intake side of the pump, so no construction or doors are later needed to eliminate leaks. A pump stack can be very rapidly carved out with this method as even if a miner/builder is trapped on the containment side of a pump, they can walk up the ramp to the intake side of the pump above and walk out.
* Power can be transmitted to the stack by channeling out the tile directly above the intake (light) tile of the topmost pump and mounting a gear assembly. If the gear assembly is supported by an adjacent gear assembly or horizontal axle on a stable floor (be careful to not have that adjacent gear assembly disengage via lever), this will allow the stack to hang from the gear assembly. If a lower pump needs to be removed, or should self-destruct, the problem of the entire pump stack disassembling described above is eliminated. Further, if the supported gear assembly is built first, the pump stack can be built both from the top and bottom simultaneously, halving construction time, assuming that sufficient attention is paid to make sure that the pumps will align with the proper orientation when the two partial stacks meet. Properly channeling/ramping out the stack should ensure this.
* When pumping water, make sure all tiles on the containment side of the stack are covered with a [[construction|constructed]] floor or [[fortification]] to prevent subterranean trees from growing and blocking flow of the stack. Fortifications have the added advantage that, when used with water, they will never become muddy.
* When using pumps to empty a large body of liquid, make sure that the pump output is properly isolated from the intake, otherwise the liquid can flow backwards into the pump's walkable tile and cause problems (such as flushing the dwarf operating it into the body of liquid being drained).

===Improved Magma Pump Stack===

Because a pump stack pumping magma is known to cause significant [[Maximizing_framerate|lag]], a [http://www.bay12forums.com/smf/index.php?topic=72296.0 new type of pump stack] was developed by [http://www.bay12forums.com/smf/index.php?action=profile;u=19835 NecroRebel] that causes a much smaller drop in [[FPS]]. Changing the single tile magma chamber at the output of every pump from a 1 by 1 to a 3 by 3 area reduces the lag to 1/15th of that caused by the original pump stack. The designer hypothesizes that the larger chamber requires many fewer temperature calculations when magma is pumped in or out; that also implies that there will be no improvement for water pumps.

====Newer Magma Pump Breakthroughs====

Newer breakthroughs in magma pump design has since made the 3x3 reservoir design obsolete.
NecroRebel has tested a [http://www.bay12forums.com/smf/index.php?topic=72296.msg1772802#msg1772802 1x3 head-over-tail variation] (which is very similar to [[Screw_pump#Pump_stack|the typical 1 by 1 pump stack]]) as well as a [http://www.bay12forums.com/smf/index.php?topic=72296.msg1795907#msg1795907 2x3 head-over-head variation]. Both of these new designs require less space and work as effective as his original 3x3 reservoir head-over-head design, with no significant drop in FPS. The 1x3 head-over-tail design has the advantages of requiring the least amount of space and being simple to refit from the standard 1 by 1 water pump stack.

{{buildings}}

User:Vasiln/Build order

2012-04-03T19:47:07Z

Vasiln:

I once did some careful examination of a creature triggering a pressure plate linked to various buildings built either before or after the pressure plate. I added those findings to the [[pressure plate]] page. However, some of the things I found felt inconsistent with [[User:Hussell|Hussell's]] findings regarding build order. In particular, he found that build order of [[gear assembly|gear assemblies]] affected the period of his [[repeater]]s, whereas I found that gear assemblies were always triggered on the same tick, regardless of whether they were built before or after the triggering pressure plate. Also, I found that the delay of pressure plates was 99 ticks, rather than the traditionally accepted 100.

These findings have always kind of bothered me, but I think I have a hypothesis that explains it.

==The Grand Unified Hypothesis of Build Order==

Every tick, the game evaluates every creature and building in sequence. Here's the order in which it does so (according to my hypothesis):

*1) Every creature checks its [[speed]] to determine whether it can move to the next tile in its path. If it can, it moves. If its next tile is occupied or inaccessible, it recomputes path.
*2) Every tile of fluid is evaluated to determine whether it should flow or teleport, and if it should, it does.
*3) Every variable-state building is evaluated (more on this later).
*<s>4) Every tile of [[water]] is evaluated to determine whether it should flow (or maybe teleport), and it does so, if it should.</s>

The important part of this is step 3. In particular, buildings are evaluated in the reverse order to which they were built. If you build a pressure plate, then a [[door]], the game will first run the door's ''think'' function, then run the plate's ''think'' function.

Here are the ''think'' functions for various variable state buildings, as far as I can tell:

====Door====
*If a ''close'' signal has been generated for this door, close the door.
*Note that the door doesn't itself evaluate ''open'' signals!
====Pressure plate====
*If triggering criteria are met, and the device most recently sent a ''close'' signal, send an ''open'' signal. Additionally, open any doors or [[hatch cover|hatches]] linked to this pressure plate, and toggle <s>any linked gear assemblies</s> the '''appearance''' of any gear assemblies, making them show up as engaged or disengaged.
*If triggering criteria are met and the device most recently sent an ''open'' signal, don't do anything, except remember this tick.
*If triggering criteria are not met, and it has been exactly 100 ticks since triggering criteria were last met, send a ''close'' signal. Additionally, toggle <s>any linked gear assemblies</s> the '''appearance''' of any linked gear assemblies.
*If triggering criteria are not met, and it has been greater than or less than 100 ticks since triggering criteria were met, don't do anything.
====Bridge====
*If no open or close is scheduled for this device, check for a signal. If ''open'', schedule an open in 100 ticks. If ''close'', schedule a close in <s>99</s> 100 ticks.
*if no signal, or an open or close is already scheduled, don't do anything.
====Screw Pump====
*If the pump is adjacent to a powered gear assembly, there is fluid in its intake tile, and there is no fluid in an acceptable output tile, destroy the water in its intake tile and generate an equivalent amount of water in the first acceptable output tile.
*Otherwise, don't do anything.
====Gear Assembly====
*If an ''open'' or ''close'' has been generated by a device linked to this assembly, toggle the actual state of this assembly (not the apparent state, which is managed by the pressure plate).
<s>*If gear assembly is adjacent to a device with power and is engaged, consider this tile powered.</s>
<s>*If gear assembly is not adjacent to a device with power or is not engaged, do not consider this tile powered.</s>
<s>*Note that gear assemblies do not evaluate signals!</s>
====Other Furniture====
I believe that the think functions described earlier apply to all other forms of furniture. Hatches use the same think function as doors. Grates, bars, and floodgates use the same think function as bridges. <s>[[Lever]]s require a special note: I believe they function the same way as a pressure plate. However, there's a chance that the dwarf pulling them actually sends the signals, in which case you would expect to see levers functioning as if they were always built before the furniture they trigger.</s> Levers do not function like other furniture! It is the dwarf that sends open and close signals, rather than the furniture, which means that signals from levers are always evaluated before any other buildings. Levers automatically open doors and toggle gear assemblies, since those are not functions of the furniture themselves.

===How this reconciles Hussell's clock and my goblin repeater===
This model of build order demonstrates how a gear assembly can both be engaged at the end of a tick, yet a pump attached to that gear assembly may or may not yet be powered, based on the order in which the two components were built. That disconnect between my data and Hussell's been bothering me, and this hypothesis explains both results.

==Predictions==
Now that I've got a working hypothesis (including bits that I'm not very sure of, for instance, exactly when non-dwarves are evaluated, exactly how power is evaluated, exactly when flow is evaluated), it's time to make some predictions.

===Formulating data===
====200-step repeater====
Let's examine the behavior of Hussell's [[user:Hussell/ClockRepeater|200 step repeater]] in terms of my theory. Reprinted here:
{|
|-
|Z-level +1
|Z-level 0
|Z-level -1
|-
|
{| cellspacing=0 cellpadding=0 style="font-family: 'Courier New', monospace; font-weight: bold; font-size: 135%; color: #808080; background-color: #808080"
|-
|█
|█
|█
|█
|█
|█
|- {{c||0}}
|{{c||8}}|█
|{{c|0}}|█
|{{c|2}}|%
|{{c|a}}|%
|{{c|0}}|█
|{{c||8}}|█
|-
|█
|█
|{{c|c|0}}|*
|█
|█
|█
|-
|█
|{{c|7|0}}|>
|{{c|7|0}}|*
|█
|█
|█
|-
|█
|█
|█
|█
|█
|█
|}
|
{| cellspacing=0 cellpadding=0 style="font-family: 'Courier New', monospace; font-weight: bold; font-size: 135%; color: #808080; background-color: #808080"
|-
|█
|█
|█
|█
|█
|█
|- {{c||0}}
|{{c||8}}|█
|{{c|0}}|█
|{{c|a}}|%
|{{c|2}}|%
|{{c|a}}|^
|{{c||8}}|█
|-
|█
|█
|{{c|a|0}}|*
|{{c|7|0}}|┼
|█
|█
|-
|█
|{{c|7|0}}|X
|{{c|7|0}}|*
|█
|█
|█
|-
|█
|█
|{{c|6|0}}|║
|█
|█
|█
|}
|
{| cellspacing=0 cellpadding=0 style="font-family: 'Courier New', monospace; font-weight: bold; font-size: 135%; color: #808080; background-color: #808080"
|-
|█
|█
|█
|█
|█
|█
|-
|█
|{{c|c|0}}|^
|█
|█
|█
|█
|-
|█
|{{c|7|0}}|┼
|█
|█
|█
|█
|-
|█
|{{c|7|0}}|<
|█
|█
|█
|█
|-
|█
|█
|█
|█
|█
|█
|}
|}

Just to clarify, pressure plates trigger on 2+/7 water, and are linked to the gear assembly of the same color. Device is built in the following order: first the upper pump, then the lower pump, then the gear assemblies, then the pressure plates. Beginning state has 7/7 water in the left-hand reservoir, both gears disengaged. At t=0, we engage the green gear via lever. Let's examine, ''in order'', the events happening during important ticks.

In a previous version of this page, I got everything wrong about this sequence. Rather than strike-out a bunch of stuff, I've just replaced it-- you can always look at the revision history if you want to see my embarrassing mistakes.

T = 0: Lever sends ''open''. Red plate has water on it, but did last tick as well: no signal. Green plate has no water, no signal. Green gear assembly engages in response to ''open''. Lower pump pumps left-to-right.
T= 1: Red plate deactivated, schedules close for T=100. Green plate has water, sends ''open''. Green gear assembly disengages. Lower pump unpowered (but will continue to pump through T=49). Upper pump unpowered.
T =100: Red plate sends ''close''. Green plate has water, but previously activated. Red gear assembly engages. Lower pump unpowered. Upper pump powered, moves water right-to-left.
T =101: Red plate dry (water needs to fall onto it). Green plate dry, schedules ''close'' for T = 200. Lower pump unpowered, upper pump powered.
T~=120: Water falls onto red plate. Red plate sends open. Green plate dry. Lower pump unpowered. Upper pump unpowered, but will continue to pump through T~=168.
T =200: Red plate previously activated. Green plate sends ''close''. Green gear assembly engages. Lower pump powered, moves water left-to-right. Upper pump unpowered. '''Same as T=0.'''

In the previous version, I underestimated the time it took pressure plates to reset. I'm embarrassed about that, and it led me to a quixotic search for a 100 tick repeater that wasted a lot of my energy.

====Pressure plate trigger data====

Here, I'm just going to link you to http://mkv25.net/dfma/movie-2363-timingdetails.

<s>Actually, on reviewing that, it doesn't necessarily demonstrate what I want it to. This could be due to imperfect frame-by-frame capture for movies, or it could be because I screwed up. I will have to confirm.</s> Yes, it does demonstrate the effects, you just have to slow it down to a rate below 1 to see all of the frames.

====Dropping a dwarf takes 7 ticks====
Creatures fall at a constant rate of 6 ticks. However, when you drop a dwarf, it takes 7 ticks for the dwarf to fall the first z-level. This, according to my hypothesis, is because the dwarf doesn't know the ground isn't there during the tick the floor disappears, because the ground doesn't disappear during the dwarf's ''think'', it disappears later, during the hatch's ''think''. '''But see the caveat below!'''

===Testable Predictions===
====Screw pumps and pressure plates====
The following design, seen from the side, can behave multiple ways, depending on build order.

# %% # Return pump
# %%^# Feed pump, plate (1+/7 water)
# #### 7/7 reservoir
###

*1) Build return, feed, then plate. Plate doesn't trigger. Water is moved first from the feed, then to return, and stays in the reservoir.
*2) Feed, return, then plate. Plate doesn't trigger first tick, but triggers on the next tick. Water is moved first from the return, then the feed, and so stays on top of the pressure plate.
*3) Return, plate, then feed. Plate triggers, although water remains in the reservoir.
*4) Feed, plate, then return. Plate doesn't trigger, although water remains on top of the plate.
*5) Plate, return, feed. Plate doesn't trigger, and water remains in the reservoir.
*6) Plate, feed, return. Plate triggers, and water stays on top of the plate.

Those are the predictions. Time to test!

=====Findings=====
I forgot to take gravity into account in my predictions. Water takes a certain amount of time to fall, and until it falls fully into the reservoir, it cannot be pumped back by the feed. This changes where we expect water to sit, but it doesn't change our predictions regarding pressure plate activation.
*1) Plate doesn't trigger. Water stays in the reservoir side. Meets predictions.
*2) Plate triggers. Water stays mostly in the reservoir side. That's because it takes time to fall to get pumped by the feed again. I missed the first tick, can't say whether it only triggered on the second tick.
*3) Plate doesn't trigger. Doesn't meet predictions. Will rebuild to verify.
*4) Plate triggers. Doesn't meet predictions. Will rebuild to verify.
*5) Plate doesn't trigger.
*6) Plate triggers.

Note that both feed and destination tiles are muddy. I'll DFHack unmuddy them to see if water is actually never touching a the ground on the machines.

After rebuild, 3 triggers, and 4 doesn't trigger. I figure I screwed up build order originally. Note that it doesn't look to me like Hack can unmuddy specific tiles, so I didn't test that.

So far, so good. Predictions are as expected.

====Levers====
Next prediction is regarding levers. I anticipate that levers behave the same way as pressure plates in regards to build order. Those predictions are established on the pressure plate page, and my hypothesis tells me to expect them. I'm going to test bridges, doors, and gear assemblies (as those represent the three build types in my hypothesis). Note that it's hard for me to establish exactly when a lever is activated, so I'm instead just going to compare the open and close signals of furniture built before and after the lever.
*1) Both doors open at the same time, but the door built after the lever closes 1 tick later.
*2) Both gear assemblies open and close at the same time.
*3) The bridge built earlier opens and closes 1 tick before the bridge built later.

=====Findings=====
Findings did not meet predictions. Buildings responded identically, regardless of build order.
*At tick=-1, there is an active "pull lever" job at the lever.
*At tick=0, there is no active "pull lever" job. Doors open or close, and gears engage or disengage.
*At tick=100, bridges open or close.

There are two interesting parts to this finding. First, lever signals are being evaluated before all other signals-- I believe it's happening in the dwarf phase, with completion of the lever pull task. <s>Second, open and close signals are being acknowledged by bridges at the same time-- 100 ticks after receipt of signal. Is there some way to rectify this with the behavior of bridges linked to pressure plates?</s> Of course there is-- it is the 99 tick delay associated with pressure plates that is responsible for the 199 tick closing of bridges, not the bridges themselves.

====Gear assemblies====
Consider the following machine:
# %%*# Return pump, return gear
#*%%^# Feed gear, feed pump, plate (1+/7 water)
# #### 7/7 reservoir
###

Both gears begin disengaged, linked to a lever that has just been pulled (t=-1, queued pull job; t=0, no queued job)

We expect that power won't be transferred to pumps on the tick it's received by a gear assembly '''unless''' that gear assembly is built after the pump to which it's transferring power.

*1) Build plate, then feed pump, return pump, feed gear, return gear. Both pumps are in operation on the first tick (t=0), and feed pumps last. Plate triggers on t=0.
*1.1) Build plate, then feed pump, return pump, return gear, feed gear. Exactly as with 1).
*1.2) Plate, feed pump, feed gear, return pump, return gear. Exactly as with 1).
*2) Plate, then return pump, then feed pump, return gear, feed gear. Both pumps operate at t=0, but return pumps last. Plate doesn't trigger.
*2.1) Plate, return pump, feed pump, feed gear, return gear. Exactly as with 2).
*2.2) Plate, return pump, return gear, feed pump, feed gear. Exactly as with 2).
*3) Plate, return gear, return pump, feed pump, feed gear. On tick 0, feed is powered and return is not. Plate triggers on t=0. At t=1, return gear activates, plate sends ''close'' at t=99.
*4) Plate, feed gear, feed pump, return pump, return gear. On tick 0, return is powered and feed is not-- no trigger at t=0. At t=1, feed becomes powered, and plate triggers.

I'm not going to test 1.1, 1.2, 2.1, or 2.2. I will test the others. Particularly notable is the behavior of 3.

=====Findings=====
Initial findings were flawed. 1, 2, and 4 behaved as predicted, but 3 didn't-- in fact, it never activated the plate at all. Tearing down and rebuilding, even rebuilding gears earlier in the power supply, didn't change anything. In fact, the strange behavior of 3 makes me distrust what I saw with 4-- maybe I didn't look carefully enough?

====Gear assemblies revised====
What does this mean? Could it be because I turned power on with a lever? That would suggest that gears do manage their own signals in a way. What if I do a pressure plate activated gear, built before the plate that activates it, but after the pump it powers? Something like,
*
# %% #
# %%^#
# ####
###

Okay, build return pump, feed pump (independently powered), plate, gear. 1) Gear starts out inactive. Plate doesn't trigger. Feed moves water. Return doesn't function. 2) Gear is inactive. Plate triggers. Feed has nothing to pump. What does the return pump do? Pump, or not? If it does not, then the plate was unable to activate it this tick. I know that the gear appears active at the end of the turn, but that doesn't mean it functions.

=====Findings=====
What actually happens: Tick 1: feed works. Tick 2: Return doesn't pump. Tick 3: Return pumps.

So the trick is that gear assemblies '''look''' like they toggle without regard to build order, but build order still affects whether they actually transmit power or not.

====Water flow====
This is a simple one, and I'm going to use Hack to test it.

# ## 7/7 water
# ^# 7/7 water, 0/7 water and plate that triggers on 2+
####

Predicted: Plate does not trigger on first tick, but triggers on second tick.

=====Findings=====
Water doesn't teleport on the first tick-- it takes a few frames. When the water lands on the plate, the plate triggers immediately, rather than at the next tick. This suggests that water moves before buildings are evaluated.

====Mutual Lever Drop====
So I started thinking about when exactly hatches open, since build order doesn't affect them, and think I came up with a good way to see if they open in the triggering device's turn. We design a simple drop system, where a lever controlled hatch drops a dwarf a z-level. The thing is, we get two dwarves, and we let them drop each other using this method. If levers are evaluated in the dwarf phase, and hatches open when triggered (not later in the tick), then one dwarf, later in the dwarf queue, will take 6 ticks to fall, and one dwarf, earlier in the dwarf queue, will take 7 ticks to fall. It's totally important to only let two dwarves into the system-- '''who''' pulls the lever might be a determining factor for how long it takes the dwarf to fall!

=====Findings=====
Yup, sure enough, it takes a different amount of time, depending on who pulls the lever. When a dwarf that has arrived more recently pulls the lever dropping a dwarf that has arrived earlier, it takes 6 ticks. When the earlier dwarf drops the later dwarf, it takes 7 ticks. This suggests:

*Dwarves are evaluated in a last in, first out method, similarly to furniture.
*Lever signals are sent during the turn of the dwarf who pulls the lever.
*Hatches (and presumably doors as well) open '''immediately''' upon an ''open'' signal, rather than waiting for the hatch to evaluate that signal.

Very interesting.

v0.34:Giant otter

2012-04-01T03:43:16Z

Vasiln: hmm, somehow got missed