Dwarf Fortress Wiki - User contributions [en]

Talk:Building destroyer

2026-07-04T08:04:19Z

CaptainTofu: Screenshot for bridge destruction

Updated article: Building Destroyers can destroy bridges. Screenshot available but uploading a jpeg is considered a "harmful action". Uploaded it to my steam profile.
https://steamcommunity.com/sharedfiles/filedetails/?id=3757310242

Building destroyer

2026-07-04T08:01:47Z

CaptainTofu: Corr.: Raised bridges can be destroyed. Screenshot available but DF Wiki detects uploading a jpg as "harmful action". See discussion.

{{migrated article}}
{{Quality|Unrated}}
{{av}}
{{Catbox}}
'''Building destroyers''' are creatures with the {{token|BUILDINGDESTROYER|c}} token and will actively seek out various [[furniture|furnishings]], [[workshop]]s and other [[building]]s and topple or destroy them. Uncompleted [[construction]]s are [[Construction#Destruction|vulnerable]], but completed ones are not. They come in two varieties, the first being annoying, and the second dangerous. Most buildings will be "toppled" (deconstructed), leaving the building material or furniture unbuilt but otherwise unharmed, however [[door]]s, [[hatch cover]]s, and [[floodgate]]s will be damaged until destroyed, not deconstructed.

Creatures with this tag are gifted with an incredible ability to sense exactly where your buildings are, and will generally charge a building from 10 tiles away, with the exception of forgotten beasts and (semi-)megabeasts. 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 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 nearly '''all''' types of buildings they can reach, whether or not they block their path - [[door]]s, [[floodgate]]s, [[hatch]] covers, vertical/horizontal [[bars]], floor/wall [[grate]]s, [[statue]]s, [[workshop]]s, and even furniture are vulnerable.{{verify|Are all buildings are still targeted in current ver?}} The only buildings that will be spared by a building destroyer are [[well]]s, [[road]]s, [[trap]]s (including [[lever]]s and track stops), [[animal trap]]s, [[chain]]s, [[cage]]s, [[stockpile]]s, [[Trap#Upright Spear/Spike|upright weapon]]s, and any buildings submerged in 4/7 or deeper [[Water#Depth|liquid]] (even if they're innate swimmers). They can destroy most furniture and buildings from a lower [[z-level]] when a valid path exists to that furniture, though locked hatches and closed grates are safe as long as no alternative paths exist. 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. Note that building destroyers can destroy raised [[bridge]]s but tend to prioritize choosing am unblocked path, even if it includes building constructions.

==Destroying from underneath==

Building destroyers cannot destroy buildings unless they can path to the building on the z-level of the building. 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 '''unless''' a clear alternate path to the building exists. If such a path exists, they do not have to follow it; they can destroy the building from the z-level below while standing on a ramp or stairs that leads up to the building's z-level.

Consider the following diagrams, as viewed from the side:
{|
|{{diagram|spaces=yes|\
╔════
═╝ [#0FF]┼
[#F00]B▲╔══
═══╝
}}
| style="padding: 1em" |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▲╔══
═══╝
}}
| style="padding: 1em" |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▲╔══
═══╝
}}
| style="padding: 1em" |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▲║▲
═══╩══
}}
| style="padding: 1em" |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║
║< <║
╚══════╝
}}
| style="padding: 1em" |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.'''
|}

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 in which 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.

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

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

==<s>Dangerous</s> Fun Variety: level 2==
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. A [[bridge|drawbridge]] will act like a constructed wall ''(if up)'' or floor ''(if down)'', blocking building destroyer 2's without that danger of being destroyed.

Tame animals still carry their building destroyer tokens, and have been observed to occasionally topple a statue.

'''[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|HFS creatures]]
*All [[Experiment]]s
*[[Werebeast]]s (in werebeast form only)

Level 2 building destroyers can destroy chairs, beds, tables, coffins, non-empty farm plots, furnaces, trade depots, shops, doors, floodgates, chests, weapon racks, armor stands, workshops, cabinets, statues, glass windows, gem windows, siege engines, archery targets, your embark wagon, screw pumps, unfinished constructions, floor hatches, wall/floor grates, wall/floor bars, gear assemblies, horizontal/vertical axles, water wheels, and windmills.

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

==Capture==

Considering a good part of the building destroyers are useful to capture, and that most of them are not trapavoid, you can easily trap them with the right arrangement of cage traps, furniture and walls.

See [[Trap design]] for more information on this subject.

==Undead==
All [[undead]] building destroyers are level 1 (except if they are undead versions of level 2 destroyers), and they also gain the ability to destroy wooden [[support]]s, which generally ends poorly for the creature.

Due to the way undeath is classified, "non-living" creatures such as [[magma man|magma men]], [[bronze colossus]]es, and inorganic [[forgotten beast]]s/[[titan]]s are also considered to be undead.{{verify}}

==Bugs==
* Building destroyers can, and will, 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, and they can become stuck if they start destroying the building while adjacent. This can be a result of a fight, for instance when a Forgotten Beast kills the last defender while standing in such a spot, then it won't move to a better suiting position and will stand idling, unless killed or distracted.

{{Category|Creature attributes}}
[[ru:Building destroyer]]

Garbage dump

2026-06-28T11:35:46Z

CaptainTofu: dumping command does not affect worn/held items

{{Quality|Superior}}
{{av}}
{{projects}}
'''Garbage dumps''' are [[activity zone]]s in or from which dwarves will throw items marked for dumping.

[[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]].]]Garbage dumps are ''not'' the same as [[Refuse#Refuse|refuse]] stockpiles.
* Refuse stockpiles can be designated to accept specific type(s) of refuse, such as animal [[corpse]]s or [[bones]], and then are automatically filled by haulers whenever the items appear on the map.
* Garbage dumps don't have categories - dwarves will dump any items marked to be dumped, '''including objects of value!'''

Garbage dump zones are useful for many things beyond [[garbage disposal]]; they can create [[quantum stockpile]]s, transport materials to a job site, send items to the [[trade depot]] when no caravan is present, [[trap design#Falling_debris_trap|drop rocks]] on enemies below, and numerous other uses. Also active garbage dumps seem to increase the likelihood of vermin, which are usually encountered near food and refuse stockpiles (ie. rats, hamster, but also - in good biomes - fluffy wamblers), to be created nearby.

=== Create garbage dump ===
To place a garbage dump, select zone ({{menu icon|z}}), then Garbage Dump, paint your desired shape, either on a flat area or next to a cliff or hole, and click Accept. After accepting the placement, the zone can renamed, repainted, suspended, or deleted.

If the dump zone is designated next to a [[cliff]] or hole, the items will be dropped off the edge; otherwise they will be dropped on a tile in the zone. Note that, like [[Water source|water sources]], the dump zone must be designated '''adjacent''' to a cliff for dwarves to dump items off of it, ''not'' directly above it. Although each ground tile within that zone is considered a garbage dump tile, dwarves can drop multiple items on a single tile, usually the closest tile when they path to the zone.

Most items dropped in magma will be destroyed, and items dropped in a river may get washed downstream; in either case the items will be very hard to recover (''ergo, best not to do either of those in the first place'').

=== Marking items to dump ===
To mark an individual item for dumping when it is:
* On the '''ground''': Click the tile the item is on, then if there is more than one item there, click the tab of the item on the right edge of the sheet window, and click the dump button ([[File:Button dump.png]]).
* In a '''workshop''': Click one of the tiles the workshop, find the item in the list of items in that workshop (which may not be viewable if the UI is scaled to large), and click the dump button.
* '''Held''' by a dwarf: View the dwarf's sheet, select the Items tab, find the item in the list, click the button to view the item's sheet ([[File:Mag glass icon.png]]), and click the dump button.
* Inside a '''container''': Display the container's item sheet, find the item in the list of items in that container, and click the dump button.
* In the '''stocks''' menu: Type {{k|k}} or click the Stocks button, then either:
**click the filter input at the top and enter text to match the item, and when you see the item, click the dump button.
**select the item category, scroll to the item, and click the dump button.

To mark multiple items for dumping:
* As above in the Stocks menu, but click the dump button for a group of items.
* Use bulk designation {{menu icon|i|p}}
'''NOTE:''' Bulk dumping designates ''all'' items on the tiles for dumping, even built [[furniture]], the construction materials making up buildings, items inside [[Storage|container]]s, etc. The only exceptions are items worn or held by a creature. In the case of built furniture and building components, this will have no immediate effect; however, upon deconstruction the item will immediately be dropped on a nearby square by the dwarf hauling the item to await disposal in the nearest dump.

=== Moving items to dump ===
[[File:garbage_dump_preview.png|right]]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]].

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. If a garbage dump is located next to open space, dwarves will always stand on a garbage dump square when dropping ''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 and [[pasture]]s.

Dwarves will ''not'' dump items that are in a tile marked "Above Ground" unless you allow them to in [[Standing orders]].

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.

'''NOTE:''' If you designate items for dumping, but forget to mark an active garbage dump, your dwarves will ignore the item until an active garbage dump is marked.

=== Reclaim dumped items ===
Dumped items are automatically marked as [[forbid]]den, preventing dwarves from touching them. Therefore, these items can't be used, or even selected in workshop jobs, etc.

If, for some reason, [[Urist]] is yet again incapable of locating their favorite pair of cave troll [[leather]] [[sock]]s, they should think to look among the black hole of matter that is the nearest garbage dump, as the socks could be snugly lodged between a few billion rocks.

You can reclaim dumped/forbidden items in the same ways as in [[#Marking items to dump]] section above, except clicking the forbid button ([[File:Button forbid active.png]]).

===Dwarves won't dump no matter what I do===

Dumping items requires the '[[refuse hauling]]' labor. Items located in an "outside" tile will not be moved unless 'gather refuse from outside' is enabled in your [[Standing orders]]. Probably due to a bug, dwarves occasionally ignore items that are meant to be dumped; toggling forbid and dump status on, then off again seems to correct this problem.

=== Strategy ===
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 ({{menu icon|i|F}}) 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.

==See also==
*[[Garbage disposal]]
[[ru:Garbage dump]]

{{Zones}}
{{Category|Zones}}

Minecart

2026-06-21T06:08:43Z

CaptainTofu: /* Hauling route */ Added a trouble shooting note about temperature setting and softlocked minecarts

{{Quality|Masterwork}}
{{av}}
{{old}}
[[File:minecart_sprite_preview.png|right]]A '''minecart''' is a [[tool]] intended for [[hauling]]. It can be made of [[wood]] at a [[carpenter's workshop]] or 2 bars of [[metal]] at a [[metalsmith's forge]] (using the [[Blacksmith|blacksmithing]] labor.) Minecarts store up to five times as many items as [[wheelbarrow]]s and are quite a bit faster than dwarves hauling objects by hand, but have the disadvantages of requiring a dedicated track network, a complex route planning phase, and the possibility of dwarves [[Fun|blundering into the path of carts filled with lead ore]]. Tracks may be carved into stone, or [[Construction|constructed]]; the latter allows above-ground routes, but these are more difficult to set up due to their additional [[building material|material requirements]].

Just like wheelbarrows, minecarts are considered [[item]]s and are stored in a [[furniture]] [[stockpile]]. Despite their five-times-greater capacity, they are only 33% larger than wheelbarrows (minecarts have a [[size]] of 40,000 cm³) and are identical in base [[item value|value]] when made from the same [[material]] (the value may differ due to the [[item quality]]). [[thief|Thieves]] or even mischievous animals can steal minecarts, even when they are moving on a track.{{cite forum|109460/3289070}} However, minecarts moving fast enough or being ridden cannot be stolen.

The invention of minecarts revolutionized the [[minecart logic|Science of Dwarfputing]] by enabling smaller, faster logic systems to be built.

== Basic Minecart Usage ==
[[File:Leitnagel Hund.png|thumb|Minecarts]]Minecarts can be used to swiftly transport dwarves, [[flow|fluids]], and/or large amounts of items, but before you have a functional minecart, there are several preconditions that need to be met. First of all, you need an actual minecart, constructed either in a [[carpenter's workshop]] or [[metalsmith's forge]]. For the minecart to be able to move, you also need to carve (with {{Menu icon|v|t}}) or construct (with {{Menu icon|b|n|k}}) a track, which could be as simple as a straight line. Finally, you need to construct stops on your track (with {{Menu icon|b|n|K}}) where the minecart will start and stop.

After you have created the stops and assigned a cart to the track, you must create logic routes connecting several stops and designate starting conditions for each stop by selecting the stops for the minecart, take note to designate the tiles where your minecart will physically stop. This is done with the {{Menu icon|h}} hauling key. The most basic conditions are how the cart's movement is initiated and in which direction the cart should start moving. Carts can be either pushed (a dwarf stands at a stop and gives the cart a single push) or guided (a dwarf continually pushes the cart forward, guiding it along the track). The [[hauling]] [[labor]] required for pushing and guiding carts is called "Push/Haul Vehicles" and is turned on by default.

To control which items are to be transported, you can add conditions specifying: (1) which kind of items are to be loaded and unloaded, (2) stockpile links to define which stockpile(s) the items should be un/loaded to and from.

===Capacity and weights ===
Minecarts have a [[Size|capacity]] of 500,000 cm³ – five times the capacity of [[wheelbarrow]]s.

'''Examples* of the capacity of one cart'''
{| class="wikitable"
|-
! Item
! # of items
|-
| [[stone]]
| style="text-align: right;" | 5
|-
| [[wood|log]]
| style="text-align: right;" | 10
|-
| [[block]]/[[bar]]
| style="text-align: right;" | 83
|-
| minecarts
| style="text-align: right;" | 12
|-
| [[Kitchen|prepared meals]]
| style="text-align: right;" | 500
|-
| [[Trap_component#Spiked_ball|spiked balls]]
| style="text-align: right;" | 500
|-
| [[Sand]] [[bags]]
| style="text-align: right;" | 500
|-
| [[Weapon#Native_weapons|mace]]
| style="text-align: right;" | 625
|-
| [[Weapon#Native_weapons|spears]]
| style="text-align: right;" | 1250
|-
| [[cloth]]
| style="text-align: right;" | 2500
|}
: ''(* See [[Size#Items]] for a more complete list of item sizes, and use the formula {500,000 ÷ (item size)}, dropping all fractions, to determine a minecart's capacity for that item.''

:: ''Example: A [[door]] is listed at a volume of "30,000". 500,000 ÷ 30,000 = 16.666, so a minecart can hold 16 doors, plus some smaller object(s) equal to or less than .667 (2/3) of a door, or 20,000.)''

The total weight of the loaded minecart does not affect the initial velocity received from pushing or launching from a roller.{{bug|6296}} However, the load of a minecart ''does'' affect whether a [[pressure plate]] triggers or not, based on the pressure plate's setting and the ''total'' weight of the 'cart.

'''Weights of different carts'''

{| class="wikitable"
|-
! Type of cart
! Empty cart
! Fully loaded (items)
|-
| oaken minecart
| 28Γ
| 378Γ (10 oak logs)
|-
| iron minecart
| 314Γ
| 1698Γ (83 marble blocks)
|-
|-
| copper minecart
| 357Γ
| 1682Γ (10 obsidian boulders)
|-
| platinum minecart
| 856Γ
| 10482Γ (83 gold bars)
|}

The weight of a minecart is one twenty-fifth (1/25) the [[density]] of its material in Urists. Because pressure plates can be set to trigger at intervals of 50 Urists, minecarts with weights just under a multiple of 50 are ideal for switching based on whether they're full or empty. The best minecart materials for full/empty switching are as follows:

{| class="wikitable sortable"
|-
! Material !! Minecart weight !! Content weight required to trigger !! Banana roasts required to trigger (for scale)
|-
| [[Glumprong]] || 48 || 2 || 4
|-
| [[Electrum]] || 596 || 4 || 7
|-
| [[Nickel silver]] || 346 || 4 || 7
|-
| [[Brass]] || 342 || 8 || 14
|-
| [[Bismuth]] ([[Strange mood|moods]] only) || 391 || 9 || 15
|-
| [[Fine pewter]] || 291 || 9 || 15
|-
| [[Lay pewter]] || 291 || 9 || 15
|-
| [[Tin]] || 291 || 9 || 15
|-
| [[Trifle pewter]] || 291 || 9 || 15
|}

{{anchor|Tracks}}

=== Creating tracks ===
[[File:minecart_ride_anim.gif|thumb|200px|right|A dwarf riding a minecart from a higher level.]]Minecart tracks are made up of contiguous track, tracked ramp, or bridge tiles. Track tiles and tracked ramp tiles have a direction or series of directions associated with them. These directions dictate which directions a minecart on a given tile may move from that tile. For example, a Track NE (northeast) tile allows a minecart on it to move either north or east from its present position. Therefore, if you want your minecart to move east along a straight piece of track, then return west using that same track, you would need to use EW tracks so that the cart could travel east initially, then return west over the same track. Excluding designs in which the cart will "jump" tracks via a drop or other ramp, tracks must be valid end to end to work for most looped or straight-track applications. A single east only track tile in your line of east-west tracks will cause any route using the track to fail the moment it tries to go the wrong way over that tile. Minecart tracks can be built in two ways: carved or constructed. A given minecart track need not use carved or constructed elements exclusively, as the two methods can be used interchangeably depending on the needs of a given section of track. The way the tracks are built is slightly different between the two, as explained below.

====Simple tracks====

'''Carved'''

A single-tile wide strip of natural stone can be designated to be [[Stonecutter|carved]] (with {{menu icon|v|t}}), which will create a straight two-way track. The creation of corners, crossings, and T-junctions is as simple as designating another strip of track that overlaps an existent or newly designated track. Carved tracks are removed by [[smoothing]] the rock they're on, which results in a smooth floor (that can be re-carved if necessary), or by building a [[floor]] on top and subsequently removing it. Dwarves can carve corner tracks in one pass by designating the track carving twice and canceling unwanted carvings (with {{menu icon|x}}). Tracks can be carved in any natural floor tile, rough, smooth and even over engravings, providing an easy method to remove low-quality or undesired floor engravings. Once a track has been carved, it's important to check the track directions for each tile in the route carefully to make sure no mistakes were made by yourself or the game's track carving logic.

'''Constructed'''

Tracks can also be built as regular [[construction]]s (through {{menu icon|b|n|k}}. This method is resource-expensive, since each track tile requires one stone, [[bar]], or [[block]] for construction. Corners, crossings, T-junctions, and ramps also have to be designated individually. However, it is usually the only way to build tracks above ground or on soil (barring the [[Obsidian farming|creation of obsidian]]). Constructed tracks are designated for removal like any regular construction; be aware that removing track ramps built on top of natural ones will also remove the original ramp, leaving a flat floor.

====Ramps====

'''Carved'''

The carving of natural ramps is a little more confusing: to carve a two-way track on a ramp (natural only, does not work on constructed ramps), you must designate the track '''starting on the ramp and one square beyond''' in the direction you want the track to go. For the side of the ramp square you want to head upward, there '''must''' be either a natural or constructed wall in the square next to it, otherwise the game assumes you are trying to carve it on the same level – this can result in the track being carved underneath a door or other object. If you have accidentally done this, you can correct it by smoothing the ramp and constructing a single square of wall next to it, then re-carving the ramp correctly, however, the wall must stay there permanently — removing it will disconnect the track.

'''Constructed'''

The track and ramp must be constructed first as a constructed Ramp, and then as a Track from the construct track menu ({{menu icon|b|n|k}}). When constructing track ramps, the stated direction should be the same as the connected tracks. For example, a track going up from West to East would require, starting from the West, a Track (EW), a Track/Ramp (EW) and a Wall behind the ramp, underneath the section of track above it. Incorrectly placed ramps result in minecarts ignoring the ramp and crashing into the supporting wall. They will not, however, display as unusable as when the supporting wall is missing.

'''Examples of ramps'''

A simple ramp would look like this:
{{diagram|spaces=yes|\
z +0 z +1
░░░░ ░░░░
═▲o ░▼═
░░░░ ░░░░
o : wall
}}

Carving track corners into ramps is rather unintuitive and complicated. Since carving tracks always requires two tiles to connect in a straight line as input, you have to give two separate designations for a single job: a track bit from the ramp tile to the "below" direction and another one to the wall of the "upward" direction. If you wanted to change direction on a ramp from east to north:
{{diagram|spaces=yes|\
z +0 z +1
░░░░░ ░░░░░
░░░░░ ══╗░░
══▲░░ ░░▼░░
░░░░░ ░░░░░
}}

you would need to connect the ramp on z +0 both to the west and to the north by issuing two "carve track" commands, one selecting the ramp and the track tile to the west, and another connecting the ramp tile with the wall to the north. A stonecutter would then carve a NW track corner into the ramp, allowing carts to pass the corner correctly both going up and down. Such track corners are perfectly serviceable for guided carts, but moving down a route of several of them by pushed or ridden cart is problematic - ramps on corners behave very counter-intuitively, resulting in loss of speed when going down and diagonal movement when going up.

Moving to and from ramps (or between ramps "pointing" in different directions) causes some non-trivial adjustments to speed and even moving along the tiles at a fixed speed ''unrelated to the entry/exit velocity values'', because transitions to/from ramps are processed differently and are not to be "skipped". This affects compact track/ramp combinations (such as e.g. a simple 2x2 ramp spiral) most, and combined with bouncing often makes them work not in the way one could expect. {{cite forum|144328/5705102}}

=== Hauling route ===

A hauling route is a list of directions describing how and under what conditions a minecart will move. The proper setting up of routes is essential for a working rail system. Routes, stops, departure conditions and stockpile links are managed from the {{menu icon|h}} hauling menu. If minecarts refuse to be hauled, double check active burrows and in case of [[magma]] or [[Dragonfire|fire]] involvement [[temperature]] setting. Changing this setting may result in tiles not cooling down from past heat exposure.

==== Route ====
A route defines the path a minecart will take along a track, as well as under what conditions it will move or stop moving. A route is made up of stops. Stops are precisely what they sound like, a position on the track at which you want a minecart to stop. A minecart track might use as little as a single stop for a looped track, which will serve as both a starting and stopping point for the cart, or it could contain many stops, perhaps to load supplies or wait for a bridge to be manually lowered, before reaching its destination or returning to its starting point. It is important to note that you only need to place stops on a route where you actually want the cart to stop and wait for some action to occur. They are not needed to help navigate the cart along the track beyond telling it where on the track to stop.

New routes are created with the {{menu icon|h}} hauling key. Existing ones can be removed (without confirmation), and also nicknamed ([[File:Quill.png]]). Before operating, the route must have a vehicle assigned ([[File:Button assign vehicle.png]]) to it (this can be done with either the route or a stop selected). Assigning a full minecart to a route may result in a slow hauling job if the contents are heavy.

==== Stops ====
Stops are the individual waypoints that make up a hauling route. A given stop consists of the location of a tile, as well as conditions describing when, where, and how a cart should be moved after being stopped at that tile. Stops can be created from within the {{menu icon|h}} hauling menu, by placing the cursor over a tile and hitting [[File:Button add stop.png]] while highlighting the route (or a stop within) you've already designated. A minecart will begin its route at the first stop created, and continue through each subsequent stop, being guided, pushed, or ridden from each stop to the next depending on the conditions specified. In many basic minecart applications, the cart will end up at the same stop it began at, though this is not always the case. It is important to note that hauling stop order is enforced, even if there is no track. A dwarf will drag the cart overland back to a skipped stop in the route's list if your tracks bypass it somehow, including if the minecart does not stop on the stop after it is pushed/ridden.

Once a stop has been placed, it is given a default set of conditions under which to move the minecart if it is stopped there. Each new stop gets the same default conditions regardless of the track it is placed upon (e.g. guide the cart to the north). For this reason new stops might get marked by yellow exclamation marks ({{DFtext|!|#ff0}}) due to invalid directions. One important thing to note is that as you place additional stops, the display will show paths between the stops you have defined. However, this is '''not''' necessarily the actual route the minecart will take once the route is in operation. For example, if a route were defined with two stops at opposite ends of a track with many twists and turns, a line will be drawn directly between those stops to show the order in which they will be visited. These route lines may crisscross all over the tracks, but so long as the track is valid end to end, the cart will follow the track from one stop to the next, even across twists, turns, and z-level changes. Route stops, which are the steps that make up a route, should not be confused with physical Track Stops, described below.

Note that setting a stop on a sloped track may cause the minecart to roll away, preventing it from being properly loaded.

===== Stockpile links =====
By placing the cursor on top of a stockpile and using {{k|s}}, you can create stockpile links while defining a hauling stop. Links can also be redefined by selecting them, placing the cursor over a different stockpile, and pressing {{k|p}}. The cart will then be filled by items present in its various linked stockpiles in preference to other items. Note that bins should be used with caution in stockpiles that are linked to minecarts. Bins cause problems when used with the "Desired Items" list in a stop's conditions. For example, if a minecart is set to accept only granite blocks, and to depart north when it is 100% full of granite blocks, it will not depart if any of those granite blocks are in bins, even if bins are also included in the desired items list. Two solutions to this problem exist as of v0.40.24. First, bins can be disallowed in stockpiles that are linked to stops. Alternatively, bins '''can''' be used in conjunction with minecarts provided that the minecart's departure conditions use only "any items" instead of "desired items." This option can be toggled in the advanced conditions menu for a stop, accessible via the {{key|C|}} key. The cart's contents can still be controlled by specifying what items are allowed in the linked stockpile.

===== Departure condition =====
Departure conditions involve setting conditions in which the minecart will leave on the route. Each condition includes:
# A departure mode (Guide, Ride or Push).
# An initial departure direction (NSEW). Note that this defines the initial direction of movement only. Even if a track includes many turns, as long as the initial movement direction is valid the cart will follow the minecart track thereafter.
# A timer, before which the departure condition cannot be met.
# Conditions on the amount of items in the cart.
Departure conditions are created with the {{k|n}} key. A new departure condition will read: "guide north immediately when empty of desired items". This condition can be changed between basic presets with {{k|c}}. "Advanced" mode ({{k|C}}) allows for more precise control over departure conditions: fine tuning the percentage from 0 to 100 in 25% steps ({{k|f}} and {{k|F}}), switching it being either the maximum or the minimum amount of items for the condition to be met ({{k|m}}), and whether the cart accepts all or only a specific set of items ({{k|l}}). Common to both screens are the departure mode ({{k|p}}, Push, Ride or Guide), {{k|d}}irection, and timer ({{k|t}} and {{k|T}}) options.

To have a cart only carry a specific set of items, the stop can be set to only carry "desired" items, opening the selection screen with the {{k|Enter}} key while having said stop condition selected, and toggling as desired, or it can simply be linked to a stockpile and set to depart once it is full of items from its linked stockpiles, regardless of type.

=== Track Stops ===
A Track Stop, not to be confused with a route stop, is an optional, single-tile construction which serves two purposes. First, it can be used to cancel a cart's momentum in order to slow or stop it as it passes over the Track Stop. This might be necessary if a cart were pushed down a series of ramps to its destination. Second, a Track Stop can cause a cart to automatically dump its contents as it passes over the Track Stop. Track Stops are constructed via {{menu icon|b|n|K}}, and must be constructed atop an existing piece of track. If a Track Stop has been set to automatically dump a cart's contents, the cart will dump its contents in the direction indicated when it passes over the Track Stop. Depending on the friction settings chosen for the Track Stop, the cart might then stop after dumping, or it might continue on its route to another destination.

Track Stops are not mandatory; in fact, their main use is in automated rail systems. However, even in basic rail systems it can be useful to set a Track Stop to dump items: this saves time that dwarves would otherwise spend in removing items from the cart, time that is better spent driving the cart back to where it's needed. Dumping will occur even with a guided cart. '''Take care not to set Track Stops at a loading site to dump their contents''', or dwarves will never be able to fill the cart. It will dump any contents the moment they are loaded.

Track Stops are constructed using the [[Mechanic]] labor.

* See [[#More_on_Track_stop |More on Track Stops]]

=== Step-by-step tutorial ===

Let's construct a simple minecart route. This route will move stone blocks from an input stockpile to an output stockpile. We'll begin by creating the stockpiles:

[[File:minecart-example-1-v50.03.png|200px|Stockpiles designated.]]

The input stockpile is on the left; the output stockpile is on the right. We'll be moving blocks from left to right. Disable bins in both stockpiles, and set the input stockpile to accept only from links. Then make the stockpile take from the mason's workshop where the blocks are being produced.

Next, carve the track:

[[File:minecart-example-2-v50.03.png|200px|Track carving designation.]]

Note that the ends of the designation are uniquely shaped; this is automatic, and not anything you need to control. Now, wait for your stonecutters to come along and carve the track into the stone. (Your haulers will probably also fill up the input stockpile while you wait.)

In addition, while we're waiting for that to happen, we'll build an iron minecart in the forge.

[[File:minecart-example-3-v50.03.png|200px|Track carved.]]

When the track has been carved, it will look like the above (the track will be solid instead of flashing). Now, order a track stop to be constructed (Under "Constructions") next to the output stockpile:

{|
| [[File:minecart-example-4-v50.03.png|200px|Track stop designation.]]
| [[File:minecart-example-5-v50.03.png|200px|Select dumping direction.]]
|}

You must select the dumping direction ''before'' placing the track stop. We want our blocks to be dumped into the output stockpile east of the track stop. Then wait for a mechanic to come along and build the track stop.

[[File:minecart-example-6-v50.03.png|200px|Track stop constructed.]]

Now we'll define the actual ''route''. This is done in the {{k|H}}auling menu. Press 'Add New Route' to begin defining a route. Select 'Add a stop' then click the track next to the input stockpile:

{|
| [[File:minecart-example-7-v50.03.png|200px|Route definition, in progress.]]
| [[File:minecart-example-8-v50.03.png|400px|Route definition, in progress.]]
|}

Select 'Add a stop' again then click the stop next to the output stockpile define the second stop:

{|
| [[File:minecart-example-9-v50.03.png|200px|Stop 2 designation.]]
| [[File:minecart-example-10-v50.03.png|400px|Route definition, two stops.]]
|}

At this point, the route has been positioned, but they haven't been ''defined'' yet.

Click the Minecart icon for the route (not the stop) and assign a minecart to the route.

Select the minecart icon for the first stop to select what items will be hauled to the minecart. By default no items will be hauled to the minecart. As we've set the input stockpile to only take blocks from the workshop, you can either set to to accept blocks, or set it to accept all items.

Click the stockpile icon for the first stop, select the "take from" icon (middle button) and select the input stockpile.

[[File:minecart-example-11-v50.03.png|350px|Set the stockpile.]]

Select the Conditions button ('''<>=≠''') for the first stop and check out the defaults. For the first stop, these are largely fine however you should change the direction button for all the conditions so the minecart goes the correct direction when it's ready.

[[File:minecart-example-11.1-v50.03.png|350px|Set the direction.]]

Select Conditions for the second stop. These need to be changed so the minecart is returned to the start immediately. Erase the bottom two conditions, change the direction to point back to the stop, and then finally click the '''>=''' button so it changes to '''<='''. This will make it so the cart is returned regardless of how full it is (which is good, as it'll always be empty!)

[[File:minecart-example-11.2-v50.03.png|350px|Fix the conditions for the second stop.]]

Once the minecart is in place, dwarves should fill it with blocks from the input stockpile, which will in turn be filled with blocks from the workshop where your mason has been toiling dutifully. When the minecart is full, the blocks will be dumped into the 1x1 stockpile on the right. Automatic quantum dumping!

If the route has any issues, you'll see a red ! on the minecart in the route screen. Be aware that this appears initially until the minecart is put in place. If your route is correctly set up, your dwarves carry items to the cart and the percentage will change on the route screen.

{|
| [[File:minecart-example-12-v50.03.png|frame|Route with an issue.]]
| [[File:minecart-example-13-v50.03.png|frame|Cart correctly getting filled up.]]
|}

=== Troubleshooting ===

Because of the complexity of the system, all but the most careful and experienced minecart users will encounter issues. Most route issues can be diagnosed and fixed from the {{k|H}}auling menu.

'''Symptom:''' {{DFtext|! Set dir/connect track|6:1}} message appears to the right of one or more stops

:;Possible Causes:
:* Game cannot find a path for ''guiding'' the cart without carrying. The game checks for haul route validity assuming the cart will be guided. This warning will be shown when the path crosses impassable tiles, requires a dwarf to carry the cart, or is not fully guidable.
:** If your cart path relies upon advanced tricks like deliberate falling into pits or ignoring floor types, even a path designed entirely as you intended will still trigger the yellow warning. If the route is working as intended, you can safely ignore this warning.
:* Invalid departure direction in one or more conditions for the stop. Edit the stop using {{k|Enter}} and press{{k|d}} until it is pointing in a valid direction.
:* Track stop built on trackless tile. Track stops must be built on tiles where tracks already exist to be usable.
:* Discontinuous track. If the route indicator seems to draw between your first and last stop, this is the cause. Make sure destinations are linked by track to both directions, and that there are no sneaky gaps in the tracks.
:** ''Ramps''' are notorious for their finicky use. It is recommended to check every ramp to confirm no unintended one-way ramps remain.
:** To carve a two-way track on a (natural) ramp, you must designate the ramp ''and one square beyond'' in the direction you want the track to go.
:** Ramps '''must''' have a solid wall on the side opposite to the track ("behind" the ramp), or they will neither work nor be marked as "unusable". The wall can be natural or constructed.
:* Discrepancies in desired/kept item configurations.

'''Symptom:''' The status '''0% V''' always appears to the right of one stop.

:;Possible Causes:
:* Stop not set to take from a stockpile. Edit the Stop using {{k|Enter}} and make sure you see a message like "Take from Stockpile #1".
:* Take conditions and stockpile contents do not overlap.
:* Track stop is set to dump. A track stop set to dump cannot be filled. You must either set the stop to a time-based departure or deconstruct the track stop and rebuild it without dumping. (Alternatively, with [[DFHack]] you can modify "Dump on arrival" to "No" using the {{key|q}} menu without rebuilding the stop.)
:* Minecart itself is designated to be dumped (such as when using mass-dump).

'''Symptom:''' Dwarves fill the minecart properly, but will not move it thereafter.

:;Possible Causes:
:* Minecart contains items not listed as desired on its current stop. Check minecart contents using the {{key|k}} and {{key|z}} keys and ensure that all items in the cart are desired items.
:* Minecart contain desired items ''in bins''. Minecarts seem to have problems realizing that they are in fact full of desired items if some of those items are in bins, even if bins are also among the desired items for that stop. '''This cannot be solved by adding the appropriate bins to the stop's desired items.''' Either disallow bins in stockpiles you intend to load minecarts from, or set the departure conditions to rely only on percentage of total load rather than percentage of desired items using the advanced conditions menu ({{key|C}} key).

'''Symptom:''' Dwarves repeatedly attempt to load the minecart, but no items are ever loaded into it.

:;Possible Causes:
:* Track Stop set to dump used as a loading site. Every time a dwarf places an item into a cart resting on such a track stop, the item will be immediately dumped, causing unlimited, useless cart loading jobs. Autodumping Track Stops should never be used at a loading site.

'''Symptom:''' A dwarf picks up the minecart and carries it to its destination.
:* See [[#Quirks|Quirks]]

=== Danger ===
Minecarts are not without <strike>danger</strike> [[fun]]. Although designating a track automatically sets the [[traffic]] designation to low, dwarves ''may'' still walk on them, and [[creature]]s ignore traffic designations altogether. If an unlucky dwarf or creature fails to [[dodger|dodge]] a minecart, they can be injured. Most of this danger can be avoided by setting the minecart {{k|h}}auling commands to guide instead of push or ride (dwarves guiding minecarts will ignore traffic restrictions), as well as by [[pasture|pasturing]] domestic animals and preventing the access of other creatures to the tracks. Note that removing the track doesn't reset that tile back to normal traffic priority, so you may wish to manually clean up traffic designation afterward. Also note that bridges that are used as tracks don't have their traffic priority changed automatically (since they're just normal bridges), which could cause dwarves to pathfind normally through dangerous minecart entrances in your fort's walls if you're not careful.

The only <s>fool</s>''dwarf''-proof method is to make the tracks inaccessible. There are several ways to create a track which works for minecarts but doesn't allow creature-traversal; the simplest is perhaps building a [[statue]] on the tracks. Other options include adding single-tile holes (minecarts moving at reasonable speed will jump the gap), vertical drops, minecart-triggered doors, small pools of liquid (4/7 water or 2/7 magma), and hostile creatures overlooking the tracks. For safety, both ends of the track should be isolated, making the dangerous center sections completely inaccessible (though maintenance access can be provided by a locked door).

Danger does not always involve living victims: careless route designation can also result in minecarts careening off tracks or colliding with each other. If this occurs, the [[item]]s may be scattered; this can cause even more hauling jobs than the minecart aimed to eliminate. Even <s>better</s> worse, scattered items, especially [[weapon]]s, can injure passing [[dwarf|dwarves]] or other [[creature]]s; in the words of Toady One the Great, "Accidental grapeshotting of the dining room should be possible now."

Of course, the danger of using minecarts means they can also be [[Trap_design#Minecarts|used as weapons]] by imaginative players.

== Advanced usage and automation ==
Minecart-specific effects are implemented via track stops, rollers and [[pressure plate]]s with "track" condition set. Since all three are considered [[building]]s, they can't be built on the same square (however convenient track stop + pressure plate would be) nor a simple ramp, and are removed separately.

=== More on Track stop ===
Track stops are constructions that allow further automation of minecart systems via adjustable features such as braking by friction and automatic dumping of contents. They can be built from logs, bars and blocks through {{K|b|n|K}}; friction amount, dumping toggle and dumping direction must be set '''before''' construction, and these settings can be neither changed nor seen thereafter; however, track stops can be linked to [[pressure plate]]s or [[lever]]s to toggle friction and dumping On or Off (trigger state is inverted: switch On = track stop Off). In thoughts screen, dwarves will admire track stops as traps.

If a [[stockpile]] is placed on the tile that a track stop is set to dump to, it can act as a [[Exploit#Quantum_stockpiles|quantum stockpile]] and any items dumped from a minecart that match the storage settings of the stockpile will remain there and accumulate. Normally track stops are built on top of existing track to operate on moving minecarts, but they can also be used without tracks to create [[Quantum_stockpile#The_Minecart_Stop|automatic quantum stockpiles]] (see also [[#Step-by-step_tutorial|step-by-step tutorial]]). It is not always desirable to collect ALL of certain items into one quantum stockpile, such as when distributing a material to multiple separate industries. You can link your quantum stockpile to various other stockpiles, ensuring that your dwarves will keep them supplied as necessary. Because quantum stockpiles never fill up like regular stockpiles, it may be a good idea to add a switch to turn them off.

Items dumped from a minecart at a track stop (or dumped by any other means) into open space fall through z-levels until they land on a solid surface. Items falling onto a designated [[stockpile]] will automatically be considered part of that stockpile, even if the stockpile is set to disallow those items (they will, however, be automatically moved to a more appropriate stockpile, if available). Items falling on top of a minecart will '''not''' fall "inside" the minecart. Use with caution; dwarves have fragile skulls.{{bug|5945}}

=== Automated propulsion ===
==== Roller ====
{{Main|Roller}}

A '''roller''' is a [[power]]ed [[machine component]] for the automated propulsion of minecarts. They are built over the top of existing tracks with {{K|b|M|r}}, requiring a [[mechanic]], ''(length/4)+1'' [[mechanism]]s and a [[rope]]. Rollers may also be placed directly on ramps to help pull carts up Z levels. Rollers are very useful to maintain a cart's momentum along long routes, to get them to climb Z-levels without dwarfpower involved, and to get them to reach speeds unattainable by guiding dwarves. These devices are variable-length (1-10), variable-direction and variable-speed ([[Minecart#Numbers_behind_the_scene|see below]]), all traits that can be set at construction time; a roller uses two units of power per tile it is long.

Single-tile rollers transfer power in all four cardinal directions, while other rollers generally only transfer power perpendicular to their activity direction. Longer rollers can also transfer power along their activity direction if built in the correct order, although this can be hard to accomplish and is easily broken. Rollers cannot be powered from above.

Rollers have great acceleration and capped speed. Carts going faster than the roller are unaffected. If a cart moves across an active roller in the direction the roller works and moves slower than the roller's specified speed, the cart will be set to the roller's speed. A cart going against a roller's movement direction will be sent back the way it came (once again at the roller's speed), unless it was moving extremely fast: speed increment of 100000 allows to reverse carts from the full "highest" (50000) speed roller to full "highest" speed back, but ramps can accelerate a cart beyond this. {{cite forum|144328/5702453}}
A cart crossing over a roller perpendicular to its current movement direction will gain the roller's amount of speed in the perpendicular direction without directly changing its forward motion. Without an adjacent wall to constrict its movement, this will typically send a cart off the rails on a diagonal path, completely unable to follow any tracks until it collides with a wall or is otherwise brought to rest. However, if the roller is placed over a track turn and pushes ''from'' the direction of that turn's track, the turn affects carts ''after'' the roller, so they will be forced into the turn rather than derailed in a diagonal direction. {{cite forum|144328/5702453}}

{{diagram|spaces=yes|\
tracks: full:
║ ║
═╗═ ═╢═
║ ║

╢ : roller pushing from W to E
}}
If the roller is powered, carts from ''all'' directions (unless too fast) exit S, because speed imparted by the roller forces carts toward E and ''then'' into the turn.
If not powered, carts from W and N exit S, carts from E and S exit W. Carts above derail speed will ignore the turn, of course.

{{diagram|spaces=yes|\
║ ║
═╗═ ═╟═
║ ║

╟ : Roller pushing from E to W
}}
Carts from the E or W: exit W.
Carts from N: derailed diagonally, exit SW.
Carts from S: derailed diagonally, exit NW.

Rollers affects carts on a track - if placed on a floor or ramp without any tracks, they are ignored. Depowered rollers are also ignored, friction is determined by the tiles underneath.

Because of their one-way nature, rollers are unsuitable for most two-way minecart tracks (unless you set gears toggling roller A->B off while toggling A<-B rollers on). However, a minecart set to be ''guided'' is not affected by rollers at all{{cite forum|109460/3286235}} — this allows a one-way track to be used in both directions. In addition, unpowered rollers do not affect minecarts.

Care must be taken in [[glacier]]s and other extremely cold [[biome]]s, since rollers (and the machinery used to power them) will not operate when constructed on natural [[ice]] floors.

==== Impulse ramps ====
Carts can be given momentum without rollers or changing z-level by exploiting a design oversight in a phenomenon called "'''impulse ramps'''". Ramps don't actually impart any downward velocity even when making carts descend; there is no basic "rolling downhill" acceleration effect. However, a track ramp which has at least one wall/fortification and exactly one other connection will ''always'' accelerate a cart towards the other connection, no matter where the cart enters the tile from. If a track ramp faces three directions such as ╩, then two of those directions need to be facing walls for the cart to be accelerated towards the remaining direction. This means carts can be accelerated even if the cart doesn't actually change z-level at all.

Example of straight impulse acceleration:

{{diagram|spaces=yes|\
▒▒▒▒▒▒▒▒▒▒ ▒▒▒▒▒▒▒▒▒▒
═▲▲▲▲▲▲▲▲▲▲═ ═╚╚╚╚╚╚╚╚╚╚═
▒ : Wall
═ : Normal track
▲/╚ : N/E Track/Ramp
}}If a cart enters from the left, it will speed up on every track/ramp and exit to the right going very very fast—more than one tile every step. If it enters from the right, then it will bounce back impulsed by the ramp if it's going slow enough.

As another oddity, carts coming from ramps will in some cases "teleport" through most of the next tile. This is called the "checkpoint effect", and is explained in detail in the Physics section, below. This negates the deceleration of the next tile if it is a ramp "angled" in a different direction.

You can just make an upward spiral alternating impulse ramps and regular upward ramps. It takes no power, is quick and cheap to build, requiring only channeling and track carving, and the cart goes up fast, but not so fast that it launches its contents.

Examples of impulse elevators:

{{diagram|spaces=yes|\
z +0 z +1 z +2 z +3
░░░░░ ░░░░░ ░░░░░ ░░░░░
░╔░░░ ░▼╚╗░ ░░▼▼░ ░░░░░
░╝░░░ ░▼░░░ ░░░╔░ ░░░▼░
░▼▼░░ ░░░░░ ░░░╝░ ░╚╗▼░
░░░░░ ░░░░░ ░░░░░ ░░░░░

z +0 z +1 z +2 z +3 z +4 z +5 z +6 z +7 z +8 z +9
░░░░ ░░░░ ░░░░ ░░░░ ░░░░ ░░░░ ░░░░ ░░░░ ░░░░ ░░░░
░▼░░ ░░╗░ ░╔▼░ ░▼░░ ░░░░ ░╔╝░ ░▼▼░ ░░░░ ░░╗░ ░╔▼░
░╔╝░ ░▼▼░ ░░░░ ░╚░░ ░▼╝░ ░░▼░ ░╚░░ ░▼╝░ ░░▼░ ░░░░
░░░░ ░░░░ ░░░░ ░░░░ ░░░░ ░░░░ ░░░░ ░░░░ ░░░░ ░░░░

░ : Wall
╔,╚,╗,╝ : Track/Ramp
▼ : Down Ramp (empty space)
}}

Note that these impulse elevators, due to the checkpoint effect and upward curved ramp effect, will not actually result in carts traveling straight up the ramp. They will lose speed, bounce off a ramp, then be accelerated back into the spiral after a 9-turn delay on both tiles on the floor where they are stopped. This is because the checkpoint effect allows carts to travel up the ramps in a single turn, but also prevents the impulse ramps from adding acceleration unless the cart is slowed to staying on the ramp for more than one turn. Initial acceleration will carry the cart up a variable number of floors before this effect occurs, but this bouncing back and forth will occur every 5 z-levels after the first time the cart stops. When the cart ''is'' traveling upwards, it will pass every tile at a rate of one tile per turn regardless of its actual speed, due to the checkpoint effect. In tracks with only a single cart, this is negligible, but when multiple carts are on the same track (such as when you place multiple carts on a magma cart lift) this can cause collisions which derail carts, or cause other unexpected or undesired behaviors.

The following impulse ramp (while larger) should alleviate these problems by using a straight ramp to go upwards, preceded by an impulse ramp to exploit the checkpoint effect and negate up ramp costs. Corners still decelerate carts, so the cart will tend towards a velocity of 72k, which is above derail speed. Derail speed breaks (see Controlling Speed, below) may be necessary at the top.

{{diagram|spaces=yes|\
z +0 z +1 z +2 z +3
░░░░░░ ░░░░░░ ░░░░░░ ░░░░░░
░░░░░░ ░╔╔═░░ ░░▼▼╗░ ░░░░░░
░║░░░░ ░▼░░░░ ░░░░╗░ ░░░░▼░
░╚░░░░ ░▼░░░░ ░░░░║░ ░░░░▼░
░╚▼▼░░ ░░░░░░ ░░░░░░ ░░═╝╝░
░░░░░░ ░░░░░░ ░░░░░░ ░░░░░░

░ : Wall
║,═,╔,╚,╗,╝ : Track/Ramp
▼ : Down Ramp (empty space)
}}

Also, if you want to have a cart following a below-derail speed, the following track works well:
{{diagram|spaces=yes|\
z +0 z +1 z +2 z +3
░░░░░ ░░░░░ ░░░░░ ░░░░░
░░░░░ ░══░░ ░▼▼║░ ░░░▼░
░║░░░ ░▼░░░ ░░░║░ ░░░▼░
░║▼▼░ ░▼░░░ ░░░░░ ░░══░
░░░░░ ░░░░░ ░░░░░ ░░░░░

░ : Wall
║,═ : Track/Ramp
▼ : Down Ramp (empty space)
}}
In this elevator, the cart collides with the walls in the corners, but then realigns on the ramp, picks up speed, checkpoints through the next ramp, and slams into the next wall. It is slower (10 ticks per floor) but produces reliable speeds, and will exit the impulse elevator at little more than push speeds.

A sort of opposite effect to impulse ramps also exists: ramps lacking the proper "up" and "down" connections are treated as flat track, even if they actually go up or down z-levels. This allows building "anti-impulse" slopes consisting entirely of ramps only connected up, which a minecart can travel up forty levels and more, needing no more than a single push.

=== Controlling traffic ===

==== Switching ====

As tracks are constructions or tile features, [[door]]s and other furniture can be built on them. A [[door]] or [[floodgate]] can be turned on or off by a [[lever]], effectively controlling the flow of automated minecarts. This may be <s>dangerous</s> [[fun]], however.
{{diagram|spaces=yes|\
->
A ════┤≡════ B
┤ : roller pushing to East
≡ : door
}}
The roller pushes the cart east, but until the "departure condition" is fulfilled, the door remains closed and blocks the path.

[[Bridge]]s can also act as tracks, but only if they're lowered or not retracted. This property can enable levers to turn tracks on and off. However, care should be taken to ensure that such bridges are never operated while a cart is on top of them, as the cart will be flung off the track. It's worth noting that it's often faster, and cheaper, to construct large bridges than long sections of constructed track.

A powered track switch can be constructed by building an "inverted" corner as illustrated below.
{{diagram|spaces=yes|\
B B
║ -> ║
║ ║
════╚═══ ════├════
A C A C
├ : roller pushing to West.
}}

If the cart is pushed East from the stop at 'A' while the roller is activated, it will arrive at 'B'. If the roller is not running, it will arrive at 'C'. The switch works by the roller first reversing the incoming cart's movement and the cart ''then'' following the track corner.

This switch is very reliable, reacts instantly to on/off signals, and carts of any speed can be switched by this design, although very fast carts will require rollers that are several tiles long, up to three. The requirement for power can be inconvenient or impractical. Non-powered solutions may use controlled derailment, or a connecting bridge.
{{diagram|spaces=yes|\
B ╥
║
║
╞════╝ ════╡
A D C
}}
Here the track between A and C is not continuous. The only continuous track is A->B, with a corner (not a T section). Fast moving carts will tend to derail at D and rejoin the track to C. Placing a door at D will prevent the derailment, so the cart continues to B. The door is operated by mechanisms elsewhere (typically, a lever, but some fun can be had with pressure plates).

Since it depends on derailing, this switch requires a very fast cart, faster than what can be achieved with rollers alone. To gain sufficient speed, a cart must be accelerated further, usually by descending several levels or through impulse ramps. The high speed makes the cart much more dangerous and harder to control.

If carts are moving too slowly to derail at the corner, a retractable bridge may be used as a connector between A and C.
{{diagram|spaces=yes|\
B╥
║
║
A╞════bbb════╡C
}}
The bridge must overlap the corner. Bridges behave like a track crossing, allowing carts to pass in a straight line. When retracted, the corner reappears, so the carts will continue to B. Bridges take 100 steps to react to a signal, necessitating rather long "lead times" when switching tracks via bridge.

As mentioned above, special care must be taken to make sure the bridge doesn't change state while the cart is passing over it. Retracting bridges will throw the cart, causing it to stop dead. Raising bridges can even crush the cart.

==== Controlling Speed ====


Minecarts can reach extremely high speeds, especially when descending multiple Z-levels. A minecart will derail at a track corner if its speed exceeds 0.5 t/st (tiles per step), '''unless''' the route in the direction of travel is blocked:

Will derail at > 0.5 t/st:

{{diagram|spaces=yes|\
in ══╗ -> derailing
║
out
}}

Will not derail at > 0.5 t/st:
{{diagram|spaces=yes|\
in ══╗O
║
out

O : wall/column.
}}

This behavior can be used to build a "speed limiter", that will ensure that when a minecart exits it is traveling below derail speed, as illustrated in these three examples:
{{diagram|spaces=yes|\
░░░░ ░░░░░ ░░░░░
in ═╔═╗░ ░╔S╗░ ░╔S╗░
out ═╬═╝░ out ═╗═╝░ out ═╗═╝░
░╚S╝░ ░╚═╝═ in ░╚S╝░
░░░░░ ░░░░ ║░░░
in
░ : wall
S : Track Stop (High Friction or lower)
}}
If the minecart is traveling below derailment speed, it will not be affected; if fast enough to derail at a turn, it will jump the open turn to the alternate path, be slowed as it crosses the Track Stop, and get put back into the main path only once it can take a corner. (Granted, you could do the same just with any track corners, but it may take a lot of turns and time.)

Since all the derailings, bounces and ramps can impart a sideways component of speed small enough to start visible drift many tiles away (say, [[Fun|in the middle of a bridge]]), track turns have one more use: forcing the carts to move strictly along the grid directions. Carts passing a turn below derailing speed convert one component of velocity into another, thus eliminating the drift.

A powered setup using corner rollers to decelerate carts can also be used:
{{diagram|spaces=yes|\
in ═╔╔╔╔╔╔╔ in ═┤┤┤┤┤┤┤
╚╚╚╚╚╚╚═ out ╚╚╚╚╚╚╚═ out
┤ : roller pushing to East
}}
Each roller reduces cart speed by 50000. When speed is finally reversed, the cart is sent south at a predictable 0.5 t/st, then directed west again. This design is suitable for extremely fast minecarts; the above layout capable of taking a cart moving over 6 t/st to below derail speed in a single step! As long as the cart lands on one of the roller tiles, all previous tiles apply their deceleration. (A cart fast enough to skip over the entire roller will not be slowed at all.) The linear design also means you can send a bunch of carts into it at once without collisions.

=== Loading liquids ===
[[Water]] and [[magma]] can also be loaded into minecarts by submerging them to a depth of at least 6/7 while standing still or moving at speeds of at most 10000. Loading fluids onto minecarts can be difficult because the added friction provided by fluids can stop a cart in a submerged tile. Curiously, filling a minecart with magma does not injure a dwarf ''riding'' it. A minecart will hold enough fluid to increase the depth of a single tile by 2. This amount is listed as "'''833 units'''" (rather than "depth 2"), which weighs 459Γ (water) or 999Γ (magma). An iron or steel cart filled with magma weighs 1313Γ, while an adamantine cart filled with magma weighs 1007Γ. Since you need a minecart above the liquid's level, possible arrangements may include pressure-activated sluices, rollers (with magma-safe chains for magma), pouring from above to "submerge" it briefly on the same level and drain excess away (dig deeper and leave a vaporizer, though if you could have power for rollers, may as well use a pump) and exploits with ramps (not necessarily impulse ramps, "same height" passing dip does it).
The liquids can be dumped by a constructed track stop.

== Quirks ==
This little quirk concerns dwarf-managed minecarts. If a track which was previously open becomes blocked (ex. flipping a switch connected to a floodgate you've built on the track to raise it) and the conditions for departure are met, instead of refusing to ride/guide the minecart or ride/guide it until it reaches the obstacle, the dwarf will pick up the minecart off the tracks and haul it to its scheduled destination on foot. If the distance is long enough and the weight of the cart heavy enough (due to being filled with heavy items such as stones), the dwarf may drop the cart because of fatigue/hunger/thirst before reaching the destination. This will cancel that vehicle setting job and make another dwarf come by and attempt to haul the cart to the nearest appropriate stockpile where another dwarf will pick up the cart and attempt to haul it to its initial stop. If the stockpile is far enough from initial stop, this second dwarf who is attempting to place the minecart on its tracks may also drop the minecart out of fatigue/hunger/thirst creating a loop that will go on until a dwarf with enough endurance manages to place the minecart where it belongs.

In fact, it seems dwarves are more than happy to attempt to carry a minecart from one stop to another even if just waiting until the track is open again would be the more sane option.

Dwarves will also carry a minecart to its next stop if the direction specified is incorrect (or invalid). This can often occur when using the default departure settings and forgetting to set the direction of each condition.

Dwarves can admire buildings while riding mine carts. Dwarves will not fall asleep during a ride (at least not from being drowsy). If riding on a continuous powered track loop, the dwarf will die of dehydration/starvation as they can not jump off to get sustenance.{{cite forum|109460/3377228}} Dwarves riding in submerged minecarts will gain experience in [[swimming]].{{cite forum|129889}}

Tracks block wagon access to trade depots, unless they're on a ramp. [[Bridge]]s can also be used, as they function as tracks but do not block wagons.

== Physics ==


Minecart physics depend greatly on the departure mode set in the route stop conditions.

When set to "Push" or "Ride", minecarts will move according to the regular laws of momentum, gaining speed when going downhill, losing it slowly due to friction when on a flat plane, and more quickly when going uphill. In these modes, minecarts will move in a straight line until they either are brought to a stop by friction or an obstacle, or until they encounter a turn. A minecart will roll straight past "blocked" ends of T-junctions or track ends, they have no power to restrict a cart's movement. The cart's behavior is largely independent of the weight of its contents (including fluids and dwarves): heavily loaded carts gain more momentum when accelerating, but this only plays a role in collisions: a heavy cart gains just as much speed and is as easy to stop as a light one. In either case, dwarves can not push nor ride an unpowered cart up a ramp. The cart will stall and roll back towards the direction it came. At best, this is a waste of time; at worst, it will give your cart-pushing dwarf a [[fun|fun surprise]]. To solve this, the player can either use Rollers (see below) or set the cart to be Guided.

The difference between "Push" and "Ride" is whether the dwarf will go along with the cart or not.

{{DFtext|Push}}: the dwarf will give the cart an initial push, not enough to go up a ramp, but enough to go some way along flat track. The dwarf will remain at the first stop, ready for a new job.

{{DFtext|Ride}}: the dwarf will give the cart the same initial push and then hop aboard the cart riding it to the next stop.

{{DFtext|Guide}}: the dwarf will steadily walk the cart to its destination while seemingly ignoring all laws of physics.

While being guided by a dwarf, minecarts will:
*Ignore the weight of any and all items inside.
*Ignore active working rollers.
*Will ''not'' collide with other guided carts even when a full frontal collision would be expected.
*Will ascend ramps with ease like a crundle scaling a cliff.

Because of these quirks, minecarts being guided will always move at the speed of the dwarf that is guiding them. It is thus recommended to pick the most [[attribute#Agility|agile]] of your dwarves for cart-guiding tasks.
It also means for simple non-powered rail systems, "Guide" is the recommended method of transport despite it diverting a dwarf from other, potentially more important tasks.

Some samples with behavior:
{{diagram|spaces=yes|\
A <-> B A <-> C A <-> B
B B B
║ ║ ║
A══╝ A══╩══C A══╬╗
You can only go A->B ╚╝
Works when the cart Works
is in Guide mode.
}}
In the second example above, a cart "pushed" from B will go over the junction and roll off into the unknown south.

=== Numbers behind the scenes ===

According to early research by '''expwnent'''{{cite forum|112831/3536975}}:

The minecart has 3 variables for velocity. Velocity can be thought of as tiles per 100000 ticks, so a velocity of one hundred thousand means a cart travels one tile per tick. By going down a large number of ramps, a maximum velocity of 270,000 can be reached, which presents the limit for most practical applications. Short bursts of (much) higher speeds are possible through carefully planned collisions of high-speed carts.{{cite forum|137557/5145499}} (See [[#Perfectly Elastic Collisions|Perfectly Elastic Collisions]].)

Every tick the cart adjusts sub-tile position units by the amount of their velocity, as well as adjusts velocity depending on current tile (speed is reduced by the "friction" of the tile, or accelerated if going "down" a ramp). On flat (non-ramp) tiles, the cart will move to the next tile when the sub-tile position goes 50000 away from the centre of the tile, denoted by the no-fraction integer value - tile 15 e.g. has its centre at the exact value 15 and its borders at co-ordinates 14.5 and 15.5.

Since most deceleration and acceleration is applied per step, with the notable exception of corners, a cart going at twice the speed of another one can travel about four times the distance before coming to a stop when going in a straight line, but only twice the distance along a winding track with very many corners.

A push will teleport a cart to the middle of the next tile in one tick with 19990 speed (10 speed is lost due to track friction), while a roller will directly give a cart the roller's set speed (minus friction) and the cart starts accumulating distance from its standing position. When a cart leaves a ramp it will emerge after one tick at the very end of the next regular tile.

Friction of tiles:
{| class="wikitable"
|-
! Tile
! Friction
! Comment
|-
| Tracks
| 10
|-
| Ground/Floor
| 200
|-
| Unusable ramp
| 10
|-
| Upwards ramp
| 4910 (10+4900)
|-
| Downwards ramp
| -4890 (10-4900)
|-
| Roller
| ±100000 (but capped by the set speed)
|-
| Corner track
| 10
| Speed reduced by 1000 upon leaving the corner tile
|-
| Track stop (highest)
| 50000
|-
| Track stop (high)
| 10000
|-
| Track stop (medium)
| 500
|-
| Track stop (low)
| 50
|-
| Track stop (lowest)
| 10
|-
| Water 1-6
| Additional (WaterLevel - 1) * 100
| rowspan="2" | [[#Skipping|See Skipping]]
|-
| Magma 1-6
| Additional (WaterLevel - 1) * 500
|-
| Empty space
| 0
|}

Water of depth 7/7 provides a friction of about 10000 per step. Maximum-depth magma causes at least as much friction, possibly more. This higher friction may not apply to very slow-moving carts.

Impulse sources:
{| class="wikitable"
|-
! Feature
! Speed
|-
| Push
| 20000
|-
| Roller lowest
| 10000
|-
| Roller low
| 20000
|-
| Roller medium
| 30000
|-
| Roller high
| 40000
|-
| Roller Highest
| 50000
|-
|}

Note, again, that nearly all of these values are applied ''per tick'', rather than ''per tile''. The exceptions are curves, which is 1k deceleration per direction change at the end of the tile, and rollers, which ''set'' the speed every tick. This makes rollers particularly useful in high-deceleration situations, such as underwater, but require that ''nearly every tile'' in such high-deceleration situations have a roller.

A cart heading up a ramp can experience deceleration on multiple ticks, (and stays on the tile more ticks the slower it is going, resulting in greater deceleration,) and as such, a cart leaving a "Highest Speed" roller with 50k velocity will not be able to climb 10 consecutive straight ramps, since they are ''not'' "5k deceleration each". In fact, the first ramp not on a roller will be -15k velocity, and, depending slightly upon other factors of "remainder" x position, the second may completely cancel forward momentum, and send it rolling back down, where it will bounce off the roller repeatedly. Using rollers to power carts up ramps reliably requires rollers every other un-rollered ramp. Fortunately, rollers can be built upon ramps, themselves, which allows for rollers to only need to be built every other floor. (Exploiting the [[#Checkpoint Effect|checkpoint effect]] can allow one to bypass this requirement.)

There are two important speed values which affect carts' behaviour:

"Derailing" can happen when a cart moves at speeds in excess of 50000 - carts will ignore track corners unless forced to obey them by walls or other obstacles blocking the straight path.

The "shotgun" effect takes place when a collision changes a cart's movement speed by more than 55000: loaded carts subject to such a change eject their contents, which then keep on moving in a ballistic trajectory, in the direction and at the speed the cart had before the collision (with a small random vector added). This effect entirely rides on the amount of speed ''change'' - a speeding cart crashing into a wall can be subject to it just as well as a standing cart accelerated by a speedy cart smacking into it. It can even happen when two relatively slow-moving carts (down to speeds below 20000 in extreme cases) collide head-on.

=== Sub-tile Positions and Velocity ===
Carts store six values that are unique to them. Three sub-tile position values, and three velocity values. (X, Y, and Z.)

Note that the Z position and velocity only matter when a cart is in flight. (See [[#Falling|Falling]] and [[#Cart Jumps|Cart Jumps]].)

Each non-ramp tile is functionally composed of 100,000 individual minimal-length positions ''within'' the tile in both dimensions. When a cart has velocity, it is added or subtracted from the current position every tick, and then a friction force is applied to the cart.

In essence, every sub-tile position unit is a decimal value of a tile, 0.00001 tiles, in a game that largely prefers integer values.

The exact cart coordinates shown e.g. by a DFHack script must be rounded arithmetically (up or down to the nearest integer) to find the current tile: a cart in the centre of a tile will be at sub-tile zero in all directions, and it will cross into the next tile when subtile value is more than 50 000 higher or lower than the full number.

When carts move beyond the borders of a tile, they physically move a tile on the map, and start at the far end of the sub-tile position the next tile. (I.E., traveling West, a cart that starts a tick 15,000 X away from the border and has an X velocity of -20,000 will move -5000 X past the adjacent border of the next tile in direction -X. It will also lose 10 velocity in that tick due to friction with the track if it is on a track, or 100 velocity if it is on regular ground, or no velocity if it is airborne.)

Ramp tiles are longer, approximately 141,420{{cite forum|157627/0}} in the direction where it "slants downward", (to approximate a 45 degree slope, it is square root of two times longer,) with a centre-to-border distance of 70,710. Because of this, a cart with no velocity dropped from a hatch will land at the center of a tile, 70,710 away from the tile's borders in both directions, and will start rolling in the ramp's "downward" direction, picking up the ramp's acceleration (4890 per tick in the direction of the ramp's "downward" direction) every single tick, then moving that sub-tile amount every tick. (This results in a cart that takes 5 ticks of acceleration to leave its ramp - 6 ticks overall - and to leave the ramp with about 23k velocity, slightly more than a push.) When it enters another ramp ''facing the same direction downwards'', a cart will start at the -70710 or +70710 position, and have twice as far to travel. This means that if a cart enters a ramp from the side, it will gain twice the momentum of simply starting at the midpoint of a ramp.

Note that passing from one direction of ramp to another or to flat terrain causes unintuitive behavior, "teleporting" to the end of another tile in what is called the "[[#Checkpoint Effect|checkpoint effect]]".

Note, however, that all sub-tile positions are carried over from tile-to-tile. This separate tracking of velocity and position between X and Y can lead to problems with diagonal motion:

{{diagram|spaces=yes|\
z0 z-1
▒║▒ ▒▒▒
═▼═ ▒╬▒
▒ ▒ ▒║▒
▒ : Wall
═, ║ : Track
╬ : Track and Ramp
}}

If a cart is passing West-to-East over this setup, the valid ramp to the South will apply "Southward" acceleration to the cart (-Y velocity) as it passes through the ramp tile. Assuming it only spends two ticks in that tile, it will have gained a lasting -5k Y velocity, which will still apply motion Southward. If the cart continues travelling over straight track for another ten steps, it will have accumulated enough Southward motion to try to move a tile South, even if all tracks are facing East-West.

A single tile spent on the ramp will not grant lasting southward motion, because the acceleration will be neutralised through the checkpoint effect when the cart leaves the ramp again, but the cart will be displaced about 5k sub-tiles southward, which can cause it to gain more or less speed than an undisplaced cart when meeting another south- or north-accelerating ramp.

'''Non-curving tracks do not correct this motion'''.

They don't "tip back over" without adjustments in the track. Any value of sideways motion on tracks larger than 990 will lead to a derailment. (Lower values will be nullified by friction before they are enough to lead to derailment, but there is currently no way to apply such a small amount of velocity.)

If the tile to the South is a wall at that point, it will be considered a collision with a wall that ''halts all motion''. If the tile is open, the cart will simply leave the track and travel over the terrain beside it. In almost any circumstance, this is undesirable behavior.

The only way to appropriately deal with this is to either cancel out this behavior with an equal amount of acceleration in the opposite direction, or to take a curve.

Note, again, that sub-track position is saved in both directions, so when a cart approaches a curve, it will already have a shorter or longer distance past the curve when it makes the turn.

Curves are applied at the end of a tile. If a cart is moving East, and approaches a North-West track corner at 30k velocity, and friction is eliminated for the purposes of a cleaner demonstration, then when it enters the tile on the western (X coordinate) border of the tile, but in a central North-South (Y) orientation (sub-tile -50k X and 0 Y due to arithmetic rounding), it will then move 30k East (+X) the next tick, and be at -20k X sub-tile position, and 0 Y sub-tile position. Next tick, it is at +10k X sub-tile position, and 0k Y sub-tile position. Two more ticks would take it to +70k X, but that's past the tile border, so it stops at 50k, turns (and thus loses 1k velocity, but translates the rest from X-velocity to Y-velocity) and travels another 20k. It is now at 0k X sub-tile position, and -20k Y sub-tile position (i.e. it's re-set from the end to the middle of the tile with respect to the X co-ordinate). Next tick, it travels at 29k velocity North, and so moves to 0k X sub-tile position, and +9k Y sub-tile position. Then in two more turns, it leaves to the North.

In the case of diagonal motion due to having velocities in X and Y at the same time, it is critical which tile the cart actually tries to enter next. Only if the path into that tile is blocked by the corner branches will the cart take the corner and rewrite its velocity, otherwise it leaves the corner tile without changes to its motion. If the cart is redirected by the corner, all sideways velocity is lost, as forwards velocity ''overwrites'' sideways velocity in a curve. If, in that example in the paragraph above, the cart entered at -50k X sub-tile position with 30k X velocity, and 40k Y sub-tile position and -1k Y velocity, it would take that "curve" (or rather, redirection of velocity) on the fourth turn, while it is at 37k Y sub-tile position to start with, and then move to -53k Y sub-tile position at the end of that tick. It would then move to -26k Y sub-tile position in the following turn, and take 3 turns to clear the tile.

But, most importantly, it would be centered in the X sub-tile position, and all sideways velocity is safely removed.

There are two common ways to gain sideways velocity: Rollers facing perpendicular to the cart's travel path (which, as covered above, are almost always a bad idea, as it is easier to push ''against'' the travel direction of a cart into a curve, which redirects all velocity in the new direction,) and [[#Corner Ramp Derail|corner ramps]], and require a curved track to compensate for sideways velocity within a few tiles.

=== Track Direction Irrelevance ===
Carts that are traveling independently (that is, not guided) only care that tracks ''are'' on the tile, not which direction the tracks actually move. Tracks respect only curves (with two exits) and ramps.

This means, for example, that the following tracks, when a (non-guided) cart travels from West-to-East, are functionally identical in effect:

{{diagram|spaces=yes|\
A════════════B A╬║╚╔╣╩╦╠╥╨╞╡B
}}

This is because so far as the cart is concerned, only valid ramps and curves with two exits where there is no exit in the path they are traveling matters.

Hence, if a minecart encounters the end of the track or a T junction with no "exit" in its movement direction, it will simply leave the track and continue on its course in a straight line until it encounters an obstacle, slows to a stop, or encounters another track even if the tile at which it joins the new track instantly sends it around a corner.

In fact, in a track designed for pushes or rides, a "║", a "╦", a "╬", and a "╥" are ''only different in appearance'', and are ignored by an unguided cart, which will continue in its current direction, regardless of the track. For any purpose but guided tracks, ''only curves and ramps matter at all''.

Tracks like T-junctions, however, ''are'' respected by dwarves guiding carts, who will lift and carry carts if they cannot find a valid track to their destination, and can choose to follow any orthogonal direction at a four-way junction in much the same way as they normally pathfind. What this functionally means is that T and four-way junctions ''only guide dwarves hauling a cart, not carts, themselves''.

Carts only check for curves when they are halfway through a tile. When they get there, they look to see if their path has no exit. (That is, if it is traveling East, it checks if there is an East exit.) If there is, it ignores all other track directions, and keeps traveling. If there is not, it checks to see if there are only two exits to the track, and if one of those directions was the direction it "came from". (That is, if traveling West from the East, it checks if there is a valid exit to the West, and if not, if there is an East exit and EITHER a North or South exit.) If there is not, it ignores the track anyway, and keeps on traveling as though it were still on track.

If there is a curve the cart will respect, it checks for derailment. Carts derail if their speed is higher than 50k. Carts at this critical speed will then check for blockages of their forward path. If there is an obstacle to their path, which may be a wall or even furniture or buildings like a door, they will not derail and respect the curve, anyway. Derailing carts do not "[[#Cart Jumps|jump]]" unless they hit completely untracked tile or an invalid ramp, but simply ignore the layout of the tracks entirely. With invalid ramps, this means not respecting the ramp, and likely results in collision with a wall, zeroing of all velocity, and a cart that requires manual retrieval.

If the cart is traveling at a speed that will not derail, or is forced to turn by a supporting wall, it will subtract 1000 from the "forwards" velocity of the cart, and redirect all forward velocity to the direction of the curve. This change in the direction of velocity ''overwrites'' any "diagonal" velocity, which can prevent diagonal velocity derailments, but any perpendicular velocity is not preserved, and is instead discarded.

=== Valid and Invalid Ramps ===
Ramps are functionally defined for cart purposes as being a tile which exerts an acceleration force upon its "downward slope", and which allows connection to tracks a z-level above or below. This downward slope requires a cart to have at least one track branch touching a wall tile and one ''and exactly one'' carved exit to the tile that is the "bottom" of the ramp. Ramps accelerate carts in this "downward" direction (possibly leading to [[#Corner Ramp Derail|diagonal movement]]), and the deceleration of an "uphill" ramp is actually just the acceleration being applied against the direction of a cart's movement.

This is where players can find an exploit in the behavior of ramps - if there are ''two'' "downhill" exits to a ramp (such as a "T junction" on a ramp where only one exit faces a wall), then the ramp provides no acceleration ''or'' deceleration, allowing carts to travel up ramps without any loss of momentum except for the standard "flat track" deceleration, because as far as the cart is concerned, the track ''is'' flat. (A T junction is also not a curve, so the track is considered flat and straight no matter what direction the cart is traveling.)

Similar effects can be achieved when there are ''no'' "downhill" exits to a ramp. This may be the case if you have, for example, an East-West track with a one-tile channel with a ramp in it. The cart will travel through the "dip" with no change in velocity. It can also be the case if you abuse the [[#Track Direction Irrelevance|Track Direction Irrelevance]], and set only exits ''up'' the ramp, and none leading ''down'' the ramp. For example, if a cart is traveling from West to East up a slope, only carving East exits on each tile of ramp will make the cart travel up the ramp, and then recognize the tile it is on as being a "flat" tile, thus ignoring any deceleration from traveling uphill.

Note that this effect only reliably occurs at below-derail speeds as the cart will treat the ramp as an invitation for a ramp jump otherwise. (This almost always results in a collision with a wall that will stop forward progress.)

=== Falling ===
When falling, a minecart appears to cause no damage upon collision, possibly to allow cart "stacking" across Z-levels.{{cite devlog|2012|04|06}} A dwarf riding in a minecart that is dropped multiple z-levels suffers normal fall damage. Minecarts can fall through up/down stairs.

While airborne, carts do not feel the effects of friction in any horizontal direction, and will continue until they strike an obstacle. Carts that land on tracks instantly re-rail themselves regardless of track directionality.

Falling carts accelerate similarly to the way that a ramp will accelerate a cart in a special z-only velocity that only applies to airborne carts. (Actually, since a tile is notionally 1.5 times as high as it is wide/long, acceleration due to gravity in freefall appears slightly ''slower'' than ramp acceleration, since it has to move the cart (or any other object) a greater distance.) Ramp acceleration, while it logically should be partially z-directional, is only recorded as x- or y-directional, and there is no translation of z-directional velocity upon landing. Landing carts zero out their vertical velocity upon landing, even when landing on ramps, although carts that had horizontal momentum while falling preserve it.

This means a cart falling onto a track ramp is accelerated as if starting from the middle of the ramp - i.e. to the same speed, no matter how many Z-levels it was dropped, vertical velocity is negated. {{cite forum|144328/5701211}} As a consequence, the fall damage to passengers is also negated.

Carts falling onto a floor can, however, cause damage to creatures ''one tile below the floor''. This can be used in an [[exploit]] called a "thumper", where carts are caused to repeatedly fall on a floor above an entrance to the fort, inflicting significant damage (as though it were a collision) on those below the cart.

=== Cart Jumps ===
Carts that cross off of "up" ramps relative to their current direction of travel, which do not have a ceiling above them, are traveling above derail speed, and do not have valid ramp track before them can translate a portion of their horizontal velocity into vertical velocity, causing a cart to be projected into the air until vertical velocity is negated and overcome by the gravitational acceleration. Because downwards acceleration is applied per-tick, this creates a reasonable facsimile of the parabolic motion of an actual object rolled up a ramp and launched with significant speed.

{{diagram|spaces=yes|\
z0 z0 hiding ramps z+1 A z+1 B (hidden ramp)
▒▒▒▒▒▒▒▒▒▒▒▒ ▒▒▒▒▒▒▒▒▒▒▒▒ ▒▒▒▒▒▒▒▒▒▒▒▒ ▒▒▒▒▒▒▒▒▒▒▒▒
═▲▲▲▲▲══▲▒▲═ ═╚╚╚╚╚═══▒══ ▼▼▼▼▼ ▼═▼ ▼▼▼▼▼ ▼╚▼
▒ : Wall
═ : track
▲ : Ramp
}}
In this diagram, if there is no ceiling above it, the track in z+1 A will launch its carts airborne when they travel across the ramp. z+1 B (with a ramp on the tile on the hill) will not launch the cart. The cart would also not be launched with ''any'' valid ramp, even if it does not travel in an appropriate direction, such as North/South (which the cart will ignore, as it is not a curve, anyway, although it may produce acceleration that may cause diagonal movement.)

Carts will also start "jumping" from the track if it hits an un-tracked tile, flying over and ignoring any tracks until it is ready to land. Carts that land upon tracked tiles re-rail themselves, and clever designers use this feature to jump over curved track sections in one direction or another. (Retracting bridges over untracked tiles can cause jumps or not cause jumps depending upon the status of the bridge.) Minecart speed must be carefully regulated to ensure reliability of jump length.

Hitting untracked tiles at around 70k velocity creates a vertical component to acceleration that allows for jumps of around 6 (horizontal) tiles that do not actually leave the z-level the cart is on, but which do apply z-direction velocity on the cart, as per falling.

At the start of a jump, there is a takeoff period before the cart stops interacting with terrain and starts counting as a projectile(i.e the cart will fly over open space, but will still bump into fortifications, activate checkpoint effects etc.). The "runway" length before takeoff is affected by the velocity of the cart. After flying through the runway, the cart starts acting as a projectile. However, if the last tile of the runway is not open space - for instance, it is a track or a floor - the cart will not act as a projectile for 1 extra tile. In other words, the runway is extended by 1 tile if its last tile is not open space.

Carts that approach a downward slope at a high enough velocity will also make a jump, (or rather, ignore the ramp and fly forwards) but will not do so if the [[#Checkpoint Effect|Checkpoint Effect]] is exploited through an impulse ramp before the actual downhill as the impulse ramp "tricks" the cart into thinking it has already started going downhill.

=== Skipping ===
If a minecart is moving fast enough, it can skip over [[water]] or [[magma]] of level 5 or higher, making splashes of [[mist]] (or [[magma mist]]) as it attempts to move on them horizontally. This horizontal movement is independent of the minecart and its content's [[weight]].

Skipping causes significant friction on the cart, and even a cart going at max speed from ramps can only make about 50 tiles without requiring re-acceleration. (Carts that decelerate enough that they do not trigger the skipping effect will, of course, sink.)

=== Corner Ramp Derail ===

Corners on upward ramps can cause diagonal movement, forcing a derail even if the cart has a wall next to it, which will force a stop when it touches a wall that forces dwarves to manually reset the cart.

This is caused by the fact that a cart, after turning the bend in the track and entering e.g. a flat tile, will be subject to the checkpoint effect which applies 5k acceleration opposed to the last amount of ramp acceleration it received. Since the cart has just passed a corner, this compensatory speed adjustment now goes to the "outside" of the corner and creates enough lateral velocity to carry the cart off the track after eleven steps. (Down corner ramps do not have this problem, as the downward direction is in line with the past-corner movement direction and the checkpoint effect works on the only remaining movement vector.)

There are two fixes to this problem. One is to simply not put corners on up ramps. The other is to "cancel" the lateral speed after a cart has passed the ramp, either by sending the cart through another corner or by putting a high-friction track stop on the exit tile. In the latter case, the cart will lose 10000 speed in the desired direction, but the same speed loss will apply to the undesired lateral speed, nullifying it.

=== Checkpoint Effect ===
The checkpoint effect, [http://www.bay12forums.com/smf/index.php?topic=144328.0 explained in depth by Larix], is an odd and highly exploitable feature of ramps where minecarts "teleport" through the next tile of track, ignoring nearly all minecart physics (except that they stop at all walls or other obstacles and only respect curves with no backing wall and invalid ramps if they are below derail speed) and passing through that tile in just a single tick, and to the very end of the next tile.

This effect occurs when a cart leaves a downward ramp for any other direction of tile. (This includes ramps which accelerate in different directions, even a ramp which goes from accelerating East to accelerating North due to a bend in a chain of standard down ramps in a curve.) This allows, for example, two valid straight ramps directly next to one another with a cart dropped onto one or the other with no momentum to have the cart pick up acceleration going "down" the ramp as normal, but then flying up through the "up" ramp it travels into with no loss of momentum, as though it had come from an impulse ramp. If the two ramps had at least one space of distance between them, and then a cart were dropped in, the cart would instead "rock" back and forth between the two ramps.

This seems to be because ramps have a slightly longer length than regular tiles—141,420, rather than 100,000 distance. When this "snaps back" after a ramp, it seems to project the cart suddenly further along the track, making it jump a tile ahead even when otherwise moving at relatively low speeds.

This [[bug]] is the cause of a ''wide array'' of unexpected behavior among people who do not take this bug into account. It causes derailments or failure to climb up seemingly valid impulse elevators. In general, it makes a system that behaves extremely counter-intuitively, and operates ''any time a cart encounters a valid ramp''. At the same time, when its effect is accounted for, it is highly exploitable: It causes "perpetual motion devices" using no power when two opposing ramps are placed next to one another, since the "uphill" effect of the opposing ramp is ignored, preventing deceleration.

Another useful thing to note about this exploit is that carts traveling at no less than 71,000 or so speed (enough to travel half a ramp tile in a single tick) can travel through every tile in just one tick at no change in velocity as long as the tiles alternate between impulse ramp or actual down ramp and any other tile type. The cart checkpoints through the non-down-ramp tiles, and can pass through the (impulse) down ramp tiles in a single tick, before they can actually start gaining momentum.

{{diagram|spaces=yes|\
▒▒▒▒▒▒▒▒▒▒ ▒▒▒▒▒▒▒▒▒▒
═▲═▲═▲═▲═▲═ ═╚═╚═╚═╚═╚═
▒ : Wall
═ : Normal track
▲/╚ : N/E Track/Ramp
}}

If the cart enters from the West at less than 72,000 speed, some of those ramps will cause Eastward acceleration.

This means that an impulse ramp not contiguous to other impulse ramps has a top speed of around 75k:

{{diagram|spaces=yes|\
▒▒▒▒▒ ▒▒▒▒▒
▒╔═╗▒ ▒╔═╗▒
▒╚▲╝▒ ▒╚╗╝▒
▒▒▒▒▒ ▒▒▒▒▒
}}
This setup makes a cart that travels clockwise at a speed that fluctuates around 75k velocity. If the cart has more than 72k velocity, it fails to accelerate in the ramp, as it leaves the ramp in a single turn due to checkpointing to the halfway point. After that, the curves sap 1k velocity, and every tick saps 10 velocity.

Two contiguous impulse ramps with a same-facing "downwards slope", however, do not suffer the checkpoint effect in the second tile, giving functionally triple the space to accelerate. This means it will add velocity (at the standard rate of 4.9k per tick) up to a maximum speed of 216k.
{{diagram|spaces=yes|\
▒▒▒▒▒▒ ▒▒▒▒▒▒
▒╔══╗▒ ▒╔══╗▒
▒╚▲▲╝▒ ▒╚╗╗╝▒
▒▒▒▒▒▒ ▒▒▒▒▒▒
}}
This example results in a cart moving three times as fast as the previous cart.

Three successive ramps results in the highest attainable speeds.

In practical terms, this means that only consecutive ramps should be used for high acceleration, but singleton ramps can be used to have speeds that are somewhat regulated.

=== Stacking ===
If a minecart lands on top of another minecart, they may form a stack, with the upper cart on the z-level above the lower. Subsequent carts do not form a stack, but rather quantum stockpile in the same space. This behaviour is useful for [[megaprojects]] and [[trap design]] with minecarts as the weaponry. Moderation should still be exercised: carts take longer to fall into a "stacking" tile already occupied by other carts and will spend that time "hanging" in the air above the stack. This can lead to following carts striking them, which can cause all kinds of malfunctions. The extra time is two game steps for every cart already in the stack, which doesn't hurt stacks of ten carts very much but makes stacks of 100+ rather impractical.

These minecarts on the upper level generally need to be struck with another minecart to move out, or have their support removed. The latter option is safest done by shooting it away with another minecart, manual removal of a stack-supporting cart typically causes the next cart from the stack to [[fun|fall on top]] of the hauler.

=== Perfectly Elastic Collisions ===
Minecart collisions are perfectly elastic, meaning that not only do minecarts not take damage, but that two carts that are rolling which have frontal collisions of near-similar speed, and where one cart is no more than twice the mass of the other cart, will result in a billiard-ball-like effect of the lighter cart bouncing off the heavier cart with a proportional speed increase dependent upon the relative momentum behind the heavier cart.

Using this trick with carts already at the 270,000 maximum speed from ramps can result in "supersonic" carts traveling at speeds in the millions (travelling a dozen tiles per tick), but where they are suddenly subject to 10,000 units of "terminal velocity" friction per tick. [http://www.bay12forums.com/smf/index.php?topic=137557.0 Thread with SCIENCE here].

While hypothetically capable of launching a minecart into orbit when used in conjunction with a ramp, no cargo can be contained in the launched cart, as the collisions will force ejections of the cargo. Your "unwilling volunteer" [[goblin]] space pioneers will simply become paste underneath the wheels of an extreme high-speed cart.

== Non-standard uses ==
Minecarts include some interesting characteristics that have motivated uses beyond hauling. They can be useful for creating fully-automated [[Quantum stockpile|quantum stockpiles]], [[garbage disposal]]s, [[Water_wheel#Micro_Water_Reactor|water reactors]], and [[portable drain]]s. Storing perishable goods (meat, meals, etc.) inside a minecart appears to guard against rot and vermin.
Minecarts can be [[Trap_design#Minecarts|used as weapons]], or as (hopefully non-fatal) triggers to restart stalled [[health care]]. They can also be used to time/control game events, either using a basic [[repeater]] or much more advanced [[minecart logic]].
Minecarts trigger [[pressure plate]]s, which means a trap can be designed to trigger when a thief attempts to steal a minecart.
A pressure plate can be used as automatic and more precise custom "launch when full enough" system - as long as weight of your minecarts stays the same. You cannot build a hatch or roller on the same tile, so launch by bumping with another cart.{{cite forum|15096/4580050}}
Dwarves riding minecarts can attack enemies within reach (which goes back to dev log). This applies to shooting, and they actually can hit targets while riding by.{{cite forum|109460/5266119}} Whether a minecart protects the rider and how it interacts with dodging is not known yet. Minecart riders can also [[Swimmer#Teaching_swimming|train swimming]] and [[Megaprojects#Surveillance_Track|detect ambushers]].

== Simple Example Layouts ==

=== 2-way Minecart Route ===
[[File:Simple2wayminecart.PNG|500px|Simple 2-way Minecart Route]]

This is an example of how a 2 way route can be established.
* Stop 1 is non dumping, frictionless (Feeder Stockpile from North in this example)
* Stop 2 friction and dump (dumps South in this example)
* Stop 3 is non dumping, frictionless (Feeder Stockpile from North in this example)
* Stop 4 friction and dump (dumps South in this example)

Now you create a Route hauling your desired items from Stop 1 to Stop 2 . Immediately guide the empty cart to Stop 3 (because the stop has no friction, a pushed cart will overshoot the stop).
Haul desired items from Stop 3 to Stop 4. Immediately guide the empty Cart to Stop 1.

=== Automated Minecart Funicular (Elevator that also goes sideways)===
This is an example to set up stone delivery from multiple Z levels with a common set of tracks while automatically returning the cart to where it is supposed to go. In this example, the South track goes upwards towards the drop off point, the North track goes downwards for cart return.
The design pictured consists of the following:
[[File:MinecartFunicular.gif|frame|left]]
* Two ramps next to a wall spaced one tile apart
* Tracks on top of the ramps to make an inclined track
* A 3X1 channel dug down next to the ramps on the side opposite the wall
* 2 gear assemblies, one between the ramps, one over the middle channel
* Rollers on the upward track pointing towards the wall (South ramp in this example)
* A hatch over the channel next to your downwards ramp (North ramp in this example)
* A wall diagonally adjacent to the to the upwards channel
* Tracks leading from the hatch to the single wall
* A wall next to the curved section of track
* A pressure plate set to trigger on minecarts on the track underneath the minecart. Link the pressure plate to the hatch
* Set up a minecart route with one stop where the minecart is. Set the condition to push the minecart in the direction of the channel with any condition and contents you wish
* Each subsequent level needs to be shifted one tile in the direction of the ramp down
{{clear}}
The unloading level just needs to pass the cart over a track stop set to dump in whatever direction you want, then send it back down the return track. It also needs to provide power to the rollers, 12 power is required per level.
[[File:MinecartFunicularTop.gif|thumb|left]]
{{clear}}
How it works
* The minecart sitting on the pressure plate keeps the hatch open so that other carts may pass
* When the cart is off the pressure plate the hatch closes. This causes the cart to pass over the hatch back to its loading position
[[File:MinecartFunicularHatch.gif|thumb|left]]
{{clear}}
== Adventure mode ==
In addition to being used for hauling, minecarts can also be ridden in [[adventure mode]]. (Adapted from forum thread {{cite forum|122903/4258212}})

# If the minecart is in your inventory, drop it. If it is already on the ground, proceed to step 2.
# Press {{k|u}} when you are 1 tile away from the minecart (or standing on the same tile as the minecart).
# You will be presented with the following options:
[[File:minecart adventure mode menu.png|left]]
{{clear}}
* If you {{DFtext|Push}} the minecart, it will move a few tiles in the direction you chose. Physics comes into play here, so it will gain/lose speed depending on the usual factors.
* If you {{DFtext|Ride}} the minecart, you will hop into the minecart, even if you were a tile away, and it will move in the chosen direction with you in it. It will gain/lose speed depending on the usual factors. Whilst the minecart is in motion, you should press {{k|.}} to skip your turn; if you attempt to move whilst the minecart is still in motion, the laws of physics come into play, and you will take [[wound|damage]]. However, it is currently possible to jump out of a moving minecart safely.{{bug|10104}} Alternatively, you can push the minecart whilst it's still in motion (although it's unclear how one can bend [[physics]] so as to push a moving minecart whilst inside the minecart). If you push it in the same direction you are already travelling in, you will greatly increase the minecart's velocity. You can also push it in different directions, and this will cause it to gradually change direction-the amount of pushes this requires depends on the minecart's velocity. Once the minecart has stopped moving, you may move out of it safely, or you may want to give it another push. Note that if you push a minecart right after having ridden it (still on the same tile as the minecart), it will act as though you chose to ''ride'' it.
* When the minecart is on a track, options appear to {{DFtext|Guide}} it in directions that the tracks lead. This moves the cart 1 tile in the direction it is guided. Guiding the cart is the only way to move a minecart from a maximum friction track stop (other than taking it into inventory.)

Minecarts in adventure mode are not restricted by a lack of tracks. However, they are hindered by natural ramps. Attempting to go up a slope will lead up the cart slamming into the wall. The good news is you'll make it over the ramp. The bad news is you likely won't stick the landing.

Note that while carts are a powerful weapon if heavy and fast enough, they have their limits, and a collision can sharply reduce the speed of a cart depending on what you hit, potentially enough to eject the rider. Trying to run over a human will send them flying, while trying to ram a dragon will not end well.

If you want to test this out without creating an adventurer, the [[object testing arena]] allows you to spawn minecarts ({{k|k}}-{{k|c}}-{{k|n}})

== Forging and Melting ==
* Metal minecarts cost '''two''' [[metal]] bars to forge, or '''six''' [[adamantine]] wafers.
* When a non-adamantine metal minecart is melted down, it will return '''1.8''' metal bars, for an '''efficiency of 90%'''.
* When an adamantine minecart is melted down, it will produce '''1.8''' wafers, for an '''efficiency of 30%'''.

== See also ==
* [http://www.bay12forums.com/smf/index.php?topic=109460.0 The "How Does Minecart" Thread] by '''Girlinhat''' et al.
* [http://www.bay12forums.com/smf/index.php?topic=112831.0 SCIENCE: Quantifying minecart physics] by '''Snaake''' et al.
* [http://www.bay12forums.com/smf/index.php?topic=129676.0 How to build a Multi-cart Ore to Magma Minecart Project without needing power] by '''WanderingKid'''. (Images recovered from wayback machine and posted here: https://imgur.com/gallery/LpRsDwO)
* [http://www.bay12forums.com/smf/index.php?topic=144328.0 My very own Minecart Education Thread. Ten Lessons, now complete.] by '''Larix'''.
* [https://www.youtube.com/watch?v=hctG2dQzHwg Real-life railcarts/conveyor hybrid] which uses similar mechanics.

== Bugs ==
*A dwarf will drop her [[child|baby]], if she has one, when boarding a minecart set to be ridden.
*Dwarves have no concept of traffic safety and will walk into busy minecart lines to retrieve objects, often with deadly consequences. This is especially problematic in [[Swimming#Minecart_training|clever applications]] depending on dwarves riding the carts very frequently, because they have a bad habit of dumping their worn clothes on the tracks after a minecart ride. Adding an automatically-operated [[hatch cover]] at the end of such a ride can help prevent [[unfortunate accident]]s.
*Dwarves cannot guide a minecart through an unlocked door unless another dwarf opens the door.{{bug|6056}}
*It is possible for a creature and minecart moving towards each other to pass without collision if they exchange tiles in the same tick.
*After a minecart ride, a dwarf will sometimes haul the minecart to a storage stockpile, leaving another dwarf to haul the vehicle back to the route.
*Minecarts falling onto a floor injure creatures in the tile below the floor.{{bug|6068}}
*If a minecart travelling at high speed hits a wall, it and its contents may go through the wall, or even end up embedded in it.{{bug|5996}}
*A minecart's initial velocity is not affected by weight, when pushed or launched from rollers.{{bug|6296}}
*Removing a stop that has a vehicle waiting on it may cause the game to crash.{{bug|5980}}
*Jumping out of a minecart in motion does not lead to injury.{{bug|10104}}
*Jumping into a stationary minecart can lead to significant injury.{{bug|10229}}

{{Gamedata|{{raw|v50:item_tool.txt|ITEM_TOOL|ITEM_TOOL_MINECART}}}}

{{Category|Fortress mode}}
{{Category|Interface}}

[[ru:Minecart]]

Water wheel

2026-06-10T07:47:45Z

CaptainTofu: /* Flowing Water */ Tiny punctuation correction

{{migrated article}}
{{Quality|Exceptional}}
{{V50 machine|name=Water wheel|key=h
|icon=[[File:water_wheel_icon.png]]
|construction=
* 3 [[Log]]s
|construction_job=
[[Carpentry]]
|power=Needs 10 power. Generates 100 power. Net gain of 90 power.
}}{{av}}
'''Water wheels''' provide [[power]] via water [[flow]]. To build one, select {{key|b}}uild menu and choose {{key|m}}achines/fluids. It requires 3 [[wood]] and generates 90 net power, which can be used to operate one or more [[Screw pump|pumps]] or [[mill]]s. You can use [[axle]]s and [[Gear assembly|gears]] to distribute the power of a water wheel, or connect the machinery directly.

Water wheels do ''not'' work with [[waterfall]]s, or magma—they need "[[flow]]ing" water, according to the definition of the game.

(* Dwarf Fortress' version of "flow" is not intuitive—see below.)

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

== Construction ==
[[File:water_wheel_anim.gif|thumb|151px|right|Animation of a water wheel connected to a millstone.]] The [[carpentry]] labor is needed for construction.

A water wheel occupies 3 adjacent tiles (N-S or E-W axis, no diagonals). It is the [[Wood#Types|color]] of the first wood selected for it, so you could build a red wheel with one piece of [[goblin-cap]] and two of any other wood.

While you can build a water wheel on solid ground, it won't provide any power. A useful water wheel is built in an empty tile with no floor (you need to dig a ramp going down) so it can be powered by water from tiles one [[Z-axis|z-level]] below. Build the water wheel with its central tile orthogonally next to a gear assembly, a horizontal axle, a screw pump, or the central tile of a pre-existing water wheel.

Don't hang the water wheel from a gear assembly you wish to control with a switch, as a disconnected ("switched off") gear assembly can't support anything and will cause the water wheel to deconstruct.

A water wheel produces [[power]] as long as it has [[flow]]ing water with a minimum depth of 4/7 under at least one of its three tiles. The easiest way to do it is by placing the water wheel over a [[river]] or [[brook]]. '''With a brook, you must first channel through the surface''', since brooks have a floor of sorts over them.

Furthermore, the water beneath the water wheel must be flowing in the right '''direction''' for it to work. For example, placing a N-S water wheel over water flowing straight east or west will be useless. Since most water in Dwarf Fortress flows diagonally, this is rarely an issue.

==Designs==
'''Key:'''

'''#''' = '''Wall'''
○ = '''Millstone'''
+ = '''Floor'''
~ = '''Water'''
W = '''Water Wheel'''
* = '''Gear Assembly'''
═ = '''Axle'''

{|style="border: 1px solid #0b0; background: #dfd"
|+'''Basic watermill design'''
|- style="font-family: monospace; font-weight: bold; font-size: 135%"
|style="color: #777; padding: 0"|#
|style="color: #777; padding: 0"|+
|style="color: #777; padding: 0"|+
|style="color: #777; padding: 0"|+
|style="color: #777; padding: 0"|+
|style="color: #07F; padding: 0"|~
|style="color: #777; padding: 0"|+
|- style="font-family: monospace; font-weight: bold; font-size: 135%"
|style="color: #777; padding: 0"|#
|style="color: #777; padding: 0"|+
|style="color: #777; padding: 0"|+
|style="color: #777; padding: 0"|+
|style="color: #777; padding: 0"|+
|style="color: #07F; padding: 0"|~
|style="color: #777; padding: 0"|+
|- style="font-family: monospace; font-weight: bold; font-size: 135%"
|style="color: #777; padding: 0"|#
|style="color: #333; padding: 0"|○
|style="color: #777; padding: 0"|+
|style="color: #777; padding: 0"|+
|style="color: #777; padding: 0"|+
|style="color: #970; padding: 0"|W
|style="color: #777; padding: 0"|+
|- style="font-family: monospace; font-weight: bold; font-size: 135%"
|style="color: #777; padding: 0"|#
|style="color: #333; padding: 0"|*
|style="color: #970; padding: 0"|═
|style="color: #970; padding: 0"|═
|style="color: #970; padding: 0"|═
|style="color: #970; padding: 0"|W
|style="color: #777; padding: 0"|+
|- style="font-family: monospace; font-weight: bold; font-size: 135%"
|style="color: #777; padding: 0"|#
|style="color: #777; padding: 0"|+
|style="color: #777; padding: 0"|+
|style="color: #777; padding: 0"|+
|style="color: #777; padding: 0"|+
|style="color: #970; padding: 0"|W
|style="color: #777; padding: 0"|+
|- style="font-family: monospace; font-weight: bold; font-size: 135%"
|style="color: #777; padding: 0"|#
|style="color: #777; padding: 0"|+
|style="color: #777; padding: 0"|+
|style="color: #777; padding: 0"|+
|style="color: #777; padding: 0"|+
|style="color: #7FF; padding: 0"|~
|style="color: #777; padding: 0"|+
|- style="font-family: monospace; font-weight: bold; font-size: 135%"
|style="color: #777; padding: 0"|#
|style="color: #777; padding: 0"|+
|style="color: #777; padding: 0"|+
|style="color: #777; padding: 0"|+
|style="color: #777; padding: 0"|+
|style="color: #07F; padding: 0"|~
|style="color: #777; padding: 0"|+
|}
{|style="border: 1px solid #0b0; background: #dfd"
|+'''Dual watermill design'''
|- style="font-family: monospace; font-weight: bold; font-size: 135%"
|style="color: #777; padding: 0"|#
|style="color: #777; padding: 0"|+
|style="color: #777; padding: 0"|+
|style="color: #777; padding: 0"|+
|style="color: #777; padding: 0"|+
|style="color: #07F; padding: 0"|~
|style="color: #07f; padding: 0"|~
|- style="font-family: monospace; font-weight: bold; font-size: 135%"
|style="color: #777; padding: 0"|#
|style="color: #777; padding: 0"|+
|style="color: #777; padding: 0"|+
|style="color: #777; padding: 0"|+
|style="color: #777; padding: 0"|+
|style="color: #07F; padding: 0"|~
|style="color: #7FF; padding: 0"|~
|- style="font-family: monospace; font-weight: bold; font-size: 135%"
|style="color: #777; padding: 0"|#
|style="color: #333; padding: 0"|○
|style="color: #777; padding: 0"|+
|style="color: #777; padding: 0"|+
|style="color: #777; padding: 0"|+
|style="color: #970; padding: 0"|W
|style="color: #970; padding: 0"|W
|- style="font-family: monospace; font-weight: bold; font-size: 135%"
|style="color: #777; padding: 0"|#
|style="color: #333; padding: 0"|*
|style="color: #970; padding: 0"|═
|style="color: #970; padding: 0"|═
|style="color: #970; padding: 0"|═
|style="color: #970; padding: 0"|W
|style="color: #970; padding: 0"|W
|- style="font-family: monospace; font-weight: bold; font-size: 135%"
|style="color: #777; padding: 0"|#
|style="color: #777; padding: 0"|+
|style="color: #777; padding: 0"|+
|style="color: #777; padding: 0"|+
|style="color: #777; padding: 0"|+
|style="color: #970; padding: 0"|W
|style="color: #970; padding: 0"|W
|- style="font-family: monospace; font-weight: bold; font-size: 135%"
|style="color: #777; padding: 0"|#
|style="color: #777; padding: 0"|+
|style="color: #777; padding: 0"|+
|style="color: #777; padding: 0"|+
|style="color: #777; padding: 0"|+
|style="color: #07F; padding: 0"|~
|style="color: #07F; padding: 0"|~
|- style="font-family: monospace; font-weight: bold; font-size: 135%"
|style="color: #777; padding: 0"|#
|style="color: #777; padding: 0"|+
|style="color: #777; padding: 0"|+
|style="color: #777; padding: 0"|+
|style="color: #777; padding: 0"|+
|style="color: #07F; padding: 0"|~
|style="color: #07F; padding: 0"|~
|}
This is by no means the limit of water power from one location, depending on the width of your river/brook/channel you can stack many water wheels side-by-side (really big assembles will need to be artificial as there is a limit to how wide the game created water flows get). Just remember to make sure there is a support structure in place before you place the next wheel.

== Perpetual Motion ==

Due to the relatively low power draw of a [[screw pump]], a ''self-powering'' assembly can be made with a water wheel that still leaves plenty of excess power for other uses. This is undeniably an [[exploit]] and possibly a bug.

To get it working, you must start the pump manually.*

:''(* Exceptions are [[aquifer]]s, which can sometimes have a natural [[flow]]. This can be good if, for example, you want the wheel '''not''' to provide any power while building a pump next to it. It is not clear what causes an aquifer to keep a flow. It is difficult to replicate and might be lost with additional [[channel]]ing, so designs will have to be adapted if found.)''

It is good to have a ready source of water to refill the machine, as water tends to escape and evaporate. As the water level decreases, the water wheel may intermittently stop providing power; when the level falls below 4/7, the wheel stops providing power altogether.

'''*REMEMBER TO BUILD AN ORTHOGONAL PUMP, HORIZONTAL AXLE, OR GEAR ASSEMBLY BEFORE THE WATER WHEEL*'''

===Dwarven Water Reactor===
{{projects}}
This compact two-wheel design produces 170 surplus power (less additional [[axle|power train]]). While the water reactor provides a constant source of mechanical power in high amounts, the use of several reactors can cause performance issues in the game. When building your water reactor, it is recommended that you include a method to stop it once started ''(explained below)''.

<div style="float:right; margin:2ex 20ex;">  
{|
!'''Lower Level'''
!
!'''Upper Level'''
|-
|
{| style="border-spacing:0;"
|-
|{{RT|╔|7:0:1}}
|{{RT|═|7:0:1}}
|{{RT|╦|7:0:1}}
|{{RT|═|7:0:1}}
|{{RT|╗|7:0:1}}
|-
|{{RT|║|7:0:1}}
|{{H2O}}
|{{RT|║|7:0:1}}
|{{H2O}}
|{{RT|║|7:0:1}}
|-
|{{RT|║|7:0:1}}
|{{H2O}}
|{{RT|║|7:0:1}}
|{{H2O}}
|{{RT|║|7:0:1}}
|-
|{{RT|║|7:0:1}}
|{{H2O}}
|{{RT|O|7:0:1}}
|{{H2O}}
|{{RT|║|7:0:1}}
|-
|{{RT|╚|7:0:1}}
|{{RT|╗|7:0:1}}
|{{H2O}}
|{{RT|╔|7:0:1}}
|{{RT|╝|7:0:1}}
|-
|{{RTB|0:0:0}}
|{{RT|╚|7:0:1}}
|{{RT|═|7:0:1}}
|{{RT|╝|7:0:1}}
|{{RTB|0:0:0}}
|}

|

|
{| style="border-spacing:0;"
|-
|{{RT|╔|7:0:1}}
|{{RT|═|7:0:1}}
|{{RT|═|7:0:1}}
|{{RT|═|7:0:1}}
|{{RT|╗|7:0:1}}
|-
|{{RT|║|7:0:1}}
|{{RT|W|6:1:1}}
|{{RT|+|7:0:0}}
|{{RT|W|6:1:1}}
|{{RT|║|7:0:1}}
|-
|{{RT|╝|7:0:1}}
|{{RT|W|6:1:1}}
|{{RT|X|2:0:0}}
|{{RT|W|6:1:1}}
|{{RT|╚|7:0:1}}
|-
|{{RT|+|7:0:0}}
|{{RT|W|6:0:0}}
|{{RT|X|2:0:1}}
|{{RT|W|6:0:0}}
|{{RT|+|7:0:0}}
|-
|{{RT|+|7:0:0}}
|{{RT|+|7:0:0}}
|{{RT|≈|3:0:1}}
|{{RT|+|7:0:0}}
|{{RT|+|7:0:0}}
|-
|{{RT|+|7:0:0}}
|{{RT|+|7:0:0}}
|{{RT|+|7:0:0}}
|{{RT|+|7:0:0}}
|{{RT|+|7:0:0}}
|}
|}
</div>

[[File:Reactor with mist generator.png|thumb|right|Reactor with Mist Generator attached.]]
[[File:Water channel.png|thumb|right|Lower Level water channel]]
:: '''Key'''
:{{Raw Tile|║ ═ ╔ ╗ ╦ O ╚ ╝|7:0:1}} = '''Wall'''
:{{Raw Tile|+|7:0:0}} = '''Floor'''
:{{Raw Tile|W|6:0:0}} = '''Water Wheel''' with floor underneath
:{{Raw Tile|W|6:1:1}} = '''Water Wheel''' with water underneath
:{{Raw Tile|≈|1:0:1}} = '''Water''' on current level
:{{Raw Tile|≈|3:0:1}} = '''Water''' on level below
:{{Raw Tile|X|2:0:0}} = '''Screw Pump''' output to north {{Raw Tile|X|2:0:1}} = '''Screw Pump''' drawing from south ''(and temporary initial [[Pump operator|operator]] location, to start process)''

Dig the V-shaped channel, then fill it with water (either by designating it as a [[pond]] and letting your dwarves [[Hauling#Water_hauling|haul water]] in [[bucket]]s, or via connecting to an existing source of water). On the top level, channel out two tiles under each wheel: one tile under the center of the wheel and another one by the pump output. Build the pump pumping from the south, then the two water wheels.

Start the pump manually ( {{k|q}}, {{k|Enter}} )—if there is enough water*, the "reactor" will start immediately and the pump operator will leave. The water from the north end of the pump will spill over the top-most floor tile, filling that to 7/7 and the two tiles east and west of it to ~5/7, but will not overflow back past the water wheel to the walkway area. Note that for the upper level, no southern walls are shown as none are needed, unless you don't follow the design and do something to create water pressure.

*''(* Estimated minimum depth to prime the reactor is 3/7 to 4/7, though this is not guaranteed as ~some~ water will be in motion on the z-level above via the pump action.)''
* The ideal amount of water in this design is apparently 63 units of water. In other words, six tiles below the V are full (7/7), and three more above are also full up to 7/7, which will generate a reliable, permanent flow without ever losing any of that water to evaporation. An easy way to do this is to simply leave your pond fill command on after the reactor activates. They will eventually fill it up to the optimal level and stop.
* When you first start the pump, you are likely to have at least some excess water splash out while the fluid level achieves equilibrium - don't locate this in an area that you don't want any mud in.
* If the reactor is connected to a load totaling more than 100 power (including that used by the water wheels and pump), it may sometimes fail to start. Using a gear assembly to disconnect the load from the reactor before starting it can fix this.

The reactor can be safely halted either by blocking the tile the pump draws water from or "overloading" the reactor (since drawing more power than the reactor supplies will stop the pump that keeps the cycle going until the load is reduced and the pump is manually restarted by dwarf-power). An easy way to halt the reactor is to place a lever-linked hatch cover over the tile the pump draws from. When the cover is closed, the pump can't draw any water, and the reactor stops. More drastically, the reactor will obviously be halted by deconstructing the pump. Deconstructing one wheel will cause a flood (and almost immediately cancel any job order to deconstruct the other components), and deconstructing the pump will cause both wheels to collapse (unless they are attached to [[machinery]] outside them, not shown).

[[Power]] can be routed up from the pump or off to the side from a wheel; the bottom of the pump is difficult to access without danger of water escaping. Routing power from a wheel is typically safe in practice, but it's not impossible for a small amount of water to escape the reactor if it is temporarily overfilled. Power can also be routed out of the reactor via a gear or horizontal axle over the pump's intake tile; while this does not interfere with the pump's operation or present a danger of flooding, it makes it more difficult to shut down the reactor. In either case, it's typically wise to place a [[gear assembly]] linked to a [[lever]] early in the power train in order to allow disconnecting the power at that point, as opposed to needing to halt the entire reactor to stop the power supply.

Expanded versions can produce more power, and can be added later with minimal advance planning; such extensibility is easily attainable by placing dis-engageable gears on either side of the two water wheels, then attaching minireactors at your leisure, or halting the original reactor by other means. Alternatively, it may be easier to simply produce a second reactor, then connect to the power train at another location.

''Note: If created in an aquifer, there is a chance that the channeled tiles will have a natural [[flow|water flow]] - this will cause the pump to start the moment the first wheel is finished, flooding the work area for the second.''
*This can be countered by connecting something that consumes >90 power while building the water wheels -19 [[gear assembly|Gear assemblies]] works

===Mini Water Reactor===
This alternative is even more compact than the original dwarven water reactor, but it can be used in tight spots where you don't need more than 80 units of power surplus. You can consider this an extension unit to the DWR, as it can be added to one or the other side to provide an additional 80 power to the resulting power train.

To safely build a mini reactor and add it to a previous reactor without the risk of flooding and/or loss of power, you need to '''first turn off the original reactor'''.

It is better if you plan ahead; for example, build a larger reactor from the start, if you need more than 170 units of power

As stated previously, the design below produces 80 surplus power (less additional powertrain).

{|
|'''Lower Level'''
|'''Upper Level'''
|-
|
{| style="border-spacing:0;"
|-
|{{RT|╔|7:0:1}}
|{{RT|═|7:0:1}}
|{{RT|╗|7:0:1}}
|{{RTB|0:0:0}}
|-
|{{RT|║|7:0:1}}
|{{H2O}}
|{{RT|║|7:0:1}}
|{{RTB|0:0:0}}
|-
|{{RT|║|7:0:1}}
|{{H2O}}
|{{RT|║|7:0:1}}
|{{RTB|0:0:0}}
|-
|{{RT|║|7:0:1}}
|{{H2O}}
|{{RT|╚|7:0:1}}
|{{RT|╗|7:0:1}}
|-
|{{RT|╚|7:0:1}}
|{{RT|╗|7:0:1}}
|{{H2O}}
|{{RT|║|7:0:1}}
|-
|{{RTB|0:0:0}}
|{{RT|╚|7:0:1}}
|{{RT|═|7:0:1}}
|{{RT|╝|7:0:1}}
|}

|
{| style="border-spacing:0;"
|-
|{{RT|╔|7:0:1}}
|{{RT|═|7:0:1}}
|{{RT|═|7:0:1}}
|{{RT|╗|7:0:1}}
|-
|{{RT|║|7:0:1}}
|{{RT|W|6:1:1}}
|{{RT|+|7:0:0}}
|{{RT|║|7:0:1}}
|-
|{{RT|╝|7:0:1}}
|{{RT|W|6:1:1}}
|{{RT|X|2:0:0}}
|{{RT|╚|7:0:1}}
|-
|{{RT|+|7:0:0}}
|{{RT|W|6:0:0}}
|{{RT|X|2:0:1}}
|{{RT|+|7:0:0}}
|-
|{{RT|+|7:0:0}}
|{{RT|+|7:0:0}}
|{{RT|≈|3:0:1}}
|{{RT|+|7:0:0}}
|-
|{{RT|+|7:0:0}}
|{{RT|+|7:0:0}}
|{{RT|+|7:0:0}}
|{{RT|+|7:0:0}}
|}
|}
When building the mini reactor, follow the same order as for the DWR. The channel, however, is slightly different—you only need one water wheel. If it is an addition to a full size reactor or set of reactors, all channels will need to be fairly full with water to start the reactor.

===Micro Water Reactor===

Replacing the pump with a dumping [[minecart]], the micro reactor is even more compact and produces up to 90 surplus power per water wheel (less additional power drain).

<diagram>
z z-1
+++ ╔═╗
+[#0:0][@6:0]─[#@]+ ║[#0:0][@6:0]■[#@]║
+[#0:0][@6:0]─[#6:0][@]═[#@] ║[#1:0]▲[#@]║
+[#0:0][@6:0]─[#@]+ ╚═╝
+++

</diagram>

Channel two adjacent tiles to create a trench, remove the ramp from one trench tile and build a [[Minecart#Track_Stops|track stop]] dumping into the other trench tile. Optionally link a lever to the track stop (to disable and enable the reactor later). Add a minecart to the track stop, build a water wheel over the trench, and use a pond [[zone]] to fill the ramp tile. The reactor requires 11 units of water for continuous operation; any excess will simply disappear. Once filled, the minecart will dump water into the ramp tile. The water will then flow back to the minecart tile, refilling the minecart and repeating the process endlessly.
It's best to use a [[metal]] minecart for this, as wooden ones may be pushed from the track stop by the moving water.

For more power, each trench can operate two water wheels and multiple trenches can be arranged in a row to provide as much power as needed. (Each trench should remain isolated to avoid interference.) This example provides 356 surplus power with only 4 tiles of moving water:

<diagram>
z z-1
+++++
+[#0:0][@6:0]─[#@]+[#0:0][@6:0]─[#@]+
+[#0:0][@6:0]─[#6:0][@]═[#0:0][@6:0]─[#6:0][@]═[#@] ╔═╦═╗
+[#0:0][@6:0]─[#@]+[#0:0][@6:0]─[#@]+ ║[#0:0][@6:0]■[#@]║[#0:0][@6:0]■[#@]║
+[#0:0][@6:0]─[#@]+[#0:0][@6:0]─[#@]+ ║[#1:0]▲[#@]║[#1:0]▲[#@]║
+[#0:0][@6:0]─[#6:0][@]═[#0:0][@6:0]─[#6:0][@]═[#@] ╚═╩═╝
+[#0:0][@6:0]─[#@]+[#0:0][@6:0]─[#@]+
+++++

</diagram>

For a more compact design, several trench rows can be staggered to produce a solid block of water wheels, scaling to whatever size necessary. The example below provides 538 power with 8 tiles of moving water:

<diagram>
z z-1
+++++ ╔═╗
++[#1:0].[#@]++ ║[#0:0][@6:0]■[#@]║
+[#0:0][@6:0]───[#@]+ ║[#1:0]▲[#@]║
+[#0:0][@6:0]───[#6:0][@]═[#@] ╔╩╦╩╗
+[#0:0][@6:0]───[#@]+ ║[#0:0][@6:0]■[#@]║[#0:0][@6:0]■[#@]║
+[#0:0][@6:0]───[#@]+ ║[#1:0]▲[#@]║[#1:0]▲[#@]║
+[#0:0][@6:0]───[#6:0][@]═[#@] ╚╦╩╦╝
+[#0:0][@6:0]───[#@]+ ║[#0:0][@6:0]■[#@]║
++[#1:0].[#@]++ ║[#1:0]▲[#@]║
+++++ ╚═╝

</diagram>

Note: To avoid access problems, large blocks of micro-reactors should be built and filled one layer at a time.

== Flowing Water ==

[[File:Flowing water reactor over.png|thumb|right|Water wheels over a patch of "flowing" water]]
[[File:Flowing Water Reactor Under.png|thumb|right|A screw pump produces pressurized water that flows off the map edge through carved fortifications, flagging the water as flowing.]]
[[File:Flowing water reactor still.png|thumb|right|The water movement can be cut off and the water retains the "flowing" flag.]]

Water wheels need flowing water. The game considers it to be flowing water under two circumstances:

1. When deeper water flows into shallower water ("gradient flow"). Water which does not have a gradient—such as stretches of water 7/7 deep—is generally not considered to be flowing water even if the water technically flows through those tiles.

2. When water flows off the map edge or into an aquifer. (Water entering an aquifer vanishes from the map, since the aquifer can never become full, even if it's only a single tile). This type of flow returns from a map edge or an aquifer sink, giving the water the "flowing" quality. Water flowing off the map counts as flowing even at full 7/7 depth. This kind of flow is found in brooks, streams and rivers. Artificial water channels work just as well, as long as they flow off the map.

A tile marked as flowing off the map will keeps this quality even if the water movement is later blocked. This is evident in that a dammed river will continue to power water wheels, even though the water is no longer flowing off the map. This works just as well for dwarf-made water channels, the flowing quality is so persistent that it will remain even if the area is completely drained and refilled, although while the tiles contain less than 4/7 water they won't power water wheels regardless.

Adventure mode doesn't handle flowing water predictably. Water reactors may suddenly stop providing power each time the map is loaded in. Water won't regain flow status even as the minecart continues to dump fluid. Aquifer drains don't create flow. Even river water may become still after freezing and thawing. (Map edge drains don't have anywhere to drain, and may lead to [[Fun]] instead!)

=== Legitimate Artificial Rivers ===
You can create an underground river with 7/7 water to power water wheels by letting water from a river, lake, sea, or aquifer flow off the map edge in a cavern. For this, you need to build an aqueduct and bring the river to the map edge. Be careful: if the water spreads significantly before flowing off the map edge, the game won't consider it flowing water. Water flowing from a higher elevation (Z level) to a lower one is also considered flowing water.

=== Flowing Water Reactors ===
You can exploit the game's definition of flowing water to create bodies of water that power water wheels despite the absence of actual water flow. When a channel is dug into an aquifer, it will sometimes have a "natural flow". However, if water is pumped into an aquifer channel, the channel will always have a "natural flow" because water is regarded as disappearing from the map at that point, and the tiles are marked as flowing water, and will power water wheels—even if the pump is removed.

The other way to create water movement is letting water flow off the map edge—most commonly through a fortification carved into a map edge, although a map edge on the surface or in a cavern also works. The water will be considered flowing water, even if the map edge gets blocked by a floodgate or a raising bridge. You can even do this with stagnant water pools (e.g. murky pools); for example, digging out a channel next to a map edge, building a floodgate to seal the map edge drain, filling the channel with 4/7 water, opening the floodgate, closing it, and filling it back up to 4/7 water.

The ethics of these reactors are not very different from constant motion machines, these using water wheels to generate power and a fraction of said power to move the water with a screw pump. A water wheel generates 100 units of power and consumes 10 units of power, the latter 10 presumably being the energy the water wheel requires to move the water in front of its blades. But if the water wheel moves water in and of itself, the pump actually becomes unnecessary. The water wheel itself both moves the water and is moved by the water.
[[File:water_wheel_preview.png|thumb|340px|center|Circular version works much better than the triangular one.]]
{{Translation| dwarven = arel kol | elvish = alu rere | goblin = esp sost | human = thomo pobe}}

{{buildings}}

Talk:Main Page

2026-06-08T09:27:18Z

CaptainTofu: Added error for submitting discussion pages

{{Archive|
# [[Talk:Main Page/archive1|Archive 1]]
# [[Talk:Main Page/archive2|Archive 2]]
# [[Talk:Main Page/archive3|Archive 3]]
}}

== Needed page; Invader creature roster ==
The page would consist of multiple lists; each of them would have all creatures what certain type of [[Siege]] or [[Ambush]] invaders can field. It would include name, picture, probability of such creature being used on siege, combat role (Soldier/Pet/Mount/exc), size and special qualities (flying, aquatic, immune to whatever, exc). Probably something extra on top of this.

The parts would be:
# Roster of [[goblin]] [[sieges]].
# Roster of [[elf]] [[sieges]].
# Roster of [[human]] [[sieges]].
# Roster of [[dwarf]] [[sieges]].
# Roster of [[necromancer]] [[sieges]].
# Roster of [[bandit]] [[sieges]].
# Roster of [[elf]] [[ambush]].
# Roster of [[kobold]] [[ambush]].
# Roster of [[necromancer]] [[ambush]].
# Roster of [[Subterranean animal peoples|cavemen]] [[ambush]].
# Roster of [[werewolf]] attacks.
# Probably something else what i didn't write yet.

Remember what i can't create pages. So to make it, i would need to write idea there. --[[Special:Contributions/109.62.164.162|109.62.164.162]] 16:45, 1 May 2024 (UTC)
* As far as i understand, animal must have "Mount", "Exotic Mount", or "War Animal" with it. Humans don't ride Exotic Mounts, but can field them as war animals (IDK if they even field them at all - probably not). Elves and Goblins ride Exotic Mounts. Elves and Humans use surface animals, Goblins use subterranean animals, enemy Dwarf sieges use both subterranean and surface. [[Special:Contributions/95.71.85.187|95.71.85.187]] 09:47, 11 October 2024 (UTC)

== How to create a new language page? ==

I've just seen one dwarf requesting a Japanese page.

If possible, I'll gladly translate this wiki into Korean. Korea is relatively a small country so the language is not that widely used, but surely there are some players, I guess.

I don't know where to ask about this :9

== Free SSL Certificate ==

If the operators want to re-enable https, they can get a free (as in beer) certificate from https://letsencrypt.org/ . Instructions are on that site and it's very easy.
:HTTPS is enabled now as of the June 2019 upgrades. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 22:53, 3 July 2019 (UTC)

== Re: Discord ==

I notice there's a Discord on this page. But shouldn't it be the Kitfox Games Discord, since that's the only official Discord for Dwarf Fortress?

[[User:AlastríonaCatskill|AlastríonaCatskill]] ([[User talk:AlastríonaCatskill|talk]]) 13:43, 12 February 2020 (UTC)
;I wasn't aware of it. If that is the case, then it should probably be added to the page. [[User:OluapPlayer|OluapPlayer]] ([[User talk:OluapPlayer|talk]]) 16:03, 12 February 2020 (UTC)

Yeah, the only reason there is one at all is because somebody added some random one. I changed it to the only DF discord I knew of at the time. The only way I've now been able to find it is to search for 'Kitfox Games discord'. It's not listed on the bay12 links page, a forum thread, the reddit, or the Steam pages. Anyway, I've DMed Victoria on the KitfoxGames discord to make sure they're OK with adding the invite to this page. [[User:Ziusudra|Ziusudra]] ([[User talk:Ziusudra|talk]]) 20:08, 12 February 2020 (UTC)

...Sorry, is it too late for this? I mean, while we're still discussing this, it looks like [https://dwarffortresswiki.org/index.php/Talk:Main_Page#B12G_Discord someone else got left behind as well]. Add, or not? [[User:Silverwing235|Silverwing235]] ([[User talk:Silverwing235|talk]]) 22:21, 12 February 2020 (UTC)

I'm not sure what you were trying to link to. Do you mean this: http://www.bay12forums.com/smf/index.php?topic=163555.0 Note that the thread was locked because of drama. There's a lot of red flags: the drama, despite using the name Bay12Games it never uses the word 'unofficial', the rules channel posts are from a deleted user, the announcements channel hasn't updated in well over a year, many channels haven't been active in months. I'm not so much saying no, but I am asking: should it be linked?

There's also this: http://www.bay12forums.com/smf/index.php?topic=157332.0 But that invite is invalid. [[User:Ziusudra|Ziusudra]] ([[User talk:Ziusudra|talk]]) 02:35, 13 February 2020 (UTC)

Ah, it's a ''dead'' discord. I see now. There was just no response to the April '17 topic, I stumbled across it all and got curious. No, I don't think it should be linked. Thanks for the analysis, anyway! [[User:Silverwing235|Silverwing235]] ([[User talk:Silverwing235|talk]]) 11:44, 13 February 2020 (UTC)

== [[Multithreading]] ==

Would it be OK to create [[Multithreading]] page describing why (preferably with citations)
* even perfectly implemented boost would not be significant
* multithreading is not something that can be bolted on complex program
* DF is complicated case where taking advantage of multithreading is not obvious http://www.bay12forums.com/smf/index.php?topic=34311.msg7833713#msg7833713
* DF is filled with many gamebreaking bugs unfixed for many years, multithreading bugs are unusually awful to fix
* author of DF has minimal experiences with multithreading
* writing multithreaded code is hard
* writing correct multithreaded code is awfully hard
* fixing bugs in a multithreaded code is nightmare

and multithreading is not going to happen, ever

http://www.bay12forums.com/smf/index.php?topic=34311.msg7833713#msg7833713
http://www.bay12forums.com/smf/index.php?topic=107833.0
https://bholley.net/blog/2015/must-be-this-tall-to-write-multi-threaded-code.html + “At Mozilla, there is a sign on the wall behind one of our engineer’s desks. The sign has a dark horizontal line, below which is the text, ‘You must be this tall to write multi-threaded code.’ The line is roughly nine feet off the ground. We created Rust to allow us to lower that sign.” http://www.oreilly.com/programming/free/files/why-rust.pdf

[[User:Mko|Mko]] ([[User talk:Mko|talk]]) 03:07, 28 March 2020 (UTC)
:I disagree with some of your talking points
:* In DF each AI actor makes its own decisions, the computations can be done in parallel for an ncores speedup
:* This parallelism should be built into the lowest design levels of the program, it can be done in a DF-like program
:* With training and experience a good developer can write and debug multithreaded code.
:I agree that multithreading is unlikely to be done in DF; It can not easily be bolted on and I rather see the developer spend time on game-play.
:Is it worth to create a wiki page for what is essentially a one line explanation?
:--[[User:MathFox|MathFox]] ([[User talk:MathFox|talk]]) 18:40, 31 March 2020 (UTC)
::We would essentially be writing a page about a thing that doesn't matter to Dwarf Fortress. I can't agree to the existence of a page that's basically "This subject doesn't exist in the context of the game but here's the reasons why it should or shouldn't". This is better reserved for forum discussion, not a wiki. [[User:OluapPlayer|OluapPlayer]] ([[User talk:OluapPlayer|talk]]) 12:54, 1 April 2020 (UTC)

::: Well this aged poorly
-- [[User:Antsy555|Antsy555]] ([[User talk:Antsy555|talk]]) 15:38, 18 September 2023 (UTC)

== Re: Discord II ==

Good morning.

I was confiding with some friends, who had alerted me to the "Unofficial Bay 12 Discord" posted on this Wiki. Simply put, allegations of the use of ableist slurs were thrown, as well as screenshot evidence of using hard racist slurs against people of colour.

I feel that the Unofficial Discord should hereby be removed from the social media part of the website for the following reasons:
* No official connection to Bay 12 or the publishers [and, by extension, every non-Bay12 forum should be removed - especially dead ones]
* This unofficial Discord is actively opposed to the standpoints that Toady One and Threetoe have posted on the bay12games site over the recent days.
* This unofficial Discord uses slurs and other problematic language that actively harms the image of the Dwarf Fortress community
* This unofficial Discord will likely make it so that people steer away from the game.

I do not feel comfortable with the Wiki platforming a known racist Discord server, as that is de facto support of the messages of that server.
[[User:AlastríonaCatskill|AlastríonaCatskill]] ([[User talk:AlastríonaCatskill|talk]]) 12:02, 21 June 2020 (UTC)

Update: Apparently, this same Discord has been banned from the r/dwarffortress subreddit for as long as one of the mods can remember, and the link to it was banned on the official Kitfox Discord as well. I can post the screenshots I have of actively problematic behaviour on this Discord but I will not do it unless necessary, as the contents are alarming like that which will not be named. [[User:AlastríonaCatskill|AlastríonaCatskill]] ([[User talk:AlastríonaCatskill|talk]]) 12:10, 21 June 2020 (UTC)

:I've removed the link. Safe to say, we don't need the wiki to be associated with this sort of people. [[User:OluapPlayer|OluapPlayer]] ([[User talk:OluapPlayer|talk]]) 21:58, 21 June 2020 (UTC)

::The "Unofficial Bay 12 Discord" was already not linked on the main page - the only place it was mentioned is this talk page. Are you talking about that one or the Unofficial Dwarf Fortress Discord that is linked on the main page? The latter does have it's #elfposting channel, but that channel is initially hidden, opt-in only, and clearly labelled as a lawless zone. For an analogy, there are many very awful subreddits, but we still link to reddit - (yeah that's a little different but not much). Otherwise the unofficial DF discord is well modded and such behavior is not allowed in other channels. So, are you certain which discord/channel the screenshots came from? [[User:Ziusudra|Ziusudra]] ([[User talk:Ziusudra|talk]]) 22:29, 21 June 2020 (UTC)

Since there's some confusion, AlastríonaCatskill, could you confirm and/or provide some evidence that following the link that was on the main page (removed in [https://dwarffortresswiki.org/index.php?title=Main_Page&diff=253449&oldid=251109]) takes you to the discord that you were referring to? The only reference I can find to a discord removed from the /r/dwarffortress sidebar is for a different discord, not the one that was linked on the main page (although it's possible that just the invite link was different). I just want to make sure that we're removing the right one here. If you have anything that you don't want to share publicly, you can PM me on the forums (same username) or [[Special:EmailUser/Lethosor|email me]] through the wiki, which I think is working. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 01:45, 22 June 2020 (UTC)

:@Lethosor, I have emailed you the relevant images via the link you had created. The Discord that was on the main page and removed today is indeed what was being referred to, especially with the confirmation of the #elfposting channel being from said Discord. In my opinion, @Ziusudra, the inclusion of a problematic part of that community, even as opt-in, is unacceptable in my book for a community to be platformed on this Wiki. [[User:AlastríonaCatskill|AlastríonaCatskill]] ([[User talk:AlastríonaCatskill|talk]]) 03:26, 22 June 2020 (UTC)

Hello, I am the owner of the Unofficial Dwarf Fortress discord. I just want to clear a few things up and open a channel of communication.
Several years ago, the original owner of the discord left, in no small part due to all the sexism and racism and such.
After a few days of an having an interim owner, it was given to another user, who onboarded several users as admins, including me.
The new owner tried a lot to curb terrible stuff on the server, however this often lead to drama.

The r/dwarffortress delisting happened after some of that drama spawned a new discord with a more "free speech" orientation,
things spilling over to the forums and other places. Some time after that, she left the server to me, due to the amount of
stress running that place caused her. When I took over I also tried to make it a better place, but with slower and subtler
methods that wouldn't spark drama. Completely disallowing some behaviour outside of #elfposting was part of that,
and later making that channel hidden by default was another. Now, the discord is much much better to be in
than it ever was before, though it still has major flaws. I don't like #elfposting at all myself, but I don't rule with an iron fist nor
do I know what much I can do without sparking massive drama again. Since April this year I have had some plans to make the discord
quite a bit better, however some of my mods have been against it in part due to feeling it would cause bigger problems
(though, as you probably know, some of them participate in #elfposting).
With recent events, both within and outside the DF community, we have decided to move ahead, every mod on board,
with some plans including phasing out the #elfposting channel in a way which will not create large issues for moderation.
It will be fully gone within one (1) week of now.

Also, I am a tad annoyed that you posted about this here but completely neglected contacting us. In the future, could you
please contact me or one of my mods when you have any concerns about the server? I really do care about these things and we need feedback.
—[[User:Lonjil|Lonjil]] ([[User talk:Lonjil|talk]]) 10:32, 22 June 2020 (UTC)

: Thank you for replying here Lonjil. Unfortunately, I cannot trust your take on this matter for several reasons.
: # One of the moderators has an anti-semitic stereotype profile picture
: # Even if the only place of no censorship is the elfposting channel, and even if it is opt-in, the complete chaos of racist slurs allowed there is completely unacceptable for minority players and an extremely toxic environment. There have been instances of straight hate speech on the channel / server as well, suggesting to kill people of colour and LGBTQIAA+ people.
: In short, the toxicity of your Discord's community makes it not just uncomfortable, but downright dangerous for minority people playing Dwarf Fortress. As Tarn and Zach have made liberal-to-leftist political views in the past, the chances of minorities to play the game is higher - and I wouldn't want to be a person of colour signing up for a shitposting channel to only be met with over 10,000 instances of the hard-n word being used. The Discord should remain off of the Wiki until things shape up and all instances of hate speech be purged from server history. Personally I would rather all non-official channels of communication be removed from the page, period, but that is a less pressing discussion than active hatred of minorities being platformed on the Wiki via your unofficial Discord. [[User:AlastríonaCatskill|AlastríonaCatskill]] ([[User talk:AlastríonaCatskill|talk]]) 12:30, 22 June 2020 (UTC)

:: Small edit / follow-up to my previous message. My friend tells me that elfposting is the most commonly used channel, which goes to show the level of hatred allowed into the community. It may be best to remove the channel in entirety, and make a new meme channel with no hate speech allowed. [[User:AlastríonaCatskill|AlastríonaCatskill]] ([[User talk:AlastríonaCatskill|talk]]) 12:33, 22 June 2020 (UTC)

::: The admin you are referring to is a jew, who lives in Israel. I prefer to not police people of other ethnicities when it comes to negative stereotypes and such of themselves, they know what they are comfortable with far better than I ever could.

::: Elfposting is not, by any reasonable measure, the most used channel. It has fewer users than any other channel. It has a fair number of messages, but only because there is no rule against spamming in there. So, nearly all of it is spam, which was the point of the channel to begin with.

::: "It may be best to remove the channel in entirety" this is exactly what is happening, as I already said. We're giving the channel regulars a few days to hear the news, but then the channel will be gone. We already have a more pleasant meme channel from an experiment we did in April, which we are bringing back. —[[User:Lonjil|Lonjil]] ([[User talk:Lonjil|talk]]) 13:57, 22 June 2020 (UTC)

Hi all - thanks for keeping this discussion civil. I've been investigating the policies of other DF communities, and I've come to the conclusion that it would be best for the wiki to only link to the official DF Discord (Kitfox). I'll also make a pass through the other sites linked on the main page. I'm sorry to those of you working hard to maintain Discords and other unofficial communities out there - I know it's difficult, and I don't want to judge your communities without being a part of them. However, there will always be debates like these about whether a community deserves to be linked from a more "official" place, like the wiki, and no matter where we draw the line(s), people will be upset. The policy of only linking to the Kitfox Discord seems to have worked for other communities, which is why I'm applying it here. I would be happy to have a broader discussion at [[DF:Centralized Discussion]] if anyone wants to. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 01:48, 23 June 2020 (UTC)

== Put Chinese language wiki on other Languages ==
Found it on Internet([http://cdf.wikidot.com/start]) – [[template:unsigned|unsigned]] comment by [[User:45.58.187.66|45.58.187.66]]

:I added a link to it. I'm not sure what the process is for adding interwiki link support (support for links to pages in the sidebar, like how [[DF2014:Cat]] links to http://dfwk.ru/Cat) but I can look into that too. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 01:40, 19 August 2020 (UTC)
::Hello! I'm the admin of [https://dfzh.huijiwiki.com/ Chinese Dwarf Fortress wiki], and I've previous put its link on the main page. We've now enabled interwiki link from our site to English site, and we wish to get one back from English site to CN site as well. Hope that is possible, and thanks so much! The URL for our site should be: <code>https://dfzh.huijiwiki.com/wiki/$1</code> [[User:Xjtu-blacksmith|xjtu-blacksmith 黑山雁]] ([[User talk:Xjtu-blacksmith|talk]]) 11:26, 1 November 2022 (UTC)

:::Added. Prefix is "zh", for example: https://dwarffortresswiki.org/index.php?title=Main_Page&diff=266849&oldid=266730 —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 19:45, 28 November 2022 (UTC)

== Villains Wiki ==

To started putting some creatures on the Villains Wiki, because I want to spread the word of Dwarf Fortress around, and these creatures fit the theme of the wiki anyway. Here's an example page, and the template of all pages: 
[https://villains.fandom.com/wiki/Goblins_(Dwarf_Fortress) Villains - Goblins] 
[https://villains.fandom.com/wiki/Template:Dwarf_Fortress_Villains Villains - Template of DF Villains]

If anyone could add more info to those pages, or think more creatures should be on that wiki, please let me know. Or you could add it yourself. -- [[User:Zippy|Zippy]] ([[User talk:Zippy|talk]]) 13:37, 9 January 2021 (UTC)

== Replace Chinese Wiki with the new one on Fandom ==

The previous Chinese wiki on wikidot seems to be inactive for a long time, with its main page refers to the download link of v0.44.10, and most pages are never updated even earlier than that version. Recently we are working on a new site on Fandom ([https://dwarf-fortress.fandom.com/zh]), trying to keep everything up to date. Wish to replace the links on dwarffortresswiki's main page and the sidebar link (inter-language link) with the one at Fandom, so that more people may get to the right place and join us. [[User:Xjtu-blacksmith|xjtu-blacksmith 黑山雁]] ([[User talk:Xjtu-blacksmith|talk]]) 04:16, 30 December 2021 (UTC)

:I've added the link of Fandom site onto the main page, without removing the previous one. [[User:Xjtu-blacksmith|xjtu-blacksmith 黑山雁]] ([[User talk:Xjtu-blacksmith|talk]]) 11:09, 12 May 2022 (UTC)
:We've migrated Chinese Wiki to huijiwiki.com, which is now shown on Main Page. [[User:Xjtu-blacksmith|xjtu-blacksmith 黑山雁]] ([[User talk:Xjtu-blacksmith|talk]]) 07:41, 29 May 2022 (UTC)

::Added. The "zh" prefix should work for links. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 19:43, 28 November 2022 (UTC)

== Kitfox Discord ==

<blockquote>
''2022-04-15 BlueManedHawk . . (8,594 bytes) (-135)‎ . . (The Kitfox Games discord server has an unethical code of law. I don't think the wiki should be supporting it.)''

''2022-04-15 Ziusudra . . (8,729 bytes) (+135)‎ . . (Undo revision 263652 by BlueManedHawk[:] please discuss changes such as this on the talk page first) (Tag: Undo)''
</blockquote>

Alright, I can do that.

The Kitfox Games discord server has a code of law that contains the following immoralities:

:- Is very vague and nebulous, allowing the moderators to exploit the vagueness to be able to do very different things in similar circumstances in alignment with their biases. (Not that they do that, but the fact that it's possible is concerning.) 
:- Contains a "These rules are subject to common sense." clause, essentially meaning that the moderators are able to do whatever they want and hide it behind the barrier of "common sense". This goes completely against the point of the concept of rules in the first place as a promise from those in power in regards to what they will and will not do. 
:- Allows for infinite punishment.

That last one could do with a bit of explaining. Let us begin with the premise that the punishment for a crime should be proportional to the severity of the crime. I think we can all agree on this. Therefore, an infinite punishment should only ever be given for an infinite crime. However, humans are not infallible. People make mistakes. And this means that if a court of law is able to administer an infinite punishment, they run the risk of accidentally giving somebody an infinite punishment that they do not deserve. This, I think we can all agree, is unnacceptable. Therefore, infinite punishment cannot every be administered ethically.

I hope that this explains why I want the link to the Kitfox games discord removed.

Regards,

—[[User:BlueManedHawk|BlueManedHawk]] ([[User talk:BlueManedHawk|talk]]) 22:29, 15 April 2022 (UTC)
:* Their rules are not vague or nebulous, they even give examples of what the rules cover. Of all the discords I am on, their rules are some of the most detailed.
:* The "''depending on the action and our judgement''" is quite similar to the "''depending on how disruptive you were and your prior history''" found in the DF forum rules, and is pretty standard social media boilerplate and is itself common sense.
:* Their rules state "''Breaking these rules will result in a warning or ban''", which is not at all "''infinite punishment''", and is again quite similar to the "''If you violate the guidelines, you will be warned, muted for a period of days, or banned completely''" on the forums. It's not like they can keep anyone from playing the game or interacting with the other communities.
: Your referring to their rules as "code of law" is hyperbolic. Their rules are quite similar to the rules of the forum. So, I disagree and think the link should stay. [[User:Ziusudra|Ziusudra]] ([[User talk:Ziusudra|talk]]) 23:13, 15 April 2022 (UTC)
::* The rules are pretty vague. Examples aren't enough. A strict, clear, unambiguous definition is necessary to prevent abuse.
::* While it is true that their clause is ''normal'', that doesn't mean it's ''right''.
::* The explanation of bans doesn't explain how long the bans will last. Since there's nothing explicitly stating that infinite punishment won't be given, and since "ban" by itself generally refers to a permanent ban, I think that it's allowing infinite punishment.
::* I'm not sure how the term "code of law" is hyperbolic. I use the term synonymously with "set of rules".
::* I can't seem to find a code of law for the forums. However, if what you said is true, then clearly we should also remove the link to the forums.
::
:: Regards,
::
:: —[[User:BlueManedHawk|BlueManedHawk]] ([[User talk:BlueManedHawk|talk]]) 02:59, 16 April 2022 (UTC)
::: http://www.bay12forums.com/smf/index.php?topic=27009 It's linked in the header at the top of every forum page, though if the header is collapsed you won't see it.
::: Unambiguous rules are technically impossible since human behavior is limitless. That's why we hav judges for actual laws - even society's strictest laws need a human adjudicator. Then, even with "permanent bans", both Kitfox and Bay12 hav public email addresses and twitter accounts which can be used to petition to hav a ban removed.
::: Finally, suggesting the removal of the links to the official forums for the game this wiki is dedicated to is unreasonable, to the point of making me wonder if you're trolling. [[User:Ziusudra|Ziusudra]] ([[User talk:Ziusudra|talk]]) 04:59, 16 April 2022 (UTC)

::::I agree with Ziusudra. More broadly, I think we should keep links to "official" DF channels, and Kitfox is a DF publisher. If a potential for "infinite punishment" warrants removing links to the offending site, then by your logic, we should remove all links to the wiki from the wiki because users here have been banned permanently. That has been done based on the best judgement of the people who volunteer their time to run the wiki and has been open to appeals, and I expect other channels are similar. I'm not interested in entertaining this argument here. If you have specific issues with a specific external site, I suggest that you get in touch with the moderators there instead. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 05:34, 16 April 2022 (UTC)

:::::Hello.

:::::As I mentioned below, the DFWiki is in a position of power, and by removing the link to them, we can potentially force their hand into making their code of law more moral. On the other hand, keeping the link there could potentially be seen as supporting their immoral behavior, tarnishing the reputation of the site. This is why I brought up my issues with an external site onto this one: because these issues also affect it.

:::::It is true that by my logic, the DFwiki is operating immorally. However, I would like to mention that ''you are in a position of power on the wiki'', Lethosor. I would think that you have the ability to change the Wiki's code of law to be more moral. You have the choice to make the wiki a better place, and I advise that you take it.

:::::Regards,

:::::—[[User:BlueManedHawk|BlueManedHawk]] ([[User talk:BlueManedHawk|talk]]) 06:22, 16 April 2022 (UTC)

::::Hello.

::::* I don't know which header you're referring to—wherever it is, it seems to not be there for me. Regardless, I thank you for clarifying which guidelines you were referring to.
::::* Unambiguous rules are largely impossible because nobody has yet created an unambiguous language. However, that doesn't mean that we shouldn't still seek to get as close to unambiguous as possible when constructing a code of law.
::::* Claiming that the bans are transient because it's possible to appeal them is optimistic, and while there is a place for optimism, this is not it. Any potential that a legal system has for corruption is one that we cannot assume will not be used, and often, corruption begets corruption, continuing the cycle until a revolution happens.
::::* Being a central repository of knowledge on DF, the DFwiki is in a position of power. If we do remove the link to the Kitfox discord under the condition that they make their code of law more moral, then we can theoretically force their hand, maybe. There is, of course, a risk to this, and this should be deliberated before a decision is made.
::::* I am not a troll. Why does everybody keep thinking that?

::::Regards,

::::—[[User:BlueManedHawk|BlueManedHawk]] ([[User talk:BlueManedHawk|talk]]) 06:22, 16 April 2022 (UTC)

== Advertisements problem ==

One of the full-page advertisements(a pop-up that obscures the whole page) had what looked like a "close" button, but it just tried to redirect me to another page.
Full page advertisments aren't untoward but like, web elements that say 'close' are expected to do what they say, otherwise it's intercepting clicks. – [[template:unsigned|unsigned]] comment by [[User:Eerr|Eerr]]

:Do you have a screenshot of the offending ad, or can you take one if it happens again? My understanding is that that is something we (admins) don't have control over, but we can report misleading ads to Google. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 03:09, 2 June 2022 (UTC)

== Kitfox Discord (again) ==

Hi. I'm again requesting the removal of the link to the Kitfox discord server for only two reasons this time: the code of law gives infinite power to the moderators, and the criminal justice system uses punishment to deal with criminals. These are obviously both immoral, and until the server fixes these issues, the DF wiki ought to remove the link so as not to seem to be promoting them. [[User:BlueManedHawk|BlueManedHawk]] ([[User talk:BlueManedHawk|talk]]) 21:45, 15 September 2022 (UTC)
:And again, I don't support removing the official publisher's discord just because you think that there is some thing wrong with their completely normal and reasonable moderation practices, none of which involves "infinite power", "punishment", "criminals", or other such hyperbole. Banning is not "punishment", it is protection of the community from those that act to harm it, nor is it "infinite power" since all it does is keep those rule breakers off one discord server and nothing else. All of which also happens on both the Bay12 Forums and this very wiki, both of which, by your logic, you should immediately stop using lest you appear to be promoting them. [[User:Ziusudra|Ziusudra]] ([[User talk:Ziusudra|talk]]) 03:45, 16 September 2022 (UTC)
::Normalizing of horribly unethical practices is not okay. I do not think it is hyperbole to use the terms "infinite power, "punishment", and "criminals". The server is a jurisdiction like any other, and it should be held to the same standards of morality as any other—this includes not using punishment as a means to deal with those who break the law. It is completely possible to protect the community without using bans—bans simply get rid of problems instead of fixing them, and are ineffective against the diligent. Infinite power is not an okay thing to give to those who govern a jurisdiction—dictatorial power structures have been shown to fail many times over throughout history.
::
::If we simply must keep any official venues for DF on the main page, regardless of morality (this includes the forums, which i agree should also be removed), then the Wiki ought to put a disclaimer of some sort clarifying that they are being listed not in support of the governance policies of the communities, but simply because they are official.
::
::[[User:BlueManedHawk|BlueManedHawk]] ([[User talk:BlueManedHawk|talk]]) 17:24, 17 September 2022 (UTC)
:::Good god, how many of these discussions are you gonna keep making? Is there anything that ''doesn't'' offend you? -- [[User:Zippy|Zippy]] ([[User talk:Zippy|talk]]) 13:14, 22 September 2022 (UTC)
::::There's no need to be rude. But to answer your question, i'm going to have as many discussions as are necessary until a concensus is reached. [[User:BlueManedHawk|BlueManedHawk]] ([[User talk:BlueManedHawk|talk]]) 21:43, 22 September 2022 (UTC)
:::::You can't keep just keep making constant requests of "guys can we please remove that and that and that and this and this because of like business and anti-competitive stuff and yeah and like" but then turn around and go "why does everyone think I'm a troll?" Can you seriously not connect those two things together? I've been part of this community for a long time, and you are the one and only person who gets all offended by things that no one else would even care to think about. This wiki is not the place for that. -- [[User:Zippy|Zippy]] ([[User talk:Zippy|talk]]) 10:48, 23 September 2022 (UTC)
::::::I really don't understand why people think that i'm a troll. If you or someone else were to explain it to me in a manner that's more polite than your previous messages have been, i'd be happy to listen. [[User:BlueManedHawk|BlueManedHawk]] ([[User talk:BlueManedHawk|talk]]) 20:18, 23 September 2022 (UTC)
:::::::Hmmmmmmm, no. I'm gonna skip the "polite" thing and just speak the truth. No regrets. The fact that you can't see why people think you're a troll makes the situation even worse. You're someone who got all bent out of shape over a Minecraft diamond reference, something that no one else would ever care about. You keep saying you don't see how people think you're a troll when it was explained to you many times. All this goofy legal stuff you keep bringing up is best left elsewhere. Not here. -- [[User:Zippy|Zippy]] ([[User talk:Zippy|talk]]) 13:59, 24 September 2022 (UTC)

== Wiki logo ==

The new wiki logo requires getting used to. Personally, I wouldn't mind something simpler like [[:File:Dfhack-logo.png|DFhacks]] with a more fancy version going to the mainpage. Maybe someone from the community can come up with something, here is what [https://ibb.co/26J569S my meager skill] able to come up with --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 13:20, 7 December 2022 (UTC)
:I just noticed it and I have to agree. It's like being hit in the face with a brick. It references DF relatively deep lore ([[obsidian]] and [[semi-molten rock]]) and it feels way too harsh compared to the relatively relatable and much more early-game relevant icon of a dwarf mining. --[[User:Lurker|Lurker]] ([[User talk:Lurker|talk]]) 13:01, 10 December 2022 (UTC)
:: For reference here is the [[:File:DFDefault.png|digger]] from the classic intro and bellow rendering of what steam version uses in its loading phase, as well as [https://ibb.co/mtzdLm3 this simple variant]
<diagram>
¦¦¦¦¦¦
¦ ¦
¦ ¦
¦ ¦ ¦ ¦
▒ ▒
▒▒▒▒▒▒▒▒
▒▒ ¦¦ ▒▒
▒▒▒▒▒▒
▒▒▒
▒▒
</diagram> --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 15:39, 11 December 2022 (UTC)

== steam release ==

: "''We are working on a migration that will be complete in the next few days''"
Any estimate on how long that is going to take? --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 08:53, 10 December 2022 (UTC)
: Additionally, who is working on this wiki migration, and why is it a closed process? I feel like the migration could have been largely completed by now if everyone was able to help, but that sentiment may just be coming from my ignorance. [[User:Trainzack|Trainzack]] ([[User talk:Trainzack|talk]]) 00:40, 17 December 2022 (UTC)
::See thread at [[Dwarf_Fortress_Wiki_talk:Versions#v50_organization]]. Emi and I are planning to use a MediaWiki bot for this. My current ETA is 2 days from now. I've asked for help in a few places to write such a bot and have had no responses. My concern with a manual migration (e.g. if we have people copy over just some pages manually) is that it would likely result in a state that is much more complicated to finish. I'm sorry it hasn't gotten done yet. Open to help with automating this. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 04:39, 17 December 2022 (UTC)
:::Ah, that page completely eluded me! Thanks for pointing in that direction. I would be totally willing to help write a bot, just let me know what I can do. [[User:Trainzack|Trainzack]] ([[User talk:Trainzack|talk]]) 14:37, 17 December 2022 (UTC)
::::Thanks for offering. I actually ended up with some time today to work on the migration script. It's almost done, just need to run some final checks before setting it loose. Hopefully tomorrow. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 07:15, 19 December 2022 (UTC)

== wiki tasks ==

Dwarf old head but new account. I'm trying to do a little grunt work for migrating raws and stuff every time I browse the wiki but adding raws is gated behind the adding a page permission. Is there a honey-do list for stuff that needs editing in order to get some contributions under my belt? ☺ --[[User:Hotty gremlin|Hotty gremlin]] ([[User talk:Hotty gremlin|talk]]) 01:47, 24 December 2022 (UTC)
:This lists every page that still has the migration template on it: https://dwarffortresswiki.org/index.php/Special:WhatLinksHere/Template:Migrated_article [[User:Ziusudra|Ziusudra]] ([[User talk:Ziusudra|talk]]) 02:26, 24 December 2022 (UTC)

== New main page gallery images ==

Should we start some sort of initiative, maybe over discord as well, for people to provide a few new images from the premium version to use on the main page? --[[User:Vallode|Vallode]] ([[User talk:Vallode|talk]]) 15:47, 6 January 2023 (UTC)
:What's stopping us from just extracting the sprites? [[User:BlueManedHawk|BlueManedHawk]] ([[User talk:BlueManedHawk|talk]]) 23:05, 6 January 2023 (UTC)
::Nothing, but I'm talking about screenshots from in-game similar to the ones in [[Main_Page/gallery]]. :) --[[User:Vallode|Vallode]] ([[User talk:Vallode|talk]]) 09:26, 7 January 2023 (UTC)
:::Ahhh. Yeah, i suppose that half of the screenshots should be from Premium. [[User:BlueManedHawk|BlueManedHawk]] ([[User talk:BlueManedHawk|talk]]) 20:21, 7 January 2023 (UTC)
::Same as one can do from any official screenshots or youtube videos. And lets just say that anyone who want to get their hands on the sprites will not waste time here, there are far easier/quicker alternatives so much so that I can probably make you lmgtfy link for it. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 11:32, 7 January 2023 (UTC)
:For what it's worth, I think there has historically been some level of notability in the screenshots provided, and I'd like for that to continue. E.g. a screenshot of an interesting event would be a good fit, but a screenshot of two cats for the sake of showing something with the premium tileset might not be such a good fit. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 03:13, 8 January 2023 (UTC)

== Migration Progress ==

{{User:OddballJoe/Sandbox/MigrationProgress}}
Made a migration progress bar we could use for the main page. I think it might be a bit too depressing, haha. I'd add a separate category for [[Template:migrated section]] to populate it. Might need to double-check [[User:OddballJoe/Sandbox#stats|my math]] before adding it. [[User:OddballJoe|OddballJoe]] ([[User talk:OddballJoe|talk]]) 02:23, 8 January 2023 (UTC)

:Fixed the math, looks good to me. Will add if nobody objects. [[User:OddballJoe|OddballJoe]] ([[User talk:OddballJoe|talk]]) 19:28, 10 January 2023 (UTC)

== Proposal for holistic crafting/construction format changes across the wiki ==

I propose that any item, workshop, or building that can be constructed or crafted have a unified formatting applied to its entry page pertaining to its constituent components ("Rock boulder x1"), product output ("Rock block x4), and workshop of construction ("Stoneworker's Workshop").

Problem being solved: User visiting pages on the wiki is met with inconsistent or absent information regarding the production and workshop location of many if not most items. When this information does exist, it is typically located inconsistently within the page in-line with narrative text.

"Steel" on the wiki is the best example of this being done but with this proposal I feel that a unified tabled format would help improve readability across the board and build user expectation.

I'm new to wikis but I am starting my workday now and will revisit this topic throughout the day to propose a format to seek feedback and gauge temperature on the subject.

Individual item names within a recipe should be hyperlinked to the wiki entry for that item for good UX, contributing to a user's ability to flow through their problem and quickly find the information they're seeking.

To get the ball rolling, parameters for some examples would be:

"Rock Block"

Recipe

Skill used: Stonecrafter

Workshop: Stoneworker's Shop

Required Components: Economic or Non-economic Stone Boulder x1

Resulting Product: Stone Block x4

"Metworker's Shop"

Recipe

Required Components: Stone Boulders, Blocks, Bars x1

"Bridge"

Recipe

Required Components: Stone Boulders, Blocks, Bars x(Variable)

Note: Please mind the formatting on this proposal, though the idea is sound I've yet to interface with this markup, my field is UI/UX and I will revisit this post once I've brushed up on wiki formatting to make this proposal shine. – [[template:unsigned|unsigned]] comment by [[User:Venality|Venality]]

: I'm in favor of something like this. We already do it for workshops with {{tl|V50_workshop}} and could do something similar for items. Couple of thoughts:
* Some of the recipes (aka reactions) are defined in the raws, not sure what proportion. It might be worth considering automating the inclusion of some of this data from raws, with parser functions or Scribunto or an external script.
* A lot of this data would be helpful to cross-reference. E.g. an item page lists the workshop needed to make it, the workshop page lists the items it can make, and a material page lists the items that can be made from it. This could be set up to stay up-to-date with an extension like [https://www.mediawiki.org/wiki/Extension:Cargo Cargo]; I've never used it but it looks reasonably straightforward. That could help organize a lot of other data too, like creatures. [[User:OddballJoe|OddballJoe]] ([[User talk:OddballJoe|talk]]) 19:31, 11 January 2023 (UTC)

== Bad caching of main page ==

Viewing the main page right now, logged out in an incognito window, displays the latest version as v50.05 and the "up-to-date" article count as 266, instead of v50.07 and 310. The html shows "Cached 20230205190127", so it's a 3-day old cached page. It also says "Cache expiry: 3600", which seems to imply hourly expiry. Maybe adding <nowiki>{{CURRENTHOUR}}</nowiki> to the page will force a cache expiry via the magic word cache logic? In any case, caching needs to be fixed so we're not serving outdated pages. —[[User:OddballJoe|OddballJoe]] ([[User talk:OddballJoe|talk]]) 17:43, 8 February 2023 (UTC)

== Outdated Knockout Link ==

Please update the link to the Knockout forum thread to [https://knockout.chat/thread/46824 this one], as the current link on the page links to a closed thread. I'd do it myself but the Main Page appears to be locked to admin-only edits now. [[User:OluapPlayer|OluapPlayer]] ([[User talk:OluapPlayer|talk]]) 13:53, 25 April 2023 (UTC)

== Duplicate version links ==

At the top of the page, under the number of articles, are links to the previous versions. At the bottom of the page, more version links are listed after "Archives", which appear to be redundant and can be removed. --[[User:Cali|Cali]] ([[User talk:Cali|talk]]) 01:28, 30 April 2023 (UTC)

== Remove the link to Masterwork ==

Hello. Currently the Other/Mods section has a link to [[Masterwork:Main_Page|the Masterwork namespace]]. I vouch for that link to be removed for three reasons:
#
# It no longer works with the current version of DF, due to the mod changes in v50.01. A mod(pack) which is not playable on the version of the namespace, should not be advertised before all others, if at all. The [[list of mods]] does not include mods which are outdated for the namespace.
# I believe that its popularity has heavily waned, and though it once was a contender for the most popular raw setup (including vanilla!), this is far from the case now. It not being updated for a long time likely contributes. So the break-out popularity of its past which warranted a link does no longer exist.
# The downloads are broken/removed due to the whole Meph debacle. This is an issue with the Masterwork namespace as a whole, which needs separate discussion over there. But essentially it breaks the purpose of the Masterwork namespace, since they document an unavailable mod, and fail in providing (links to) downloads for the mod. The Main Page should not link to pages that serve no purpose.

--[[User:Voliol|Voliol]] ([[User talk:Voliol|talk]]) 11:26, 21 July 2023 (UTC)

:That sounds fine to me. The only edit in the past [https://dwarffortresswiki.org/index.php/Special:RecentChanges?hidebots=1&namespace=1000%3B1001&limit=500&days=90&enhanced=1&urlversion=2 90 days] was a spam edit to [[Masterwork:Salamander]]. What link should we put in its place? It would be nice to keep an even number of links if we can. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 03:43, 22 July 2023 (UTC)

::Category:Game_development maybe? Fits the category of "other", isn't already on the main page, and is of general interest. [[User:Ziusudra|Ziusudra]] ([[User talk:Ziusudra|talk]]) 22:04, 22 July 2023 (UTC)

:::What about [[DFHack]]? It is an utility like others in the linked [[utilities]] article, but it is greater in scope and likely popularity, to the point of being on Steam separately from ''Dwarf Fortress'' itself. The Other/Mods section seems to be about a combination of ways players can interact with the game and add to it, beyond its usual scope, and technical details. DFHack fits right into this by not only being a player-made utility, but by providing an environment for players to binary hack the game, and of course being highly technical. —[[User:Voliol|Voliol]] ([[User talk:Voliol|talk]]) 09:09, 3 August 2023 (UTC)

== Broken Bug Tracker Link ==

The "Mantis Bug Tracker" link on the main page (at the bottom in the "Useful Links" section) is broken, pointing at the old bug reporting page.
As per the [https://kitfoxgames.notion.site/How-to-Report-Bugs-in-Dwarf-Fortress-Updated-Nov-2023-b5e2ca19dabe408897d1c2669599b7a2 Kitfox Announcement (from Nov 2023)], it should now be pointing to the page https://dwarffortressbugtracker.com.
I'd also recommend updating the text of the link from "Mantis Bug Tracker" to just "Bug Tracker" or "Dwarf Fortress Bug Tracker".

Note that I already made this update on the [[Known bugs and issues]] page, it just needs to be propagated to the main page (which I can't do because the main page is locked).

== Remove or Replace Blogs ==
Both entries ([http://dfstories.com/ Dwarf Fortress Stories], [http://www.bravemule.com/ Bravemule]) in the blog section are broken. I think it would make sense to remove the mention of blogs altogether. To my knowledge, there is no DF blog in existence to replace those? [[User:Urist2000|Urist2000]] ([[User talk:Urist2000|talk]]) 22:34, 2 December 2024 (UTC)
:Yes, please remove these. Dfstories has been down for 6 months. Bravemule hasn't had Dwarf Fortress content since 2016. [[User:Jecowa|Jecowa]] ([[User talk:Jecowa|talk]]) 09:56, 27 January 2025 (UTC)
:Can they be replaced with links to archived versions of the websites instead of being totally removed? [[User:Ringtail Raider|Ringtail Raider]] ([[User talk:Ringtail Raider|talk]]) 19:14, 20 October 2025 (UTC)

== Broken link in Blogs section ==

The link to Bravemule in the blogs section is dead - the most recent archive.org mirror I can find is https://web.archive.org/web/20161115202645/http://www.bravemule.com/matulremrit/

I tried to update this myself, but the page is protected.

Edit: Just saw the discussion point above. The most recent archive.org mirror for dfstories.com is https://web.archive.org/web/20240223090633/https://dfstories.com/

--[[User:Urist208|Urist208]] ([[User talk:Urist208|talk]]) 21:47, 30 January 2026 (UTC)

== Error for submitting discussion page ==

Trying to start a discussion page ("submit") for an existing article will always result in an error message like this: [2f5c283358b9e32de489c3f4] 2026-06-08 09:15:20: Fatal exception of type "Error"
I found no way to report bugs for this wiki.