Dwarf Fortress Wiki - User contributions [en]

Large pot

2023-02-04T08:35:52Z

Kelvie: /* Material selection */ Add volume of large pots (from dfhack's getVolume() function)

{{migrated article}}
{{Quality|Unrated}}

{{av}}
{{buggy}}

{{item|name=Large pot
|tile={{char|232}}
|wood=n
|woodcraft=y
|stone=n
|stonecraft=y
|metal=n
|metalcraft=y
|glass=y
|cloth=n
|leather=n
|ceramic=y
|bone=n
|shell=n
|gem=n
|wax=n
|used for=
* Storage
}}

'''Pots''', also known as '''large pots''', are containers that function much like [[barrel]]s, and have the same capacity, but can be made from materials other than wood or metal, such as [[stone]], [[ceramic]], and [[glass]]. The game refers to these containers sometimes as "pot" and sometimes as "large pot" but there is no actual distinction.

For most uses, large pots can replace [[barrel]]s. However, stone pots are usually heavier than wooden barrels, so tasks that require moving stone barrels may be slowed to some extent compared to wooden ones. (See "[[Large pot#Material selection|material selection]]", below).

Note, however, that large pots cannot replace barrels in all situations. Some tasks may ''specifically'' require "barrels" (eg. "Process Plant to Barrel"), and some workshops '''specify''' a barrel for their construction, e.g. an [[Ashery]] or [[Dyer's shop]].

Large pots can be made from stone by a [[stone crafter]] at a [[craftsdwarf's workshop]], [[ceramic]] at a [[kiln]], [[glass]] at a [[glass furnace]], [[wood]] at a [[craftsdwarf's workshop]], or [[metal]] at a [[metalsmith's forge]]. Pots made from stone, [[stoneware]], [[glass]], [[wood]], [[porcelain]], [[metal]], or [[glaze]]d [[earthenware]] are water-tight and can be used to store liquids, and even for [[brewing]]. Unglazed earthenware can only be used for storing dry items. Metal pots are made using the [[metalcrafting]] skill, as opposed to metal barrels, which use the [[blacksmithing]] skill.

Pots are stored in the Large Pots/Food Storage section of the Furniture stockpile. Empty pots are listed under Tools when viewing the fortress's [[stocks]] or when moving them to a [[trade depot]].

== Material selection ==
As with other containers, several factors are relevant in choosing the proper material for making large pots. Namely, availability, value, fire/magma safety, vermin resistance, <s>hippie</s> elf kosherness, and most importantly '''weight'''.

Pots made from stone of typical* [[Density#Density of some materials|density]] will be 33% heavier than typical* wooden barrels. Fire clay "stoneware" pots weigh the same as a wooden barrel, while earthenware pots are lighter but must be glazed. This makes large stone pots superior for any stockpile that does not require the containers to be moved, such as [[Kitchen|prepared meals]]. Ceramic pots are superior to typical wood in all cases.

: (* There are exceptionally light or heavy examples of both stone and wood, but the majority of types of each fall into a "typical" weight category.)

Pots are only 1/4 as heavy[http://www.bay12forums.com/smf/index.php?topic=127471.msg4342164#msg4342164] as barrels made from the same material (e.g. metal, glass). This means metal pots are generally a better storage option than metal barrels, saving the industry precious dwarf-hours by hauling faster due to lighter containers. Additionally, a metal barrel costs '''3''' bars, but a metal pot only '''1''', making metal barrels a vastly less attractive option.

But in the case of large pots, stone is typically used chiefly due to its abundance, especially for young outposts. Doing so will conserve wood (likely the only other economic choice) for tasks for which stone cannot be used (and metal is not always practical), such as making [[bed]]s, [[bin]]s, [[bucket]]s, [[cage]]s, [[charcoal]], [[crutch]]es and [[splint]]s, [[pipe section]]s, [[stepladder]]s, [[training weapon]]s, [[wheelbarrow]]s, and many other items* of various usefulness and importance.
: (* [[crossbow]]s & [[bolt]]s could fall here, too, but those often deserve to be made of a weapons-grade metal)

Large pots take up 500 units of volume.

Unless, of course, the embark location has trees aplenty, making it viable to use wood for most everything, including pots, though this obviously requires a sufficient amount of woodcutters, wood crafters, axes, and contempt towards the <s>tree-huggers</s> elves.

== Forging and Melting ==

* Metal pots cost '''one''' [[metal]] bar to forge, or '''one''' [[adamantine]] wafer.

* When a pot is [[Melt item|melted]] down, it will return '''0.3''' metal bars/adamantine wafers for an efficiency of '''30%'''.

== Bugs ==
* Pots will not be used for processing [[sweet pod]]s into [[dwarven syrup]]. {{Bug|4356}}
* Dwarves will sometimes leave pots in furniture stockpile even when using them to store food. {{Bug|1833}}

== See also ==
* [[Container]]

{{Translation| dwarven = or tezad | elvish = lacifa momo | goblin = sted ag | human = lod utag}}

{{Gamedata|{{raw|DF2014:item_tool.txt|ITEM_TOOL|ITEM_TOOL_LARGE_POT}}}}

{{Category|Items}}
[[ru:Large pot]]

Wheelbarrow

2023-02-04T08:33:51Z

Kelvie: Checked capacity numbers in dfhack. This number is consistent with the storage page.

{{migrated article}}
{{Quality|Unrated}}
{{av}}{{buggy}}

A '''wheelbarrow''' is a [[tool]] used to increase the speed of [[hauling]]. Wheelbarrows can be made of [[metal]] or [[wood]] at a [[metalsmith's forge]] or [[carpenter's workshop]], and can carry the equivalent of a single [[stockpile]] tile, be it a single [[stone]], a bin or barrel (with its contents included), or a stray item. This is equivalent to one fifth of a [[minecart]]'s capacity.

Wheelbarrows have a [[size]] of 3000 and a capacity of 10,000, meaning that you can fit 3 wheelbarrows in a wheelbarrow.

== Construction ==
Wheelbarrows are constructed of either wood or metal:

{| border="1" cellpadding="5" cellspacing="0" style="margin:1em 1em 1em 0; background:#F9F9F9; border:1px #AAA solid"
|- style="background: #F9F9F9"
! Material !! Worker !! Workshop
|- style="background: #F2F2F2"
| [[Wood]] (1 log) || [[Carpenter]] || [[Carpenter's workshop]]
|- style="background: #F2F2F2"
| [[Metal]] (2 bars) || [[Metal crafter]] || [[Metalsmith's forge]] or [[Magma forge]]
|}

== Utility ==
[[File:De re metallica 1556-085.png|thumb|Dwarven wheelbarrows are sturdy and practical.]]
Stone stockpiles have 1 wheelbarrow automatically assigned upon designation, though any stockpile can have wheelbarrows assigned in the Set Building Tasks/Prefs ({{k|q}}) menu with the {{k|w}} hotkey. Wheelbarrows will be stored in their assigned stockpile when not in use, potentially sharing a tile with a stockpiled item. A stockpile's wheelbarrows are only used to carry items ''to'' that stockpile; they will not be used to carry items away ''from'' it.

Dwarves carrying items in wheelbarrows ignore the weight of the contents, moving always at their top speed. This makes them particularly useful for hauling heavy items like stone, which slow haulers a lot. There's little benefit to carrying light items in a wheelbarrow, as dwarves won't load multiple items in it. They will, however, load a single bin ''full of items'' in a wheelbarrow.

Wheelbarrows carry less stuff than [[minecart]]s, but do not require a track to be preconstructed, and can go up and down stairs.

If wheelbarrows are assigned to a stockpile, dwarves will use them exclusively and cease hauling items to it with their bare hands, meaning that the number of assigned wheelbarrows is also the maximum number of active hauling jobs for said stockpile. This behaviour can save haulers for other more urgent jobs, but is sometimes inconvenient. Increasing the number of assigned wheelbarrows and adding linked stone stockpiles can allow you to pour more dwarfpower into hauling. If you set wheelbarrows at your stockpile to 0, all haulers may carry stones there, but will do it by hand, which is painfully slow work when long distances are involved.

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

== Bugs ==
* If a stockpile is assigned both a wheelbarrow and [[container]], dwarves will only use the wheelbarrow to move the container to the stockpile, carrying the items to be stored in the container by hand. As a workaround, a "feeder" stockpile with wheelbarrows enabled can be designated to "give to" an adjacent "storage" stockpile with containers enabled.

* If all of a stockpile's tiles are occupied by wheelbarrows, it will stop requesting new items even though the tiles under the wheelbarrows have no stockpiled item. Consequently, stockpiles need to have more tiles than wheelbarrows to work correctly.{{bug|8861}}

* Items can occasionally be left inside a wheelbarrow, causing the wheelbarrow to become unusable. This can cause a stockpile to stop collecting items if all of its wheelbarrows end up in this state{{bug|6074}} You can work around this by marking the contents of the wheelbarrow for dumping.

* Dwarves carry wheelbarrows instead of pushing them when the wheelbarrows themselves are being hauled.{{bug|6008}}

{{D for Dwarf}}
When they push an empty wheelbarrow, any dwarf walking by will jump in and demand a ride. To avoid this, the decision was made long ago that empty wheelbarrows must be carried to avoid elvish-type laziness.

{{Gamedata|{{raw|DF2014:item_tool.txt|ITEM_TOOL|ITEM_TOOL_WHEELBARROW}}}}

{{Category|Items}}

[[ru:Wheelbarrow]]

Minecart

2023-02-04T08:32:35Z

Kelvie: /* Capacity and weights */ Fix capacity of minecarts to be consistent with the storage page

{{migrated article}}
{{Quality|Unrated}}
{{av}}
[[File:Leitnagel Hund.png|thumb|Minecarts]]
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 [[Metal crafter|metalcrafting]] 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 4000) 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.

Although most of the utility of minecarts is in [[fortress mode]], an [[adventure mode|adventurer]] can also ride in a minecart. Adventurers can also pick up and relocate minecarts.

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

== Basic Minecart Usage ==
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 {{k|d}} {{k|T}}) or construct (with {{k|b}} {{k|C}} {{k|T}}) a track, which could be as simple as a straight line. Finally, you need to construct stops on your track (with {{k|b}} {{k|C}} {{k|S}}) 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. This is done with the {{k|h}}auling 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|size capacity]] of 50,000 – five times the capacity of [[wheelbarrow]]s.

'''Examples of the capacity of one cart'''
{| class="wikitable"
|-
! Item
! Amount
|-
| [[stone]]
| 5
|-
| [[wood|log]]
| 10
|-
| [[block]]/[[bar]]
| 83
|-
| minecarts
| 12
|-
| [[Kitchen|prepared meals]]
| 500
|-
| [[Trap_component#Spiked_ball|spiked balls]]
| 500
|-
| [[Sand]] [[bags]]
| 500
|-
| [[Weapon#Native_weapons|mace]]
| 625
|-
| [[Weapon#Native_weapons|spears]]
| 1250
|-
| [[cloth]]
| 2500
|}

The 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.

'''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 ===
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: Engraved/carved or constructed. A given minecart track need not use engraved 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 [[Engraver|carved]] (with {{K|d}} {{k|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. Engraved tracks are removed by [[smoothing]] the rock they're on, which results in a smooth floor (that can be re-engraved 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 {{K|d}} {{K|x}}). Tracks can be engraved 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 engraved, 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 engraving logic.

'''Constructed'''

Tracks can also be built as regular [[construction]]s (through {{K|b}} {{K|C}} {{K|T}}). This method is resource-expensive, since each track tile requires one stone, [[bar]], or [[block]] for construction, and time-consuming, since you can't designate strips longer than 10 tiles at a time. 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 together as a Track/Ramp from the construct track menu ({{K|b}} {{K|C}} {{K|T}}). 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 engraving 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. An engraver 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 {{k|h}}auling menu.

==== 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 {{k|h}}auling key. Existing ones can be removed (without confirmation) with the {{k|x}} key, and also {{k|n}}icknamed. Before operating, the route must have a {{k|v}}ehicle assigned 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 {{k|h}}auling menu, by placing the cursor over a tile and hitting {{k|s}} 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.

===== 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 {{k|b}} {{k|C}} {{k|S}}, 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.

Counter-intuitive to their construction method, Track Stops are considered [[building]]s and must be removed by {{k|q}} {{k|x}}.
* 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 engravers 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, you will be dwarfs 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 by {{k|q}} {{k|x}}.

=== 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}} {{K|C}} {{K|S}}; 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.

*Note: As of v0.47.05, the friction and direction settings '''can''' be adjusted after the track stop has been constructed. The stop can be {{K|q}}ueried to show the settings as they were set prior to construction, and two options will appear that allow the settings to be changed. The friction amount can be decreased or increased by pressing {{K|a}} or {{K|s}} respectively, cycling from "Lowest" to "Highest". The direction to dump can be toggled through the four cardinal points by pressing {{K|d}} until the desired direction is selected.

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". 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. This means carts can be accelerated even if the cart doesn't actually change z-level at all; ramps don't actually impart any downward velocity even when making cart descend. 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.

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 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 above, will be slowed down and checked again. Granted, you could do the same just with track turns, but it may take a lot of turns and time.

Since all the derailings, bounces and ramps can impart a sideway 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.

=== 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, which weigh 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, bouncing back 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, and 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 with it to the next stop.
{{DFtext|Guide}}: minecarts seem to ignore all laws of physics. That is:
*Ignore the weight of any and all items inside. Therefore:
**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.
*Ignore working rollers.
*Will ''not'' collide with other guided carts even when a full frontal collision would be expected.
*Will go up ramps like nobody's business.
This is therefore the recommended method of transport for simple non-powered rail systems, 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 that are traveling at derail velocity 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.

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]], 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 [[healthcare]]. 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 [[Swimming#Minecart_training|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 kicked 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 kick 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|DF2014:item_tool.txt|ITEM_TOOL|ITEM_TOOL_MINECART}}}}

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

[[ru:Minecart]]

Bag

2023-02-04T08:32:07Z

Kelvie:

{{Quality|Unrated}}
{{av}}
{{item|name=Bag
|tile=♂|col=0:6:0
|wood=n
|stone=n
|metal=n
|glass=n
|cloth=y
|leather=y
|ceramic=n
|bone=n
|shell=n
|gem=n
|wax=n
|used for=
* Storage}}
'''Bags''' are [[Storage|storage]] items that, like [[Barrel|barrels]] and [[Bin|bins]], conserve stockpile space by containing up to 100 seeds of the same type, as well as allowing for the collection and storage of quarry bush leaves and edible and inedible powders: flour, sugar, dye, gypsum plaster, quicklime, and sand. Bags can be made at a [[Clothier's shop]] out of 1 plant, silk, or yarn cloth; or they can be made at a [[Leather works]] out of 1 leather. They can also accept all types of decorations.

Bags containing plant-derived items and powders (seeds, quarry bush leaves, flour, sugar, and dye) are stored in Food stockpiles, and in fact cannot be prevented from being used there so long as the items contained in the bag are permitted. Dwarves will always store seeds in bags whenever possible. If the Food stockpile also allows barrels, then bags containing plant-derived items may then also be stored in barrels, saving even more space.

Empty bags and all other bags except sand bags are stored in Furniture stockpiles under Bags, with the material specified under Other materials (Leather, Plant cloth, Silk). Despite there being an entry for gypsum plaster under Stone/clay, this is ignored and gypsum plaster and quicklime bags will be stored along with your empty bags.

Sand bags have their own category in Furniture stockpiles, Sand bags, and do not require any material type to be selected.

Unlike in previous versions bags can no longer be constructed as storage furniture.

Bags take up 100 volume in storage (empty or full), and you can store 500 of them in a [[minecart]].

[[File:ML - Geldbeutel.jpg|thumb|300px|center|A coin bag from the ancient times. Strangely, dwarves don't store coins in bags.]]

{{D for Dwarf}}

* Currently, bags are unable to reproduce due to being all-male. This may be a bug.

==See also==
* [[Storage]]

Minecart

2023-02-04T08:27:34Z

Kelvie: Tested how many sand bags go into a minecart

{{migrated article}}
{{Quality|Unrated}}
{{av}}
[[File:Leitnagel Hund.png|thumb|Minecarts]]
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 [[Metal crafter|metalcrafting]] 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 4000) 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.

Although most of the utility of minecarts is in [[fortress mode]], an [[adventure mode|adventurer]] can also ride in a minecart. Adventurers can also pick up and relocate minecarts.

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

== Basic Minecart Usage ==
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 {{k|d}} {{k|T}}) or construct (with {{k|b}} {{k|C}} {{k|T}}) a track, which could be as simple as a straight line. Finally, you need to construct stops on your track (with {{k|b}} {{k|C}} {{k|S}}) 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. This is done with the {{k|h}}auling 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|size capacity]] of 500,000 – five times the capacity of [[wheelbarrow]]s.

'''Examples of the capacity of one cart'''
{| class="wikitable"
|-
! Item
! Amount
|-
| [[stone]]
| 5
|-
| [[wood|log]]
| 10
|-
| [[block]]/[[bar]]
| 83
|-
| minecarts
| 12
|-
| [[Kitchen|prepared meals]]
| 500
|-
| [[Trap_component#Spiked_ball|spiked balls]]
| 500
|-
| [[Sand]] [[bags]]
| 500
|-
| [[Weapon#Native_weapons|mace]]
| 625
|-
| [[Weapon#Native_weapons|spears]]
| 1250
|-
| [[cloth]]
| 2500
|}

The 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.

'''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 ===
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: Engraved/carved or constructed. A given minecart track need not use engraved 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 [[Engraver|carved]] (with {{K|d}} {{k|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. Engraved tracks are removed by [[smoothing]] the rock they're on, which results in a smooth floor (that can be re-engraved 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 {{K|d}} {{K|x}}). Tracks can be engraved 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 engraved, 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 engraving logic.

'''Constructed'''

Tracks can also be built as regular [[construction]]s (through {{K|b}} {{K|C}} {{K|T}}). This method is resource-expensive, since each track tile requires one stone, [[bar]], or [[block]] for construction, and time-consuming, since you can't designate strips longer than 10 tiles at a time. 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 together as a Track/Ramp from the construct track menu ({{K|b}} {{K|C}} {{K|T}}). 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 engraving 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. An engraver 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 {{k|h}}auling menu.

==== 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 {{k|h}}auling key. Existing ones can be removed (without confirmation) with the {{k|x}} key, and also {{k|n}}icknamed. Before operating, the route must have a {{k|v}}ehicle assigned 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 {{k|h}}auling menu, by placing the cursor over a tile and hitting {{k|s}} 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.

===== 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 {{k|b}} {{k|C}} {{k|S}}, 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.

Counter-intuitive to their construction method, Track Stops are considered [[building]]s and must be removed by {{k|q}} {{k|x}}.
* 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 engravers 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, you will be dwarfs 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 by {{k|q}} {{k|x}}.

=== 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}} {{K|C}} {{K|S}}; 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.

*Note: As of v0.47.05, the friction and direction settings '''can''' be adjusted after the track stop has been constructed. The stop can be {{K|q}}ueried to show the settings as they were set prior to construction, and two options will appear that allow the settings to be changed. The friction amount can be decreased or increased by pressing {{K|a}} or {{K|s}} respectively, cycling from "Lowest" to "Highest". The direction to dump can be toggled through the four cardinal points by pressing {{K|d}} until the desired direction is selected.

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". 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. This means carts can be accelerated even if the cart doesn't actually change z-level at all; ramps don't actually impart any downward velocity even when making cart descend. 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.

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 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 above, will be slowed down and checked again. Granted, you could do the same just with track turns, but it may take a lot of turns and time.

Since all the derailings, bounces and ramps can impart a sideway 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.

=== 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, which weigh 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, bouncing back 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, and 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 with it to the next stop.
{{DFtext|Guide}}: minecarts seem to ignore all laws of physics. That is:
*Ignore the weight of any and all items inside. Therefore:
**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.
*Ignore working rollers.
*Will ''not'' collide with other guided carts even when a full frontal collision would be expected.
*Will go up ramps like nobody's business.
This is therefore the recommended method of transport for simple non-powered rail systems, 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 that are traveling at derail velocity 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.

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]], 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 [[healthcare]]. 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 [[Swimming#Minecart_training|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 kicked 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 kick 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|DF2014:item_tool.txt|ITEM_TOOL|ITEM_TOOL_MINECART}}}}

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

[[ru:Minecart]]

Block

2023-01-31T17:31:01Z

Kelvie: Remove mentions of boulder as it's confusing (actual boulders can't be turned into blocks).

{{migrated article}}
{{Quality|Unrated}}
{{av}}

:''For "blocking" in combat, see [[Armor]].''

[[File:stone_blocks_preview.jpg|thumb|230px|right|Not Minecraft related.]]A '''block''' is a type of building material that is more architecturally efficient than their non-processed counterparts. Blocks are lighter, faster building, and more valuable. This makes blocks especially useful for large construction projects.

[[Stone]], [[wood]], [[glass]], [[ceramic]], and [[metal]] blocks can be created respectively in a [[Stoneworker's workshop]], a [[carpenter's workshop]], a [[glass furnace]], a [[kiln]], and a [[forge]]. One stone or a wooden log can be shaped into 4 blocks, which makes them more useful for larger constructions. All other materials only produce 1 block/task, and all blocks share the advantages in construction and value. Ceramic blocks are called "bricks", though they behave the same as all other blocks.

Blocks can be used as building materials for [[road]]s, [[bridge]]s, [[workshop]]s and [[construction]]s. When a raw material (e.g. raw stone rock) is used instead, the game will describe the result as "rough", while buildings built from blocks are not given that adjective. Additionally, blocks are '''required''' to build [[well]]s, [[screw pump]]s, and [[ashery|asheries]].

Even though blocks are quite useful in terms of construction, they cannot replace other functions of the raw material. E.g: Stone blocks cannot be used for making furniture or craft goods, tools such as [[pot]]s or [[jug]]s, [[mechanism]]s, or [[catapult]] ammunition. Nor can wooden blocks be used to make furniture, craft goods, tools, siege weapon components, ballista arrowheads, or crossbow bolts, or be burned at a [[wood furnace]]. Metal blocks can't be used for [[metalsmith's forge]] jobs but '''can be melted down''' at a [[smelter]].

==Blocks vs. rocks==

The clearest distinction between a [[building]] built with [[stone|raw stone]] and a building built with a stone block is that more buildings can be built of blocks, as each stone produces 4 blocks. Note that this does not apply to [[glass]], or [[ceramic]] blocks/bricks, which are only made in sets of 1; [[metal]] blocks are also made in sets of 1, but since you get 4 bars at a time from smelting ore, the end result is equivalent to stone.

Blocks have less volume, and thus [[weight|weigh]] much less than raw forms of construction materials - stone blocks weigh only 6% as much as a raw stone, and wooden blocks weigh 12% as much as the log from which they are carved. This weight difference can dramatically reduce hauling time, especially if you are using large amounts of materials. Forming metal bars into blocks makes no difference in regards to weight, though it does simplify the tracking of resources - if you use metal bars to build workshops and constructions, your [[stocks]] screen will still list them in the summary view, potentially misleading you into believing you have more available bars than you actually have.

Building a bridge out of blocks instead of rocks also '''cuts the building time by two thirds''', independent of clearing and hauling time. This difference in building time presumably extends to other buildings and constructions where you can choose between blocks and rocks. The appearance of [[bridge]]s and paved [[road]]s will be different depending on whether blocks or rocks are used. The use of blocks is indicated by the floor tile {{Tile|+|#FFF|#000}}, and the use of rocks is indicated by a rough ground tile {{Tile|≈|#FFF|#000}}.

Unlike raw stone or wood, up to 30 blocks can be stored in each [[bin]] in bar/block [[stockpile]]s, which can improve hauling time between stockpiles. A [[minecart]] can carry up to 83 blocks.

Blocks are more valuable than rocks, having a [[Value#Items with material but without quality|base value]] of 5, compared to the raw material value of 3 for stone, wood or glass, while metal bars already have a base value of 5. This, combined with the yield of 4 blocks per stone, nets a value increase of 17 when using basic stones for blocks.

Metal ores and economic stone will still produce multiple stone blocks if cut in a mason's workshop. However, this breaks use for any purpose other than building and [[strange mood]]s, such as [[reaction]]s: blocks of [[flux]] '''cannot''' be used for making [[pig iron]] or [[steel]], nor can blocks of [[ore]] be [[smelter|smelted]] into metal (without modding reactions). Note that "filler" blocks of [[raw adamantine]] are excellent for increasing [[artifact]] value without wasting too much adamantine on legendary doors, tables, etc.

{{Translation
| dwarven = kastar
| elvish = epuba
| goblin = zobo
| human = xugot
}}

{{Category|Items}}
[[ru:Block]]

Demon

2023-01-25T23:55:43Z

Kelvie: /* Containment */ add note about demons that can't open doors.

{{migrated article}}
{{Quality|Unrated}}
{{av}}
{{spoiler}}

'''Demons''' {{Tile|&|7:0}} are procedurally-generated [[creature]]s who inhabit the [[Underworld]]. These immense, malicious and formidably powerful beasts are among the most powerful enemies in the game in both [[fortress mode]] and [[adventurer mode]]. They are not available to be spawned in the [[object testing arena]].

== Overview ==
[[File:Assdemon.png|thumb|right|300px|"Etar Patternedtombs was a mint green demon. It was the only one of its kind. A gigantic feathered ass twisted into humanoid form. It undulates rhythmically. Its mint green feathers are patchy. Beware its deadly gas!" ([http://www.bay12forums.com/smf/index.php?topic=76346.msg2667300#msg2667300 post]).]]Demons inhabit the Underworld. They are randomly generated at worldgen, creating unique [[fun]] for every player. Examples of possible demons include giant centipedes made of ash that hunger for blood, eyeless mosquitoes that spit toxins, and emaciated fruitbats with giant clicking mandibles. The number of different types of demon created during world generation is closely related to world size, and it can be directly controlled with [[advanced world generation]] – a world generated with "{{tt|Number of Demon Types}}" set to {{tt|0}} in advanced world generation will not have any demons in it.

All demons share certain traits. They are [[Creature token#SUPERNATURAL|supernatural]], [[fanciful]], evil-aligned creatures represented by an ampersand with a randomized [[color]]. They are all able to swim in and [[Amphibious|breathe]] water and magma, and [[Building destroyer|destroy buildings]]. Furthermore, they are [[Trapavoid|immune to traps]], [[No Pain|pain]], fear, nausea, [[No Stun|stunning]], [[No Exert|exertion]], dizziness, fevers, fire, any sort of poison, and have fixed body temperature, thus are unaffected by extremes of heat and cold (even if made of materials that would suggest otherwise). Roughly half possess [[Creature_token#EXTRAVISION|extravision]]. They are very large (size 10,000,000, smaller than a [[megabeast]], but larger than a [[giant]] and 167 times the size of a [[dwarf]]). They don't require sleep, food, or drink. All non-unique demons start out at Accomplished [[skill]] level in the following combat skills: wrestling, biting, striking, kicking, fighting, archery, dodging, and observing. Unique demons start out at Grand Master in the same skills. All unique demons, and roughly a half of non-unique ones, possess intelligence ([[Creature token#CAN_LEARN|<code>[CAN_LEARN]</code>]] + [[Creature token#CAN_SPEAK|<code>[CAN_SPEAK]</code>]]), so demons you face may well have developed their skills to a higher level than they began with; however, their skills cannot rust to a lower level. The initial wave spawns exactly one frame after you open the Underworld; the amount spawned can range from 10 to over 100. Demons inhabiting the Underworld spawn in groups of 1-5 individuals. The size of their population, specified as 5-10 in the raws, appears to be irrelevant, as the game makes all inhabitants of the Underworld spawn in limitless numbers. As long as the Underworld is unsealed, demons will continue to wander in from the edges of the map indefinitely, due to having populations that are (functionally) infinite.

Demons receive large bonuses to every physical [[attribute]] except agility, and to the mental attributes of focus and willpower (also analytical ability, memory, linguistic ability, and social awareness, but those are less relevant). Many, but not all demons, are capable of flight. They may possess a wide variety of special attacks, including webbing, firebreath, poisonous appendages, toxic spittle or poison breath. Inorganic or zombie demons are especially difficult to kill; they can be killed by bisection, decapitation, or pulping via blunt weapons (inorganic blobs can only be killed in this manner), but this is far beyond the capacities of an ordinary dwarf.

Demons of each species can be all genderless, all male or all female, or have both male and female castes. The latter can breed if given enough time. All demons are born adults, and immediately reach their full size after being born. They have a [[pet|pet value]] of 2000☼, but cannot be tamed, and you are rather unlikely to capture one. If you have deactivated compressed saves, the raws for a given world's demons (as well as [[forgotten beast]]s, [[titan]]s, [[werebeast]]s, etc.) can be found in the [[Saved game folder|world.dat]] of its save folder. Blob/inorganic demons tend to be genderless and non-sapient, but more research is required on this.

Due to their somewhat spoilery nature – new players are unlikely to know they exist, creating [[Fun|much surprise]] when they inevitably dig too deep – veteran ''Dwarf Fortress'' players tend to hide the existence of demons by giving them nicknames, the most famous being '''Hidden Fun Stuff''' and '''clowns''', with the Underworld being their "circus". Unique demons (see below), by extension, are usually referred to as the '''ringleaders'''.

Dwarves may [[Preferences|like]] a species of demon for their ''horrifying features'', their ''rhythmic undulations'' or their ''bloated appearance''.

== Their interaction with the world ==
Certain types of demons, those described as "being twisted into humanoid form" and marked with {{token|UNIQUE_DEMON|c}} instead of {{token|DEMON|c}} in world.dat, will occasionally escape the underworld. This happens by the aid of a [[deity]] matching that particular demon's [[sphere]] through a ritual conducted with an [[artifact]] [[slab]]. Once they are in the mortal world, they will gain rule over a [[goblin]] [[civilization]] – each goblin faction in the world will be led by a unique demon, and attempting to create a world without demons in it through [[advanced world generation]] will lead to goblins being locked away in the underworld until a dwarf civilization digs too deep. As noted in [[Legends|legends mode]], these demons will occasionally make journeys to the [[Cavern|depths of the world]] and tame the creatures that dwell in them – most specifically, species with the {{token|PET_EXOTIC}} token – going from [[giant rat]]s to [[voracious cave crawler]]s and [[cave dragon]]s. Presumably, this is how goblin civilizations gain access to these creatures to use them in [[siege]]s.

Demons may also arise when a dwarven civilization digs too deep in [[world generation|worldgen]] – the dwarves have a chance to fight them off, but, most of the time, the fortress will be taken over by goblins under a demonic ruler.

Found within the goblins' [[dark fortress]]es are demonic [[Underworld spire|spires]] made of [[slade]], whose lowermost levels lead directly into the Underworld. They will also create slade [[vault]]s, whose treasure is guarded by incredibly powerful and dangerous [[angel]]s. If you can manage to fight off those freakishly strong beings ([[Fun|don't expect to by the way]]), you can find in the vault's centre the slab that contains the demon's true name. Learning this name allows your adventurer to either banish it back to the Underworld or bind it to your servitude. Although you will have a next to unkillable super soldier on your side if you opt for the latter, it's more of a bragging-rights reward, if anything – getting past the angels already requires pretty much being a god among men.

<gallery class="center" widths="400px" heights="184px">
File:Demon banish.png|Banishing a demon back to the Underworld
File:Demon compel service.png|Compelling service from demon
</gallery>

Escaped demons can also take over human civilizations by impersonating [[deities]] and having humans worship them. As with conventional lords, you can encounter them as normal in adventure mode – they won't be hostile to you and will behave as any other member of the civilization they rule. They can also arrive as non-hostile diplomats from human civilizations in fortress mode. Depending on the type of demon, this can be mildly amusing, or inadvertently deadly to your fort or adventurer.

In [[fortress mode]], goblin law-giver demons may arrive as part of a goblin siege and are most of the time very dangerous.{{verify}}

Demons can (and, in most cases, will) spread sphere-aligned evil from sites they control. Nightmare or darkness demons will spread regions filled with [[bogeymen]], death demons will spread reanimating evil regions, and so on. The evil-spreading can be reversed if the demon is slain or their site conquered or razed (e.g. through a [[raid]].

Depending on their spheres, demons may also be granted abilities similar to those of [[necromancer]]s. Death demons are able to create [[experiment]]s and raise corpses and [[intelligent undead]], though they do not raise corpses in world gen because they would be hostile to the goblins they rule. Nightmare demons may be able to summon [[nightmare]]s and [[bogeymen]].

== Demon generation ==
Although the exact algorithm used to produce demons is unknown, something of the algorithm can be gathered from the string dump and analysis of demons. When generating a demon, the game begins by picking a creature from a predefined list, which is fixed and includes creatures not found in vanilla DF (such as anteater, ankylosaurid) and more general shapes (blob, quadruped, and humanoid). It is granted spheres, with a preference for "negative" spheres like misery, death, and torture. If inorganic, a material will be chosen, either one of the hardcoded ones (such as salt, ash, ice, or vomit), flames, or a randomly chosen raw-defined inorganic (any type of stone, soil, gem, metal, or other, such as gypsum plaster). If organic, it will get some sort of randomly-colored covering (such as feathers or hair) and/or have some feature (such as its eyes, nose or skin) removed. It will be granted a few "extra" features, like a tail, a trunk, or a shell, and a flavorful descriptor (such as "it knows and intones the names of all it encounters"). It may get some sort of special attack (such as a poisonous sting, toxic breath, fire breath). It will finally be given a name consisting of an adjective and a noun. The adjective will be based on the creature's color, its material (such as "inferno" or "snow"), what animal it's shaped like, or a descriptor (such as "winged", "three-eyed" or "skinless"), and the noun chosen from the following list: demon, devil, fiend, brute, monster, spirit, ghost, banshee, haunt, phantom, specter, or wraith.

== Strategy ==
[[File:Demon_Size.png|thumb|right|200px|Estimated size comparison between a typical demon, and a dwarf.]]

Of all of the challenges facing a player, defeating a demon horde is probably the most difficult, unless you are using certain [[trap]] schemes – and even then, you will need to take special precautions.

=== Containment ===
Containment is the simplest strategy for dealing with demons. A simple constructed wall will block any demon. Because of their building destroyer status, demons cannot be contained via locked doors. However, indestructible artifact-quality portals can stop them, as can some bridges. As building destroyers can only destroy objects on the same z-level, a [[floor grate]] or forbidden [[hatch cover]] on a staircase/channel will also block movement. It may be difficult to lure demons away from artifact furniture, should the area need to be accessed to reset a trap. If using [[bridge]]s, be aware that any raising bridge that lands on a demon will deconstruct, and that demons can easily have internal temperatures greatly exceeding the melting points of [[steel]] or [[iron]], leading to deconstruction as they pass over them. Because of their vast numbers, containment is an important part of any attempt to defeat them – fighting two groups of 25 demons is much easier than fighting one group of 50.

One particular gentleman, AussieGuy on the Bay12 forums, has found an ingenious method for disposing of an entire demonic invasion at once: a [[Megaprojects|stupid dwarven trick]] known as "the dwarven checkerboard".([http://www.bay12forums.com/smf/index.php?topic=94140.0 Source])

When using forbidden hatches to control flow of demons, note that some demons may be spawned with CANOPENDOORS to be not set, so once you unforbid the hatch, only the demons that can open doors will go through the door. The ones that can't open doors will remain behind the hatch, even if it is passable.

=== Traps ===
Because all demons avoid traps, trapping demons can be very difficult – but not impossible. Demons become vulnerable to traps when they are webbed, so if you can find a way to get web onto your traps, the demons will be affected as any other creature (including your own dwarves!) would be.

Alternatively, advanced triggered traps may be used. Demons do not set off [[pressure plate]]s, but if you can contain them, retracting upright spikes, casting them into [[obsidian]], or caving a portion of mountain onto them are all effective. Any plan involving these kind of traps must involve both a way to bait the demons to where you want them and a way to keep the demons where you want them. Tame animals appear to work well as bait, but need to be replaced as they're killed. Bridges can be used to contain the demons, but be wary of the risks of deconstruction as described above.

Many traps need to be designed with the potential for extreme temperatures in mind. Obsidian trappers may find water used in the casting process boiling into steam before it contacts magma. Frequently, demons made of fire or steam explode on death, broiling nearby creatures and furniture. This effect can destroy upright spikes, leaving you with a trap chamber full of demons that you have no way to deal with. Demons do not destroy supports directly, but a hot enough demon may cause the destruction of nearby supports, just through heat damage. A clever dwarf might find a way to turn that to their advantage, if only such a thing as a clever dwarf existed.

=== Ranged combat ===
Ranged combat sounds appealing, especially in the face of demons that explode with unimaginable heat upon death, but should be considered carefully. Most demons have vastly more powerful ranged attacks than marksdwarves have. Demons made of weak materials can be easily killed or dismembered by bolts, but inorganic demons composed of stronger stuff will only suffer chipped "bones".

[[Fortification]]s are appealing, as they can be dug directly into [[adamantine]] without ever exposing your fortress to a path to the demons. Even demons made out of steam cannot pass through a fortification unless it is submerged in 7/7 water or magma. Demons with syndrome attacks may attack through fortifications even without a path, although they appear to do so less frequently than if they have a path.

Still, should you contain a group of demons composed of weaker materials, marksdwarves can be very effective.

=== Melee combat ===
Demons can be very frightening melee opponents, as each one alone is nearly the size of a [[megabeast]], extremely fast, and has tremendous natural combat skills. That would be bad enough, but there tend to be pages of them rather than individuals. However, demons can still be defeated in melee combat.

Despite their powerful attacks, many demons are made up of very flimsy materials, such as salt, snow, steam, or filth. A strong punch can decapitate creatures like this. Some demons, however, can be made of much harder materials, and it can be very difficult to bring down a demon composed of minerals or armor-quality metal. Blunt weapons can be reasonably effective against weaker-material demons by severing limbs and body parts despite blunt status, but are not nearly as effective against demons as they are against earthly foes that suffer from pain and blood loss; without internal organs or blood loss, piercing weapons are relatively ineffective. Good slashing weapons can reliably take down demons of any material type.

The challenge of melee combat is how to deal with an enormous number of strong combatants while protecting against area-of-effect syndrome attacks and death explosions. Restraining visibility via a labyrinthine battleground is a good start. The area effects suggest meeting them with successive small waves of melee dwarves, but if the dwarves are too few, they'll be butchered by hundreds of angry demons before making a dent.

In all cases, your demon-fighting melee dwarves should be very well armed and armored (steel and adamantine) and Legendary in some, if not all, of the relevant combat skills.

=== Clean-up ===
Unfortunately, once the wave of demons has been dealt with, it's not yet over. [[Syndrome]]-bearing dust and blood may litter the battlefield and your survivors, and can be very difficult to isolate and contain. Some dwarves may carry burning items back from their encounters with very hot demons. Survivors should all pass through a shallow pool of water to wash them and their equipment of anything dangerous and to douse any flames. Any path used for the fight is best abandoned and walled up. Demons will continue to enter the Underworld from its map edges, as wildlife do on the surface, but path differently from the initial wave, content to wander through the Underworld even should a simple unobstructed path exist into your fortress.

== Killed demons ==
Only unintelligent demons can be butchered in unmodded games, and butchering them yields products similar to those from [[forgotten beast]]s, including copious amounts of [[meat]] and [[bone]]s, vividly-colored [[hair]], [[feather]]s, [[scale]]s or [[chitin]], and [[shell]]s, if the demon had one. All materials obtained from demons have a value multiplier of 1, and aren't appreciably better than their mundane counterparts.

Inorganic demons cannot be butchered, and after killing them you obtain only a massive demonic corpse to use in your [[stupid dwarf trick]].

{{D for Dwarf}}

Little do demons know that though their claws and fire cannot pierce the [[adamantine]] sealing them away, a simple [[copper]] [[pick]] (or any other kind of pick, for that matter) can dig right through it with ease. Armok forbid these unholy creatures ever get their hands on one.

{{gamedata|title=Example raws (as extracted from world.sav)|[OBJECT:CREATURE]

[CREATURE:DEMON_1]
[NAME:brine brute:brine brutes:brine brute]
[CASTE_NAME:brine brute:brine brutes:brine brute]
[GENERATED]
[DEMON]
[NATURAL_SKILL:WRESTLING:10]
[NATURAL_SKILL:BITE:10]
[NATURAL_SKILL:GRASP_STRIKE:10]
[NATURAL_SKILL:STANCE_STRIKE:10]
[NATURAL_SKILL:MELEE_COMBAT:10]
[NATURAL_SKILL:RANGED_COMBAT:10]
[NATURAL_SKILL:DODGING:10]
[NATURAL_SKILL:SITUATIONAL_AWARENESS:10]
[LARGE_ROAMING]
[LARGE_PREDATOR]
[DIFFICULTY:10]
[BIOME:SUBTERRANEAN_CHASM]
[UNDERGROUND_DEPTH:5:5]
[POPULATION_NUMBER:5:10]
[CLUSTER_NUMBER:1:5]
[FEMALE]
[PHYS_ATT_RANGE:STRENGTH:450:1050:1150:1250:1350:1550:2250]
[PHYS_ATT_RANGE:TOUGHNESS:450:1050:1150:1250:1350:1550:2250]
[PHYS_ATT_RANGE:ENDURANCE:450:1050:1150:1250:1350:1550:2250]
[PHYS_ATT_RANGE:RECUPERATION:450:1050:1150:1250:1350:1550:2250]
[PHYS_ATT_RANGE:DISEASE_RESISTANCE:700:1300:1400:1500:1600:1800:2500]
[MENT_ATT_RANGE:ANALYTICAL_ABILITY:1250:1500:1750:2000:2500:3000:5000]
[MENT_ATT_RANGE:FOCUS:1250:1500:1750:2000:2500:3000:5000]
[MENT_ATT_RANGE:WILLPOWER:1250:1500:1750:2000:2500:3000:5000]
[MENT_ATT_RANGE:PATIENCE:0:333:666:1000:2333:3666:5000]
[MENT_ATT_RANGE:MEMORY:1250:1500:1750:2000:2500:3000:5000]
[MENT_ATT_RANGE:LINGUISTIC_ABILITY:450:1050:1150:1250:1350:1550:2250]
[MENT_ATT_RANGE:MUSICALITY:0:333:666:1000:2333:3666:5000]
[MENT_ATT_RANGE:SOCIAL_AWARENESS:700:1300:1400:1500:1600:1800:2500]
[PERSONALITY:ANXIETY_PROPENSITY:0:0:0]
[PERSONALITY:DEPRESSION_PROPENSITY:0:0:0]
[PERSONALITY:BASHFUL:0:0:0]
[PERSONALITY:STRESS_VULNERABILITY:0:0:0]
[PERSONALITY:FRIENDLINESS:0:0:0]
[PERSONALITY:ASSERTIVENESS:100:100:100]
[PERSONALITY:DISDAIN_ADVICE:100:100:100]
[PERSONALITY:CHEER_PROPENSITY:0:0:0]
[PERSONALITY:GRATITUDE:0:0:0]
[PERSONALITY:TRUST:0:0:0]
[PERSONALITY:ALTRUISM:0:0:0]
[PERSONALITY:SWAYED_BY_EMOTIONS:0:0:0]
[PERSONALITY:CRUELTY:100:100:100]
[PERSONALITY:PRIDE:100:100:100]
[PERSONALITY:GREED:100:100:100]
[NO_DRINK]
[NO_EAT]
[NO_SLEEP]
[BODY_APPEARANCE_MODIFIER:HEIGHT:90:95:98:100:102:105:110]
[BODY_APPEARANCE_MODIFIER:BROADNESS:90:95:98:100:102:105:110]
[MAGMA_VISION]
[EVIL]
[FANCIFUL]
[SUPERNATURAL]
[AMPHIBIOUS]
[PETVALUE:2000]
[GRASSTRAMPLE:20]
[BUILDINGDESTROYER:2]
[ALL_ACTIVE]
[SWIMS_INNATE]
[TRAPAVOID]
[NOPAIN]
[NOSTUN]
[NONAUSEA]
[NOFEAR]
[NOEXERT]
[NO_DIZZINESS]
[NO_FEVERS]
[LARGE_PREDATOR]
[SPHERE:FISHING]
[SPHERE:HUNTING]
[SPHERE:MISERY]
[SPHERE:TORTURE]
[BODY_SIZE:0:0:10000000]
[CREATURE_TILE:'&']
[NO_THOUGHT_CENTER_FOR_MOVEMENT]
[BODY:RCP_BASIC_BODY_STANCE_WITH_HEAD_FLAG:RCP_TWO_FLIGHTLESS_WINGS]
[TISSUE:UNIFORM_TIS]
[TISSUE_NAME:tissue:NP]
[TISSUE_MATERIAL:SALT]
[TISSUE_MAT_STATE:SOLID_POWDER]
[MUSCULAR]
[FUNCTIONAL]
[STRUCTURAL]
[RELATIVE_THICKNESS:1]
[CONNECTS]
[TISSUE_SHAPE:LAYER]
[TISSUE_LAYER:BY_CATEGORY:ALL:UNIFORM_TIS]
[BODY_DETAIL_PLAN:STANDARD_HEAD_POSITIONS]
[BODY_DETAIL_PLAN:HUMANOID_HEAD_POSITIONS]
[BODY_DETAIL_PLAN:HUMANOID_RELSIZES]
[NOT_LIVING]
[NOT_BUTCHERABLE]
[COLOR:7:0:1]
[NOBREATHE]
[EXTRAVISION]
[FLIER]
[FIXED_TEMP:10040]
[FIREIMMUNE]
[GAIT:SWIM:Maximum Swim Speed:725:10:3:2175:50:LAYERS_SLOW:STRENGTH:AGILITY:STEALTH_SLOWS:50]
[GAIT:SWIM:Faster Swim:1450:5:3:2175:10:LAYERS_SLOW:STRENGTH:AGILITY:STEALTH_SLOWS:20]
[GAIT:SWIM:Fast Swim:2175:NO_BUILD_UP:5:LAYERS_SLOW:STRENGTH:AGILITY:STEALTH_SLOWS:10]
[GAIT:SWIM:Swim:2900:NO_BUILD_UP:0]( [GAIT:SWIM:Slow Swim:3900:NO_BUILD_UP:0]
[GAIT:SWIM:Creeping Swim:5900:NO_BUILD_UP:0]
[GAIT:FLY:Maximum Flight Speed:225:10:3:675:50:LAYERS_SLOW:STRENGTH:AGILITY:STEALTH_SLOWS:50]
[GAIT:FLY:Faster Flight:450:5:3:675:10:LAYERS_SLOW:STRENGTH:AGILITY:STEALTH_SLOWS:20]
[GAIT:FLY:Fast Flight:675:NO_BUILD_UP:5:LAYERS_SLOW:STRENGTH:AGILITY:STEALTH_SLOWS:10]
[GAIT:FLY:Fly:900:NO_BUILD_UP:0]) [GAIT:FLY:Slow Flight:1900:NO_BUILD_UP:0]
[GAIT:FLY:Hover:2900:NO_BUILD_UP:0]
[GAIT:WALK:Scramble:725:10:3:2175:50:LAYERS_SLOW:STRENGTH:AGILITY:STEALTH_SLOWS:50]
[GAIT:WALK:Faster Crawl:1450:5:3:2175:10:LAYERS_SLOW:STRENGTH:AGILITY:STEALTH_SLOWS:20]
[GAIT:WALK:Fast Crawl:2175:NO_BUILD_UP:5:LAYERS_SLOW:STRENGTH:AGILITY:STEALTH_SLOWS:10]
[GAIT:WALK:Crawl:2900:NO_BUILD_UP:0]
[GAIT:WALK:Slow Crawl:5900:NO_BUILD_UP:0]
[GAIT:WALK:Creep:8900:NO_BUILD_UP:0]
[GAIT:CRAWL:Scramble:225:10:3:675:50:LAYERS_SLOW:STRENGTH:AGILITY:STEALTH_SLOWS:50]
[GAIT:CRAWL:Faster Crawl:450:5:3:675:10:LAYERS_SLOW:STRENGTH:AGILITY:STEALTH_SLOWS:20]
[GAIT:CRAWL:Fast Crawl:675:NO_BUILD_UP:5:LAYERS_SLOW:STRENGTH:AGILITY:STEALTH_SLOWS:10]
[GAIT:CRAWL:Crawl:900:NO_BUILD_UP:0]
[GAIT:CRAWL:Slow Crawl:1900:NO_BUILD_UP:0]
[GAIT:CRAWL:Creep:2900:NO_BUILD_UP:0]
[DESCRIPTION:A towering slug composed of salt. It has wings and it has a gaunt appearance.]
[PREFSTRING:horrifying features]
}}

{{gamedata|title=Example [UNIQUE_DEMON] raws (as extracted from world.sav)|[OBJECT:CREATURE]

[CREATURE:DEMON_3]
[NAME:clear devil:clear devils:clear devilish]
[CASTE_NAME:clear devil:clear devils:clear devilish]
[GENERATED]
[UNIQUE_DEMON]
[SPREAD_EVIL_SPHERES_IF_RULER]
[NATURAL_SKILL:WRESTLING:14]
[NATURAL_SKILL:BITE:14]
[NATURAL_SKILL:GRASP_STRIKE:14]
[NATURAL_SKILL:STANCE_STRIKE:14]
[NATURAL_SKILL:MELEE_COMBAT:14]
[NATURAL_SKILL:RANGED_COMBAT:14]
[NATURAL_SKILL:DODGING:14]
[NATURAL_SKILL:SITUATIONAL_AWARENESS:14]
[CAN_LEARN]
[CAN_SPEAK]
[DIFFICULTY:10]
[NO_GENDER]
[PHYS_ATT_RANGE:STRENGTH:450:1050:1150:1250:1350:1550:2250]
[PHYS_ATT_RANGE:TOUGHNESS:450:1050:1150:1250:1350:1550:2250]
[PHYS_ATT_RANGE:ENDURANCE:450:1050:1150:1250:1350:1550:2250]
[PHYS_ATT_RANGE:RECUPERATION:450:1050:1150:1250:1350:1550:2250]
[PHYS_ATT_RANGE:DISEASE_RESISTANCE:700:1300:1400:1500:1600:1800:2500]
[MENT_ATT_RANGE:ANALYTICAL_ABILITY:1250:1500:1750:2000:2500:3000:5000]
[MENT_ATT_RANGE:FOCUS:1250:1500:1750:2000:2500:3000:5000]
[MENT_ATT_RANGE:WILLPOWER:1250:1500:1750:2000:2500:3000:5000]
[MENT_ATT_RANGE:PATIENCE:0:333:666:1000:2333:3666:5000]
[MENT_ATT_RANGE:MEMORY:1250:1500:1750:2000:2500:3000:5000]
[MENT_ATT_RANGE:LINGUISTIC_ABILITY:450:1050:1150:1250:1350:1550:2250]
[MENT_ATT_RANGE:MUSICALITY:0:333:666:1000:2333:3666:5000]
[MENT_ATT_RANGE:SOCIAL_AWARENESS:700:1300:1400:1500:1600:1800:2500]
[PERSONALITY:ANXIETY_PROPENSITY:0:0:0]
[PERSONALITY:DEPRESSION_PROPENSITY:0:0:0]
[PERSONALITY:BASHFUL:0:0:0]
[PERSONALITY:STRESS_VULNERABILITY:0:0:0]
[PERSONALITY:FRIENDLINESS:0:0:0]
[PERSONALITY:ASSERTIVENESS:100:100:100]
[PERSONALITY:DISDAIN_ADVICE:100:100:100]
[PERSONALITY:CHEER_PROPENSITY:0:0:0]
[PERSONALITY:GRATITUDE:0:0:0]
[PERSONALITY:TRUST:0:0:0]
[PERSONALITY:ALTRUISM:0:0:0]
[PERSONALITY:SWAYED_BY_EMOTIONS:0:0:0]
[PERSONALITY:CRUELTY:100:100:100]
[PERSONALITY:PRIDE:100:100:100]
[PERSONALITY:GREED:100:100:100]
[NO_DRINK]
[NO_EAT]
[NO_SLEEP]
[BODY_APPEARANCE_MODIFIER:HEIGHT:90:95:98:100:102:105:110]
[BODY_APPEARANCE_MODIFIER:BROADNESS:90:95:98:100:102:105:110]
[MAGMA_VISION]
[EVIL]
[FANCIFUL]
[SUPERNATURAL]
[AMPHIBIOUS]
[PETVALUE:2000]
[GRASSTRAMPLE:20]
[BUILDINGDESTROYER:2]
[ALL_ACTIVE]
[SWIMS_INNATE]
[TRAPAVOID]
[NOPAIN]
[NOSTUN]
[NONAUSEA]
[NOFEAR]
[NOEXERT]
[NO_DIZZINESS]
[NO_FEVERS]
[LARGE_PREDATOR]
[SPHERE:BLIGHT]
[SPHERE:DEATH]
[SPHERE:MURDER]
[SPHERE:TWILIGHT]
[BODY_SIZE:0:0:10000000]
[CREATURE_TILE:'&']
[BODY:RCP_UPPER_BODY:RCP_LOWER_BODY:RCP_NECK:RCP_HEAD:RCP_TWO_PART_ARMS:RCP_TWO_PART_LEGS:RCP_TAIL:RCP_4_FINGERS:RCP_4_TOES:RCP_LUNGS:RCP_HEART:RCP_GUTS:RCP_THROAT:RCP_SPINE:RCP_UPPER_SPINE:RCP_BRAIN:RCP_SKULL:RCP_MOUTH:RCP_TONGUE:RCP_TEETH:RCP_RIBS]
[CANOPENDOORS]
[EQUIPS]
[BODY_DETAIL_PLAN:STANDARD_MATERIALS]
[REMOVE_MATERIAL:SKIN]
[REMOVE_MATERIAL:HAIR]
[USE_MATERIAL_TEMPLATE:SCALE:SCALE_TEMPLATE]
[BODY_DETAIL_PLAN:STANDARD_TISSUES]
[REMOVE_TISSUE:SKIN]
[REMOVE_TISSUE:HAIR]
[USE_TISSUE_TEMPLATE:SCALE:SCALE_TEMPLATE]
[BODY_DETAIL_PLAN:VERTEBRATE_TISSUE_LAYERS:SCALE:FAT:MUSCLE:BONE:CARTILAGE]
[BODY_DETAIL_PLAN:STANDARD_HEAD_POSITIONS]
[BODY_DETAIL_PLAN:HUMANOID_HEAD_POSITIONS]
[BODY_DETAIL_PLAN:HUMANOID_RIBCAGE_POSITIONS]
[BODY_DETAIL_PLAN:HUMANOID_RELSIZES]
[USE_MATERIAL_TEMPLATE:SINEW:SINEW_TEMPLATE]
[TENDONS:LOCAL_CREATURE_MAT:SINEW:200]
[LIGAMENTS:LOCAL_CREATURE_MAT:SINEW:200]
[HAS_NERVES]
[NOBREATHE]
[EXTRAVISION]
[FIXED_TEMP:10040]
[SELECT_MATERIAL:SCALE]
[STATE_COLOR:ALL_SOLID:CLEAR]
[COLOR:0:0:1]
[SELECT_TISSUE_LAYER:HEART:BY_CATEGORY:HEART]
[PLUS_TISSUE_LAYER:SCALE:BY_CATEGORY:THROAT]
[TL_MAJOR_ARTERIES]
[USE_MATERIAL_TEMPLATE:GOO:GOO_TEMPLATE]
[BLOOD:LOCAL_CREATURE_MAT:GOO:LIQUID]
[USE_MATERIAL_TEMPLATE:CLAW:NAIL_TEMPLATE]
[USE_TISSUE_TEMPLATE:CLAW:CLAW_TEMPLATE]
[TISSUE_LAYER:BY_CATEGORY:FINGER:CLAW:FRONT]
[TISSUE_LAYER:BY_CATEGORY:TOE:CLAW:FRONT]
[USE_MATERIAL_TEMPLATE:POISON:CREATURE_EXTRACT_TEMPLATE]
[ENTERS_BLOOD]
[SYNDROME]
[SYN_NAME:demon sickness]
[SYN_AFFECTED_CLASS:GENERAL_POISON]
[SYN_IMMUNE_CREATURE:DEMON_3:ALL]
[SYN_INJECTED]
[SYN_CONTACT]
[SYN_INHALED]
[SYN_INGESTED]
[CE_DROWSINESS:SEV:100:PROB:100:START:565:PEAK:1649:END:4938:RESISTABLE:SIZE_DELAYS:SIZE_DILUTES]
[SECRETION:LOCAL_CREATURE_MAT:POISON:LIQUID:BY_CATEGORY:ALL:SCALE]
[FIREIMMUNE]
[ATTACK:PUNCH:BODYPART:BY_TYPE:GRASP]
[ATTACK_SKILL:GRASP_STRIKE]
[ATTACK_VERB:punch:punches]
[ATTACK_CONTACT_PERC:100]
[ATTACK_PREPARE_AND_RECOVER:2:2]
[ATTACK_FLAG_WITH]
[ATTACK_PRIORITY:MAIN]
[ATTACK:KICK:BODYPART:BY_TYPE:STANCE]
[ATTACK_SKILL:STANCE_STRIKE]
[ATTACK_VERB:kick:kicks]
[ATTACK_CONTACT_PERC:100]
[ATTACK_PREPARE_AND_RECOVER:2:2]
[ATTACK_FLAG_WITH]
[ATTACK_PRIORITY:MAIN]
[ATTACK_FLAG_BAD_MULTIATTACK]
[ATTACK:BITE:CHILD_BODYPART_GROUP:BY_CATEGORY:HEAD:BY_CATEGORY:TOOTH]
[ATTACK_SKILL:BITE]
[ATTACK_VERB:bite:bites]
[ATTACK_CONTACT_PERC:100]
[ATTACK_PENETRATION_PERC:100]
[ATTACK_PREPARE_AND_RECOVER:2:2]
[ATTACK_FLAG_EDGE]
[ATTACK_PRIORITY:MAIN]
[ATTACK_FLAG_CANLATCH]
[ATTACK:FSCRATCH:CHILD_TISSUE_LAYER_GROUP:BY_TYPE:GRASP:BY_CATEGORY:ALL:CLAW]
[ATTACK_SKILL:GRASP_STRIKE]
[ATTACK_VERB:scratch:scratches]
[ATTACK_CONTACT_PERC:100]
[ATTACK_PENETRATION_PERC:100]
[ATTACK_PREPARE_AND_RECOVER:2:2]
[ATTACK_FLAG_EDGE]
[ATTACK_PRIORITY:MAIN]
[ATTACK:TSCRATCH:CHILD_TISSUE_LAYER_GROUP:BY_TYPE:STANCE:BY_CATEGORY:ALL:CLAW]
[ATTACK_SKILL:STANCE_STRIKE]
[ATTACK_VERB:scratch:scratches]
[ATTACK_CONTACT_PERC:100]
[ATTACK_PENETRATION_PERC:100]
[ATTACK_PREPARE_AND_RECOVER:2:2]
[ATTACK_FLAG_EDGE]
[ATTACK_PRIORITY:MAIN]
[ATTACK_FLAG_BAD_MULTIATTACK]
[SELECT_MATERIAL:ALL]
[MAT_FIXED_TEMP:10040]
[HEATDAM_POINT:NONE]
[COLDDAM_POINT:NONE]
[IGNITE_POINT:NONE]
[GAIT:SWIM:Maximum Swim Speed:725:10:3:2175:50:LAYERS_SLOW:STRENGTH:AGILITY:STEALTH_SLOWS:50]
[GAIT:SWIM:Faster Swim:1450:5:3:2175:10:LAYERS_SLOW:STRENGTH:AGILITY:STEALTH_SLOWS:20]
[GAIT:SWIM:Fast Swim:2175:NO_BUILD_UP:5:LAYERS_SLOW:STRENGTH:AGILITY:STEALTH_SLOWS:10]
[GAIT:SWIM:Swim:2900:NO_BUILD_UP:0]
[GAIT:SWIM:Slow Swim:3900:NO_BUILD_UP:0]
[GAIT:SWIM:Creeping Swim:5900:NO_BUILD_UP:0]
[GAIT:WALK:Sprint:225:10:3:675:50:LAYERS_SLOW:STRENGTH:AGILITY:STEALTH_SLOWS:50]
[GAIT:WALK:Run:450:5:3:675:10:LAYERS_SLOW:STRENGTH:AGILITY:STEALTH_SLOWS:20]
[GAIT:WALK:Jog:675:NO_BUILD_UP:5:LAYERS_SLOW:STRENGTH:AGILITY:STEALTH_SLOWS:10]
[GAIT:WALK:Walk:900:NO_BUILD_UP:0]
[GAIT:WALK:Stroll:1900:NO_BUILD_UP:0]
[GAIT:WALK:Creep:2900:NO_BUILD_UP:0]
[GAIT:CRAWL:Scramble:225:10:3:675:50:LAYERS_SLOW:STRENGTH:AGILITY:STEALTH_SLOWS:50]
[GAIT:CRAWL:Faster Crawl:450:5:3:675:10:LAYERS_SLOW:STRENGTH:AGILITY:STEALTH_SLOWS:20]
[GAIT:CRAWL:Fast Crawl:675:NO_BUILD_UP:5:LAYERS_SLOW:STRENGTH:AGILITY:STEALTH_SLOWS:10]
[GAIT:CRAWL:Crawl:900:NO_BUILD_UP:0]
[GAIT:CRAWL:Slow Crawl:1900:NO_BUILD_UP:0]
[GAIT:CRAWL:Creep:2900:NO_BUILD_UP:0]
[GAIT:CLIMB:Scramble:225:10:3:675:50:LAYERS_SLOW:STRENGTH:AGILITY:STEALTH_SLOWS:50]
[GAIT:CLIMB:Faster Climb:450:5:3:675:10:LAYERS_SLOW:STRENGTH:AGILITY:STEALTH_SLOWS:20]
[GAIT:CLIMB:Fast Climb:675:NO_BUILD_UP:5:LAYERS_SLOW:STRENGTH:AGILITY:STEALTH_SLOWS:10]
[GAIT:CLIMB:Climb:900:NO_BUILD_UP:0]
[GAIT:CLIMB:Slow Climb:1900:NO_BUILD_UP:0]
[GAIT:CLIMB:Creep:2900:NO_BUILD_UP:0]
[DESCRIPTION:A gigantic eyeless chameleon twisted into humanoid form. It squirms and fidgets. Its clear scales are large and set far apart. Beware its noxious secretions!]
}}

{{Creatures}}
{{Category|Amphibious}}
{{Category|Building destroyer}}
{{Category|HFS}}
{{Category|Fanciful}}
{{Category|Fire immune}}
{{Category|Learns}}
{{Category|No Exert}}
{{Category|No Pain}}
{{Category|No Stun}}
[[ru:Demon]]

{{Translation
| dwarven = uthgúr
| elvish = slevina
| goblin = arstruk
| human = rohir
}}

Cage

2023-01-16T16:40:16Z

Kelvie: /* Creature containment */ Add note about trading creatures.

{{migrated article}}
{{Quality|Unrated}}
{{av}}

{{furniture|name=Cage
|tile=‼|col=0:6:0
|wood=y
|metal=y
|glass=y
|rooms=
* [[Jail]] (if metal)
}}
:''For information on cage traps, see [[Trap#Cage_Trap|traps]].''

'''Cages''' are used in [[cage trap]]s, [[jail]]s, [[zoo]]s, [[Activity_zone#Pit/Pond|pit]]s and aquariums. A glass cage is called a '''terrarium''' or, if filled with [[water]] for holding [[Captured live fish|captured]] live aquatic [[vermin]], an '''aquarium'''.

Cages are stored in an animal [[stockpile]] (unless they have been [[Wear|worn out]] somehow, in which case they are stored in a refuse stockpile). Dwarves will attempt to collect and store cages in stockpiles if the "Dwarves Gather Animals" [[Standing_orders|order]] ({{k|y}} - '''Standing orders''' tab - '''Hauling''' tab) is enabled.

Empty cage storage can be controlled by toggling the "empty cages" option for animal stockpiles.

==Building and using a cage==
[[File:cage_preview.jpg|thumb|270px|right|Cages work well for humanoids as well.]][[File:cage_trap_preview.jpg|thumb|270px|right|Capturing that thing was the "easy" part. ''Art by kruggsmash'']]

A cage can be constructed from a log of [[wood]] at a [[carpenter's workshop]], three bars of [[metal]] at a [[metalsmith's forge]], or from [[glass]] at a [[glass furnace]].

You can then either build them on a tile via {{k-|b|r|g}} (this is needed for linking a [[lever]] to them, or assigning a tame animal to it) or simply keep them stockpiled so they can be used to load cage [[trap]]s.

When building a cage, you can choose a cage that already has something inside. To precisely select which cage to use, you can expand the list of cages with {{k|x}}.

===Creature containment===

To assign creatures to a cage, first build the cage in the location you want using {{k-|b|r|g}}. You can only assign creatures to a cage that is not part of a dungeon zone. Cages in a dungeon will have prisoners assigned automatically as part of the [[Justice#Cages_and_Chains|justice]] system. To assign a creature to the cage, first select the cage, and then press the "+" button on its status page. Use {{k|Shift}} and the mouse wheel to quickly scroll up and down the list of [[creatures]], and {{k|click}} to assign them to the cage. Creatures currently assigned to the cage are listed at the top; the rest of the creatures are listed in order of arrival on the map (including any inaccessible creatures). Note that tame grazing creatures will starve if left in cages, though pet owners may feed their pets. Instead of caging grazers, assign them to a [[zone|pasture]] that has plenty of tasty [[grass]] and/or [[cave moss]].

Multiple creatures can be assigned to the same cage with no penalty. It is possible to fit hundreds of [[dog|puppies]] with dozens of [[dragon]]s, and whatever other animals are on hand, in a single cage with no ill effects. This has led some players to conclude that cages include some sort of hidden "cage space" that allows infinitely tight packing of creatures.

There is no particular labor for releasing creatures from built cages. Select the cage to examine it (it must first be "built," not just stored - use {{k-|b|r|g}} to build a cage, and then to toggle the animal(s) currently inside (animals assigned to the cage will show up on the cage's page). Any available dwarf will perform the job, so beware of pitting untamed or hostile creatures with a weak dwarf.

Alternatively, creatures can be released from un-built cages provided that they are able to be assigned to a pasture, ie. animals, tame or otherwise. Once assigned to a pasture, a dwarf will automatically remove them from their cage and lead them to their assigned pasture. Note that if the cage containing the creature is already within the pasture, the creature will '''not''' be released, as it is considered to be already in its pasture.

Caged citizens of (and visitors to) your fort, if wounded, will be freed by the "Recover Wounded" job and taken to the nearest hospital zone. This mostly occurs during loyalty cascades, when separatists are knocked unconscious while fighting on a cage trap. If the hauling dwarf is from the other faction, it is possible that they lay the patient in bed and then immediately attack her.

You can get details about the creatures which are in a built cage by pressing {{k|t}} and then {{k|enter}}. There, you can scroll the list of creatures and get details, for example, you can tell whether a creature is male or female, which is useful if you are preparing a breeding program.

[[Vermin]] can also be assigned to cages, to save space or [[animal trap]]s. However, if you try to release them ({{k|q}} and then {{k|a}}), the dwarf will pickup an animal trap and put the poor creature back in a stock cage. To explicitly release an animal, instead "pull" the animal somewhere else: either assign the animal to a [[pit]] (which could simply be a hillside outside your fortress), or a pasture. This has the benefit of making it clear where the animal is being released. However, keep in mind the dwarf will uncage the animal first and then lead it to the release, so large/dangerous animals may escape en route. Consider using the [[dump]] command to move the cage before release, or assign the animal stockpile next to the pit/pasture.

Bees show up in the list of creatures that can be assigned to a cage, but the dwarves will not start the task, and it will not be shown in the {{k|j}}obs list.

Creatures in cages cannot be attacked (though any existing attack orders will '''not''' automatically cancel, leaving your militiadwarves milling around the cage uselessly). Most caged creatures are also unable to attack, although some special attacks (such as gaseous noxious secretions) can still be used. Creatures in cages are also immune to damage from falling, and falling objects. [[Breeding]] creatures are unable to get pregnant if caged, although they will give birth while caged if they were already pregnant. Creatures in cages also age, so [[kitten]]s in a cage will eventually become adult cats. Creatures in cages are affected by extreme temperatures, and [[dwarven atom smasher|atom smashing]] the cage will also obliterate the occupants, even if they are normally immune to smashing. Casting a cage in [[obsidian]] will not harm the occupants (though the temperature might, if the cage is subjected to magma for very long).

Beware of cages that contain creature(s) with very high internal temperature, such as [[fire imp]]s. They cannot harm your dwarves directly while caged, but their body heat ''can''; by heating up the tile that the cage occupies. If the cage-hauler is very slow and weak, they may spend enough time in each tile to feel the effects of the heat, and they will, dutifully but foolishly, continue to haul the cage until their head melts off. To move "hot" cages safely over long distances, make sure that a strong or fast dwarf hauls it.

"Deconstructing" a cage via {{k-|q|x}} with creatures in it does not harm the cage, the dwarves will return the cage (with the creatures in it) to the nearest animal stockpile.

If you melt the cages, creatures inside will be released.

==== Trading contained creatures ====

Most creatures can be traded, but not sapients (such as goblins, trolls, trologdytes). If you attempt to haul caged sapient creatures to the trade depot, they will try to escape instead, and many times they will not go without a fight!

===Prisons===

To set a cage as a [[jail]], {{k|q}}uery the cage, designate it as a {{k|r}}oom, and then set it to be used for {{k|j}}ustice. Only [[metal]] cages may be used in this way, despite [[wood]]en cages being strong enough to hold [[dragon]]s.

If the cage is already located within a designated Jail room, it will be automatically included in the jail.

===Remotely opening cages===

A built cage can be linked to a [[lever]] to remotely open it. When the cage opens, the occupant(s) inside are released, the cage and [[mechanism]] deconstruct and can be returned to their respective stockpiles. Note that you have to use a "built" cage as described above, it won't work with cages on your stockpile. Also note that the mechanism attached to the lever will '''not''' automatically deconstruct; you have to manually deconstruct the lever to get back the mechanism used to open the cage.

Alternately, when traders are around, you can select "move good to trading depot" and select the cage of choice. When a hauler takes the cage, any untameable creatures inside will be released; be sure to disarm the creature beforehand... This is also the easiest way of releasing caged dwarves.

A way to release creatures from stockpiled cages (which have not been built) is to assign the creatures to a [[pasture]] (which is possible for any living thing except dwarves). The same precautions as for trading the cage should be taken first.

Another way is to use the [[container]] spilling effect: cages [[Trap_design#Shotgun|hurled from a colliding minecart]] ''also'' spill their contents upon collision (see [http://www.bay12forums.com/smf/index.php?topic=109460.msg3340230#msg3340230 this forum message]). This combines timing control of a lever or pressure plate with the reusability of pitting. If you want to deliver Goblin snatchers into your target practice room despite [[Thief|thieves]]' ability to wriggle out of normal pitting, or a bunch of [[cave floater]]s toward invaders, this method may be preferable.

===Cages and fluids===

A cage will protect a creature inside it from [[swimmer|drowning]], so if you want to drown a creature in a cage, you must open it remotely, as explained in the above section (as a corollary, if your fortress is drowning in water, you can cage your dwarves and rescue them later). However, built cages will not protect caged creatures from [[magma]], making this a somewhat faster option, as it doesn't require linking each cage to a lever. Cages which are not [[magma-safe]] will be degraded and/or destroyed by this process, and cages which are made of flammable materials (such as wood) may be set on [[fire]]. Any items the creature had equipped will teleport {{verify}} to wherever the creature was caged, typically a tile with a [[cage trap]] on it. These items may or may not be on fire; no case of teleporting !!large cave spider silk sock!!s have yet been observed, but this doesn't prove it can't happen. Exercise caution.

It's also possible to cage fluids(done by pushing uncaged animals/invaders over armed cage traps with water.) The cage containing the liquid must be built to remove the liquid. *magma not tested (yet)

===Buying cages ===
Traders may bring cages for sale. If those contain a [[tame]]d [[creature]] or [[vermin]], the item will be listed as ''(creature) cage'', and the material will only be mentioned in parentheses behind the item name, e.g. Wolf Cage (Oaken).

===Selling caged creatures ===
If you want to sell an animal, you need to assign it to a constructed cage first (see above) and then deconstruct the cage by {{K|q}}uerying it and pressing {{K|x}}. You can then select the cage in the trading menu.

Note that only tamed animals can be traded safely. The dwarf assigned to hauling a container will look through its contents and chuck out anything that can't be traded. In the case of cages, this means anything sentient - including such nasties as [[cyclops|cyclopes]].{{Bug|4065}} Letting such monsters loose in the middle of your fort is good [[fun]].

=== How to disarm hostiles in cages ===
An easy way to take away all prisoner-held armor and clothing is via the mass designation tool. Designate an area with {{K|d}}-{{K|b}}-{{K|c}} to claim and {{K|d}}-{{K|b}}-{{K|d}} to dump an area (i.e. your animal [[stockpile]], filled with caged prisoners). Afterwards, hit {{K|k}}, and go over each cage and press {{K|d}} for each of them - this stops the dumping on the cages themselves. You will need a [[DF2012:Activity zone#Garbage Dump|garbage dump]] set up already for the dwarves to take the dumped items to. The dwarves will strip the prisoners naked and haul the items away. The cages themselves (and the creatures within) will remain in place. The items will end up in the garbage dump zone. If you want to reuse the items, you need only to designate claim {{K|d}}-{{K|b}}-{{K|c}} on your garbage dump zone to reclaim the items after they are dumped there. If your animal stockpile is outdoors, you need to have the "Dwarves Gather Refuse from Outside" {{K|o}}-{{K|r}}-{{K|o}} order set.

An easier way to selectively disarm prisoners is to designate mass forbid {{K|d}}-{{K|b}}-{{K|f}} and mass dump {{K|d}}-{{K|b}}-{{K|d}} on all of the caged prisoner stockpile. You will need a [[bookkeeper]] for this. Press {{K|z}} and go to the [[stocks]] screen. Find an item category with items marked '''F''' and '''D'''. Press {{K|f}} to remove the '''F''' for those items, but don't remove the '''D'''. This will unforbid them, but they will remain marked for dumping. When you exit the stocks screen, the dwarves will haul those items from the cages and drop them into the garbage dump. When the dwarves have finished the hauling tasks, designate a mass claim {{K|d}}-{{K|b}}-{{K|c}} and mass undump {{K|d}}-{{K|b}}-{{K|D}} on the same area as earlier to remove the forbid and dump designations from the cages and the rest of the contents.

This method can be used to confiscate specific items from caged prisoners, like weapons, armor or bags containing stolen property or kidnapped children. It can be more useful to just remove their weapons if you want to use your caged prisoners for target practice; they will be more durable with their clothes and armor equipped, but not very dangerous without their weapons.

To selectively remove only weapons from caged prisoners, first claim the entire prisoner stockpile, then {{K|d}}-{{K|b}}-{{K|h}} to hide everything including cages, buildings and prisoner equipment. Go in to your standard (non-dfhack) stock screen and browse the weapons section. Anything tagged with a blue '''H''' is a hidden prisoners' weapon, dump them. Once you have selectively removed only their weapons, use {{K|d}}-{{K|b}}-{{K|H}} to unhide everything. This works with everything like shields and armor, not just weapons.

[http://www.bay12forums.com/smf/index.php?topic=81601.0 Source.]

Alternatively, [https://dfhack.readthedocs.io/en/stable/docs/_auto/base.html#stripcaged dfhack 'stripcaged'] is available, but the 'weapons' switch also removes their shields.

'''An updated process for v50 can be found in the following reddit conversation:''' https://www.reddit.com/r/dwarffortress/comments/zluzq6/disarming_caged_prisoners/

=== Emptying refuse ===
If you [[animal trainer|tame an animal]] while it is inside a cage (a process which involves feeding a plant to the caged animal), you may leave seeds inside the cage. To get these out, you must mark them for [[activity zone#Garbage_Dump|dumping]], designate a garbage zone, and wait for a dwarf to dump the seeds in the garbage zone. Then you can reclaim them.

Animals that expire in a cage (built in a [[zoo]], or just sitting in an animal stockpile) also clutter up the cage until removed. If the cage is unbuilt and the animal is [[butcher]]able, your dwarves may haul the animal, cage included, to the butcher shop for processing. If not, you will need to manually clean the cage by dumping the corpse and any other items.

Marking refuse for dumping can be done by pressing {{k|k}} for an unbuilt cage ({{k|t}} for a built cage), then selecting the cage and pressing {{k|Enter}}, then selecting the item and pressing {{k|Enter}} again, and finally pressing {{k|d}} to mark the item (rather than the cage) for dumping. Or if there is a lot of refuse, you can use {{k|d}}-{{k|b}}-{{k|d}} to mass-dump everything in the tile, and then un-mark the cage itself.

=== How to quickly empty out many cages ===
If you have many [[Trap#Cage_Trap|cage traps]] then you may have trouble emptying out cages quickly enough at times. See [[Mass pitting]] for suggestions on how to quickly recycle cages. Be advised that there are now reports of frequent escapes while using this method (confirmed for v0.40.10).

Another easy way to quickly empty cages is to simply send the imprisoned creatures to a pasture, where your squad can slaughter them.
(Your dwarves can drag every goblin except thieves).
The easiest way is to place the pasture right next to the cages and let your dwarves shoot them down. This way you can kill the thieves and monsters too.

Another fun method is to put a 1x1 pasture in the middle of your barracks. Next, tell a squad to kill the target creature in the cage and watch them line up around the prisoner. Finally, assign the prisoner to the pasture in the middle of the barracks. A dwarf will be along shortly to drag the prisoner from the stockpile to the pasture, while your squad beats on them enroute. Even thieves that can't be dragged are still mobbed by your squad waiting as soon as the cage is opened.

== Comparison of cage types ==
As stated before, cages can be made either of wood, metal, or glass. The choice of material reflects the cage's usefulness at certain tasks. To compare:
* '''Wooden''' cages are [[weight|light]] and [[value|cheap]], and easy to mass produce in most [[biome]]s. They are notably not resistant to [[fire]], and will burn up in a forest fire, even when already loaded into an otherwise fire-safe [[cage trap]]. Wooden cages can also be bought from [[elf|elven]] [[caravan]]s if your site has no access to wood itself.

* '''Metal''' cages have the advantage of not being flammable. These are usually [[fire-safe]], and a few types are [[magma-safe]] as well, but this varies depending on what [[metal]] they are made of. These cages are inferior for usage in cage traps, though, because of their high [[weight]] they take ''a lot'' of time to be hauled back and forth. Cages made of cheap metals (copper, tin, zinc, nickel, lead) can be bought in bulk from [[human]] and [[dwarf|dwarven]] merchants, and are the only type of cages these merchants will ever sell.

* '''Glass''' terrariums can be made at a [[glass furnace]] from as little as a [[bag]] of renewable [[sand]]. The three types of glass have exactly the same physical properties, they differ only in [[value]]. All are magma-safe, having a melting temperature higher than any metal. They are heavier than wooden, but much lighter than metal ones, and their weight usually does not inhibit hauling jobs. For all non-decorative uses, green glass should be chosen, as it requires less ingredients and takes less time to be produced than other types of glass.

{{buildings}}

==Bugs==

* Creatures in cages that come from dead merchants can only be freed by assigning them to a [[Zone#Pen/Pasture|pen/pasture zone]] and then when they have been put there, deassigning them from the pen/pasture.
* When bringing a cage to the Trade Depot in order to trade it, any untameable creatures inside the cage will be freed. Tamed (and presumably also wild but tameable) animals can be safely traded. {{Bug|4065}}
* Aquariums cannot be used to store large fish (they will drown), though vermin fish work just fine. {{Bug|1590}}
* Dwarves trapped in cages cannot be directly freed. They can only be released by building the cage and connecting a [[lever]] to it, or ordering the cage be brought to a trade depot. {{bug|3070}}

{{Translation
| dwarven = mokez
| elvish = ofúru
| goblin = obtux
| human = tin
}}

{{Category|Justice}}
{{Category|Buildings}}

Strange mood

2023-01-15T05:18:56Z

Kelvie: Add my observation to the bone requirement without a butcher, we can talk about it in the Talk page in case I'm misunderstanding.

{{migrated article}}
{{Quality|Unrated}}
{{av}}
{{buggy|bugsection=Bugs}}
{{minorspoiler}}
[[File:strange_mood_prev.png|thumb|350px|right|A dwarf losing ownership of his mind. ''Artwork by Zippy'']]
Periodically, individual [[Dwarf|dwarves]] are struck with an idea for a [[legendary artifact]] and enter a '''strange mood'''. Dwarves which enter a strange mood will stop whatever they are doing and pursue the construction of this artifact to the exclusion of all else. They will not stop to eat, drink, or sleep. Pretty much the only thing that can pause a dwarf is giving birth, after which they will immediately get back to making the artifact. If they do not manage to begin construction of the artifact within a handful of months, they will go [[#Failure|insane]] and die soon afterward.

Note: All controllable civilizations with the {{token|STRANGE_MOODS}} token are able to enter strange moods, though, by default, the only civilization this applies to is dwarves.

==Overview==
[[File:mood_announce_v50_x2.png|right]]Once your fortress has at least 20 dwarves, occasionally, one of them will be struck by a "strange mood". These largely random events will be seen as an [[announcement]], and will pause the game.

A dwarf struck by a strange mood will seek an appropriate workshop, immediately claim it for the duration of the mood, attempt to collect the materials to create their [[artifact]] of choice, and, once those have been collected, proceed to do so. Depending on the exact mood (see [[Strange mood#Types of moods|types of moods]], below), both the workshop and the artifact are based on the highest "moodable skill" of that dwarf (see "[[Strange mood#Skills and Workshops|Skills and Workshops]]", below).

At the end of this process, if successful, the dwarf will '''usually''' gain enough [[experience]] to become Legendary (or higher), and then return to life as normal, but now with a Legendary skill. The "possessed" mood is an exception to this rule, as it does not grant any experience upon completion.

A dwarf cannot be struck by more than one mood in their lifetime.

=== In Fortress mode ===
# The game will announce that the dwarf has entered one of five different types of strange moods. The [[#Types of moods|types of moods]] are listed below. While in a mood, a dwarf will display a blinking exclamation point (see [[Status icon|status icons]]).
# For the duration of the mood, the dwarf will claim a workshop related to the skill that the mood affects (not all skills are eligible), kick out any dwarf who was using it, and render it otherwise unusable until the mood has ended. If a moody dwarf does not claim a workshop, it is because the appropriate workshop does not exist. (See [[#Skills and workshops|skills and workshops]] below to determine which workshop(s) might be required.) A moody dwarf will ''not'' be able to build a needed workshop; another dwarf with the appropriate [[labor]] designation must do so for them, if one is necessary. Furnaces are also counted as a workshop.
# After claiming a workshop, the dwarf will set about collecting the required materials for their artifact. If the dwarf remains idle inside the workshop, it's because they cannot find the right material. Reference the [[#Demands|demands]] section to determine what may be required. Important Note: They will only collect these materials in the order that they require them. In other words, you have to determine where they are on the list of required materials and then provide the next one before they will continue collecting other materials.
# Once all materials have been gathered, the game will once again pause and center, and the moody dwarf will begin construction. Upon completion, the dwarf will create a semi-random artifact related to the skill affected and gain [[legendary]] (or higher) status in that skill (unless the mood type is [[#Possessed|possessed]]). See the [[#Skills and workshops|skills and workshops]] for information on which skills can be gained, or the [[#Artifacts created|artifacts created]] section for more details on the artifacts themselves.
# While you have some control over the skill the dwarf uses, and so some (but less) control over the type of artifact created, and (with some effort) the materials used, you have no control over which dwarf is struck by a mood, nor the type of mood that strikes them, nor the specific type of artifact created.
# The conditions necessary for a strange mood to occur have been fully understood due to a disassembly of the game; see below for the exact mechanics.

===In world generation===
Long before your seven dwarves [[embark]] on their adventure, non-player dwarves may also be struck by strange moods during world generation, albeit these are treated more abstractly. These events are a primary source of non-player artifacts that are scattered across the outside world when the game starts (see [[Mission]]). They have the same properties and quality as any artifact your fortress could have produced, and may be stolen or pillaged just like any other non-player artifact.

== Skills and workshops ==
If struck by a Fey, Secretive or Possessed mood, the workshop and artifact will be based on the highest "moodable skill" that a dwarf possesses. Not all skills are moodable. Fell and Macabre moods will either claim a butcher's shop and use Bonecarving, or a tanner's shop and use Tanning (see [[Strange mood#Types of moods|Types of moods]], below).

{| class="wikitable sortable" cellpadding="4" style="border:1px solid black;border-collapse:collapse;text-align:left;float:right;margin:0 0 20px 30px;vertical-align:top;"
|-
! Highest skill
! Workshop required
|- style="background-color:palegreen"
| [[Armorsmith]]
| [[Metalsmith's forge]] (or [[Magma forge]])
|- style="background-color:palegreen"
| [[Bone carver]]
| [[Craftsdwarf's workshop]]
|- style="background-color:palegreen"
| [[Bowyer]]
| [[Bowyer's workshop]]
|- style="background-color:wheat"
| [[Carpenter]]
| [[Carpenter's workshop]]
|- style="background-color:palegreen"
| [[Clothier]]
| [[Clothier's shop]]
|- style="background-color:lightgray"
| [[Engraver]]
| [[Craftsdwarf's workshop]]
|- style="background-color:wheat"
| [[Gem cutter]]
| [[Jeweler's workshop]]
|- style="background-color:wheat"
| [[Gem setter]]
| [[Jeweler's workshop]]
|- style="background-color:wheat"
| [[Glassmaker]]
| [[Glass furnace]] (or [[Magma glass furnace]])
|- style="background-color:palegreen"
| [[Leatherworker]]
| [[Leather works]]
|- style="background-color:wheat"
| [[Mason]]
| [[Mason's workshop]]
|- style="background-color:palegreen"
| [[Mechanic]]
| [[Mechanic's workshop]]
|- style="background-color:wheat"
| [[Metal crafter]]
| [[Metalsmith's forge]] (or [[Magma forge]])
|- style="background-color:wheat"
| [[Blacksmith|Metalsmith]]
| [[Metalsmith's forge]] (or [[Magma forge]])
|- style="background-color:wheat"
| [[Miner]]
| [[Stoneworker's workshop]]
|- style="background-color:lightgray"
| [[Stone crafter]]
| [[Craftsdwarf's workshop]]
|- style="background-color:wheat"
| [[Tanner]]
| [[Leather works]]
|- style="background-color:palegreen"
| [[Weaponsmith]]
| [[Metalsmith's forge]] (or [[Magma forge]])
|- style="background-color:wheat"
| [[Weaver]]
| [[Clothier's shop]]
|- style="background-color:lightgray"
| [[Wood crafter]]
| [[Craftsdwarf's workshop]]
|- style="background-color:lightgray"
| <none>
| [[Craftsdwarf's workshop]]
|}

A dwarf will claim a workshop according to their highest applicable skill, and upon completion of the artifact, gain 20,000 [[experience]] in that skill (excepting [[Strange mood#Possessed|possessed]] dwarves). This will give the dwarf a legendary-level [[skill]] (specifically, "legendary+1" or higher, depending on the dwarf's initial skill level). The table to the right describes all applicable skills and their potential workshop requirements – there are only 20 skills that determine the workshop and that can be affected by a mood (sometimes referred to as '''moodable''' skills.) If a dwarf does not possess at least one of the moodable skills listed to the right, they will take over a [[craftsdwarf's workshop]] and gain one of [[bone carver]], [[stone crafter]], or [[wood crafter]] skills, producing an artifact [[craft]].

When selecting the desired mood skill, only the level itself is checked, and if the highest level found is shared by multiple skills, then one will be selected randomly.

This fact can be utilized to maximize the possibility of getting a dwarf with the specific legendary skill you want: since ''non''-moodable skills are ignored, whenever possible make sure that each dwarf's highest ''moodable'' skill is one of those you want. Have all your peasants, [[farmer]]s, non-professional military and other dwarves without any moodable skills do one job each in the skill(s) you most want; if a "[[experience|dabbling]]" skill is the highest moodable skill they have, that is the skill that will be used. [[Guildhall]]s related to moodable skills may both help and hinder, as demonstrations will increase skill levels without any jobs being done.

[[Scholar]]s may discuss mechanics as part of their work and gain a small amount of experience in it. This is the only skill that scholars discuss that is moodable.

=== "Best" skills ===
Some skills produce generally useful and valuable items, and others produce only trinkets or jewelry. While "best" is very subjective, balancing the artifact itself with the Legendary skill the mood (usually!) produces, and both of those against the needs and goals of the current fortress, generally speaking the skills can be broken down into tiers of usefulness.

Note that in addition to an artifact, the mood will (usually) raise the dwarf to Legendary in the chosen skill; often this is, from a practical standpoint, more valuable than an artifact, so you might consider trying to push poorly-trained dwarves towards moodable skills you have a need for, instead, in case they are struck by a mood.

* [[Weaponsmith]] is one of the "best" skills. While the moody dwarf might create a questionable lead spear or lightweight aluminum mace, the odds are they'll create something that is still more deadly than its ☼steel☼ equivalent. And with a little manipulation, you can at least make sure the item ''is'' steel, although they could still give you a non-dwarf weapon. [[Mechanic]] is a close second for reliability and usefulness –- any mechanism's [[quality]] modifies the chance for a trap to hit its target, an artifact [[Trap#Weapon trap|weapon trap]] never jams{{verify}}, and an artifact lever in a room will make its value skyrocket (even if not connected to anything!).
* [[Armorsmith]] is similarly valuable, having a decent chance to create something with exceptional value for your military (or at least one member of it), but, similar to weapons, this requires manipulating available material to avoid getting [[Armor#Material|soft]], useless gold or lead [[armor]] pieces. And, while moody [[Bowyer]]s can create artifact wood/bone [[crossbow]]s of great accuracy, they can also give you [[blowgun]]s. Good luck with either one.
* Artifact [[furniture]] is unbreakable by building destroyers and creates otherwise-impossible fortress defense options. A dwarf with a preference for doors, hatches, or floodgates will always produce that item, which can then be locked against many enemies that would otherwise break through. It can also have huge monetary worth for improving room value, and placing an artifact item where all can pass by and admire it will be good for general morale. These skills include [[Mason]]s, [[Miner]]s (who are treated the same as masons), [[Carpenter]]s, and [[Blacksmith|Metalsmith]]s. Many of these can also produce items from the lower-utility lists, below. But maybe you'll get an artifact [[mug]] for your tavern. Good luck with that, too.
* These next are (very?) odds-against; chances are good that they'll produce something on one of the ''next'' lists, or at best some nice furniture, but there's a (very) small chance it'll be something truly useful as well as valuable. [[Clothier]]s can make an artifact [[rope]], and [[metal crafter]]s can create [[chain]]s, either of which can be used for your main [[well]]. Similarly with a [[carpenter]] or [[blacksmith]] and [[bucket]]s. [[Glassmaker]]s can create an artifact trap component. [[Leatherworker]]s and [[tanner]]s can create [[shield]]s, and both they and [[bone carver]]s can create artifact Leather/Bone Armor pieces, which are great if you have Hunters, etc. Which are all better than the next two...
* Next to last are skills that produce an artifact that could only be worn by one dwarf, and perhaps admired by others they come in contact with. [[Clothier]]s and [[weaver]]s fall just below some of the above: for no ability to produce anything except wearable, non-military items. [[Gem cutter]]s and [[Gem setter]]s can fall on this list too, as creating something of pure monetary value and no practical use in your dwarven society.
* Last on the list are "crafts" – surprisingly valuable trinkets in the form of amulets, totems, rings, figurines – or, at best, crowns, which at least ''sound'' impressive. These skills are [[engraver]], [[stone crafter]], and [[wood crafter]] (and a distinct chance from several of the skills mentioned earlier: [[bone carver]], [[gem cutter]], [[gem setter]], [[glassmaker]], and [[metalcrafter]].)
:* Peasants, defined here as having no moodable skill, always produce from the crafts list: It's always a good idea to have every newly arrived "peasant" migrant craft just one item from the moodable skill of your choice, to avoid such a tragic waste of dwarfcraft.

== Types of moods ==
For each of the following types of moods, the first message is how the mood is [[Announcement|announced]]; the second message appears in the dwarf's profile when he or she is viewed with the {{K|v}} key. All moody dwarves will have "Strange Mood" listed as their active task and are "quite content", regardless of any recent [[thought]]s they may have had.

=== Fey ===
* {{Gametext|<dwarf> is taken by a fey mood!|7:1}}
: ''Has the aspect of one fey!''

This is the most basic strange mood. Fey dwarves will clearly state their demands when the workshop they are in is examined.

=== Secretive ===
* {{Gametext|<dwarf> withdraws from society...|7:0}}
: ''Peculiarly secretive...''

Secretive moods are the same as fey moods, except a secretive dwarf will sketch pictures of their required materials instead of clearly stating their demands if they cannot find what they need. Descriptions of all these [[#Demands|secretive requirements]] can be seen only by viewing the workshop that the moody dwarf has claimed, with {{k|q}}, and then only while the dwarf is waiting inside it. More than one "picture" is likely; these will cycle through the entire list automatically if any one is not available. (Since materials are gathered ''in order'', it's quite possible that only one of a long list is needed to allow the moody dwarf to continue on their project. If the dwarf has gathered some of the materials (seen as "tasked" when looking at the workshop with {{k|t}}), then the next in the list is what they are looking for.)

=== Possessed ===
* {{Gametext|<dwarf> has been possessed!|5:1}}
: ''Possessed by unknown forces!''

Possessed dwarves have cryptic material requests, and have the unfortunate distinction of not receiving any experience upon successful construction of an artifact. No controllable circumstances lead to a possessed mood instead of one of the more desirable fey or secretive moods, it is purely luck-based. Possessed dwarves will mutter the name of the artifact they are working on (which, under some circumstances, might end up being ''their own name'') once they have all the materials they need.

A possession is the only mood that does '''''not''''' result in a jump in [[experience]].

A possessed dwarf that "keeps muttering <name of the artifact>..." has already gathered everything they need.

=== Fell ===
* {{Gametext|<dwarf> looses a roaring laughter, fell and terrible!|5:0}}
: ''Has a horrible fell look!''

A dwarf that goes into a fell mood will try to take over a [[butcher's shop]] or a [[tanner's shop]]. If neither are available, any other workshop will be used instead. The dwarf will then ''murder'' the nearest dwarf, drag the corpse into the shop and make some sort of object out of dwarf [[leather]] or [[bone]]. The unfortunate dwarf is killed on the spot – no dragging to the workshop, just sneaking up behind them, killing them, and dragging their corpse to the workshop. Once the artifact is completed, the fell dwarf will become a legendary [[bone carver]] or [[leatherworker]]. Only unhappy dwarves may enter a fell mood.

Amusingly, it seems fell dwarves can also murder [[ghost]]s. If they do, they will murder a living dwarf as well, since ghosts obviously don't yield a corpse to butcher.{{bug|4681}}

Aside from the loss of a potentially important dwarf in the wrong place at the wrong time, there doesn't seem to be any downside to a fell mood. The end result is always an artifact and a legendary craftsdwarf. Since the only ingredient used (a dwarf) is available in abundance, a fell mood will only fail if the fell dwarf is completely isolated from other dwarves, or if the proper workshop does not exist.

If no one is around to witness the murder, whichever dwarf Urist McEmo decides to slaughter will be reported as missing some time after their death. If the murder is witnessed (or if the <s>idiot</s> dwarf in fell mood reports themself), the moody dwarf will be subject to dwarven [[justice]].

=== Macabre ===
* {{Gametext|<dwarf> begins to stalk and brood...|0:1}}
: ''Brooding darkly...''

Macabre moods are similar to fell moods, but the dwarf will not murder a fellow dwarf. A macabre dwarf may require [[bone]]s, [[skull]]s, or vermin [[remains]]; if you do not happen to have any, you will have to make some, e.g. by butchering an animal and/or allowing a [[cat]] to go hunting, or let the moody dwarf go [[insane]]. Like fell moods, only unhappy dwarves can enter macabre moods.

==Caveats==
* Shells are perhaps the most difficult-to-obtain material for a strange mood, though there are several {{catlink|Shell|creatures}} that produce shells. Some of these, such as [[armadillo]]s and [[common snapping turtle]]s, are butcherable. Vermin from [[fishing]] are the easiest and most renewable source of shells. [[Pond turtle]]s are common in many embarks in [[murky pool]]s, but usually only appear in small numbers, and can go extinct easily. A stream or river almost guarantees a functionally inexhaustible supply of [[mussel]]s. [[Nautilus]]es can also serve as sources of shells when cleaned at a fishery. Nevertheless, shells are rare and hard to acquire. Currently, the only way of trading for shells is to hope that the [[elven]] caravan brings some tamed shell-producing large creature. Traded [[cave lobster]]s and [[turtle]]s are ''processed'' fish (with the shells already removed). Tamed vermin with shells cannot be butchered for their shells, since the only way to get a vermin's shell is to [[Fish cleaning|clean]] it. Since all shelled non-vermin animals are [[exotic pet|exotic]], only elves will bring them. If you should be fortunate enough to acquire some breeding, shelled, butcherable animals, it's probably worth keeping a breeding pair around in case of future need. Only dwarves with a [[preference]] for shells will demand shells in a strange mood.
* All demands for cloth are for a specific generic type (plant, silk, or yarn). Clothiers and Weavers will demand [[adamantine]] cloth if any is available, otherwise the type will be the generic form of the dwarf's first cloth preference, or a randomly chosen variety if the dwarf has no preference (or if the cloth is for a decoration, not the primary material). Types of cloth your fortress has not produced are '''not''' excluded, so it's best to keep a few bolts of each type of cloth in reserve.
* Should the claimed workshop be a [[magma forge]] and lose power due to insufficient magma beneath it, the mood will fail immediately and the dwarf will go [[insanity|insane]]. Should the forge be in danger of losing power, you should forbid it before it is claimed and wait until it is powered up reliably. Once magma forges are built, at least some dwarves will no longer be satisfied with a regular forge.
* Similarly, if a workshop claimed by a dwarf is deconstructed, destroyed or [[Creature_token#BUILDING_DESTROYER|toppled]] the mood will immediately fail and the dwarf will go insane.
* The mood's primary material will only be mentioned ''once'' in the dwarf's requests, even if the dwarf wants more than one unit of it. [http://www.bay12forums.com/smf/index.php?topic=75139.0]
* The item type of the artifact to be created is not decided until the instant the mood ''ends''. Saving (even after a dwarf has begun to gather materials) will allow you to reload and the result may be a different artifact (unless the moody dwarf's preferences force a particular item type). If you want to get an artifact platinum warhammer, make sure to have platinum nearby and/or block access to any other materials.
* You can restart the artifact creating process, even after the dwarf has gathered most of the components, by forbidding the claimed items (use {{k|t}} to view the contents of the workshop, select the undesired material, and press {{k|f}} to forbid it). If other items of that type are available, the dwarf will immediately switch to them.
* Requests for bones are actually requests for any kind of bone stacks, not individual bones. Slaughter a puppy. [http://www.bay12forums.com/smf/index.php?topic=105002.0]

== Demands ==
Once a workshop is claimed, the dwarf will begin collecting materials. Each artifact will require 1-3 "base items" and up to 7 additional items for decorations. The dwarf may well need several items of one material!

If the moody dwarf remains idle, then the necessary materials are not available. [[Forbid|Forbidden]] items must be reclaimed ({{K|d}} – {{K|b}} – {{K|c}}) before they may be used, but moody dwarves will ignore settings regarding [[economic stone]]. Press {{K|q}} and highlight the workshop to receive a series of clues about what the dwarf needs. '''Hints that stay active for longer than 2 seconds mean that multiple pieces of that material will be required; each single demand will be displayed for 2 seconds, so if it says "gems... shining" for 6 seconds, 3 gems are demanded. However, the mood's primary material will always be shown for only 2 seconds, even if more than one is required.''' Materials will always be fetched ''in order'', so if at least one item has already been retrieved (the items will show up with "TSK" ("task") next to them when the workshop is viewed with the {{K|t}} context menu), it will usually be possible to tell what item is required next.

If you want your dwarves to construct their artifacts out of valuable materials instead of whatever useless thing happens to be close at hand, you can selectively forbid types of material through the stocks screen so that only the material you want them to use is available; though this might interfere with the normal crafting operations of your fortress, the disruption is generally short-lived (as long as you remember to unforbid them again afterwards!). You can even forbid something a moody dwarf is carrying (which may be necessary sometimes, since while they are not waiting in the workshop, they will not tell you what they need); the dwarf will finish hauling it to the workshop, but then immediately go searching for another. This trick can mean the difference between a bauxite statue decorated with moss agates and a native platinum statue encrusted with diamonds. Be aware that this may not always work – see below for more information.

Burrows allow even better control over a moody dwarf's material usage. Simply by creating a burrow around the claimed workshop and another part over the desired material, a moody dwarf can be controlled without forbidding every single stone in the fortress. A moody dwarf will follow the burrow definitions just like a regular worker, but be mindful that they will not leave the burrow to get materials that are outside of their assigned burrow. A problem can arise when bones from an outside refuse stockpile are needed by a moody dwarf that is assigned to a burrow.

Possessed Dwarf have been observed to demand items of a specific material. In this case the Dwarf will idle in the Workshop shouting for item categories that are in fact available. reclaiming items that were forbidden in order to make the moody dwarf use items of more valuable materials fixed that problem in the past.

The various demands are translated here:

:{| class="wikitable" style="text-align:left;width:90%;"
|-
! Material
! Fey
! Secretive
! Possessed
|-
|
| <dwarf> screams "I must have <demand>!"
| <dwarf> sketches pictures of <demand>.
| <dwarf> mutters "<artifact> needs <demand>..."
|-
| [[Stone]]
| rock
| a quarry
| stone... rock
|-
| Stone/metal [[block]]s
| rock blocks
| square blocks
| blocks... bricks
|-
| [[Wood]]
| wood logs
| a forest
| tree... life
|-
| Metal [[bar]]
| metal bars
| shining bars of metal
| bars... metal
|-
| [[Gem]]s (cut)
| cut gems
| cut gems
| gems... shining
|-
| [[Gem]]s (raw)
| rough gems
| rough gems
| rough... color
|-
| Green [[glass]]
| raw green glass
| glass
| raw... green
|-
| Clear glass
| raw clear glass{{verify}}
| glass and burning wood
| raw... clear
|-
| Crystal glass
| raw crystal glass{{verify}}
| rough gems and glass
| raw... crystal
|-
| [[Bone]] [http://www.bay12forums.com/smf/index.php?topic=105002.0;topicseen stack]
| bones
| skeletons
| bones... yes
|-
| [[Shell]] {{cite talk/this|Re:_.22Verify.22_on_the_shell_row_of_the_demands_table}}
| shells
| shells
| a shell...
|-
| [[Leather]]
| tanned hides
| stacked leather
| leather... skin
|-
| [[Cloth]] (plant fiber)
| plant cloth
| stacked cloth
| cloth... thread
|-
| [[Cloth]] (silk)
| silk cloth
| stacked cloth
| cloth... thread
|-
| [[Cloth]] (yarn)
| yarn cloth
| stacked cloth
| cloth... thread
|-
| [[Skull]]{{verify}}
| body parts
| death
| a corpse
|}

Dwarves in macabre moods will list their demands in the same fashion as those in fey moods (though with them brooding "Yes. I need <item>." instead of screaming "I must have <item>!"). They may also say "Leave me. I need... things... certain things", in which case they want special items, such as [[skull]]s or vermin [[remains]].

Related to the above behavior, moody dwarves demanding rock blocks will also accept blocks forged from metal bars.

*The first item demanded by the dwarf is based on the moodable skill being used – stoneworkers (miners, engravers, masons, stone crafters, and mechanics) will demand boulders, woodworkers (carpenters, wood crafters, and bowyers) will demand logs, leatherworkers and tanners will demand leather, weavers and clothiers will demand cloth, metalworkers will demand metal bars, gem cutters/setters will demand rough gems, glassmakers will demand raw glass, and bone carvers will demand bones.
**Metalworkers will demand adamantine wafers if any are available (unforbidden). If not, they will demand a preferred metal ''if'' you have smelted any bars of it – fey moods will state this outright, while for secretive moods and possessions, you will need to check the dwarf's [[preferences]] to see which metal they like. Metal bars acquired via [[trade]] or by melting down items (such as Goblinite) do ''not'' count as smelted. Otherwise, they will select any available metal(s).
**Weavers and clothiers will demand [[adamantine]] cloth if any is available (unforbidden). If not, they will demand a generic type of cloth (silk, plant fiber, or yarn) that matches a specific cloth preference (e.g. a dwarf that likes cave spider silk will require ''any'' type of silk cloth, and a dwarf who likes more than one type of cloth will demand whichever one appears first in their list). Dwarves without a cloth preference will demand a generic type at random.
**Glassmakers will demand their preferred type of glass ''if'' you've produced any of it (or if it's green glass); if they don't prefer any type of glass, they will randomly select one type of glass you've produced (though they will always assume you have created green glass). Note that acquiring raw glass from a caravan does ''not'' count as producing it.
**Dwarves in macabre moods will select either 1 vermin remains, 1 stack of bones, or 1-3 skulls.
**Bone carvers will demand shells if they like a type of shell; if not, they will demand bones.
**All preference-based material requests are decided the instant the mood begins – by the time the workshop is claimed, it is too late to change the dwarf's mind.
*The remaining "decoration" items are selected randomly from the following list: wood logs, metal bars, small gems, rock blocks, rough gems, boulders, bones, leather, plant/silk/yarn cloth, or raw glass (green/clear/crystal, based on what you've produced).
**Decoration items will never be the same type as the primary mood material.
**Certain mood professions will also explicitly avoid using certain items for decorations – most of these match up with the primary mood material, but miners, engravers, masons, and stonecrafters will additionally avoid requesting rock blocks.
**If you have not produced any raw glass in your fortress, moody dwarves will never request it.
**Dwarves in macabre moods have a 50% chance to replace each decoration item with either remains or bones.
** For the bone requirement, it appears that the bone stack needs to come from butchering an animal. Rotted animal corpses do not appear to count {{verify}}
*Gem cutters and gem setters have a 50% chance of only gathering a single rough gem and nothing else – when they do this, they produce a "perfect gem" with a single decoration.

Once all materials have been gathered, viewing the workshop with {{K|q}} will display a special message depending on the type of mood:
* Fey – "<dwarf> works furiously!"
* Secretive – "<dwarf> works secretly..."
* Possessed – "<dwarf> keeps muttering <artifact>..."
* Macabre – "<dwarf> works, darkly brooding..."
* Fell – "<dwarf> works with menacing fury!"

== The mechanics of moods ==

=== Frequency===
When a fortress is started, an internal counter is set to 1000. Every 100 frames (12 times per day), this counter is decremented by 1, running down to zero in about 3 months. When the counter would ordinarily be decremented when it has already reached zero, there is a 1 in 500 chance that a strange mood will strike. This means that, once all conditions are met and the clock is ticking, while there is approximately a 2.4% chance of a strange mood per day, or a ~52% chance of at least one strange mood per month, there is no guarantee when a mood will strike – might be sooner, might be (almost) never.

=== Conditions ===
In order for a dwarf to be struck with a strange mood, three conditions must be met:
:* There is no currently active strange mood,
:* The maximum number of artifacts is not met,
:* There are at least 20 eligible dwarves ''(see below)'', including dwarves who have already created artifacts.

If all three of these conditions are true, the game may trigger a strange mood according to the frequency.

==== Maximum number of artifacts ====
The maximum number of artifacts in any one fortress is limited by the lower of:
* The number of items created divided by 100.1 Mined-out rock ''does'' count as an "item created", though it is not clear whether bolts or units of drink are counted individually.
* The number of revealed [[subterranean]] tiles divided by 2304 (this is an area equivalent to a 48x48 square). Once you discover and explore the [[cavern]]s and [[magma sea]], this limit becomes largely irrelevant, and using a [[utilities#DFHack|"reveal" utility]] will eliminate it altogether, though strip-mining an area entirely and exposing it to the surface will count ''against'' this.
:1 – actually the sum of all items by type ''and'' by type+subtype+material, divided by 200. Furthermore, destroying items does '''not''' decrement these counters, so casting and mining [[obsidian]] will count toward this.

==== Eligibility ====
The deciding factor for eligibility is a dwarf's actual [[profession]]. ''(Note that "[[Skill#Professions|custom professions]]" have no effect on this!)'' Thus, dwarves may enter strange moods regardless of what skills they have or don't have, so long as they are of an acceptable profession. Dwarves who have already created an artifact are not eligible to create another, and since every mood ends in either an artifact or death, every dwarf may enter at most one mood. Dwarves who have obtained one or more legendary skills without creating artifacts ''may'' enter strange moods and will simply become even ''more'' legendary.

On-duty dwarves with a [[Soldier#Soldier professions|military profession]] other than "Recruit" ''cannot'' enter moods. Incidental military skills make no difference – eligibility (and weighting) depends purely on the actual ''[[profession]]'' as listed at the time (with the exception of unit leaders, whose on-duty and off-duty titles are the same). Soldiers are still capable of entering moods if they are ''off duty'' and thus in Civilian mode, but you don't have to worry about your axedwarves getting a burst of inspiration mid-combat and then wandering off to make a highest-quality craftsdwarfship gabbro scepter decorated with cow bone menacing spikes, cow bone rings and a cow bone image of hamster men while the trolls sack your settlement.

Children may enter moods, but babies will not.

Any other profession is eligible to enter a mood, but not all have the same ''chance'' to enter a mood.

:''('''Note''' – Specifically, and to avoid previous misunderstandings, [[Strand extractor]], [[Clerk]]/[[Administrator]]/[[Trader]], [[Doctor]] (and related), [[Soldier#Recruits|Recruit]] and [[Child]] ''are'' moodable professions.)''

There are several additional factors which will prevent a dwarf from entering a mood:
* Being unable to pick up items ("cannot grasp")
* Being dragged by/dragging another unit (off to [[jail]]/leading livestock to a [[cage]], [[chain]], [[pasture]], [[Activity zone#Pit/Pond|pit/pond zone]], or to the [[butcher's shop]] or [[farmer's workshop]].)

=== Chance ===
When determining who will have a strange mood, each eligible dwarf is put into a weighted lottery, where the chance of being selected is based on the dwarf's [[profession]]. Most professions receive 6 "tickets", but some receive additional tickets to improve their odds.

{| class="wikitable" cellspacing="0" border="2" cellpadding="5"
|-
! Weighting
! Professions
|-
| 21 ||Armorer, Blacksmith, Bone Carver, Clothier, Craftsdwarf, Jeweler, Gem Cutter, Gem Setter, Glassmaker, Leatherworker, Metalcrafter, Metalsmith, Stonecrafter, Weaponsmith, Weaver, Woodcrafter
|-
| 11 ||Bowyer, Carpenter, Stoneworker, Mason, Woodworker
|-
| 6 ||Engraver, Mechanic, Miner, Tanner, and all other [[profession]]s (including Peasant).
|}

:'''''Example:''' What this means is: if you had 21 dwarves, made up of 20 eligible farmers, furnace operators, miners, woodcutters etc. (with 6 chances each) plus one Armorer (with 21 chances), that one Armorer would have a 21 in 141 chance (20 dwarves x 6 chances each = 120 + 21 chances more = 141 total) of the mood striking them. That's about 1 in 7, while the other 20 have a 6 in 141 chance each, or about 1 in 24. The odds are still against the armorer, but much better than for any other single dwarf.''

Note that not every profession has a moodable skill. A Soaper, Architect, Furnace Operator or Strand Extractor can be taken by a mood, but that will not make those skills legendary, nor will they create an artifact bar of soap, building, bar of metal or wafer of adamantine.

=== Timing ===
A dwarf will go [[Insanity|insane]] after exactly 50000 ticks (which, at 1200 ticks per day, works out to 41.66 days, or almost a month and a half) waiting for an item they demand. However:
*The insanity countdown is reset after every item they bring to the workshop.
*It doesn't run while they are out getting something, working on their construction or on their way to claim a workshop. Only during time spent idling without either the required workshop or a required item do they spiral towards madness.
*Dwarves under strange moods do not feel hunger, thirst or drowsiness.

=== Fuel ===

{{D for dwarf}}

Curiously, [[metalsmith]]s in strange moods do not seem to require any [[fuel]] to complete their [[metal]] [[artifact]]s. It is believed that they, consumed by artistic passion, fuel the forges with their own beards, vigorously fanning the flaming hairs while they feed the furnace more beard. Such a sacrifice is a dwarf's own beard that only an artifact merits its removal. Only an artifact's completion can mollify its creator's shame; dwarves unable to complete this great pursuit go insane, not because of its failure, but because they cannot endure the inevitable humiliation.

Legend has it that the world's first [[elf]] once attempted to forge the world's most powerful artifact, imbued with magic to control all dwarves. But, because he could not suffer to cut a tree for fuel, he was unable to do so. Faced with no alternative, he kidnapped each of the seven ancient dwarves by tempting them with [[booze]], an unfamiliar drink to the first dwarves. He then forcefully shaved them and created [[charcoal]] from their beards.

Enraged by their loss, the dwarves set out to find the elf's home, based in the world's first tree. They startled the engrossed elf who fled with nothing but a handful of the tree's unborn children. After reclaiming the beard-charcoal, the dwarves set fire to this tree. Alight in flames hotter than the sun, the tree burned in what is believed to have been the world's hottest fire – a fire so hot that the tree's roots melted the inside of the earth, creating a worldwide [[magma sea]]. The elf watched this fire and swore revenge on the dwarves.

After realizing their beards could not be recovered from their charred state, the dwarves agreed to sprinkle the charcoal over the earth, as a gift and reminder to future dwarves. In doing so, they created the world's [[bituminous coal]] deposits. They then spent the next years searching for a way to create the drink they had been given. Discovering new drinks along their pursuit, the dwarves eventually perfected the hidden art of brewing booze and passed this emerging knowledge to coming generations.

== Artifacts created ==
The type of artifact created depends on the type of mood, the dwarf's highest moodable skill, and the base material. Masons and miners will always create some kind of stone furniture; bone carvers, a bone or shell object (including furniture); carpenters, a piece of wooden furniture; engravers and stone crafters, a stone craft; metalworkers, metal crafts, weapons, or armor (depending on the type of metalworker); weavers and clothiers, an article of clothing; tanners and leatherworkers, a leather armor or object. If a dwarf has no moodable skills, they will randomly select stone crafting, wood crafting, or bone carving as their mood skill and produce their artifact accordingly. The precise type of craft created is usually somewhat random, but if a dwarf has a personality preference for a particular item type, such as gauntlets or floodgates or crowns, and that thing is an available choice given the dwarf's profession, they are guaranteed to create an object of that type (if multiple preferences match, one will be randomly selected).

The first object grabbed by the dwarf will be the base material; all other materials will be used as [[decoration]]s. If a dwarf grabs a piece of [[chalk]] and makes a statue, for instance, it will be a "chalk statue", but an artifact can potentially include bone, cloth, gems, leather, metal, shell, stone, and wood decorations all at once. In some cases, a moody dwarf will produce an item which normally cannot be made from that material, leading to such odd constructions as an [[obsidian]] [[bed]], [[ruby]] [[floodgate]], or turtle [[shell]] [[cage]], but the actual item types available for each mood type are still very much restricted (e.g. only a glassmaker or jeweler can make a [[window]], and a moody clothier cannot produce an article of clothing that could not normally be made from cloth).

{| class="wikitable" cellpadding="4" style="border:1px solid black;border-collapse:collapse;text-align:left;"
|-
! Mood / Skill
! Artifact type
|-
| [[Armorsmith]]
| Each equipment item with [METAL] (mail shirt, breastplate, leggings, greaves, gauntlet, low boot, high boot, cap, helm, mask), any shield
|-
| [[Bone carver]] (bone)
| Each equipment item with [BARRED] (leggings, greaves, gauntlet, helm), any shield, instrument, toy, door, bed, chair, table, statue, coffer, bin, armor stand, weapon rack, cabinet, coffin, floodgate, hatch cover, grate, chain, cage, animal trap, figurine, amulet, scepter, crown, ring, earring, bracelet, any weapon, any trap component†
|-
| [[Bone carver]] (shell)
| Each equipment item with [SCALED] (leggings, gauntlet, helm), figurine, amulet, crown, ring, earring, bracelet, chain, cage, animal trap, instrument, toy
|-
| [[Bowyer]]
| Each ranged weapon (crossbow, bow, blowgun)
|-
| [[Carpenter]]
| Door, bed, chair, table, statue, chest, bin, armor stand, weapon rack, cabinet, coffin, floodgate, hatch cover, grate, cage, barrel, bucket, animal trap, splint, crutch
|-
| [[Clothier]]
| rowspan=2| Each equipment item with [SOFT] (dress, shirt, tunic, toga, vest, robe, coat, cloak, cape, trousers, loincloth, thong, short skirt, skirt, long skirt, braies, glove, mitten, sock, sandal, shoe, chausses, cap, hood, mask, turban, head veil, face veil, headscarf), bag, rope
|-
| [[Weaver]]
|-
| [[Engraver]]
| Figurine, amulet, scepter, crown, ring, earring, bracelet, goblet, instrument, toy
|-
| Fell Mood
| rowspan=3| Each equipment item with [LEATHER] (dress, shirt, tunic, toga, vest, robe, coat, cloak, cape, armor, trousers, loincloth, thong, short skirt, skirt, long skirt, braies, leggings, glove, mitten, sock, sandal, shoe, chausses, low boot, high boot, cap, hood, mask, turban, head veil, face veil, headscarf, helm), any shield, bag, backpack, quiver, instrument
|-
| [[Leatherworker]]
|-
| [[Tanner]]
|-
| [[Gem cutter]]
| rowspan=3| Perfect gem‡, door, bed, chair, table, statue, box, armor stand, weapon rack, cabinet, coffin, floodgate, hatch cover, grate, figurine, amulet, scepter, crown, ring, earring, bracelet, chain, flask, goblet, cage, barrel, bucket, animal trap, window, instrument, toy
|-
| [[Gem setter]]
|-
| [[Glassmaker]]
|-
| Macabre Mood (vermin remains)
| Amulet, bracelet, earring
|-
| [[Mason]]
| rowspan=2| Door, bed, chair, table, statue, quern, millstone, coffer, armor stand, weapon rack, cabinet, coffin, floodgate, hatch cover, grate
|-
| [[Miner]]
|-
| [[Mechanic]]
| Mechanism
|-
| [[Metal crafter]]
| Figurine, amulet, scepter, crown, ring, earring, bracelet, chain, flask, goblet, instrument, toy
|-
| [[Metalsmith]]
| Door, bed, chair, table, statue, coffer, armor stand, weapon rack, cabinet, anvil, coffin, floodgate, hatch cover, grate, cage, barrel, bucket, animal trap, pipe section†, splint, crutch
|-
| [[Stone crafter]]
| Figurine, amulet, scepter, crown, ring, earring, bracelet, goblet, instrument, toy
|-
| [[Weaponsmith]]
| Any weapon, any trap component†
|-
| [[Wood crafter]]
| Figurine, amulet, scepter, crown, ring, earring, bracelet, goblet, instrument, toy
|}
:† ''chance of selection for this entry is reduced by 90%''
:‡ ''this item may only be selected at the beginning of the mood (50% chance)''

If your dwarf does not have a preference for any possible items, the game will randomly select one from the list. Entries with "any" are treated as collective entries with a single chance and will randomly choose a subtype which your civilization is capable of making. This explains why bowyers and clothiers will regularly produce foreign artifacts, while weaponsmiths will not unless they have exotic preferences.

== Success ==
Once created, most [[artifact]]s will be available for use just like a normal item of its type. Artifact [[armor]] and [[weapon]]s gain extra bonuses in combat, while artifact clothing is immune to [[wear]]. Artifact mechanisms installed in weapon traps will improve attack rolls. Artifact furniture is useful for raising the value of a [[noble]]'s room. Artifact mechanisms, trap components, or weapons in [[weapon trap|weapon trap]]s can also boost a room's value considerably. Other artifacts that can be used in construction (such as [[barrel]]s, [[bucket]]s, and [[anvil]]s) may be used similarly. Artifact [[door]]s and [[hatch]]es are immune to [[building destroyer]]s, and artifact [[cage]]s can even hold gnawing vermin. All artifacts can be displayed in a [[display case]] or on a [[pedestal]], or [[trade]]d to a [[caravan]] for supplies.

Successfully creating an artifact grants a very strong happy [[thought]] (enough to make the creator totally ecstatic for several months) as well as granting the creator partial ''immunity to insanity'' – even if your fortress is left in a terrible state, any dwarf who has created an artifact is exempt from going [[insane]] due to prolonged unhappiness. The dwarf may also cry, found as a coating of dwarf tears on both their eyes.

== Failure ==
If you can't provide the desired workshop and all the required component materials within a couple of months, the dwarf will go [[insanity|insane]], which cancels the mood and the artifact. As if that's not bad enough, any dwarf who goes insane will soon die, one way or another.

A dwarf who is '''stark raving mad''', '''melancholy''', or '''catatonic''' is harmless to others (until they die and start a [[tantrum]] spiral), but a '''berserk''' dwarf will attack other dwarves and possibly pull levers at random. You may want to station a squad nearby or assign a few war dogs to the dwarf on the chance that they will lash out. If you build your workshops inside enclosed rooms with doors you can also lock the moody dwarf in the room until he or she starves. In extreme cases, building a wall around an open workshop is the best precaution.

==Bugs==
There are many bugs reported related to moody dwarves. As has been the case in 40d, most turned out to be (understandable) failures of the player to grasp the mechanics of artifact creation and demands. ([http://bay12games.com/dwarves/mantisbt/view_all_bug_page.php Bug tracker])
* If a dwarf dies due to failing to complete an artifact, a memorial made to the dwarf will read that the dwarf did create it, despite the failure, and will even list the name of the artifact that never came to be. {{bug|3640}}
* When producing an item that is normally made in pairs (gloves, boots, etc.), only a single artifact will be created.
* Attacking a dwarf who fails their mood with your militia may result in a loyalty cascade. {{bug|7107}}
* Dwarves entering a strange mood when isolated (e.g. on a stepladder) cause severe lag. {{bug|8698}}
* If the mood primary component is forbidden while working, but the strange mood still has other items tasked, the result is an iron artifact. {{bug|5625}}
* If the dwarf starts constructing the artifact and is scared off by a hostile creature before completion, they may become stuck. {{bug|9833}} Removing the floors around them, then dropping an item on them should cause them to dodge, fall, and return to the workshop.{{cite forum|161598}}

== Troubleshooting ==

'''Problem''': Moody dwarf does not claim a workshop
:'''Solution''': Check for highest moodable skill and build the corresponding workshop. If no moodable skills, build a craftsdwarf's workshop. Once [[magma forge]]s have been built, some dwarves may demand to work at a magma-powered forge or furnace while others might still insist on a coal-powered one. If a forge is needed, make sure you built a forge, not smelter. Note that [[forbid]]den workshops cannot be claimed. Verify if the dwarf is assigned to a burrow and/or if there is a civilian alert set to a burrow. If so, verify that the burrow allows access to the workshop being sought after.

'''Problem''': Moody dwarf waits in claimed workshop
:'''Solution''': Desired material is unavailable. Determine which material is requested next (materials are collected in the same order as shown in the dwarf's request list) and make some available, if possible. Note that dwarves with [[preference]]s may demand a specific type of material ([[brass]] bars or [[yarn]] cloth, for example). [[Forbid]]den and inaccessible materials cannot be collected, nor can material located outside the moody dwarf's [[burrow]].

'''Problem''': No dwarf has entered a mood for a long time
:'''Solution''': Strange moods require at least 20 dwarves; if you have that many you've, probably hit one of the two caps. Exploring the caverns can increase the number of revealed tiles very quickly, while [[craft]]ing [[goblet]]s will quickly raise your item count; [[exploratory mining]] will count toward ''both'' caps, simultaneously revealing tiles and producing boulders, though more slowly than exploring or crafting. Exposing excavated terrain to the sky is counterproductive, as it will ''lower'' your artifact cap (since the cap only counts revealed ''subterranean'' tiles).

'''Problem''': Moody dwarf wants stacked cloth, but all types are available and he's not moving
:'''Solution''': Dwarves will not take items from active hospitals. If you have no cloth available outside of hospitals, try disabling or temporarily removing the hospital designation from their zones. They will then proceed to take new items, even if they don't go for the cloth right away. It is also possible that the desired cloth has been partially consumed in order to make wound dressings.

==Trivia==
{{D for Dwarf}}
It is widely said that Tarn Adams has been in the grips of a fey mood for two decades now, and we are playing his artifact. However, neither [[human]]s nor [[giant toad]]s can enter strange moods, so this must surely be a joke.

{{Category|Dwarves}}
[[Ru:Strange mood]]

Talk:Strange mood

2023-01-15T05:17:08Z

Kelvie: Created page with "== Bone requirement == At least in my testing, when the dwarf asks for bones, it won't just take random bone (stacks) from rotted parts from battle or random wild animals(for..."

== Bone requirement ==

At least in my testing, when the dwarf asks for bones, it won't just take random bone (stacks) from rotted parts from battle or random wild animals(for example).

I had to build a butcher's workshop and butcher an animal for the bone stack to count, so I think it's worth clarifying in case other people run into it, or I'm just completely misunderstanding how bone stacks work (in which case, again, I think it's worth explaining on this wiki page how to deal with this.

Strange mood

2023-01-14T23:14:09Z

Kelvie: /* Demands */ Verified how to satisfy the bones requirement on 50.05

{{migrated article}}
{{Quality|Unrated}}
{{av}}
{{buggy|bugsection=Bugs}}
{{minorspoiler}}
[[File:strange_mood_prev.png|thumb|350px|right|A dwarf losing ownership of his mind. ''Artwork by Zippy'']]
Periodically, individual [[Dwarf|dwarves]] are struck with an idea for a [[legendary artifact]] and enter a '''strange mood'''. Dwarves which enter a strange mood will stop whatever they are doing and pursue the construction of this artifact to the exclusion of all else. They will not stop to eat, drink, or sleep. Pretty much the only thing that can pause a dwarf is giving birth, after which they will immediately get back to making the artifact. If they do not manage to begin construction of the artifact within a handful of months, they will go [[#Failure|insane]] and die soon afterward.

Note: All controllable civilizations with the {{token|STRANGE_MOODS}} token are able to enter strange moods, though, by default, the only civilization this applies to is dwarves.

==Overview==
[[File:mood_announce_v50_x2.png|right]]Once your fortress has at least 20 dwarves, occasionally, one of them will be struck by a "strange mood". These largely random events will be seen as an [[announcement]], and will pause the game.

A dwarf struck by a strange mood will seek an appropriate workshop, immediately claim it for the duration of the mood, attempt to collect the materials to create their [[artifact]] of choice, and, once those have been collected, proceed to do so. Depending on the exact mood (see [[Strange mood#Types of moods|types of moods]], below), both the workshop and the artifact are based on the highest "moodable skill" of that dwarf (see "[[Strange mood#Skills and Workshops|Skills and Workshops]]", below).

At the end of this process, if successful, the dwarf will '''usually''' gain enough [[experience]] to become Legendary (or higher), and then return to life as normal, but now with a Legendary skill. The "possessed" mood is an exception to this rule, as it does not grant any experience upon completion.

A dwarf cannot be struck by more than one mood in their lifetime.

=== In Fortress mode ===
# The game will announce that the dwarf has entered one of five different types of strange moods. The [[#Types of moods|types of moods]] are listed below. While in a mood, a dwarf will display a blinking exclamation point (see [[Status icon|status icons]]).
# For the duration of the mood, the dwarf will claim a workshop related to the skill that the mood affects (not all skills are eligible), kick out any dwarf who was using it, and render it otherwise unusable until the mood has ended. If a moody dwarf does not claim a workshop, it is because the appropriate workshop does not exist. (See [[#Skills and workshops|skills and workshops]] below to determine which workshop(s) might be required.) A moody dwarf will ''not'' be able to build a needed workshop; another dwarf with the appropriate [[labor]] designation must do so for them, if one is necessary. Furnaces are also counted as a workshop.
# After claiming a workshop, the dwarf will set about collecting the required materials for their artifact. If the dwarf remains idle inside the workshop, it's because they cannot find the right material. Reference the [[#Demands|demands]] section to determine what may be required. Important Note: They will only collect these materials in the order that they require them. In other words, you have to determine where they are on the list of required materials and then provide the next one before they will continue collecting other materials.
# Once all materials have been gathered, the game will once again pause and center, and the moody dwarf will begin construction. Upon completion, the dwarf will create a semi-random artifact related to the skill affected and gain [[legendary]] (or higher) status in that skill (unless the mood type is [[#Possessed|possessed]]). See the [[#Skills and workshops|skills and workshops]] for information on which skills can be gained, or the [[#Artifacts created|artifacts created]] section for more details on the artifacts themselves.
# While you have some control over the skill the dwarf uses, and so some (but less) control over the type of artifact created, and (with some effort) the materials used, you have no control over which dwarf is struck by a mood, nor the type of mood that strikes them, nor the specific type of artifact created.
# The conditions necessary for a strange mood to occur have been fully understood due to a disassembly of the game; see below for the exact mechanics.

===In world generation===
Long before your seven dwarves [[embark]] on their adventure, non-player dwarves may also be struck by strange moods during world generation, albeit these are treated more abstractly. These events are a primary source of non-player artifacts that are scattered across the outside world when the game starts (see [[Mission]]). They have the same properties and quality as any artifact your fortress could have produced, and may be stolen or pillaged just like any other non-player artifact.

== Skills and workshops ==
If struck by a Fey, Secretive or Possessed mood, the workshop and artifact will be based on the highest "moodable skill" that a dwarf possesses. Not all skills are moodable. Fell and Macabre moods will either claim a butcher's shop and use Bonecarving, or a tanner's shop and use Tanning (see [[Strange mood#Types of moods|Types of moods]], below).

{| class="wikitable sortable" cellpadding="4" style="border:1px solid black;border-collapse:collapse;text-align:left;float:right;margin:0 0 20px 30px;vertical-align:top;"
|-
! Highest skill
! Workshop required
|- style="background-color:palegreen"
| [[Armorsmith]]
| [[Metalsmith's forge]] (or [[Magma forge]])
|- style="background-color:palegreen"
| [[Bone carver]]
| [[Craftsdwarf's workshop]]
|- style="background-color:palegreen"
| [[Bowyer]]
| [[Bowyer's workshop]]
|- style="background-color:wheat"
| [[Carpenter]]
| [[Carpenter's workshop]]
|- style="background-color:palegreen"
| [[Clothier]]
| [[Clothier's shop]]
|- style="background-color:lightgray"
| [[Engraver]]
| [[Craftsdwarf's workshop]]
|- style="background-color:wheat"
| [[Gem cutter]]
| [[Jeweler's workshop]]
|- style="background-color:wheat"
| [[Gem setter]]
| [[Jeweler's workshop]]
|- style="background-color:wheat"
| [[Glassmaker]]
| [[Glass furnace]] (or [[Magma glass furnace]])
|- style="background-color:palegreen"
| [[Leatherworker]]
| [[Leather works]]
|- style="background-color:wheat"
| [[Mason]]
| [[Mason's workshop]]
|- style="background-color:palegreen"
| [[Mechanic]]
| [[Mechanic's workshop]]
|- style="background-color:wheat"
| [[Metal crafter]]
| [[Metalsmith's forge]] (or [[Magma forge]])
|- style="background-color:wheat"
| [[Blacksmith|Metalsmith]]
| [[Metalsmith's forge]] (or [[Magma forge]])
|- style="background-color:wheat"
| [[Miner]]
| [[Stoneworker's workshop]]
|- style="background-color:lightgray"
| [[Stone crafter]]
| [[Craftsdwarf's workshop]]
|- style="background-color:wheat"
| [[Tanner]]
| [[Leather works]]
|- style="background-color:palegreen"
| [[Weaponsmith]]
| [[Metalsmith's forge]] (or [[Magma forge]])
|- style="background-color:wheat"
| [[Weaver]]
| [[Clothier's shop]]
|- style="background-color:lightgray"
| [[Wood crafter]]
| [[Craftsdwarf's workshop]]
|- style="background-color:lightgray"
| <none>
| [[Craftsdwarf's workshop]]
|}

A dwarf will claim a workshop according to their highest applicable skill, and upon completion of the artifact, gain 20,000 [[experience]] in that skill (excepting [[Strange mood#Possessed|possessed]] dwarves). This will give the dwarf a legendary-level [[skill]] (specifically, "legendary+1" or higher, depending on the dwarf's initial skill level). The table to the right describes all applicable skills and their potential workshop requirements – there are only 20 skills that determine the workshop and that can be affected by a mood (sometimes referred to as '''moodable''' skills.) If a dwarf does not possess at least one of the moodable skills listed to the right, they will take over a [[craftsdwarf's workshop]] and gain one of [[bone carver]], [[stone crafter]], or [[wood crafter]] skills, producing an artifact [[craft]].

When selecting the desired mood skill, only the level itself is checked, and if the highest level found is shared by multiple skills, then one will be selected randomly.

This fact can be utilized to maximize the possibility of getting a dwarf with the specific legendary skill you want: since ''non''-moodable skills are ignored, whenever possible make sure that each dwarf's highest ''moodable'' skill is one of those you want. Have all your peasants, [[farmer]]s, non-professional military and other dwarves without any moodable skills do one job each in the skill(s) you most want; if a "[[experience|dabbling]]" skill is the highest moodable skill they have, that is the skill that will be used. [[Guildhall]]s related to moodable skills may both help and hinder, as demonstrations will increase skill levels without any jobs being done.

[[Scholar]]s may discuss mechanics as part of their work and gain a small amount of experience in it. This is the only skill that scholars discuss that is moodable.

=== "Best" skills ===
Some skills produce generally useful and valuable items, and others produce only trinkets or jewelry. While "best" is very subjective, balancing the artifact itself with the Legendary skill the mood (usually!) produces, and both of those against the needs and goals of the current fortress, generally speaking the skills can be broken down into tiers of usefulness.

Note that in addition to an artifact, the mood will (usually) raise the dwarf to Legendary in the chosen skill; often this is, from a practical standpoint, more valuable than an artifact, so you might consider trying to push poorly-trained dwarves towards moodable skills you have a need for, instead, in case they are struck by a mood.

* [[Weaponsmith]] is one of the "best" skills. While the moody dwarf might create a questionable lead spear or lightweight aluminum mace, the odds are they'll create something that is still more deadly than its ☼steel☼ equivalent. And with a little manipulation, you can at least make sure the item ''is'' steel, although they could still give you a non-dwarf weapon. [[Mechanic]] is a close second for reliability and usefulness –- any mechanism's [[quality]] modifies the chance for a trap to hit its target, an artifact [[Trap#Weapon trap|weapon trap]] never jams{{verify}}, and an artifact lever in a room will make its value skyrocket (even if not connected to anything!).
* [[Armorsmith]] is similarly valuable, having a decent chance to create something with exceptional value for your military (or at least one member of it), but, similar to weapons, this requires manipulating available material to avoid getting [[Armor#Material|soft]], useless gold or lead [[armor]] pieces. And, while moody [[Bowyer]]s can create artifact wood/bone [[crossbow]]s of great accuracy, they can also give you [[blowgun]]s. Good luck with either one.
* Artifact [[furniture]] is unbreakable by building destroyers and creates otherwise-impossible fortress defense options. A dwarf with a preference for doors, hatches, or floodgates will always produce that item, which can then be locked against many enemies that would otherwise break through. It can also have huge monetary worth for improving room value, and placing an artifact item where all can pass by and admire it will be good for general morale. These skills include [[Mason]]s, [[Miner]]s (who are treated the same as masons), [[Carpenter]]s, and [[Blacksmith|Metalsmith]]s. Many of these can also produce items from the lower-utility lists, below. But maybe you'll get an artifact [[mug]] for your tavern. Good luck with that, too.
* These next are (very?) odds-against; chances are good that they'll produce something on one of the ''next'' lists, or at best some nice furniture, but there's a (very) small chance it'll be something truly useful as well as valuable. [[Clothier]]s can make an artifact [[rope]], and [[metal crafter]]s can create [[chain]]s, either of which can be used for your main [[well]]. Similarly with a [[carpenter]] or [[blacksmith]] and [[bucket]]s. [[Glassmaker]]s can create an artifact trap component. [[Leatherworker]]s and [[tanner]]s can create [[shield]]s, and both they and [[bone carver]]s can create artifact Leather/Bone Armor pieces, which are great if you have Hunters, etc. Which are all better than the next two...
* Next to last are skills that produce an artifact that could only be worn by one dwarf, and perhaps admired by others they come in contact with. [[Clothier]]s and [[weaver]]s fall just below some of the above: for no ability to produce anything except wearable, non-military items. [[Gem cutter]]s and [[Gem setter]]s can fall on this list too, as creating something of pure monetary value and no practical use in your dwarven society.
* Last on the list are "crafts" – surprisingly valuable trinkets in the form of amulets, totems, rings, figurines – or, at best, crowns, which at least ''sound'' impressive. These skills are [[engraver]], [[stone crafter]], and [[wood crafter]] (and a distinct chance from several of the skills mentioned earlier: [[bone carver]], [[gem cutter]], [[gem setter]], [[glassmaker]], and [[metalcrafter]].)
:* Peasants, defined here as having no moodable skill, always produce from the crafts list: It's always a good idea to have every newly arrived "peasant" migrant craft just one item from the moodable skill of your choice, to avoid such a tragic waste of dwarfcraft.

== Types of moods ==
For each of the following types of moods, the first message is how the mood is [[Announcement|announced]]; the second message appears in the dwarf's profile when he or she is viewed with the {{K|v}} key. All moody dwarves will have "Strange Mood" listed as their active task and are "quite content", regardless of any recent [[thought]]s they may have had.

=== Fey ===
* {{Gametext|<dwarf> is taken by a fey mood!|7:1}}
: ''Has the aspect of one fey!''

This is the most basic strange mood. Fey dwarves will clearly state their demands when the workshop they are in is examined.

=== Secretive ===
* {{Gametext|<dwarf> withdraws from society...|7:0}}
: ''Peculiarly secretive...''

Secretive moods are the same as fey moods, except a secretive dwarf will sketch pictures of their required materials instead of clearly stating their demands if they cannot find what they need. Descriptions of all these [[#Demands|secretive requirements]] can be seen only by viewing the workshop that the moody dwarf has claimed, with {{k|q}}, and then only while the dwarf is waiting inside it. More than one "picture" is likely; these will cycle through the entire list automatically if any one is not available. (Since materials are gathered ''in order'', it's quite possible that only one of a long list is needed to allow the moody dwarf to continue on their project. If the dwarf has gathered some of the materials (seen as "tasked" when looking at the workshop with {{k|t}}), then the next in the list is what they are looking for.)

=== Possessed ===
* {{Gametext|<dwarf> has been possessed!|5:1}}
: ''Possessed by unknown forces!''

Possessed dwarves have cryptic material requests, and have the unfortunate distinction of not receiving any experience upon successful construction of an artifact. No controllable circumstances lead to a possessed mood instead of one of the more desirable fey or secretive moods, it is purely luck-based. Possessed dwarves will mutter the name of the artifact they are working on (which, under some circumstances, might end up being ''their own name'') once they have all the materials they need.

A possession is the only mood that does '''''not''''' result in a jump in [[experience]].

A possessed dwarf that "keeps muttering <name of the artifact>..." has already gathered everything they need.

=== Fell ===
* {{Gametext|<dwarf> looses a roaring laughter, fell and terrible!|5:0}}
: ''Has a horrible fell look!''

A dwarf that goes into a fell mood will try to take over a [[butcher's shop]] or a [[tanner's shop]]. If neither are available, any other workshop will be used instead. The dwarf will then ''murder'' the nearest dwarf, drag the corpse into the shop and make some sort of object out of dwarf [[leather]] or [[bone]]. The unfortunate dwarf is killed on the spot – no dragging to the workshop, just sneaking up behind them, killing them, and dragging their corpse to the workshop. Once the artifact is completed, the fell dwarf will become a legendary [[bone carver]] or [[leatherworker]]. Only unhappy dwarves may enter a fell mood.

Amusingly, it seems fell dwarves can also murder [[ghost]]s. If they do, they will murder a living dwarf as well, since ghosts obviously don't yield a corpse to butcher.{{bug|4681}}

Aside from the loss of a potentially important dwarf in the wrong place at the wrong time, there doesn't seem to be any downside to a fell mood. The end result is always an artifact and a legendary craftsdwarf. Since the only ingredient used (a dwarf) is available in abundance, a fell mood will only fail if the fell dwarf is completely isolated from other dwarves, or if the proper workshop does not exist.

If no one is around to witness the murder, whichever dwarf Urist McEmo decides to slaughter will be reported as missing some time after their death. If the murder is witnessed (or if the <s>idiot</s> dwarf in fell mood reports themself), the moody dwarf will be subject to dwarven [[justice]].

=== Macabre ===
* {{Gametext|<dwarf> begins to stalk and brood...|0:1}}
: ''Brooding darkly...''

Macabre moods are similar to fell moods, but the dwarf will not murder a fellow dwarf. A macabre dwarf may require [[bone]]s, [[skull]]s, or vermin [[remains]]; if you do not happen to have any, you will have to make some, e.g. by butchering an animal and/or allowing a [[cat]] to go hunting, or let the moody dwarf go [[insane]]. Like fell moods, only unhappy dwarves can enter macabre moods.

==Caveats==
* Shells are perhaps the most difficult-to-obtain material for a strange mood, though there are several {{catlink|Shell|creatures}} that produce shells. Some of these, such as [[armadillo]]s and [[common snapping turtle]]s, are butcherable. Vermin from [[fishing]] are the easiest and most renewable source of shells. [[Pond turtle]]s are common in many embarks in [[murky pool]]s, but usually only appear in small numbers, and can go extinct easily. A stream or river almost guarantees a functionally inexhaustible supply of [[mussel]]s. [[Nautilus]]es can also serve as sources of shells when cleaned at a fishery. Nevertheless, shells are rare and hard to acquire. Currently, the only way of trading for shells is to hope that the [[elven]] caravan brings some tamed shell-producing large creature. Traded [[cave lobster]]s and [[turtle]]s are ''processed'' fish (with the shells already removed). Tamed vermin with shells cannot be butchered for their shells, since the only way to get a vermin's shell is to [[Fish cleaning|clean]] it. Since all shelled non-vermin animals are [[exotic pet|exotic]], only elves will bring them. If you should be fortunate enough to acquire some breeding, shelled, butcherable animals, it's probably worth keeping a breeding pair around in case of future need. Only dwarves with a [[preference]] for shells will demand shells in a strange mood.
* All demands for cloth are for a specific generic type (plant, silk, or yarn). Clothiers and Weavers will demand [[adamantine]] cloth if any is available, otherwise the type will be the generic form of the dwarf's first cloth preference, or a randomly chosen variety if the dwarf has no preference (or if the cloth is for a decoration, not the primary material). Types of cloth your fortress has not produced are '''not''' excluded, so it's best to keep a few bolts of each type of cloth in reserve.
* Should the claimed workshop be a [[magma forge]] and lose power due to insufficient magma beneath it, the mood will fail immediately and the dwarf will go [[insanity|insane]]. Should the forge be in danger of losing power, you should forbid it before it is claimed and wait until it is powered up reliably. Once magma forges are built, at least some dwarves will no longer be satisfied with a regular forge.
* Similarly, if a workshop claimed by a dwarf is deconstructed, destroyed or [[Creature_token#BUILDING_DESTROYER|toppled]] the mood will immediately fail and the dwarf will go insane.
* The mood's primary material will only be mentioned ''once'' in the dwarf's requests, even if the dwarf wants more than one unit of it. [http://www.bay12forums.com/smf/index.php?topic=75139.0]
* The item type of the artifact to be created is not decided until the instant the mood ''ends''. Saving (even after a dwarf has begun to gather materials) will allow you to reload and the result may be a different artifact (unless the moody dwarf's preferences force a particular item type). If you want to get an artifact platinum warhammer, make sure to have platinum nearby and/or block access to any other materials.
* You can restart the artifact creating process, even after the dwarf has gathered most of the components, by forbidding the claimed items (use {{k|t}} to view the contents of the workshop, select the undesired material, and press {{k|f}} to forbid it). If other items of that type are available, the dwarf will immediately switch to them.
* Requests for bones are actually requests for any kind of bone stacks, not individual bones. Slaughter a puppy. [http://www.bay12forums.com/smf/index.php?topic=105002.0]

== Demands ==
Once a workshop is claimed, the dwarf will begin collecting materials. Each artifact will require 1-3 "base items" and up to 7 additional items for decorations. The dwarf may well need several items of one material!

If the moody dwarf remains idle, then the necessary materials are not available. [[Forbid|Forbidden]] items must be reclaimed ({{K|d}} – {{K|b}} – {{K|c}}) before they may be used, but moody dwarves will ignore settings regarding [[economic stone]]. Press {{K|q}} and highlight the workshop to receive a series of clues about what the dwarf needs. '''Hints that stay active for longer than 2 seconds mean that multiple pieces of that material will be required; each single demand will be displayed for 2 seconds, so if it says "gems... shining" for 6 seconds, 3 gems are demanded. However, the mood's primary material will always be shown for only 2 seconds, even if more than one is required.''' Materials will always be fetched ''in order'', so if at least one item has already been retrieved (the items will show up with "TSK" ("task") next to them when the workshop is viewed with the {{K|t}} context menu), it will usually be possible to tell what item is required next.

If you want your dwarves to construct their artifacts out of valuable materials instead of whatever useless thing happens to be close at hand, you can selectively forbid types of material through the stocks screen so that only the material you want them to use is available; though this might interfere with the normal crafting operations of your fortress, the disruption is generally short-lived (as long as you remember to unforbid them again afterwards!). You can even forbid something a moody dwarf is carrying (which may be necessary sometimes, since while they are not waiting in the workshop, they will not tell you what they need); the dwarf will finish hauling it to the workshop, but then immediately go searching for another. This trick can mean the difference between a bauxite statue decorated with moss agates and a native platinum statue encrusted with diamonds. Be aware that this may not always work – see below for more information.

Burrows allow even better control over a moody dwarf's material usage. Simply by creating a burrow around the claimed workshop and another part over the desired material, a moody dwarf can be controlled without forbidding every single stone in the fortress. A moody dwarf will follow the burrow definitions just like a regular worker, but be mindful that they will not leave the burrow to get materials that are outside of their assigned burrow. A problem can arise when bones from an outside refuse stockpile are needed by a moody dwarf that is assigned to a burrow.

Possessed Dwarf have been observed to demand items of a specific material. In this case the Dwarf will idle in the Workshop shouting for item categories that are in fact available. reclaiming items that were forbidden in order to make the moody dwarf use items of more valuable materials fixed that problem in the past.

The various demands are translated here:

:{| class="wikitable" style="text-align:left;width:90%;"
|-
! Material
! Fey
! Secretive
! Possessed
|-
|
| <dwarf> screams "I must have <demand>!"
| <dwarf> sketches pictures of <demand>.
| <dwarf> mutters "<artifact> needs <demand>..."
|-
| [[Stone]]
| rock
| a quarry
| stone... rock
|-
| Stone/metal [[block]]s
| rock blocks
| square blocks
| blocks... bricks
|-
| [[Wood]]
| wood logs
| a forest
| tree... life
|-
| Metal [[bar]]
| metal bars
| shining bars of metal
| bars... metal
|-
| [[Gem]]s (cut)
| cut gems
| cut gems
| gems... shining
|-
| [[Gem]]s (raw)
| rough gems
| rough gems
| rough... color
|-
| Green [[glass]]
| raw green glass
| glass
| raw... green
|-
| Clear glass
| raw clear glass{{verify}}
| glass and burning wood
| raw... clear
|-
| Crystal glass
| raw crystal glass{{verify}}
| rough gems and glass
| raw... crystal
|-
| [[Bone]] [http://www.bay12forums.com/smf/index.php?topic=105002.0;topicseen stack]
| bones (butcher an animal for a stack)
| skeletons
| bones... yes
|-
| [[Shell]] {{cite talk/this|Re:_.22Verify.22_on_the_shell_row_of_the_demands_table}}
| shells
| shells
| a shell...
|-
| [[Leather]]
| tanned hides
| stacked leather
| leather... skin
|-
| [[Cloth]] (plant fiber)
| plant cloth
| stacked cloth
| cloth... thread
|-
| [[Cloth]] (silk)
| silk cloth
| stacked cloth
| cloth... thread
|-
| [[Cloth]] (yarn)
| yarn cloth
| stacked cloth
| cloth... thread
|-
| [[Skull]]{{verify}}
| body parts
| death
| a corpse
|}

Dwarves in macabre moods will list their demands in the same fashion as those in fey moods (though with them brooding "Yes. I need <item>." instead of screaming "I must have <item>!"). They may also say "Leave me. I need... things... certain things", in which case they want special items, such as [[skull]]s or vermin [[remains]].

Related to the above behavior, moody dwarves demanding rock blocks will also accept blocks forged from metal bars.

*The first item demanded by the dwarf is based on the moodable skill being used – stoneworkers (miners, engravers, masons, stone crafters, and mechanics) will demand boulders, woodworkers (carpenters, wood crafters, and bowyers) will demand logs, leatherworkers and tanners will demand leather, weavers and clothiers will demand cloth, metalworkers will demand metal bars, gem cutters/setters will demand rough gems, glassmakers will demand raw glass, and bone carvers will demand bones.
**Metalworkers will demand adamantine wafers if any are available (unforbidden). If not, they will demand a preferred metal ''if'' you have smelted any bars of it – fey moods will state this outright, while for secretive moods and possessions, you will need to check the dwarf's [[preferences]] to see which metal they like. Metal bars acquired via [[trade]] or by melting down items (such as Goblinite) do ''not'' count as smelted. Otherwise, they will select any available metal(s).
**Weavers and clothiers will demand [[adamantine]] cloth if any is available (unforbidden). If not, they will demand a generic type of cloth (silk, plant fiber, or yarn) that matches a specific cloth preference (e.g. a dwarf that likes cave spider silk will require ''any'' type of silk cloth, and a dwarf who likes more than one type of cloth will demand whichever one appears first in their list). Dwarves without a cloth preference will demand a generic type at random.
**Glassmakers will demand their preferred type of glass ''if'' you've produced any of it (or if it's green glass); if they don't prefer any type of glass, they will randomly select one type of glass you've produced (though they will always assume you have created green glass). Note that acquiring raw glass from a caravan does ''not'' count as producing it.
**Dwarves in macabre moods will select either 1 vermin remains, 1 stack of bones, or 1-3 skulls.
**Bone carvers will demand shells if they like a type of shell; if not, they will demand bones.
**All preference-based material requests are decided the instant the mood begins – by the time the workshop is claimed, it is too late to change the dwarf's mind.
*The remaining "decoration" items are selected randomly from the following list: wood logs, metal bars, small gems, rock blocks, rough gems, boulders, bones, leather, plant/silk/yarn cloth, or raw glass (green/clear/crystal, based on what you've produced).
**Decoration items will never be the same type as the primary mood material.
**Certain mood professions will also explicitly avoid using certain items for decorations – most of these match up with the primary mood material, but miners, engravers, masons, and stonecrafters will additionally avoid requesting rock blocks.
**If you have not produced any raw glass in your fortress, moody dwarves will never request it.
**Dwarves in macabre moods have a 50% chance to replace each decoration item with either remains or bones.
*Gem cutters and gem setters have a 50% chance of only gathering a single rough gem and nothing else – when they do this, they produce a "perfect gem" with a single decoration.

Once all materials have been gathered, viewing the workshop with {{K|q}} will display a special message depending on the type of mood:
* Fey – "<dwarf> works furiously!"
* Secretive – "<dwarf> works secretly..."
* Possessed – "<dwarf> keeps muttering <artifact>..."
* Macabre – "<dwarf> works, darkly brooding..."
* Fell – "<dwarf> works with menacing fury!"

== The mechanics of moods ==

=== Frequency===
When a fortress is started, an internal counter is set to 1000. Every 100 frames (12 times per day), this counter is decremented by 1, running down to zero in about 3 months. When the counter would ordinarily be decremented when it has already reached zero, there is a 1 in 500 chance that a strange mood will strike. This means that, once all conditions are met and the clock is ticking, while there is approximately a 2.4% chance of a strange mood per day, or a ~52% chance of at least one strange mood per month, there is no guarantee when a mood will strike – might be sooner, might be (almost) never.

=== Conditions ===
In order for a dwarf to be struck with a strange mood, three conditions must be met:
:* There is no currently active strange mood,
:* The maximum number of artifacts is not met,
:* There are at least 20 eligible dwarves ''(see below)'', including dwarves who have already created artifacts.

If all three of these conditions are true, the game may trigger a strange mood according to the frequency.

==== Maximum number of artifacts ====
The maximum number of artifacts in any one fortress is limited by the lower of:
* The number of items created divided by 100.1 Mined-out rock ''does'' count as an "item created", though it is not clear whether bolts or units of drink are counted individually.
* The number of revealed [[subterranean]] tiles divided by 2304 (this is an area equivalent to a 48x48 square). Once you discover and explore the [[cavern]]s and [[magma sea]], this limit becomes largely irrelevant, and using a [[utilities#DFHack|"reveal" utility]] will eliminate it altogether, though strip-mining an area entirely and exposing it to the surface will count ''against'' this.
:1 – actually the sum of all items by type ''and'' by type+subtype+material, divided by 200. Furthermore, destroying items does '''not''' decrement these counters, so casting and mining [[obsidian]] will count toward this.

==== Eligibility ====
The deciding factor for eligibility is a dwarf's actual [[profession]]. ''(Note that "[[Skill#Professions|custom professions]]" have no effect on this!)'' Thus, dwarves may enter strange moods regardless of what skills they have or don't have, so long as they are of an acceptable profession. Dwarves who have already created an artifact are not eligible to create another, and since every mood ends in either an artifact or death, every dwarf may enter at most one mood. Dwarves who have obtained one or more legendary skills without creating artifacts ''may'' enter strange moods and will simply become even ''more'' legendary.

On-duty dwarves with a [[Soldier#Soldier professions|military profession]] other than "Recruit" ''cannot'' enter moods. Incidental military skills make no difference – eligibility (and weighting) depends purely on the actual ''[[profession]]'' as listed at the time (with the exception of unit leaders, whose on-duty and off-duty titles are the same). Soldiers are still capable of entering moods if they are ''off duty'' and thus in Civilian mode, but you don't have to worry about your axedwarves getting a burst of inspiration mid-combat and then wandering off to make a highest-quality craftsdwarfship gabbro scepter decorated with cow bone menacing spikes, cow bone rings and a cow bone image of hamster men while the trolls sack your settlement.

Children may enter moods, but babies will not.

Any other profession is eligible to enter a mood, but not all have the same ''chance'' to enter a mood.

:''('''Note''' – Specifically, and to avoid previous misunderstandings, [[Strand extractor]], [[Clerk]]/[[Administrator]]/[[Trader]], [[Doctor]] (and related), [[Soldier#Recruits|Recruit]] and [[Child]] ''are'' moodable professions.)''

There are several additional factors which will prevent a dwarf from entering a mood:
* Being unable to pick up items ("cannot grasp")
* Being dragged by/dragging another unit (off to [[jail]]/leading livestock to a [[cage]], [[chain]], [[pasture]], [[Activity zone#Pit/Pond|pit/pond zone]], or to the [[butcher's shop]] or [[farmer's workshop]].)

=== Chance ===
When determining who will have a strange mood, each eligible dwarf is put into a weighted lottery, where the chance of being selected is based on the dwarf's [[profession]]. Most professions receive 6 "tickets", but some receive additional tickets to improve their odds.

{| class="wikitable" cellspacing="0" border="2" cellpadding="5"
|-
! Weighting
! Professions
|-
| 21 ||Armorer, Blacksmith, Bone Carver, Clothier, Craftsdwarf, Jeweler, Gem Cutter, Gem Setter, Glassmaker, Leatherworker, Metalcrafter, Metalsmith, Stonecrafter, Weaponsmith, Weaver, Woodcrafter
|-
| 11 ||Bowyer, Carpenter, Stoneworker, Mason, Woodworker
|-
| 6 ||Engraver, Mechanic, Miner, Tanner, and all other [[profession]]s (including Peasant).
|}

:'''''Example:''' What this means is: if you had 21 dwarves, made up of 20 eligible farmers, furnace operators, miners, woodcutters etc. (with 6 chances each) plus one Armorer (with 21 chances), that one Armorer would have a 21 in 141 chance (20 dwarves x 6 chances each = 120 + 21 chances more = 141 total) of the mood striking them. That's about 1 in 7, while the other 20 have a 6 in 141 chance each, or about 1 in 24. The odds are still against the armorer, but much better than for any other single dwarf.''

Note that not every profession has a moodable skill. A Soaper, Architect, Furnace Operator or Strand Extractor can be taken by a mood, but that will not make those skills legendary, nor will they create an artifact bar of soap, building, bar of metal or wafer of adamantine.

=== Timing ===
A dwarf will go [[Insanity|insane]] after exactly 50000 ticks (which, at 1200 ticks per day, works out to 41.66 days, or almost a month and a half) waiting for an item they demand. However:
*The insanity countdown is reset after every item they bring to the workshop.
*It doesn't run while they are out getting something, working on their construction or on their way to claim a workshop. Only during time spent idling without either the required workshop or a required item do they spiral towards madness.
*Dwarves under strange moods do not feel hunger, thirst or drowsiness.

=== Fuel ===

{{D for dwarf}}

Curiously, [[metalsmith]]s in strange moods do not seem to require any [[fuel]] to complete their [[metal]] [[artifact]]s. It is believed that they, consumed by artistic passion, fuel the forges with their own beards, vigorously fanning the flaming hairs while they feed the furnace more beard. Such a sacrifice is a dwarf's own beard that only an artifact merits its removal. Only an artifact's completion can mollify its creator's shame; dwarves unable to complete this great pursuit go insane, not because of its failure, but because they cannot endure the inevitable humiliation.

Legend has it that the world's first [[elf]] once attempted to forge the world's most powerful artifact, imbued with magic to control all dwarves. But, because he could not suffer to cut a tree for fuel, he was unable to do so. Faced with no alternative, he kidnapped each of the seven ancient dwarves by tempting them with [[booze]], an unfamiliar drink to the first dwarves. He then forcefully shaved them and created [[charcoal]] from their beards.

Enraged by their loss, the dwarves set out to find the elf's home, based in the world's first tree. They startled the engrossed elf who fled with nothing but a handful of the tree's unborn children. After reclaiming the beard-charcoal, the dwarves set fire to this tree. Alight in flames hotter than the sun, the tree burned in what is believed to have been the world's hottest fire – a fire so hot that the tree's roots melted the inside of the earth, creating a worldwide [[magma sea]]. The elf watched this fire and swore revenge on the dwarves.

After realizing their beards could not be recovered from their charred state, the dwarves agreed to sprinkle the charcoal over the earth, as a gift and reminder to future dwarves. In doing so, they created the world's [[bituminous coal]] deposits. They then spent the next years searching for a way to create the drink they had been given. Discovering new drinks along their pursuit, the dwarves eventually perfected the hidden art of brewing booze and passed this emerging knowledge to coming generations.

== Artifacts created ==
The type of artifact created depends on the type of mood, the dwarf's highest moodable skill, and the base material. Masons and miners will always create some kind of stone furniture; bone carvers, a bone or shell object (including furniture); carpenters, a piece of wooden furniture; engravers and stone crafters, a stone craft; metalworkers, metal crafts, weapons, or armor (depending on the type of metalworker); weavers and clothiers, an article of clothing; tanners and leatherworkers, a leather armor or object. If a dwarf has no moodable skills, they will randomly select stone crafting, wood crafting, or bone carving as their mood skill and produce their artifact accordingly. The precise type of craft created is usually somewhat random, but if a dwarf has a personality preference for a particular item type, such as gauntlets or floodgates or crowns, and that thing is an available choice given the dwarf's profession, they are guaranteed to create an object of that type (if multiple preferences match, one will be randomly selected).

The first object grabbed by the dwarf will be the base material; all other materials will be used as [[decoration]]s. If a dwarf grabs a piece of [[chalk]] and makes a statue, for instance, it will be a "chalk statue", but an artifact can potentially include bone, cloth, gems, leather, metal, shell, stone, and wood decorations all at once. In some cases, a moody dwarf will produce an item which normally cannot be made from that material, leading to such odd constructions as an [[obsidian]] [[bed]], [[ruby]] [[floodgate]], or turtle [[shell]] [[cage]], but the actual item types available for each mood type are still very much restricted (e.g. only a glassmaker or jeweler can make a [[window]], and a moody clothier cannot produce an article of clothing that could not normally be made from cloth).

{| class="wikitable" cellpadding="4" style="border:1px solid black;border-collapse:collapse;text-align:left;"
|-
! Mood / Skill
! Artifact type
|-
| [[Armorsmith]]
| Each equipment item with [METAL] (mail shirt, breastplate, leggings, greaves, gauntlet, low boot, high boot, cap, helm, mask), any shield
|-
| [[Bone carver]] (bone)
| Each equipment item with [BARRED] (leggings, greaves, gauntlet, helm), any shield, instrument, toy, door, bed, chair, table, statue, coffer, bin, armor stand, weapon rack, cabinet, coffin, floodgate, hatch cover, grate, chain, cage, animal trap, figurine, amulet, scepter, crown, ring, earring, bracelet, any weapon, any trap component†
|-
| [[Bone carver]] (shell)
| Each equipment item with [SCALED] (leggings, gauntlet, helm), figurine, amulet, crown, ring, earring, bracelet, chain, cage, animal trap, instrument, toy
|-
| [[Bowyer]]
| Each ranged weapon (crossbow, bow, blowgun)
|-
| [[Carpenter]]
| Door, bed, chair, table, statue, chest, bin, armor stand, weapon rack, cabinet, coffin, floodgate, hatch cover, grate, cage, barrel, bucket, animal trap, splint, crutch
|-
| [[Clothier]]
| rowspan=2| Each equipment item with [SOFT] (dress, shirt, tunic, toga, vest, robe, coat, cloak, cape, trousers, loincloth, thong, short skirt, skirt, long skirt, braies, glove, mitten, sock, sandal, shoe, chausses, cap, hood, mask, turban, head veil, face veil, headscarf), bag, rope
|-
| [[Weaver]]
|-
| [[Engraver]]
| Figurine, amulet, scepter, crown, ring, earring, bracelet, goblet, instrument, toy
|-
| Fell Mood
| rowspan=3| Each equipment item with [LEATHER] (dress, shirt, tunic, toga, vest, robe, coat, cloak, cape, armor, trousers, loincloth, thong, short skirt, skirt, long skirt, braies, leggings, glove, mitten, sock, sandal, shoe, chausses, low boot, high boot, cap, hood, mask, turban, head veil, face veil, headscarf, helm), any shield, bag, backpack, quiver, instrument
|-
| [[Leatherworker]]
|-
| [[Tanner]]
|-
| [[Gem cutter]]
| rowspan=3| Perfect gem‡, door, bed, chair, table, statue, box, armor stand, weapon rack, cabinet, coffin, floodgate, hatch cover, grate, figurine, amulet, scepter, crown, ring, earring, bracelet, chain, flask, goblet, cage, barrel, bucket, animal trap, window, instrument, toy
|-
| [[Gem setter]]
|-
| [[Glassmaker]]
|-
| Macabre Mood (vermin remains)
| Amulet, bracelet, earring
|-
| [[Mason]]
| rowspan=2| Door, bed, chair, table, statue, quern, millstone, coffer, armor stand, weapon rack, cabinet, coffin, floodgate, hatch cover, grate
|-
| [[Miner]]
|-
| [[Mechanic]]
| Mechanism
|-
| [[Metal crafter]]
| Figurine, amulet, scepter, crown, ring, earring, bracelet, chain, flask, goblet, instrument, toy
|-
| [[Metalsmith]]
| Door, bed, chair, table, statue, coffer, armor stand, weapon rack, cabinet, anvil, coffin, floodgate, hatch cover, grate, cage, barrel, bucket, animal trap, pipe section†, splint, crutch
|-
| [[Stone crafter]]
| Figurine, amulet, scepter, crown, ring, earring, bracelet, goblet, instrument, toy
|-
| [[Weaponsmith]]
| Any weapon, any trap component†
|-
| [[Wood crafter]]
| Figurine, amulet, scepter, crown, ring, earring, bracelet, goblet, instrument, toy
|}
:† ''chance of selection for this entry is reduced by 90%''
:‡ ''this item may only be selected at the beginning of the mood (50% chance)''

If your dwarf does not have a preference for any possible items, the game will randomly select one from the list. Entries with "any" are treated as collective entries with a single chance and will randomly choose a subtype which your civilization is capable of making. This explains why bowyers and clothiers will regularly produce foreign artifacts, while weaponsmiths will not unless they have exotic preferences.

== Success ==
Once created, most [[artifact]]s will be available for use just like a normal item of its type. Artifact [[armor]] and [[weapon]]s gain extra bonuses in combat, while artifact clothing is immune to [[wear]]. Artifact mechanisms installed in weapon traps will improve attack rolls. Artifact furniture is useful for raising the value of a [[noble]]'s room. Artifact mechanisms, trap components, or weapons in [[weapon trap|weapon trap]]s can also boost a room's value considerably. Other artifacts that can be used in construction (such as [[barrel]]s, [[bucket]]s, and [[anvil]]s) may be used similarly. Artifact [[door]]s and [[hatch]]es are immune to [[building destroyer]]s, and artifact [[cage]]s can even hold gnawing vermin. All artifacts can be displayed in a [[display case]] or on a [[pedestal]], or [[trade]]d to a [[caravan]] for supplies.

Successfully creating an artifact grants a very strong happy [[thought]] (enough to make the creator totally ecstatic for several months) as well as granting the creator partial ''immunity to insanity'' – even if your fortress is left in a terrible state, any dwarf who has created an artifact is exempt from going [[insane]] due to prolonged unhappiness. The dwarf may also cry, found as a coating of dwarf tears on both their eyes.

== Failure ==
If you can't provide the desired workshop and all the required component materials within a couple of months, the dwarf will go [[insanity|insane]], which cancels the mood and the artifact. As if that's not bad enough, any dwarf who goes insane will soon die, one way or another.

A dwarf who is '''stark raving mad''', '''melancholy''', or '''catatonic''' is harmless to others (until they die and start a [[tantrum]] spiral), but a '''berserk''' dwarf will attack other dwarves and possibly pull levers at random. You may want to station a squad nearby or assign a few war dogs to the dwarf on the chance that they will lash out. If you build your workshops inside enclosed rooms with doors you can also lock the moody dwarf in the room until he or she starves. In extreme cases, building a wall around an open workshop is the best precaution.

==Bugs==
There are many bugs reported related to moody dwarves. As has been the case in 40d, most turned out to be (understandable) failures of the player to grasp the mechanics of artifact creation and demands. ([http://bay12games.com/dwarves/mantisbt/view_all_bug_page.php Bug tracker])
* If a dwarf dies due to failing to complete an artifact, a memorial made to the dwarf will read that the dwarf did create it, despite the failure, and will even list the name of the artifact that never came to be. {{bug|3640}}
* When producing an item that is normally made in pairs (gloves, boots, etc.), only a single artifact will be created.
* Attacking a dwarf who fails their mood with your militia may result in a loyalty cascade. {{bug|7107}}
* Dwarves entering a strange mood when isolated (e.g. on a stepladder) cause severe lag. {{bug|8698}}
* If the mood primary component is forbidden while working, but the strange mood still has other items tasked, the result is an iron artifact. {{bug|5625}}
* If the dwarf starts constructing the artifact and is scared off by a hostile creature before completion, they may become stuck. {{bug|9833}} Removing the floors around them, then dropping an item on them should cause them to dodge, fall, and return to the workshop.{{cite forum|161598}}

== Troubleshooting ==

'''Problem''': Moody dwarf does not claim a workshop
:'''Solution''': Check for highest moodable skill and build the corresponding workshop. If no moodable skills, build a craftsdwarf's workshop. Once [[magma forge]]s have been built, some dwarves may demand to work at a magma-powered forge or furnace while others might still insist on a coal-powered one. If a forge is needed, make sure you built a forge, not smelter. Note that [[forbid]]den workshops cannot be claimed. Verify if the dwarf is assigned to a burrow and/or if there is a civilian alert set to a burrow. If so, verify that the burrow allows access to the workshop being sought after.

'''Problem''': Moody dwarf waits in claimed workshop
:'''Solution''': Desired material is unavailable. Determine which material is requested next (materials are collected in the same order as shown in the dwarf's request list) and make some available, if possible. Note that dwarves with [[preference]]s may demand a specific type of material ([[brass]] bars or [[yarn]] cloth, for example). [[Forbid]]den and inaccessible materials cannot be collected, nor can material located outside the moody dwarf's [[burrow]].

'''Problem''': No dwarf has entered a mood for a long time
:'''Solution''': Strange moods require at least 20 dwarves; if you have that many you've, probably hit one of the two caps. Exploring the caverns can increase the number of revealed tiles very quickly, while [[craft]]ing [[goblet]]s will quickly raise your item count; [[exploratory mining]] will count toward ''both'' caps, simultaneously revealing tiles and producing boulders, though more slowly than exploring or crafting. Exposing excavated terrain to the sky is counterproductive, as it will ''lower'' your artifact cap (since the cap only counts revealed ''subterranean'' tiles).

'''Problem''': Moody dwarf wants stacked cloth, but all types are available and he's not moving
:'''Solution''': Dwarves will not take items from active hospitals. If you have no cloth available outside of hospitals, try disabling or temporarily removing the hospital designation from their zones. They will then proceed to take new items, even if they don't go for the cloth right away. It is also possible that the desired cloth has been partially consumed in order to make wound dressings.

==Trivia==
{{D for Dwarf}}
It is widely said that Tarn Adams has been in the grips of a fey mood for two decades now, and we are playing his artifact. However, neither [[human]]s nor [[giant toad]]s can enter strange moods, so this must surely be a joke.

{{Category|Dwarves}}
[[Ru:Strange mood]]

Civilization

2023-01-13T05:27:13Z

Kelvie: Add tidbit about civilizations and available crafted goods

{{migrated article}}
{{Quality|Unrated}}
{{av}}

[[File:civs.jpg|thumb|330px|right|A Chinese civilization from centuries ago.]]A '''civilization''' (also known as an '''entity''') is an organized society formed by a group of distinct, intelligent [[creature]]s. Civilizations are characterized by recognizable symbols, [[Performer|art forms]], and [[language]]s, communities possessing common [[ethic]]s and [[Personality trait#Beliefs|value]]s, the development of advanced [[site]]s and [[structure]]s, the use of defined resources, governing systems with individuals or groups exercising authority, interactions with the [[surroundings|environment]], and the creation of complex relationships and [[diplomacy]] between other entities, which can result in global networks of [[trade]], the sharing of [[knowledge]], and conflicts due to disagreements, which may break out into [[war]].

[[World generation]] controls the number of civilizations in each world. All civilizations will initially be one of the five main [[race]]s, although over time, individuals of other races can join them. In [[dwarf fortress mode]], only [[dwarven]] civilizations are currently playable by default; to play as others requires [[modding]]. [[Adventurer mode|Adventurer]]s can be from dwarven, [[elven]], or [[human]] civilizations, or they can be human outsiders from no civilization.

To start an (''unmodded'') game in fortress mode, there must be one or more dwarven civilizations; by default, the [[Advanced_world_generation#Playable_Civilization_Required|Playable Civilization Required]] option ensures this is true. You can select your civilization at the [[location|site selection]] screen, and each will have some different items available for you to [[embark]] with.

Civilizations also determine what types of items a particular civilization can craft, that is why sometimes in a game, for example, your dwarven civilization might not know how to make a specific item, such as low boots.

==Types of civilizations==
===Mountain===
The '''mountain civilization''' is established by the [[dwarf|dwarves]] {{Tile|☺|3:0}}. Mountain civilizations centralize in [[industry]], [[alcohol]], [[mining]] deep, producing ☼masterful [[craft]]s☼, and creating pretty epic [[stories]]. Mountain civilizations build great [[fortress]]es on the edge of mountain ranges, smaller [[hillock]]s in the hill-lands, and [[mountain halls]] deep in the mountain. Fortresses and mountain halls are connected by roads and underground [[tunnel]]s.

===Plains===
The '''plains civilization''' is established by the [[human]]s {{Tile|U|3:0}}. Humans are the most variable out of all the civilizations. Plains civilizations build vast [[town]]s and rural [[hamlet]]s in low plains near bodies of water. Broad roads connect nearby towns together.

===Forest===
The '''forest civilization''' is established by the [[elf|elves]] {{Tile|e|3:0}}. Forest civilizations are firmly devoted to the protection and well-being of nature, including [[tree]]s. ''Especially'' trees. Harming plants (most importantly, trees) is considered an unspeakable crime. Forest civilizations build [[forest retreat]]s made of large, outdoor structures of living trees in wooded areas.

===Evil===
The '''evil civilization''' is established by the [[goblin]]s {{Tile|g|7:0}}. Evil civilizations are keen on going to war and <s>rescuing</s> [[snatcher|kidnapping]] innocent children. They are undoubtedly the most cruel of all the civilizations. Evil civilizations construct sinister [[dark fortress]]es and blot the land with [[dark pit]]s.

Evil civilizations are actually formed by certain supernatural [[demon|beings]] from an [[hidden fun stuff|eerie place]].

===Skulking===
The '''skulking civilization''' is established by the [[kobold]]s {{Tile|k|6:0}}. Skulking civilizations [[thief|steal]] items from nearby civilizations and stay distant from other affairs, populating the natural [[cave]]s. Cave residents do not show as neighbors on the embark screen, and in default [[advanced world generation|world-gen settings]], the caves themselves are hidden from the map.

===Subterranean animal people===
Unnamed tribes spawn in deep [[cavern]]s underground, and are populated by various [[animal people|humanoids resembling animals]], forming small, crude camps. Unlike other civilizations, they do not appear in the civilizations screen. Creatures that form underground civilizations are as follows:

*{{Tile|a|6:0}} [[Amphibian man]]
*{{Tile|a|0:1}} [[Antman]]
*{{Tile|b|0:1}} [[Bat man]]
*{{Tile|f|7:1}} [[Cave fish man]]
*{{Tile|s|0:1}} [[Cave swallow man]]
*{{Tile|o|7:1}} [[Olm man]]
*{{Tile|r|2:0}} [[Reptile man]]
*{{Tile|r|0:1}} [[Rodent man]]
*{{Tile|s|7:1}} [[Serpent man]]

==Dead and struggling civilizations==
When a civilization is destroyed by war or other calamities, it becomes a dead civilization. A civilization that is quite close to being dead is said to be struggling or dying.

In fortress mode, a player may embark while part of a struggling civilization – sometimes even as part of a dead civilization.
If you are embarking as a dead or struggling civilization, you are warned about that at embark. It can be tricky to determine if your civilization is struggling or dead, but here are some indicators:

===Struggling===
*The dwarven caravan may appear, but may also be absent for one or several years at a time.
*The outpost liaison may also appear with the caravan, but could also be absent (even if the caravan comes) for several years.
*Migrants should arrive as normal.
*Your (struggling) civilization will show on the Civilization screen right after embark, though it may be said to have no important leaders.
*A monarch might be appointed: most likely triggered by some unknown event, at which one of your dwarves become monarch after a polite discussion with its peers, but at the latest at the turn of the second year of your fortress (and frequently it's the expedition leader). Note that a monarch can be elected in your fortress even when the civilization was healthy at embark, in which case the election was triggered by the death of the previous monarch and nobody was elected at the other sites.

===Dead===
*All dwarven civilizations in existence are dead. If at least one is not, the dead ones will not be available for embark.
*Only two migrant waves, no more.
*No dwarven caravans, ever.
*No monarch in the fortress or out in the world, ever.
*Right after embark, the Civilization screen is completely empty. Your (dead) dwarven civilization will show up once you make contact with any other civilization, including kobolds.

If your dying civilization has no sites, but isn’t being treated as dead, it may be because remaining historical populations (often nobles/monarchs) remain behind at a ruined site, possibly because their status as nobles prevents their migration. If having trouble creating a dead civilization, going to some ruins in Dwarf or Adventure mode, then killing the site’s residents, may kill the civilization.

==Fortress Mode==
As of version 44.11, there exist 7 information screens in the [[Civilization and World Info]] screen: World, Missions, News and Rumors, People, Artifacts, Holdings and Tribute, and Civilizations.

===World===
The world map can be accessed by pressing {{k|w}} from the [[Civilization and World Info]] menu. Use the cursor keys to navigate around the map and view other lands.

===Missions===
[[DF2014:Mission|Missions]] are commands that send one or more of your squads to visit sites outside of your fortress. They are created in the [[Civilization and World Info]] screen (accessed by pressing {{k|c}}-{{k|m}} in the main fortress view). There are multiple types of missions, such as raids, explorations, artifact recovery, and citizen recovery. ([[DF2014:Mission|Mission Page]])

===News and Rumors===
News and rumors can be accessed from the [[Civilization and World Info]] menu by pressing {{k|n}}. Display items include:
* Armies and settlers on the move as moving dots (The dots start at one location and move to a destination)
* O - Towns that were conquered
* A - Red: Towns that were attacked
* A - Yellow: An artifact's last known location
* R - Refugees fleeing an army
* P - Political event

===People and Artifacts===
The People view can be accessed by pressing {{k|p}} from the [[Civilization and World Info]] menu. It lists the recoverable missing citizens, as well as prisoners in other [[site]]s that you may rescue yourself, and the Artifacts view can be accessed by pressing {{k|a}}, listing all known artifacts. Artifact recovery missions can be launched by selecting an artifact and pressing {{k|r}}

===Civilizations===
Civilizations that you have been in contact with (either by trade or war) can be viewed by pressing {{k|c}} to go to the [[Civilization and World Info]] and then {{k|c}}. Once you've selected a civilization to view, you can switch between viewing figureheads, export/import tallies, and trade agreements for that civilization with {{k|Tab}}. Friendly civilizations will generally report positive import/export values, while hostile civilizations generally trade in [[death]] and [[fun]]. You can peruse trade agreements with the arrow keys and {{k|Enter}}. [More information is needed about the other screens.

The {{Tile|P|2:1}} or {{Tile|W|6:4:1}} to the right of the civilization screen indicates the current relationships between the selected civilization with other civilizations on the list. {{Tile|P|2:1}} indicates peace (note for goblins, you will still get sieges even if you are at "peace" with them) and {{Tile|W|6:4:1}} indicates war. As an example, if you select the dwarven civilization, and next to a goblin civilization is {{Tile|W|6:4:1}} (which is not uncommon) it means that—congratulations—your civilization is at war with the goblins. If you view your trade agreements with a civilization you are at war with the imports will be terror and the offerings will be vengeance. Do note that it is possible to be at war with your own civ, this is often caused by [[Mission|raids]].

Be aware that "neighbors" on the screen are not necessarily ''close'' neighbors, they are merely civilizations that have been contacted by yours. Your civilization may have connections with another civilization that is found on the far side of the world.

===Holdings and Tribute===
Pressing {{k|h}} will change the world tab to a map-like version. You can press {{k|l}} for the legend. Each civilization will have its own symbol surrounded by a certain color of tile. If those tiles are red, you are at war with that civilization. If the tiles are light green, you are at peace. If they are dark blue, it is your civilization. Your site will be surrounded in light blue and your occupied holdings will be surrounded by magenta. Your vassal holdings will be surrounded by a grayish-blue color, and your tributaries will be a {{Tile|T|0:7:0}} surrounded by gray, while occupied tributaries will be an {{Tile|O|0:5:0}} surrounded by purple. If you are economically linked to a settlement, the settlement will show up as an {{Tile|E|0:2:0}} surrounded by green.
[[File:HoldingsandTribute.png|thumb|right|A world on the Holdings and Tribute tab]]

{{D for dwarf}}
===Concerning Orcs===
The orc, a civilization that has been widely popular in the past, but has never been worthy of being in dwarf fortress. However, if one would like an orc in their game, he must only overfeed a goblin.

== See also ==
* [[Entity token]]

== Bugs ==
* Civilizations can be struggling, even though they should by normal logic be dead, such as having had no living members or sites for over 1,000 years.{{bug|9503}}
* Dead civilizations' missions never complete. {{bug|10891}}

{{World}}
{{Category|World}}

Tile attributes

2023-01-09T05:37:11Z

Kelvie: v50 update.

{{migrated article}}
{{Quality|Unrated}}
{{av}}
[[File:tile_status_preview.png|thumb|332px|right|Underground and above ground. Simple as that.]]Every tile in ''Dwarf Fortress'' is described as {{DFtext|Outside|3:1}} or {{DFtext|Inside|6:0}}, {{DFtext|Light|6:1}} or {{DFtext|Dark|0:1}}, and {{DFtext|Above Ground|2:1}} or {{DFtext|Subterranean|0:1}}. Unlike in versions prior to v50, these attributes can no longer be observed from the {{k|k}} menu, when the cursor is located over any single tile.

These attributes do ''not'' change what tiles look like. DFHack's Rendermax plugin implements a lighting system into the game, but this is only an aesthetic change, and does not affect tile attributes.

There are 8 different combinations, and only 4 of them occur naturally:
* {{DFtext|Outside |3:1}}{{DFtext|Light |6:1}}{{DFtext|Above Ground|2:1}} - Outdoors, or within outdoor-like conditions (such as being indoors, but with no roof above the tile, providing direct access to sunlight.)
* {{DFtext|Outside |3:1}}{{DFtext|Light |6:1}}{{DFtext|Subterranean|0:1}} - Impossible
* {{DFtext|Outside |3:1}}{{DFtext|Dark |0:1}}{{DFtext|Above Ground|2:1}} - Impossible
* {{DFtext|Outside |3:1}}{{DFtext|Dark |0:1}}{{DFtext|Subterranean|0:1}} - Impossible
* {{DFtext|Inside |6:0}}{{DFtext|Light |6:1}}{{DFtext|Above Ground|2:1}} - Constructed buildings on the surface, below-ground-level chambers with constructed floors or buildings only (possibly walls also{{verify}}) above them. Also tiles beneath branches of some trees.
* {{DFtext|Inside |6:0}}{{DFtext|Light |6:1}}{{DFtext|Subterranean|0:1}} - Impossible
* {{DFtext|Inside |6:0}}{{DFtext|Dark |0:1}}{{DFtext|Above Ground|2:1}} - Possible in [[Object testing arena|arena]], does not occur in Adventure mode. It can occur in Fortress mode, e.g: after unretire on stockpile tiles (biome becoming embark tile level biome).
* {{DFtext|Inside |6:0}}{{DFtext|Dark |0:1}}{{DFtext|Subterranean|0:1}} - Underground tunnels, including most of your fortress

Being in the dark increases [[cave adaptation]], and being outside causes it to decrease (along with stunning/nausea if the sun is out).

The entire [[Location|fortress site]] starts out as {{DFtext|Inside |6:0}}{{DFtext|Dark Subterranean|0:1}}. After that, a ray for {{DFtext|Outside|3:1}} and a ray for {{DFtext|Light |6:1}}{{DFtext|Above Ground|2:1}} falls straight down from the highest [[z-level]] for every (x,y) position on the local map, changing each tile's modifiers until something that blocks that particular "ray" is encountered. Due to this behavior, any of the previous three tile combinations will never be encountered in the same (x,y) position on a lower z-level than a higher-numbered combination.

== Outside vs. Inside ==

This attribute is determined by whether there is a roof of some kind over a tile. Weather only affects tiles which are ''Outside''. Almost any kind of geometry will block the ''Outside'' ray including natural and constructed [[wall]]s, [[floor]]s, [[stair]]s, and [[fortification]]s, and [[bridge]]s, [[grate|floor grates]], [[bars|floor bars]], and [[hatch]]es. A tile which is ''Outside'' will always be ''Light Above Ground'', but an ''Inside'' tile may be either ''Light Above Ground'' or ''Dark Subterranean''.

Tiles under lever-opened bridge, hatch, grate or floor bars will keep counting as inside until any tile in that 1×1 column is built, constructed or dug on to force an update; remaining so after closing until another update.

== Light vs. Dark and Above Ground vs. Subterranean ==

Currently these two attributes are determined in exactly the same way. Once an area is exposed to the outside world, it is ''Above Ground'' and ''Light'' (and thus channeling this tile will make the tile below it also ''Above Ground'' and ''Light''). Even after being covered up again, it will remain this way. This allows growing outdoor crops inside safely.

{{Category|Map tiles|*}}
[[ru:Tile attributes]]

Necromancer

2023-01-08T09:48:06Z

Kelvie: Verified: necromancers definitely still gesture when raising the dead.

{{migrated article}}
{{Quality|Unrated}}
{{av}}
[[File:necromancer_sprite_preview.png|right]]'''Necromancers''' {{Tile|Ñ|5:1}} are [[immortal]] beings blessed with the [[secret]]s of life and death. These [[night creature]]s are [[magic]] users who raise legions of [[undead]] and seclude themselves in [[Tower_(necromancy)|tower]]s. Most [[creatures]] that are necromancers will have their sprite appear with pale purple-like skin.

==The Origin of Necromancers==
Necromancers initially begin as normal [[historical figure]]s who are [[Creature_token#MAXAGE|mortal]], [[Creature_token#CAN_SPEAK|can speak]], [[Creature_token#CAN_LEARN| learn]] and are also part of an [[civilization|entity]]; in unmodded games these are [[dwarf|dwarves]], [[human]]s and civilized [[animal people]]. At some point in its life, one of these creatures may suddenly become "obsessed with his/her/its own mortality" and seek to become immortal. Shortly afterwards, it will begin (if it does not do so already) worshiping a [[deity]] (or a creature with the {{token|SUPERNATURAL|c}} tag) who has a [[sphere|DEATH sphere]]. Once the deity/supernatural creature becomes an object of ardent worship to the figure, it will reward the worshipper with an artifact [[slab]] containing the secrets of life and death, which is then swiftly claimed by the recipient for diligent learning, thus becoming a necromancer. This original necromancer may then take as apprentice one or more fellow immortality-seekers, who will obtain the knowledge of their master.

==Description==
Having mastered the secrets of life and death, necromancers have reached their goal of [[immortality]], in that they do not [[age]], need to [[food|eat]], [[thirst|drink]], or require [[sleep]], as they [[No Exert|never get tired or exhausted]]. However, they ''do'' need to breathe, unlike [[vampire]]s. Necromancers are still fertile, and in fortress mode, female dwarf necromancers can give birth. Their {{token|ANXIETY_PROPENSITY}} is raised by 50, while their {{token|TRUST}} is lowered by 50, and some necromancer secrets add {{token|LIKES_FIGHTING}}.

The defining characteristic of necromancers is that they know the secrets of life and death, which gives them extra powers. However, not all secrets are created equal - different secrets will yield different powers.

== Secrets ==
[[File:necromancer_preview.jpg|thumb|360px|One of the worst ways to deal with grief. ''Art by ChrisCold''.]]Each secret gives a combination of magical abilities, which come in the form of [[interaction token]]s. These abilities may vary widely in type and power level, but will always include the ability to raise corpses and [[intelligent undead]]. Depending on their [[sphere]]s (which stem from the spheres of the original [[deity]] that granted those secrets) secrets may also grant the ability to summon [[nightmare]]s, [[bogeymen]], and also the ability to "ghoulify" a living creature (in effect, giving it a [[syndrome]] that turns it into a [[thrall]], much like [[evil]] clouds). In addition, the intelligent undead will also be granted powers of their own, which may range from raising blisters to rotting nerves, to even being able to raise the dead themselves. The [[Advanced_world_generation#Number_of_Secret_Types|number of secrets]], and [[Advanced_world_generation#Allow_Divination.2C_Experiments.2C_and_Necromancy_types|which advanced powers]] they can convey, can be set in advanced world generation.

A single necromancer can learn multiple strains of necromancy by reading different sources. Ambitious necromancers tend to create more towers of the same strain via proxy, so you might find your world populated by a single strain. Usually it’s easier when you know which tower houses what kind of undead, or when you go after the source slabs via legends mode. Recovery is also easier when you have a sneaky squad of artifact raiders in fort mode.

=== Raise corpse/intelligent undead ===
Necromancers always have the [[interaction token|power]] to animate [[corpse]]s of organic creatures, which can include heads or any body parts which have a {{token|GRASP}} token or are attached to body parts which do ([[skin]], and [[hair]]). Corpses must be within the necromancer's line of sight – about 15 tiles – to be animated. Necromancers do this by gesturing; raising of the dead is reported in the [[reports|combat log]]:

{{gametext|[Necromancer] gestures!|3:1}}
{{gametext|[Corpse] shudders and begins to move!|3:1}}

Once a dead being is animated, it will become [[Adventure mode#Companions|enslaved]] to the necromancer and {{token|OPPOSED_TO_LIFE}}, regardless of previous allegiances. Unless the necromancer attacks their new undead minions, they will remain companions in Adventure mode. If you are a necromancer and attack one of your undead companions, all of them will turn neutral. Animated corpses are also neutral toward creatures that are {{token|NON_LIVING}}. Necromancers will also, occasionally, revive corpses as [[intelligent undead]] – in this case, the revived creature will retain most of its personality and existing loyalties. The name "undead" never quite appears as such in the game – instead, a procedurally-generated name like "lost butcher" or "risen zombie" is used. These undead have special powers but won't be enslaved or {{token|OPPOSED_TO_LIFE}}. In fortress mode, this means that intelligent undead raised by necromancer citizens of your fortress will stay citizens, if they were such when they died. It also means putting necromancers in military squads very risky, as they might accidentally revive your enemies with fun new powers. In adventure mode, if you attempt to raise someone you killed as an intelligent undead, they will remember you attacked and killed them, and will be hostile to you.

=== Summon [[nightmare]]s/[[bogeymen]] ===
Secrets aligned with the nightmare sphere will grant the ability to summon nightmares or bogeymen at a random location near the target to haunt it. In-game, necromancers with this ability will "call upon the night" to do so. These summons are large and freakish, but last a short amount of time. Nightmares are neutral toward creatures with {{token|NO_FEAR}}.

=== Ghoulification ===
Certain necromancers may also turn living creatures into [[infected ghoul]]s. The victims will be said to have "been infected with a contagious ghoulish condition". In adventure mode, you cannot make ghouls even if the announcement after reading a secret-containing book says you learned the power. Ghouls are opposed to life and attack/infect all living creatures who aren’t ghouls through bites. They still retain their sentience and can still bleed to death, but they maintain their gear and abilities, are immune to drowning, do not tire, and have extravision.

== In world generation ==
[[File:Secrets.png|thumb|Secrets of life and death.]]In world generation, necromancers may raise suspicions from their fellow citizens due to not aging, which can lead them to be expelled. This does not apply to necromancers living in goblin and elven civilizations since both goblins and elves are already immortal. Upon being expelled, the necromancer may form a grudge against the civilization and turn to [[villain]]y, and they will generally take refuge in a site of their own.

Necromancers who have a sufficient following may use their undead minions to build dark [[Tower (necromancy)|tower]]s, a task that requires at least 50 followers; younger necromancers may take over [[town]]s or camps instead. Necromancers will also raise a few [[intelligent undead]] as lieutenants. The building of a tower is carried out by the original necromancer of a group (the one who was given the slab) as apprentices join the group after the tower is built. Therefore, each necromancy group has one tower.

Necromancers can make zombies build their tower up a bit to increase the site's zombie cap. If the necromancer is at their zombie cap, they can still raise more zombies, but they are added to a wilderness population instead. The wilderness population can still be used for invasions, but they are also able to roam on to player forts in the region and also encounter adventurers.

Necromancers may conduct experiments on civilians and their [[domestic animal|livestock]], turning them into night creatures known as [[experiment]]s. Eventually, these experiments may leave the necromancer that made them and join other civilizations. In older worlds, many civilizations will likely have significant populations of escaped experiments. In adventure mode, it is not currently possible to create necromancer experiments.

Necromancers can also turn intelligent creatures into [[infected ghoul]]s. The ghouls can then be found around necromancer towers, but it is not currently possible to turn a creature into a ghoul in adventure mode.

Since the secrets of life and death are generated with a {{token|MUNDANE_RECORDING_POSSIBLE}} tag, necromancers will often write numerous [[book]]s during world generation, some concern the secrets of life and death (''blessed, or mayhap, cursed'') so that anyone who reads them will become a necromancer. Like the slab, all (''first-edition, not copies'') books, even those that do not contain secrets, are considered [[artifact]]s, and as such can be viewed in the "Codices and scrolls" list in [[legends|legends mode]]. Books containing the secrets of life and death will include any of the following words in their title: Annihilation, Bereavement, Death, Demise, Departure, Doom, Dying, Eternal Rest, Expiration, Extinction, Mortality, Immortality, Loss, Oblivion, Parting, Ruin, Ruination, Sleep, the Afterlife, the End, the Grave. (Note: "the End" can also turn up in mundane titles as well, typically as part of the phrase "after the end")

It is possible to ensure that a world is generated devoid of necromancers by setting the '''Number of Secret Types''' to '''0''' in [[advanced world generation]]. To the contrary, creating a world with a high number of secret types will increase the probability of there being multiple necromancers in the world. Since necromancers in unmodded games are usually humans or dwarves, having a large amount of neutral plains and/or mountains will further increase this probability, as it means that these civilizations will have more space to expand, and thus the amount of historical figures eligible for necromancy will increase.

Necromancer towers spread death-[[sphere|aligned]] [[evil]] regions around them. Destroying the tower and killing the necromancers in it (e.g. through a [[raid]] to raze the site) will reverse the evil-spreading.

Necromancer towers seem to be treated as a type of criminal government{{verify}} and as such function similarly to a regular civilization. Necromancers from opposing entities will attack each other, but amusingly, their undead armies will be neutral to everyone. Due to their ability to amass large armies quickly, necromancers are currently one of the most powerful geopolitical forces in the game, often declaring war on and destroying even powerful goblin civilizations in older worlds.

==Fortress mode==
===Sieges===
{{DFtext|The dead walk. Hide while you still can!|5:1}}
{{main|Siege#Necromancer sieges}}

Necromancers can lay [[siege]] to your fortress at any stage, including before the first [[immigration|migrant wave]], but only if their tower or town is within 20 tiles of your fortress. As such, picking a location within that distance of such a tower is regarded as a sure way to have an extra helping of [[fun]], and can be checked with {{k|tab}} during world gen. Note that if no tower is present during embark, no necromancer sieges will ever arrive (they may still show up as migrants and/or visitors), except if you [[mission|attack]] them. The sieges are structured much like normal sieges, except that the numbers tend to be much larger and much more disorganized, consisting not of individual squads but of masses of zombies coming from every side. The necromancer (or necromancers, if the former has an apprentice) may or may not arrive with the siege; if they do, and are captured or killed, you can expect to see no more activity from that particular tower. Undead are hostile to everything that breathes as well as to enemy necromancer hordes, meaning that other sieges or [[ambush]]es (or, indeed, caravans) that happen to arrive when a necromancer siege is milling about will always result in a battle. They may also send small squads or armies of experiments to attack you, sometimes stealthily acompanying their minions.

The easiest way to deal with a zombie siege is through the application of [[dwarven atom smasher|particle physics]] to grind the zombies into nothingness. Anything that obliterates any trace of the zombie will prevent raising; a drop into [[magma]] or [[semi-molten rock]] or encasing in [[obsidian]] are more creative alternatives. The jury is still out on whether slashing weapons are better or worse against necromancer sieges; although they tend to separate zombies into many parts, these parts can all be raised, leaving the question of whether the whole zombie or an arm here and a leg there is more dangerous. The undead that the necromancer(s) will bring will be sapient creatures, but if you killed some [[elephant]]s in a combat exercise and a necromancer happens upon them, the danger is magnified.

If you have a [[vampire]] and haven't walled them in yet, you can draft them and take a leisurely walk through town, as undead will ignore them (unless attacked), and the necromancer, has one arrived, is an easy, valid game for a clobbering.

Necromancers that are idle during a siege used to occasionally start [[campfire]]s.

===Ambushes===
Necromancers can arrive under cover, alone, in [[ambush]]es, and raise the dead without being seen. This is much more difficult, as you cannot see the necromancers in question, only their products. Potential necromancer ambushes can be dealt with by internalizing all corpse/remains stockpiles behind heavily trafficked areas, and posting sentries if possible.

===Residents/citizens===

Residents and citizens alike can also become necromancers if they happen to read material (such as [[codex|codexes]]/[[quire|quires]]) that contain the secrets of life and death. One way to acquire such materials is by trading for them from a [[caravan]].

Necromancers may occasionally arrive with their slab in hand. It is possible to add necromantic texts as part of your library, allowing you to turn your dwarves into necromancers once they read them. It is also possible to use the world map to send military squads to raid necromancer towers for the reading material contained in them. Dwarven necromancers no longer age, need to eat, or sleep, but they will also no longer need to drink, which can slow them down tremendously for it to be worth it. They ''may'' also raise the occasional corpse, which will often attack non-necromancers, while this might not sound like a big deal if you already have a fort full of necromancer dwarves, the real [[fun]] comes when diplomats, trade caravans, and outpost liaisons show up and if you have the dead walking among your populace. Also, be wary of sending necromancers out in melee, as intelligent undead invaders may remain hostile to your necromancers, who are ceaseless in bashing their heads in before killing them again in an endless, FPS-killing cycle.

Another way of getting necromantic reading material into your library is to "liberate" it in adventure mode, then drop the book off at a retired fortress. This will then be able to be picked up by your dwarves to read at their leisure.

A necromancer may raise the dead when threatened, which is fun when your battlefield is full of previously hostile sentients. This is why you should almost always manually control the necromancer in fortress mode.
There does not appear to be many disadvantages to having necromancer residents, however if you have too many during battle, they may raise too much undead and cause FPS death.

===Applications===
Necromancers can be made useful by applying them in [[training]] schemes. Necromancers trapped in a room with line of sight to, say, the contents of the corpse stockpile, can be used to generate an infinite amount of hostile creatures to fight; when you get tired of the sport (or your dwarves start getting beat up), simply block their line of sight with a bridge and put down the remaining enemies, and your military can walk out of training with more experience.

Capturing necromancers is simple: build a tunnel near the necromancer, link floodgates or bridges within so that it can be sealed off, and then poke a hole into the surface. Assuming the necromancer was the nearest creature to where you opened the tunnel, they will be the first one in, and you can then seal off the tunnel and trap them inside. It's difficult to get the necromancer in there alone, without a few zombies following, but it shouldn't matter. [[Cage trap]]s will work too; however, caged necromancers do not appear to revive stuff. You must put necromancers on a restraint afterwards if you want them to be able to.

They can also be weaponized. Replace the militia training room with a room full of goblins, and fun will result. Upright spike [[trap]]s can "kill" the corpses after each use so that the resulting [[goblinite]] can be gathered, and the trap reused. Given enough time and enough bodies, such a trap can even best the [[HFS|circus]].

Much like [[vampire]]s, necromancers may seize control of a [[civilization]] and become its [[monarch|king/queen]]. In that case, the dwarf in question must be isolated from any corpses, as ''they'' may be friendly, but the zombies they tend to create... will be of the dwarven-arm-ripping variety. They should be either isolated from the dead with a [[burrow]], or applied to training/killing. Either way, necromancers are very [[fun]].

===Visitors or immigrants===

Necromancers may also casually arrive as [[visitor]]s or [[immigrant]]s in your fortress. When visiting, they won't attack you or attempt to raise any corpse they see – they came to relax, and just happen to know the secrets of life and death (the visitors are normally, though not necessarily always, schemeing something). They ''will'', however, use their powers in combat (for instance, if they enlist as mercenaries in your squads), but not necessarily mindless corpse-raising – they may revive one of your dwarves that just died as an [[intelligent undead]], who is loyal to your fortress and has extra powers. Necromancer immigrants can be put to work like any other immigrant dwarf - this may be bad for your meat supply when they practice their craft on the corpses produced by your hunters, however.

==Adventurer Mode==
In [[adventurer mode]], necromancers are most commonly found in towers {{Tile|I|5:0}}, but can very rarely be found in towns and camps, due to reasons explained earlier in this article. Towers will contain all the necromancers that are part of the necromancer group to whom the tower belongs, as well as a horde of undead. Towers require abundant human populations (low savagery, large tracts of neutral land) and a high number of secrets to be generated in world generation. Elves or goblins cannot become necromancers through normal means (bestowed by a death god) as their immortality means they cannot become obsessed with their own mortality. They can still learn the secrets of life and death by reading them, however.

It is possible to become a necromancer yourself in adventurer mode by [[reader|reading]] the slab or one of the books containing the secrets of life and death. Both will be found on the tables scattered around the tower, often amongst a pile of other, less useful books.

So, becoming an immortal being who doesn't need to worry about petty things like eating, drinking and sleeping and can also raise and control an undead army merely requires you to read some slab or book. Sounds simple, doesn't it? Unfortunately, it isn't. The tower is stuffed with undead monstrosities who would probably like nothing better than to tear your poor adventurer to shreds. If that isn't bad enough, the necromancers to whom the slab and books belong will raise their
servants each time you strike them down, if they can see the corpses.

So, what can we do to get at those secrets? Well, there are methods:

* '''1. Storm the tower'''
This is probably the most obvious solution, and is also the most likely to get inexperienced adventurers killed. Once you have become powerful enough, attack the tower head-on, preferably bringing with you an army of <s>meatshields</s> soldiers (who will likely get themselves killed, but will provide a distraction for you). It is advisable for you to lure the undead out of the tower first, away from the necromancers' gaze. This will make dealing with them far easier, and will give you a lot more space to dodge (or run if things get bad). If a necromancer is in the midst of the horde, try to move around so that the necromancer is exposed, then go in for the kill. Proceed until everyone (excluding yourself) is dead. Alternatively, just run into the tower and begin hitting everything like a madman. Eventually, either you or all of the tower's occupants will be dead. Then just take the slab/book and do what you will with it.

* '''2. Sneaking'''
Since [[ambusher|sneaking]] in the current version basically makes you invisible{{verify}}, and due to the fact that lighting barely exists yet, sneaking into the tower with a high enough skill and [[thrower|throwing]] stuff will allow you to kill everyone with minimal damage done to yourself. There is, however, the risk of being spotted, in which case you are advised to run away as quickly as you can. Alternatively, you could try to sneak around the tower and steal the slab/book without killing anything, but, because of the high density of enemies in a tower, it is extremely likely that you will be spotted, swarmed and killed.

* '''3. Being a Night Creature'''
Visiting the tower as a [[night creature]] [[Faction#Faction relative hostility|to whom undead are friendly]], such as a [[vampire]], [[undead|husk/thrall]] or, of course, a fellow necromancer, is by far the easiest way to obtain the slab/a book. Seriously. The undead are {{token|OPPOSED_TO_LIFE}}, but these night creatures are {{token|NOT_LIVING}}, so they will ignore you completely. Since undead will not attack necromancers, making a mad dash for the slab/book is also a viable option, but you will risk being killed/severely wounded before you get the chance to become a necromancer. If you are already one of these night creatures, you can just skip gleefully past the undead, read the slab/book and get out. You may also want to have a chat with the necromancers, who are actually quite friendly once you get to know them. In fact, night creatures who are shunned by society will often still be accepted by necromancers, who you can even ask for [[Adventure mode#Quests|quests]]! That is, of course, unless you are an enemy of their group, in which case they will attempt to kill you. Be advised that you cannot become a necromancer as an [[experiment]].

* '''4. Fire. A lot of fire.'''
The undead hordes will not cross small fires. The aspiring adventurer can outrun undead, leading them away from the tower, then run for the entrance. If there are more undead inside, run away. Repeat this until the undead have emptied from the tower, outrunning them and herding them. Run to the tower entrance and light fires around it, sealing them out. Take your time, enjoy the books, maybe mess with a necromancer. When you're ready to leave, scale the wall or jump over the fire. Bonus points: completely enclose the undead in a fire circle they cannot escape from. Side note: while running from undead, igniting the grass in clever places will slow them down even further.

* '''5. Vampire recruit'''
Another strategy, which may not always be available but can work well, is recruiting a vampire. Undead creatures and vampires won't bother each other, but the vampire will attack any hostile necromancers present. Once the necromancers are all dead, you will be left with the far simpler task of killing the undead without having to worry about any of the corpses reanimating.

* '''6. Leapfrog'''
{{k|j}}umping is an often overlooked but fairly powerful combat tool, especially against large hordes of very stupid zombies. Huge numbers have no impact of how effective jumping is, and zombies don't really try all that hard to get out of your way. It's fairly easy to just leap through entire hordes of zombies until you get to the tower proper, at which point you can just dash up some stairs and wait a bit for the zombies to forget you. The actual sentient inhabitants of the tower are strangely hospitable (even to the living) and don't seem to mind you that much, although some experiments seem to turn aggressive if you try talking to them. Once you've found the secret the zombies have probably forgotten about you and will ignore you now that you're also a night creature, and any that still remember you can be dispatched easily without causing any more trouble.

===Playing as a necromancer===

As a necromancer, you:

*don't need to eat or drink, so you don't need to worry about running out of food/water and can get rid of the extra weight such objects produce.
*don't need to sleep, and can't get tired or exhausted, so you'll never again feel the negative effects of these statuses.
*are immortal, as necromancers do not age. This will ensure that your adventurer will not die of old age if your world goes on until its natural {{token|MAXAGE}} is reached (such as if you retire an adventurer and play fortress mode for a while).
*can reanimate corpses to create undead companions. This can be done as many times as you want, with a small [[time]] limit between each reanimation, and only requires a corpse/body part.

Becoming a necromancer also freezes your physical [[attribute]]s so that they cannot rust or be increased. Therefore, it might be wise to raise them to a high level before becoming a necromancer. (However, this does not seem to be happening in the current version, including 0.47.05, probably due to a bug, or it's a design choice. Because let's be honest, just because you're a necromancer doesn't mean you can't learn new things, right?)

==== Reanimating dead creatures ====
1.Open the actions menu by pressing {{k|x}}. 
2.Press {{k|p}} or scroll to "acquired power". 
3.Select ({{k|→}} {{k|Enter}}) "Animate corpse". 
4.Now move the cursor onto the corpse(s) you wish to animate, press the letter that they are represented by on the items screen (such as {{k|a}}) and press {{k|Enter}}. Note that you can animate more than one corpse at a time, and that you can also animate corpses that are in your inventory. 
[[File:Animatecorpsemenu.jpeg]]

It is worth noting that you can only raise corpses with intact heads or grasping body parts (hands). That is, if the creature's head and hands explodes into gore, collapses into gore, or otherwise is pulped via damage to the head or torso, then that corpse cannot be raised. It is still possible, however, to raise a corpse that has had its head completely severed. The arms and head of a single individual can also be raised as different zombies, granted they are separated properly to begin with.

Besides acting as reusable and easily-replenishable soldiers, undead hold potential usage as training dummies for weapons and wrestling skills and can be used to build for you, including animated body parts. A crafty adventurer may cut the limbs off their undead slaves and reanimate them, counting as an additional companion, and reducing build time. However, while a necromancer can still be friendly to mortals, its minions will attack everything living in sight.

For combat, because raised dead lose all their skills as well as the ability to learn, only the attributes and size of the creature at the time of their death are important.

As in fortress mode, necromancer companions and NPCs will automatically raise the dead when in the heat of battle. To counter this in adventure combat, mangle a sentient being using a blunt weapon so they can never be raised, or butcher them once and mangle the raised skin. Butchering doesn’t take time, so it doesn’t hurt to immediately butcher someone you killed.

Alternatively, you can destroy someone’s soul by raising a corpse as a non-intelligent undead. This rewrites their faction and soul traits, and any subsequent resurrection will raise them as a soulless creature loyal to you. This is very useful when you are in mass combat.

Be warned that raising a corpse in front of a lot of people who are already in combat will cause a lag spike.

==[[Object testing arena]]==
Necromancy can be assigned to any creature by simply changing the "effect" of the spawned creature to "necromancer" by pressing {{k|u}}. As expected, necromancers will reanimate dead creatures and severed body parts, though, depending on which team the player has set for the spawned necromancer and that of any creature that died that said necromancer chose to resurrect, strange behaviors can occur.

For example, a necromancer revives the body parts of a dead, dismembered dwarf in an effort to aid itself in fighting, but because the dwarf was on the "independent" team (or just a different one from the necromancer), the body parts just end up attacking the necromancer that raised them. So said necromancer may end up killing what it resurrected, only to keep resurrecting what it just killed to fight it again, which can happen over and over in an endless loop - all due to the clashing of how the arena handles teams/sides and the necromancer's natural AI in raising the dead to help itself.

==Modding==
{{mod}}
It is entirely possible to create your own unique secret class, with powers ranging from material emission (fireballs, firebreath, syndrome-inducing materials) to turning corpses into enthralled creatures, such as giant lions.
This can be accomplished by creating an "interaction_secretnamehere" raw file with the appropriate tokens.

It is also possible to improve the number of necromancers, and therefore towers, by permitting more races to have necromancers. This can be done by adding mortality to races that are not mortal ([[Elf|Elves]] and [[Goblin]]s) with the {{token|MAXAGE}} token, or by adding intelligence to other creature tokens. Even having the ability to pray seems to add yet more original necromancers (that have discovered the secret by worshiping). This could be done by giving religion to races that don't have it, like goblins (see some digging on these subjects here: http://www.bay12forums.com/smf/index.php?topic=161352.0, http://www.bay12forums.com/smf/index.php?topic=154533.0). It also seems that having a DEATH [[Entity_token#RELIGION_SPHERE|sphere]] in the religion of the race vastly improves the ability to discover the secret of life and death.

Example:
Modded goblin race with:
<nowiki>
[RELIGION:PANTHEON]
[RELIGION_SPHERE:DEATH]
</nowiki>
in entity_default and:[MAXAGE:200:250] in creature_standard, will generate a lot of tower-building necromancers.

Doing this for all races with massive population amounts in your world will ensure that towers, and, therefore, undead, are present in large numbers for more [[fun]].

{{gamedata|title=Example raws (as extracted from world.dat in version 0.47.04)|
[INTERACTION:SECRET_11]
[GENERATED]
[I_SOURCE:SECRET]
[IS_NAME:the secrets of life and death]
[IS_SPHERE:DEATH]
[IS_SPHERE:NIGHTMARES]
[IS_SECRET_GOAL:IMMORTALITY]
[IS_SECRET:SUPERNATURAL_LEARNING_POSSIBLE]
[IS_SECRET:MUNDANE_RESEARCH_POSSIBLE]
[IS_SECRET:MUNDANE_TEACHING_POSSIBLE]
[IS_SECRET:MUNDANE_RECORDING_POSSIBLE:objects/text/book_instruction.txt:objects/text/secret_death.txt]
[I_TARGET:A:CREATURE]
[IT_LOCATION:CONTEXT_CREATURE]
[IT_REQUIRES:MORTAL]
[IT_REQUIRES:CAN_LEARN]
[IT_REQUIRES:CAN_SPEAK]
[I_EFFECT:ADD_SYNDROME]
[IE_TARGET:A]
[IE_IMMEDIATE]
[SYNDROME]
[SYN_CONCENTRATION_ADDED:1000:0]
[CE_DISPLAY_TILE:TILE:165:5:0:1:START:0:ABRUPT]
[CE_DISPLAY_NAME:NAME:necromancer:necromancers:necromantic:START:0:ABRUPT]
[CE_ADD_TAG:NOEXERT:NO_AGING:NO_EAT:NO_DRINK:NO_SLEEP:NO_PHYS_ATT_GAIN:NO_PHYS_ATT_RUST:START:0:ABRUPT]
[CE_CHANGE_PERSONALITY:FACET:ANXIETY_PROPENSITY:50:FACET:TRUST:-50:START:0:ABRUPT]
[CE_CAN_DO_INTERACTION:START:0:ABRUPT]
[CDI:ADV_NAME:Animate corpse]
[CDI:INTERACTION:SECRET_ANIMATE_11]
[CDI:TARGET:A:LINE_OF_SIGHT]
[CDI:TARGET_RANGE:A:10]
[CDI:VERB:gesture:gestures:NA]
[CDI:TARGET_VERB:shudder and begin to move:shudders and begins to move]
[CDI:WAIT_PERIOD:10]
[CE_CAN_DO_INTERACTION:START:0:ABRUPT]
[CDI:ADV_NAME:Raise damned butcher]
[CDI:INTERACTION:SECRET_UNDEAD_RES_11]
[CDI:TARGET:A:LINE_OF_SIGHT]
[CDI:TARGET_RANGE:A:10]
[CDI:VERB:gesture:gestures:NA]
[CDI:TARGET_VERB:shudder and begin to move:shudders and begins to move]
[CDI:WAIT_PERIOD:10]
[CE_CAN_DO_INTERACTION:START:0:ABRUPT]
[CDI:ADV_NAME:Summon bogeymen]
[CDI:INTERACTION:SECRET_SUMMON_B_11]
[CDI:VERB:call upon the night:calls upon the night:NA]
[CDI:WAIT_PERIOD:100]
[CE_CAN_DO_INTERACTION:START:0:ABRUPT]
[CDI:ADV_NAME:Summon nightmare]
[CDI:INTERACTION:SECRET_SUMMON_N_11]
[CDI:VERB:call upon the night:calls upon the night:NA]
[CDI:WAIT_PERIOD:12000]
[CE_CAN_DO_INTERACTION:START:0:ABRUPT]
[CDI:ADV_NAME:Create ghoul]
[CDI:INTERACTION:SECRET_GHOUL_11]

[INTERACTION:SECRET_ANIMATE_11]
[GENERATED]
[I_TARGET:A:CORPSE]
[IT_LOCATION:CONTEXT_ITEM]
[IT_AFFECTED_CLASS:GENERAL_POISON]
[IT_REQUIRES:FIT_FOR_ANIMATION]
[IT_FORBIDDEN:NOT_LIVING]
[IT_MANUAL_INPUT:corpses]
[I_EFFECT:ANIMATE]
[IE_TARGET:A]
[IE_IMMEDIATE]
[SYNDROME]
[SYN_CONCENTRATION_ADDED:1000:0]
[CE_FLASH_TILE:TILE:165:3:0:0:FREQUENCY:2000:1000:START:0:ABRUPT]
[CE_PHYS_ATT_CHANGE:STRENGTH:130:0:TOUGHNESS:300:1000:START:0:ABRUPT]
[CE_SPEED_CHANGE:SPEED_PERC:60:START:0:ABRUPT]
[CE_ADD_TAG:NO_AGING:NOT_LIVING:OPPOSED_TO_LIFE:EXTRAVISION:NOEXERT:NOPAIN:NOBREATHE:NOSTUN:NONAUSEA:NO_DIZZINESS:NO_FEVERS:NOEMOTION:PARALYZEIMMUNE:NOFEAR:NO_EAT:NO_DRINK:NO_SLEEP:NO_PHYS_ATT_GAIN:NO_PHYS_ATT_RUST:NOTHOUGHT:NO_THOUGHT_CENTER_FOR_MOVEMENT:NO_CONNECTIONS_FOR_MOVEMENT:START:0:ABRUPT]
[CE_REMOVE_TAG:HAS_BLOOD:TRANCES:MISCHIEVOUS:START:0:ABRUPT]

[INTERACTION:SECRET_UNDEAD_RAISE_11]
[GENERATED]
[I_TARGET:A:CORPSE]
[IT_LOCATION:CONTEXT_ITEM]
[IT_AFFECTED_CLASS:GENERAL_POISON]
[IT_REQUIRES:FIT_FOR_RESURRECTION]
[IT_REQUIRES:CAN_LEARN]
[IT_FORBIDDEN:NOT_LIVING]
[IT_MANUAL_INPUT:corpses]
[IT_CANNOT_HAVE_SYNDROME_CLASS:WERECURSE]
[IT_CANNOT_HAVE_SYNDROME_CLASS:VAMPCURSE]
[IT_CANNOT_HAVE_SYNDROME_CLASS:DISTURBANCE_CURSE]
[IT_CANNOT_HAVE_SYNDROME_CLASS:RAISED_UNDEAD]
[IT_CANNOT_HAVE_SYNDROME_CLASS:RAISED_GHOST]
[IT_CANNOT_HAVE_SYNDROME_CLASS:GHOUL]
[I_EFFECT:RESURRECT]
[IE_TARGET:A]
[IE_IMMEDIATE]
[SYNDROME]
[SYN_CONCENTRATION_ADDED:1000:0]
[SYN_CLASS:RAISED_UNDEAD]
[CE_DISPLAY_TILE:TILE:165:3:0:1:START:0:ABRUPT]
[CE_DISPLAY_NAME:NAME:damned butcher:damned butchers:damned butcher:START:0:ABRUPT]
[CE_PHYS_ATT_CHANGE:STRENGTH:200:1000:TOUGHNESS:200:1000:START:0:ABRUPT]
[CE_ADD_TAG:NO_AGING:NOT_LIVING:STERILE:EXTRAVISION:NOEXERT:NOPAIN:NOBREATHE:NOSTUN:NONAUSEA:NO_DIZZINESS:NO_FEVERS:NOEMOTION:PARALYZEIMMUNE:NOFEAR:NO_EAT:NO_DRINK:NO_SLEEP:NO_PHYS_ATT_GAIN:NO_PHYS_ATT_RUST:NOTHOUGHT:NO_THOUGHT_CENTER_FOR_MOVEMENT:NO_CONNECTIONS_FOR_MOVEMENT:START:0:ABRUPT]
[CE_REMOVE_TAG:HAS_BLOOD:TRANCES:MISCHIEVOUS:START:0:ABRUPT]
[CE_CAN_DO_INTERACTION:START:0:ABRUPT]
[CDI:ADV_NAME:Propel away]
[CDI:INTERACTION:SECRET_RES_POWER_11_1]
[CDI:TARGET:B:LINE_OF_SIGHT]
[CDI:TARGET_RANGE:B:25]
[CDI:BP_REQUIRED:BY_TYPE:GRASP]
[CDI:USAGE_HINT:ATTACK]
[CDI:VERB:make a flicking motion:makes a flicking motion:NA]
[CDI:MAX_TARGET_NUMBER:B:1]
[CDI:WAIT_PERIOD:50]

[INTERACTION:SECRET_RES_POWER_11_1]
[GENERATED]
[I_TARGET:A:LOCATION]
[IT_LOCATION:CONTEXT_LOCATION]
[I_TARGET:B:CREATURE]
[IT_LOCATION:CONTEXT_CREATURE]
[IT_MANUAL_INPUT:target]
[I_EFFECT:PROPEL_UNIT]
[IE_PROPEL_FORCE:100000]
[IE_TARGET:A]
[IE_TARGET:B]
[IE_IMMEDIATE]

[INTERACTION:SECRET_SUMMON_B_11]
[GENERATED]
[I_TARGET:A:LOCATION]
[IT_LOCATION:CONTEXT_LOCATION]
[I_TARGET:B:LOCATION]
[IT_LOCATION:RANDOM_NEARBY_LOCATION:A:5]
[I_EFFECT:SUMMON_UNIT]
[IE_TARGET:B]
[IE_IMMEDIATE]
[IE_CREATURE_CASTE_FLAG:NIGHT_CREATURE_BOGEYMAN]
[IE_TIME_RANGE:200:300]

[INTERACTION:SECRET_SUMMON_N_11]
[GENERATED]
[I_TARGET:A:LOCATION]
[IT_LOCATION:CONTEXT_LOCATION]
[I_TARGET:B:LOCATION]
[IT_LOCATION:RANDOM_NEARBY_LOCATION:A:5]
[I_EFFECT:SUMMON_UNIT]
[IE_TARGET:B]
[IE_IMMEDIATE]
[IE_CREATURE_CASTE_FLAG:NIGHT_CREATURE_NIGHTMARE]
[IE_TIME_RANGE:200:300]

[INTERACTION:SECRET_GHOUL_11]
[GENERATED]
[EXPERIMENT_ONLY]
[I_SOURCE:EXPERIMENT]
[IS_HIST_STRING_1: infected ]
[IS_HIST_STRING_2: with a contagious ghoulish condition]
[IS_TRIGGER_STRING_SECOND:have]
[IS_TRIGGER_STRING_THIRD:has]
[IS_TRIGGER_STRING:been infected with a contagious ghoulish condition]
[I_SOURCE:ATTACK]
[IS_HIST_STRING_1: bit ]
[IS_HIST_STRING_2:, passing on the ghoulish condition]
[I_TARGET:A:CREATURE]
[IT_LOCATION:CONTEXT_CREATURE]
[IT_AFFECTED_CLASS:GENERAL_POISON]
[IT_FORBIDDEN:NOT_LIVING]
[IT_CANNOT_HAVE_SYNDROME_CLASS:WERECURSE]
[IT_CANNOT_HAVE_SYNDROME_CLASS:VAMPCURSE]
[IT_CANNOT_HAVE_SYNDROME_CLASS:DISTURBANCE_CURSE]
[IT_CANNOT_HAVE_SYNDROME_CLASS:RAISED_UNDEAD]
[IT_CANNOT_HAVE_SYNDROME_CLASS:RAISED_GHOST]
[IT_CANNOT_HAVE_SYNDROME_CLASS:GHOUL]
[IT_MANUAL_INPUT:victim]
[I_EFFECT:ADD_SYNDROME]
[IE_TARGET:A]
[SYNDROME]
[SYN_CONCENTRATION_ADDED:1000:0]
[SYN_CLASS:GHOUL]
[CE_FLASH_TILE:TILE:165:4:0:1:FREQUENCY:2000:1000:START:0:ABRUPT]
[CE_DISPLAY_NAME:NAME:diseased ghoul:diseased ghouls:diseased ghoul:START:0:ABRUPT]
[CE_ADD_TAG:NO_AGING:NOT_LIVING:OPPOSED_TO_LIFE:EXTRAVISION:NOEXERT:NOPAIN:NOBREATHE:NOSTUN:NONAUSEA:NO_DIZZINESS:NO_FEVERS:NOEMOTION:PARALYZEIMMUNE:NOFEAR:NO_EAT:NO_DRINK:NO_SLEEP:NO_PHYS_ATT_GAIN:NO_PHYS_ATT_RUST:NOTHOUGHT:NO_THOUGHT_CENTER_FOR_MOVEMENT:NO_CONNECTIONS_FOR_MOVEMENT:START:0:ABRUPT]
[CE_REMOVE_TAG:TRANCES:MISCHIEVOUS:START:0:ABRUPT]
[CE_SPECIAL_ATTACK_INTERACTION:INTERACTION:SECRET_GHOUL_11:BP:BY_CATEGORY:MOUTH:BP:BY_CATEGORY:TOOTH:START:0:ABRUPT]

}}
{{Creatures}}
{{category|humanoids}}

[[ru:Necromancer]]

Pressure

2023-01-07T20:07:58Z

Kelvie: Added a possible clarification point on pressure / falling water. From chatting on discord, others don't expect water to work like this but this is what I observed (in v50)

{{migrated article}}
{{Quality|Unrated}}
{{av}}

{{Material properties}}
''Dwarf Fortress'' features some pretty complex behavior in an attempt to simulate '''fluid mechanics'''. One aspect of this behavior is seen in the form of '''pressure'''. The basic idea here is quite simple - certain forms of '''fluids''' movement exert '''pressure''', causing them to potentially move ''upwards'' into other areas.

==Summary==
In ''Dwarf Fortress'', contrary to what many people may believe, pressure is '''not''' a property of a body of liquid. It's simply one of three rules by which liquids can be moved - the others are simple ''gravity'' (when the tile beneath contains less than 7/7 of liquid and it simply falls downward) and ''diffusion'' (when the liquid levels of two adjacent tiles are averaged, possibly pushing items around).

The following types of liquid movement follow the rules of pressure:
* [[Water]] falling downward into ''more'' water
* [[River]]/brook source tiles (whether the map edge or the "delta" where the river itself begins) generating water
** [[Lake]]s (surface or subterranean), [[ocean]]s, and the [[magma sea]] refilling from the map edge do '''not''' exhibit pressure
* [[Screw pump]]s moving water '''or''' magma

When a liquid is moved (or created) with pressure, it attempts to locate the nearest tile on the same Z-level as its destination tile (for falling water, this is 1 Z-level ''beneath'' its original location) by moving north, south, east, west, down, or up. As it tries to locate an appropriate destination, the liquid will first only try to move sideways and downward - only when this fails will it attempt to move upward. Pressure will not propagate through diagonal gaps.

'''Speculation''', from a simple test, it appears that water falling on an open tile can still spill up z-levels if it is not dispersing fast enough, *before* having filled up the entire z-level. The solution to this is to pump the water ingress tile directly.

==A demonstration of pressure using U-Bends==
A U-Bend is a channel that digs down, and curves back up. With '''pressure''' a fluid will be pushed up the other side of the u-bend. By understanding how pressure works in a u-bend you should be able to adapt this knowledge to use fluids in any configuration you desire without any unexpected surprises that could make life in your fortress more '''[[fun]]''' than anticipated. '''[[Water]]''' and '''[[magma]]''' behave very differently with regards to pressure, so read carefully.

===Water in a U-Bend===
The key to understanding how high a z-level water will reach is to understand which tile(s) pressure is being ''exerted on''. Pressure will cause the water level to go ''as high as'' the tile upon which pressure is being exerted, but ''no higher''.

The following three diagrams demonstrate different ways water might behave in a u-bend. In all three cases, the water source is on the left side of the diagram and water is filling the larger area to the right.
{| class="wikitable" style="margin-left: auto; margin-right: auto; border: none;"
! Diagram A !! Diagram B !! Diagram C
|-
| {{diagram|spaces=yes|\
▓[#00F]≈[#00F]≈[#00F]≈[#00F]≈[#00F][#080]≈▓ ▓
▓▓▓▓▓[#00F][#800]≈▓[#00F]≈[#00F]≈[#00F]≈▓
▓[#00F]≈▓[#00F]≈[#00F]≈[#00F]≈▓
▓[#00F]≈[#00F]≈[#00F]≈[#00F]≈[#00F]≈▓
▓▓▓▓▓▓▓}}
| {{diagram|spaces=yes|\
▓[#00F][#800]≈[#00F][#800]≈[#00F][#800]≈[#00F][#800]≈[#00F][#800]≈▓[#00F]≈[#00F]≈[#00F]≈▓
▓▓▓▓▓[#00F]≈▓[#00F]≈[#00F]≈[#00F]≈▓
▓[#00F]≈▓[#00F]≈[#00F]≈[#00F]≈▓
▓[#00F]≈[#00F]≈[#00F]≈[#00F]≈[#00F]≈▓
▓▓▓▓▓▓▓}}
| {{diagram|spaces=yes|\
▓ ÷÷[#00F][#800]≈▓[#00F]≈[#00F]≈[#00F]≈▓
▓[#00F]≈[#00F]≈[#00F]≈[#00F][#080]≈▓▓[#00F]≈▓[#00F]≈[#00F]≈[#00F]≈▓
▓▓▓▓▓▓▓[#00F]≈▓[#00F]≈[#00F]≈[#00F]≈▓
▓[#00F]≈[#00F]≈[#00F]≈[#00F]≈[#00F]≈▓
▓▓▓▓▓▓▓}}
|- align="center"
| Undammed River || Dammed River || Screw Pump
|- align="center"
| colspan="3" | ''(All diagrams are side views, and cover 4 z-levels of water, plus a "bottom" z-level of stone/soil.)''
|}
 
In the first example ('''Diagram A'''), we have water taken directly from a (flat) river used to fill a u-bend. In this case, the river is free to flow off the edge of the map, so the only pressure comes from the water tile on the top of the u-bend's left side (highlighted in green) falling downward (into the tile highlighted in red), so the water on the right side stops one level below the river itself, because even though the ''source'' tile is at river level, the ''destination'' tile (in red), whose height the water will reach because of pressure, is one z-level ''below'' the source tile.

In the next example ('''Diagram B'''), a '''dam''' (''not shown'') has been placed, which now prevents the river from flowing off the edge of the map. In this case, since it no longer has a "preferred" area to flow into, the pressure exerted by the river source (highlighted in red) allows the water to fill up the remaining level of the u-bend. Use caution when placing a dam on your river.
* Note that this situation also applies '''on a map where the river is running into the sea'''. Rivers running into the sea are obviously not free to flow off the edge of the map, as the sea itself actually "dams" them.

The final example ('''Diagram C'''), demonstrates how a '''[[screw pump]]''' exerts pressure - in this case, the water fills up to the same level as the pump's output tile (highlighted in red).

With these three simple examples, you should be ready to go build your enormous plumbing masterpiece, and be relatively safe from any unanticipated flooding. If you plan to work with [[magma]] as well, however, you should read further.

===Magma in a U-bend===
'''[[Magma]]''' does not exert pressure when ''it falls downward''. In our first magma example (Diagram A) we show how this works by creating a short u-bend and connecting it up to a magma pipe - it simply fills the lowest point and makes no further attempt to go back up.

In the second diagram (Diagram B) we see how with the addition of a single [[screw pump]], the entire situation changes dramatically - when the screw pump moves magma to the right side, it does so using the rules of pressure and allows the area to fill up to the level of the pump. Accidentally flooding your fortress with [[magma]] is considerably more [[fun]] than a flood of [[water]].

{|
! Diagram A !! Diagram B
|- align="center"
| Magma Pipe (side view) || Screw Pump (side view)
|-
| {{diagram|spaces=yes|\
▓[#F00]≈[#F00]≈[#F00]≈▓ ▓
▓[#F00]≈[#F00]≈[#F00]≈▓ ▓
▓[#F00]≈[#F00]≈[#F00]≈▓ ▓
▓[#F00]≈[#F00]≈[#F00]≈[#F00]≈[#F00]≈[#F00]≈[#F00]≈▓
▓[#F00]≈[#F00]≈[#F00]≈▓▓▓▓▓}}
| {{diagram|spaces=yes|\
÷÷[#F00]≈▓[#F00]≈[#F00]≈[#F00]≈▓
▓[#F00]≈[#F00]≈[#F00]≈▓▓[#F00]≈▓[#F00]≈[#F00]≈[#F00]≈▓
▓[#F00]≈[#F00]≈[#F00]≈▓▓[#F00]≈▓[#F00]≈[#F00]≈[#F00]≈▓
▓[#F00]≈[#F00]≈[#F00]≈▓▓[#F00]≈[#F00]≈[#F00]≈[#F00]≈[#F00]≈▓
▓[#F00]≈[#F00]≈[#F00]≈▓▓▓▓▓▓▓▓}}
|}

==Advanced Pressure==
=== Lazy model ===
Pressure is a lazy model, but will ''always'' behave like above. For example, a system on z0 receives water from a cistern z3 in amounts of ~3/tick. This system consists of a tree of passages, one tile wide, and contains 'underpasses' on z-1. Water will flow into the system to a depth of 7 before coming up on the other side of a the first underpass, as is expected. However, if faced with ''two'' underpasses, it will choose the nearest one and fill all the system on the other side of that underpass to a depth of 7 before filling the system on the other side of the far underpass. Similarly, if faced with multiple exits from the system, the whole flow will flow out of ''one'' exit, the nearest lowest one.{{verify}}

===Waterfalls===
Waterfalls are of special concern. When drawing water from a waterfall it is important to understand that, since the water is falling '''on top of''' the river's surface, the pressure exerted when it falls down into the river will permit it to pass through U-bends that would normally not be filled when using a flat undammed river - if you tap into a river below a waterfall just as you would above it, you could very easily flood your fortress.

==Neutralizing pressure==
There are three methods for neutralizing fluid pressure: diagonal connections, screw pumps, and active control systems. Knowing how to manipulate pressure as needed allows you to quickly move fluids wherever you wish in your fortress allowing you to build things a dwarf can be proud of. Note that [[fortification]]s do ''not'' neutralize pressure.

===Diagonal flow===
Liquids moving via pressure can only move to [[orthogonal]]ly adjacent tiles. When faced with a diagonal gap, pressure will fail to move the liquid, forcing the liquid to instead spread out. By forcing fluids through a diagonal connection you can prevent pressure from propagating past a certain point.

This does not work on a vertical basis - water only travels straight up and down to different Z-levels, never diagonally.

If you wish to maintain the rate of '''[[flow]]''' after de-pressurizing, it's recommended that you have more diagonals than water tiles - that is, if the source is 3 tiles wide, you may wish 4 or more diagonal passages.

'''Top view'''
<diagram fg="000" bg="c0c0c0">
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
[#1:1]>>>>>[#] ▒ [#1:1]>[#] [#1:1]>[#] [#1:1]>[#]
4Z Pressure ▒ 1Z Pressure
[#1:1]>>>>>[#] ▒ [#1:1]>[#] [#1:1]>[#] [#1:1]>[#]
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
</diagram>

'''Side view'''
<diagram fg="000" bg="c0c0c0">
▒[#1:1]≈≈≈[#]▒
▒[#1:1]≈≈≈[#]▒
▒[#1:1]≈≈≈[#]▒▒▒▒▒▒▒▒▒▒▒▒▒▒ ▒
▒[#1:1]≈≈≈≈≈≈≈≈RRR≈≈≈≈≈≈≈[#]▒ RRR = Pressure regulator design as seen in top view
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
</diagram>

===Pumps===
Since water pressure does not propagate through pumps, it is possible to fill a pool from a "pressurized" source using a screw pump without it overflowing. Of course, there is a downside - you still have to run the pumps and due to the source water's pressure, the pump must be [[power]]ed instead of [[pump operator|run by a dwarf]], as the tile the dwarf needs to stand on is filled by water. Furthermore, the pump will likely need to be powered from above or below (as water would simply flow around a gear or axle placed next to the pump), though creative setups are still possible by using additional screw pumps to transmit power.

Your vertical axles or gear assemblies need to be placed above the solid tile of the pump, and there must not be a channel over the walkable pump tile. (Water can only flow straight upward, not up and to the side at the same time.) Multiple adjacent pumps will also transfer '''power''' between themselves automatically.

Side view
<diagram fg="000" bg="c0c0c0">
Power Water
[#4:1]↓[#] [#1:1]↓↓↓↓[#]
▒▒▒▒▒▒[#4:1]║[#]▒▒▒[@1:1]▒[@][#1:1]≈≈≈≈[#]
▒▒▒▒▒▒[#4:1]║[#]▒▒▒▒[@1:1]▒[@][#1:1]≈≈≈[#]
.....▒[#4:1]║[#][@1:1]▒▒▒▒▒▒[@][#1:1]≈≈[#]
▒[#00D]≈≈≈≈≈[#4:1]÷[#4:1][@1:1]÷[@][#1:1]≈≈≈≈≈≈≈[#]
▒▒▒▒▒▒▒[@1:1]▒[@][#1:1]≈[#][@1:1]▒▒▒▒▒▒[@]
▒▒▒▒▒▒▒▒[@1:1]▒[@]▒▒▒▒▒▒
</diagram>

Key:
{| class="wikitable"
|-
| 1.
| <diagram fg="000" bg="c0c0c0">▒</diagram>
| Wall
|-
| 2.
| <diagram fg="1:1" bg="c0c0c0">▒</diagram>
| Wall that would flood with pressurized water if dug
|-
| 3.
| <diagram fg="4:1" bg="c0c0c0">÷[@1:1]÷</diagram>
| Pump facing left, with the right tile flooded
|-
| 4.
| <diagram fg="000" bg="c0c0c0">.</diagram>
| Floor
|-
| 5.
| <diagram fg="1:1" bg="c0c0c0">≈</diagram>
| Pressurized water
|-
| 6.
| <diagram fg="1:0" bg="c0c0c0">≈[#]</diagram>
| "Unpressurized" water
|-
| 7.
| <diagram fg="4:1" bg="c0c0c0">║[#]</diagram>
| Axle
|}

Note that the screw pump ''will'' still exert pressure when filling the pool, but said pressure will be independent of the source and can be subsequently blocked by diagonal gaps.

===Advanced systems for fine tuning pressure===

Multiple methods can be used to modify the pressure of fluids to a specific number of Z-levels. One of the simpler examples is using an active control system and mechanical cycling.

An active control system can allow some water flow while preventing pressurized water from overflowing. Such a setup is significantly more complicated than the other two options, but it can produce controlled amounts of water at varying depths and pressures. While there are many different ways to set up a control system, a relatively simple example is shown below:

====Simple example using mechanical cycling====

Side view

<diagram fg="000" bg="c0c0c0">
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒[#1:1]≈≈≈≈≈[#]▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
8Z Pressure ≈ +[#1:1]≈≈≈≈≈[#]+ ≈ 2Z Pressure
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
</diagram>

Two doors ('+') are connected to a control system (such as [[lever]]s or a [[minecart]] loop). The control system is designed to only open one of the doors at a time. When the left door is open, the pressurized water fills a reservoir. When the right door is opened, the reservoir provides reduced pressure and limited flow. The cycling can be controlled manually (by pulling levers), or automated (minecarts, pressure plates, etc.). Throughput is limited by how quickly the doors can be cycled; [[pressure plate]]s normally have a 99 tick refractory period, but clever design can reduce that significantly.

====Advanced examples using constructed pressure regulators====

Side view

<diagram fg="000" bg="c0c0c0">
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
8Z Pressure [#1:1]≈ RRR ≈≈≈≈≈[#]▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ RRR = Pressure regulator design as seen above
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒[#1:1]≈≈≈≈≈[#] ≈ 2Z Pressure
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
</diagram>

In this setup, we can use a diagonal flow pressure regulator to convert our 8Z pressure to 1Z pressure. This will then enter our chamber as 1Z, fall down a single Z and turn into 2Z pressure.

Side view

<diagram fg="000" bg="c0c0c0">
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
8Z Pressure [#1:1]≈ RRR ≈≈≈≈≈[#]▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ RRR = Pressure regulator design as seen above
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒[#1:1]≈≈≈≈≈[#]▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒[#1:1]≈≈≈≈≈[#] ≈ 3Z Pressure
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
</diagram>

Here is another example showing how to expand the concept to a 3Z level output pressure. This setup can be modified to fit any Z level of pressure. It is important to note that the output pressure is at the bottom of the mechanism, and will therefore follow the above rules for water in a U-bend.

Side view

<diagram fg="000" bg="c0c0c0">
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
8Z Pressure [#1:1]≈ RRR ≈≈≈≈≈[#]▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ RRR = Pressure regulator design as seen above
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒[#1:1]≈≈≈≈≈[#]▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒[#1:1]≈≈≈≈≈[#]▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒[#1:1]≈≈≈≈≈[#]▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒[#1:1]≈≈≈≈≈[#]▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒[#1:1]≈≈≈≈≈[#]▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒[#1:1]≈≈≈≈≈[#]▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒[#1:1]≈≈≈≈≈[#]▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒[#1:1]≈≈≈≈≈ ≈[#] 9Z Pressure
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
</diagram>

Here is a example we can see how to generate 9Z level pressure, 1Z greater pressure than our input pressure

Side view

<diagram fg="000" bg="c0c0c0">
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
8Z Pressure [#1:1]≈ ≈≈≈ ≈≈≈≈≈[#]▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ ≈≈≈ = Pressure regulator NOT present
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒[#1:1]≈≈≈≈≈[#]▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒[#1:1]≈≈≈≈≈[#]▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒[#1:1]≈≈≈≈≈[#]▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒[#1:1]≈≈≈≈≈[#]▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒[#1:1]≈≈≈≈≈[#]▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒[#1:1]≈≈≈≈≈[#]▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒[#1:1]≈≈≈≈≈[#]▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒[#1:1]≈≈≈≈≈ ≈[#] 17Z Pressure
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
</diagram>

In this final example, to illustrate the usage of pressure regulators in modifying and obtaining custom pressures, when the regulator is omitted the output pressure will be the sum of both the input pressure, and the drop pressure.

==Hatches==
[[Hatch cover|Hatches]] can be placed over [[channel]]s, [[stair]]s, [[ramp]]s, etc. to prevent [[water]] from moving vertically but will still allow the tile to be used, even as a water source (and possibly still for fishing too). Note that the construction of a hatch over the input tile of a [[Screw pump]] prevents water from being pumped.

==Plumbing schemes==
Using the information above, you can devise a number of ways to get the water where you want it to be. The following schemes provide a starting point for beginners:

===Safe well===

'''Side view'''
<diagram fg="000" bg="c0c0c0">
▒▒▒▒▒▒▒▒X▒[#1:1]≈≈≈[#] <-- potable water source
▒▒▒▒▒▒▒▒X▒
○ ▒▒><▒
▒▒ ▒▒▒▒X▒▒
▒ ▒▒▒X▒▒
▒▒#▒▒▒▒X▒▒
▒▒ X▒▒
▒▒▒▒▒▒▒▒▒▒
</diagram>

<diagram fg="000" bg="c0c0c0">
▒▒▒▒
▒▒<▒ <--up stair (to water source)
▒>▒▒ <--down stair (to reservoir)
▒▒▒▒
</diagram>

Dig the up/down stairs ('X') near a source of good clean water (river, stream), and tunnel to the location below where you want your well. Make sure to add the pressure regulator ('><') at the height of the well by digging another stairway diagonally adjacent to the first. Dig out the reservoir on the left side, channel down into the supply tunnel, and add a floor [[grate]] ('#') directly below the well (this grate keeps enemies from entering your fort via the well). Finally, channel a connection between the water source and your supply tunnel to fill the reservoir, and build your well ('○'). You can also build additional wells directly above the first, as long as you channel a clear path straight down into the reservoir.

===Pillar of pools===

Can be used to provide each level with a pool. A central 'pillar' of water extends all the way down and provides the water.

'''Top floor, top view'''
<diagram fg="000" bg="c0c0c0">
▒▒▒▒▒▒▒
._▒>|[#1:1]≈≈≈[#] <-- water tunnel (e.g. coming from a river or your cistern). | = floodgate
._▒▒▒▒▒
▒▒▒▒▒▒▒
</diagram>

'''Top −1, top view'''
<diagram fg="000" bg="c0c0c0">
▒▒▒▒▒▒▒
▒[#1:1]≈[#]▒X▒_.
▒[#1:1]≈≈[#]▒▒_.
▒▒▒▒▒▒▒
</diagram>

'''Top −2, top view'''
<diagram fg="000" bg="c0c0c0">
▒▒▒▒▒▒▒
._▒X▒[#1:1]≈[#]▒
._▒▒[#1:1]≈≈[#]▒
▒▒▒▒▒▒▒
</diagram>

Obviously, keep the central block (with up/down staircase) aligned on each level. For lower levels simply continue alternating the -1 and -2 layouts.

Don't forget to add a lever and hook it up to the top floodgate so you can shut off the main flow if you're experiencing <s>flooding</s> fun.

You can also add additional floodgates on each level if you like:

'''z-1, top view'''
<diagram fg="000" bg="c0c0c0">
▒▒▒▒▒▒▒
▒[#1:1]≈[#]▒X▒_.
▒[#1:1]≈[#]|▒▒_.
▒▒▒▒▒▒▒
</diagram>

'''z-2, top view'''
<diagram fg="000" bg="c0c0c0">
▒▒▒▒▒▒▒
._▒X▒[#1:1]≈[#]▒
._▒▒|[#1:1]≈[#]▒
▒▒▒▒▒▒▒
</diagram>

== See Also==
* [http://www.bay12forums.com/smf/index.php?topic=32453.0 Hydrodynamics Education] forum thread
* [[Flow]]
* [[River]]

{{Category|Physics}}

Controls guide

2023-01-07T07:52:30Z

Kelvie: Remove shortcut key for nonexistent controls

Controls guide

2023-01-07T05:31:05Z

Kelvie:

Controls guide

2023-01-07T05:30:14Z

Kelvie: Flesh out building shortcut keys.

Controls guide

2023-01-07T05:24:18Z

Kelvie: Minor updates

{{migrated article}}
{{Quality|Unrated}}
{{av}}
This is a beginner's guide to [[fortress mode|Fortress Mode]] interface [[controls]]. This page assumes the default [[key bindings]].

As a beginner it is recommended that you familiarize yourself with the '''(View Unit - Preferences - Labor)''' submenu, the '''Query buildings''' menu, the '''Designate''' menu, and the '''Build''' menu.

==Viewing menus==
[[File:Df-menu-keys.png|thumb|Shortcut keys for the top-level menus]]

The buttons on the bottom-left of the screen all have shortcut keys that allow you to access them.

===Creatures, u===
[[File:Creatures-tab.png|thumb|The creatures tab.]]
The Creat{{key|u}}res command gives detailed information on creatures: a [[dwarf]], an [[creature|animal]], a [[goblin]], etc.
This command has several different tabs:
* Citizens
* Pets/Livestock
* Others
* Dead/Missing

===Tasks, t===
[[File:Tasks-tab.png|thumb|The tasks tab.]]
A list of the tasks that your dwarves are doing, as well as pending tasks. You can jump to the specific dwarves, or go to their information pages from here.

===Places, P===
The {{k|P}}laces command allows you to view various places, with tabs for:
* [[Zone]]s, such as refuse, pastures, clay gathering, [[room]]s, and meeting halls.
**You can also assign a [[room]] to belong to a specific dwarf here.
* Named [[location]]s designated in your fortress (libraries, temples, guildhalls, taverns)
** In this tab you can control the supplies desired for your locations, as well as designate a worker/workers for the location as appropriate.
* [[Stockpile]]s where you can change what types of objects are stored there, how many [[barrel|barrels]] are used, etc.
* [[Workshop]]s where you can change what tasks are being worked on, set a particular task to repeat or be suspended, or change who is allowed to use the workshop.
* [[Farm plot]] you can change what crops are being planted.

===Labor, y===
Here you can assign what dwarves do what type of labor.

===Options & Orders, o===
{{key|o}} Access the [[Standing orders]]

===Nobles & Administrators, n===
{{key|n}} Access the [[Nobles screen]]

===Objects, O===

===Justice, j===

===Burrows, U===
{{k|U}} Opens the [[burrow]]s menu

===Hauling, H===
The {{k|H}}auling command allows you to designate and configure [[minecart]] routes and stops.

===Traffic, T===
The {{k|T}}raffic command allows you to assign high and low [[traffic]] areas so your dwarves can try to avoid certain tiles.

==Order your Dwarves==
These commands affect what your dwarves do.
===Build, b===
Use this command to {{key|b}}uild rooms, place [[furniture]], start [[Farm plot|farm]] plots, and such. In addition to a long list of items which can be scrolled through with the {{k|+}}/{{k|-}} keys, there are also a few sub-menus:
*{{key|w}} '''[[Workshop|Workshops]]'''
*{{k|e}} '''[[Furnace|Furnaces]]'''
*{{key|C}} '''[[Construction]]'''
*{{key|T}} '''[[Trap|Traps]]'''
*{{key|M}} '''[[Machine component|Machine components]]'''
===Designate, d===
{{key|d}} [[Designations]] menu
*{{k|d}} Mine - Mark solid walls to [[mining|mine]]
*{{k|h}} Channel - Mark to solid walls or floors to [[channel]] downwards. This will create a ramp on the Z-level below the miner.
*{{k|z}} Remove Upstairs/Ramps - Mark stairs and ramps to remove them.
*{{k|u}} Upward Stairway - Mark to dig up [[stairs]] into solid wall.
*{{k|j}} Downward Stairway - Mark to dig down stairs into either a solid wall or a floor.
*{{k|i}} Up/Down Stairway - Mark to dig up/down stairs into a solid wall.
*{{k|r}} Upward Ramp - Mark to dig a [[ramp]] into a solid wall
*{{k|t}} Chop Down Trees - Mark trees to be [[wood cutter|cut]]
*{{k|p}} Gather Plants - Mark [[plant|plants]] to be [[herbalist|gathered]]
*{{k|s}} Smooth Stone - Mark walls or floor for an [[engraver]] to smooth. This must be done before you can engrave or carve fortifications.
*{{k|e}} Engrave Stone - Mark smoothed walls or floors to [[engraving|engrave]] art into.
*{{k|a}} Carve Fortifications - Mark smoothed walls to carve [[fortification]]s into.
*{{k|V}} Toggle Engravings - Mark engraved tiles to toggles their display.
*{{k|x}} Remove Designation - Removes any designation that was made with the {{k|d}} menu
*{{k|n}} Remove Constructions - Marks constructions for removal.

===Designate, i===
*{{k|b}} Set Building/Item Properties - Used to mass designate entire areas for the following:
**{{k|c}} Claim Items/Buildings
**{{k|f}} Forbid Items/Buildings
**{{k|m}} Melt
**{{k|M}} Remove Melt
**{{k|d}} Dump
**{{k|D}} Remove Dump
**{{k|h}} Hide Items/Buildings
**{{k|H}} Unhide Items/Buildings

===Zones, z===
{{key|z}} Mark an [[activity zone]] for drinking [[water]], [[fishing]], [[dump]], [[pasture|pen/pasture]], [[Activity zone#Pit/Pond|pit/pond]], [[sand]] collection, [[clay]] collection, [[meeting hall]], [[hospital]], [[animal training]]. This interface is the reverse of designate and stockpile commands: you mark out the rectangular area first, and define what it does afterward.

===Squads, q===
This menu is used to control your military s{{key|q}}uads. You have to select what squads you want to apply what orders to using the checkboxes. The orders are:
* Attack - Selected squad will attack the selected enemies.
* Station - Selected squad will station to a specific location you choose.
* Patrol - Order the entire squad(s) to patrol a specified set of waypoints
* Defend [[burrow]] - Defend a specific burrow
* Train - Order your squad(s) to train immediately
* Cancel orders - Cancels any of the above orders.
* Equip - Opens the equipment screen for the selected squad(s).
* Schedule - Brings up the military scheduling screen.

==Fortress Information==

These commands take you away from the map, to an informational screen. Some of them also let you give orders.

===World map, Y===
====Civilizations====
A list of other civilizations that you have personally encountered (and thus within distance for [[trade]] or [[siege|war]]). Civilizations are marked with a ''P'' if you are at peace with them, or with a ''W'' if you are at war. Pressing {{key|Tab}} lets you check total exports and imports, and standing trade agreements.

===Military===
'''No longer existent in v50'''

{{key|m}} Access the [[military]] screen
* {{key|p}} '''Positions''' Create and remove squads and assign dwarves to them.
* {{key|a}} '''Alerts''' Create configure alerts. Used in conjunction with burrows to define a '''CIV Alert''', a safe place that dwarves will be forced to go when turned on. Can also be used to change the active alert schedule for your squads.
* {{key|e}} '''Equip''' Assign armor and weapons to military squads.
* {{key|n}} '''Uniforms''' Create or modify uniform templates which can be assigned using the Equip screen.
* {{key|u}} '''Supplies''' Controls if a squad carries food and drink.
* {{key|f}} '''Ammunition''' Assigns ammunition to squads.
* {{key|s}} '''Schedule''' Used to modify the [[schedule|orders]] for an alert.

===Fortress Overview, z===
''' No longer existent in v50'''
{{key|z}} This screen is filled with useful information, like your fortress's net worth, and how much food and drink you have left.
* '''Animals''' A list of all tame [[creature|animals]] in your fort.
* '''Kitchen''' From here you can specify what [[food|foods]] can be [[cook|cooked]] or [[brew|brewed]].
* '''Stone''' Controls the use of [[ore|ores]] and [[economic stone|economic stones]]
* '''Stocks''' This is an in-depth listing of every item, down to every rotting rat corpse. The accuracy of the your item count depends on your [[bookkeeper]].
* '''Justice''' Shows the details of the dwarven [[justice]] system, once you have a [[Sheriff]].
* '''Health''' Shows an overview of the health status of the fortress, once you have a [[Chief medical dwarf]].
See [[Status]] for more details.

===Redefining hotkeys===
[[File:Settings-keybindings-tab.png|thumb|Keybindings settings (Esc -> Settings -> Keybindings tab)]]
Hotkeys can be redefined in the Settings menu, under the keybindings tab.

{{Category|Guides}}
{{Category|Interface}}

Controls guide

2023-01-07T05:22:58Z

Kelvie: typo

{{migrated article}}
{{Quality|Unrated}}
{{av}}
This is a beginner's guide to [[fortress mode|Fortress Mode]] interface [[controls]]. This page assumes the default [[key bindings]].

As a beginner it is recommended that you familiarize yourself with the '''(View Unit - Preferences - Labor)''' submenu, the '''Query buildings''' menu, the '''Designate''' menu, and the '''Build''' menu.

==Viewing menus==
[[File:Df-menu-keys.png|thumb|Shortcut keys for the top-level menus]]

The buttons on the bottom-left of the screen all have shortcut keys that allow you to access them.

===Creatures, u===
[[File:Creatures-tab.png|thumb|The creatures tab.]]
The Creat{{key|u}}res command gives detailed information on creatures: a [[dwarf]], an [[creature|animal]], a [[goblin]], etc.
This command has several different tabs:
* Citizens
* Pets/Livestock
* Others
* Dead/Missing

===Tasks, t===
[[File:Tasks-tab.png|thumb|The tasks tab.]]
A list of the tasks that your dwarves are doing, as well as pending tasks. You can jump to the specific dwarves, or go to their information pages from here.

===Places, P===
The {{k|P}}laces command allows you to view various places, with tabs for:
* [[Zone]]s, such as refuse, pastures, clay gathering, [[room]]s, and meeting halls.
**You can also assign a [[room]] to belong to a specific dwarf here.
* Named [[location]]s designated in your fortress (libraries, temples, guildhalls, taverns)
** In this tab you can control the supplies desired for your locations, as well as designate a worker/workers for the location as appropriate.
* [[Stockpile]]s where you can change what types of objects are stored there, how many [[barrel|barrels]] are used, etc.
* [[Workshop]]s where you can change what tasks are being worked on, set a particular task to repeat or be suspended, or change who is allowed to use the workshop.
* [[Farm plot]] you can change what crops are being planted.

===Labor, y===
Here you can assign what dwarves do what type of labor.

===Options & Orders, o===
{{key|o}} Access the [[Standing orders]]

===Nobles & Administrators, n===
{{key|n}} Access the [[Nobles screen]]

===Objects, O===

===Justice, j===

===Burrows, U===
{{k|U}} Opens the [[burrow]]s menu

===Hauling, H===
The {{k|H}}auling command allows you to designate and configure [[minecart]] routes and stops.

===Traffic, T===
The {{k|T}}raffic command allows you to assign high and low traffic areas so your dwarves can try to avoid certain tiles.

==Order your Dwarves==
These commands affect what your dwarves do.
===Build, b===
Use this command to {{key|b}}uild rooms, place [[furniture]], start [[Farm plot|farm]] plots, and such. In addition to a long list of items which can be scrolled through with the {{k|+}}/{{k|-}} keys, there are also a few sub-menus:
*{{key|w}} '''[[Workshop|Workshops]]'''
*{{k|e}} '''[[Furnace|Furnaces]]'''
*{{key|C}} '''[[Construction]]'''
*{{key|T}} '''[[Trap|Traps]]'''
*{{key|M}} '''[[Machine component|Machine components]]'''
===Designate, d===
{{key|d}} [[Designations]] menu
*{{k|d}} Mine - Mark solid walls to [[mining|mine]]
*{{k|h}} Channel - Mark to solid walls or floors to [[channel]] downwards. This will create a ramp on the Z-level below the miner.
*{{k|z}} Remove Upstairs/Ramps - Mark stairs and ramps to remove them.
*{{k|u}} Upward Stairway - Mark to dig up [[stairs]] into solid wall.
*{{k|j}} Downward Stairway - Mark to dig down stairs into either a solid wall or a floor.
*{{k|i}} Up/Down Stairway - Mark to dig up/down stairs into a solid wall.
*{{k|r}} Upward Ramp - Mark to dig a [[ramp]] into a solid wall
*{{k|t}} Chop Down Trees - Mark trees to be [[wood cutter|cut]]
*{{k|p}} Gather Plants - Mark [[plant|plants]] to be [[herbalist|gathered]]
*{{k|s}} Smooth Stone - Mark walls or floor for an [[engraver]] to smooth. This must be done before you can engrave or carve fortifications.
*{{k|e}} Engrave Stone - Mark smoothed walls or floors to [[engraving|engrave]] art into.
*{{k|a}} Carve Fortifications - Mark smoothed walls to carve [[fortification]]s into.
*{{k|V}} Toggle Engravings - Mark engraved tiles to toggles their display.
*{{k|x}} Remove Designation - Removes any designation that was made with the {{k|d}} menu
*{{k|n}} Remove Constructions - Marks constructions for removal.

===Designate, i===
*{{k|b}} Set Building/Item Properties - Used to mass designate entire areas for the following:
**{{k|c}} Claim Items/Buildings
**{{k|f}} Forbid Items/Buildings
**{{k|m}} Melt
**{{k|M}} Remove Melt
**{{k|d}} Dump
**{{k|D}} Remove Dump
**{{k|h}} Hide Items/Buildings
**{{k|H}} Unhide Items/Buildings

===Zones, z===
{{key|z}} Mark an [[activity zone]] for drinking [[water]], [[fishing]], [[dump]], [[pasture|pen/pasture]], [[Activity zone#Pit/Pond|pit/pond]], [[sand]] collection, [[clay]] collection, [[meeting hall]], [[hospital]], [[animal training]]. This interface is the reverse of designate and stockpile commands: you mark out the rectangular area first, and define what it does afterward.

===Squads, q===
This menu is used to control your military squads. You have to select what squads you want to apply what orders to using the checkboxes. The orders are:
* Attack - Selected squad will attack the selected enemies.
* Station - Selected squad will station to a specific location you choose.
* Patrol - Order the entire squad(s) to patrol a specified set of waypoints
* Defend [[burrow]] - Defend a specific burrow
* Train - Order your squad(s) to train immediately
* Cancel orders - Cancels any of the above orders.
* Equip - Opens the equipment screen for the selected squad(s).
* Schedule - Brings up the military scheduling screen.

==Fortress Information==

These commands take you away from the map, to an informational screen. Some of them also let you give orders.

===World map, Y===
====Civilizations====
A list of other civilizations that you have personally encountered (and thus within distance for [[trade]] or [[siege|war]]). Civilizations are marked with a ''P'' if you are at peace with them, or with a ''W'' if you are at war. Pressing {{key|Tab}} lets you check total exports and imports, and standing trade agreements.

===Military===
'''No longer existent in v50'''

{{key|m}} Access the [[military]] screen
* {{key|p}} '''Positions''' Create and remove squads and assign dwarves to them.
* {{key|a}} '''Alerts''' Create configure alerts. Used in conjunction with burrows to define a '''CIV Alert''', a safe place that dwarves will be forced to go when turned on. Can also be used to change the active alert schedule for your squads.
* {{key|e}} '''Equip''' Assign armor and weapons to military squads.
* {{key|n}} '''Uniforms''' Create or modify uniform templates which can be assigned using the Equip screen.
* {{key|u}} '''Supplies''' Controls if a squad carries food and drink.
* {{key|f}} '''Ammunition''' Assigns ammunition to squads.
* {{key|s}} '''Schedule''' Used to modify the [[schedule|orders]] for an alert.

===Fortress Overview, z===
''' No longer existent in v50'''
{{key|z}} This screen is filled with useful information, like your fortress's net worth, and how much food and drink you have left.
* '''Animals''' A list of all tame [[creature|animals]] in your fort.
* '''Kitchen''' From here you can specify what [[food|foods]] can be [[cook|cooked]] or [[brew|brewed]].
* '''Stone''' Controls the use of [[ore|ores]] and [[economic stone|economic stones]]
* '''Stocks''' This is an in-depth listing of every item, down to every rotting rat corpse. The accuracy of the your item count depends on your [[bookkeeper]].
* '''Justice''' Shows the details of the dwarven [[justice]] system, once you have a [[Sheriff]].
* '''Health''' Shows an overview of the health status of the fortress, once you have a [[Chief medical dwarf]].
See [[Status]] for more details.

===Redefining hotkeys===
[[File:Settings-keybindings-tab.png|thumb|Keybindings settings (Esc -> Settings -> Keybindings tab)]]
Hotkeys can be redefined in the Settings menu, under the keybindings tab.

{{Category|Guides}}
{{Category|Interface}}

Controls guide

2023-01-07T05:22:40Z

Kelvie: Add a creatures tab screenshot

{{migrated article}}
{{Quality|Unrated}}
{{av}}
This is a beginner's guide to [[fortress mode|Fortress Mode]] interface [[controls]]. This page assumes the default [[key bindings]].

As a beginner it is recommended that you familiarize yourself with the '''(View Unit - Preferences - Labor)''' submenu, the '''Query buildings''' menu, the '''Designate''' menu, and the '''Build''' menu.

==Viewing menus==
[[File:Df-menu-keys.png|thumb|Shortcut keys for the top-level menus]]

The buttons on the bottom-left of the screen all have shortcut keys that allow you to access them.

===Creatures, u===
[[File:Creatures-tab.png|thumb|The creatures tab.]]
The Creat{{key|u}}res command gives detailed information on creatures: a [[dwarf]], an [[creature|animal]], a [[goblin]], etc.
This command has several different tabs:
* Citizens
* Pets/Livestock
* Others
* Dead/Missing

===Tasks, t===
[[File:Tasks-tab.png|thumb|The tasks tab.]]
A list of the tasks that your dwarves are doing, as well as pending tasks. You can jump to the specific dwarves, or go to their information pages from here.

===Places, P===
The {{k|P}}laces command allows you to view various places, with tabs for:
* [[Zone]]s, such as refuse, pastures, clay gathering, [[room]]s, and meeting halls.
**You can also assign a [[room]] to belong to a specific dwarf here.
* Named [[location]]s designated in your fortress (libraries, temples, guildhalls, taverns)
** In this tab you can control the supplies desired for your locations, as well as designate a worker/workers for the location as appropriate.
* [[Stockpile]]s where you can change what types of objects are stored there, how many [[barrel|barrels]] are used, etc.
* [[Workshop]]s where you can change what tasks are being worked on, set a particular task to repeat or be suspended, or change who is allowed to use the workshop.
* [[Farm plot]] you can change what crops are being planted.

===Labor, y===
Here you can assign what dwarves do what type of labor.

===Options & Orders, o===
{{key|o}} Access the [[Standing orders]]

===Nobles & Administrators, n===
{{key|n}} Access the [[Nobles screen]]

===Objects, O===

===Justice, j===

===Burrows, U===
{{k|U}} Opens the [[burrow]]s menu

===Hauling, H===
The {{k|H}}auling command allows you to designate and configure [[minecart]] routes and stops.

===Traffic, T===
The {{h|T}}raffic command allows you to assign high and low traffic areas so your dwarves can try to avoid certain tiles.

==Order your Dwarves==
These commands affect what your dwarves do.
===Build, b===
Use this command to {{key|b}}uild rooms, place [[furniture]], start [[Farm plot|farm]] plots, and such. In addition to a long list of items which can be scrolled through with the {{k|+}}/{{k|-}} keys, there are also a few sub-menus:
*{{key|w}} '''[[Workshop|Workshops]]'''
*{{k|e}} '''[[Furnace|Furnaces]]'''
*{{key|C}} '''[[Construction]]'''
*{{key|T}} '''[[Trap|Traps]]'''
*{{key|M}} '''[[Machine component|Machine components]]'''
===Designate, d===
{{key|d}} [[Designations]] menu
*{{k|d}} Mine - Mark solid walls to [[mining|mine]]
*{{k|h}} Channel - Mark to solid walls or floors to [[channel]] downwards. This will create a ramp on the Z-level below the miner.
*{{k|z}} Remove Upstairs/Ramps - Mark stairs and ramps to remove them.
*{{k|u}} Upward Stairway - Mark to dig up [[stairs]] into solid wall.
*{{k|j}} Downward Stairway - Mark to dig down stairs into either a solid wall or a floor.
*{{k|i}} Up/Down Stairway - Mark to dig up/down stairs into a solid wall.
*{{k|r}} Upward Ramp - Mark to dig a [[ramp]] into a solid wall
*{{k|t}} Chop Down Trees - Mark trees to be [[wood cutter|cut]]
*{{k|p}} Gather Plants - Mark [[plant|plants]] to be [[herbalist|gathered]]
*{{k|s}} Smooth Stone - Mark walls or floor for an [[engraver]] to smooth. This must be done before you can engrave or carve fortifications.
*{{k|e}} Engrave Stone - Mark smoothed walls or floors to [[engraving|engrave]] art into.
*{{k|a}} Carve Fortifications - Mark smoothed walls to carve [[fortification]]s into.
*{{k|V}} Toggle Engravings - Mark engraved tiles to toggles their display.
*{{k|x}} Remove Designation - Removes any designation that was made with the {{k|d}} menu
*{{k|n}} Remove Constructions - Marks constructions for removal.

===Designate, i===
*{{k|b}} Set Building/Item Properties - Used to mass designate entire areas for the following:
**{{k|c}} Claim Items/Buildings
**{{k|f}} Forbid Items/Buildings
**{{k|m}} Melt
**{{k|M}} Remove Melt
**{{k|d}} Dump
**{{k|D}} Remove Dump
**{{k|h}} Hide Items/Buildings
**{{k|H}} Unhide Items/Buildings

===Zones, z===
{{key|z}} Mark an [[activity zone]] for drinking [[water]], [[fishing]], [[dump]], [[pasture|pen/pasture]], [[Activity zone#Pit/Pond|pit/pond]], [[sand]] collection, [[clay]] collection, [[meeting hall]], [[hospital]], [[animal training]]. This interface is the reverse of designate and stockpile commands: you mark out the rectangular area first, and define what it does afterward.

===Squads, q===
This menu is used to control your military squads. You have to select what squads you want to apply what orders to using the checkboxes. The orders are:
* Attack - Selected squad will attack the selected enemies.
* Station - Selected squad will station to a specific location you choose.
* Patrol - Order the entire squad(s) to patrol a specified set of waypoints
* Defend [[burrow]] - Defend a specific burrow
* Train - Order your squad(s) to train immediately
* Cancel orders - Cancels any of the above orders.
* Equip - Opens the equipment screen for the selected squad(s).
* Schedule - Brings up the military scheduling screen.

==Fortress Information==

These commands take you away from the map, to an informational screen. Some of them also let you give orders.

===World map, Y===
====Civilizations====
A list of other civilizations that you have personally encountered (and thus within distance for [[trade]] or [[siege|war]]). Civilizations are marked with a ''P'' if you are at peace with them, or with a ''W'' if you are at war. Pressing {{key|Tab}} lets you check total exports and imports, and standing trade agreements.

===Military===
'''No longer existent in v50'''

{{key|m}} Access the [[military]] screen
* {{key|p}} '''Positions''' Create and remove squads and assign dwarves to them.
* {{key|a}} '''Alerts''' Create configure alerts. Used in conjunction with burrows to define a '''CIV Alert''', a safe place that dwarves will be forced to go when turned on. Can also be used to change the active alert schedule for your squads.
* {{key|e}} '''Equip''' Assign armor and weapons to military squads.
* {{key|n}} '''Uniforms''' Create or modify uniform templates which can be assigned using the Equip screen.
* {{key|u}} '''Supplies''' Controls if a squad carries food and drink.
* {{key|f}} '''Ammunition''' Assigns ammunition to squads.
* {{key|s}} '''Schedule''' Used to modify the [[schedule|orders]] for an alert.

===Fortress Overview, z===
''' No longer existent in v50'''
{{key|z}} This screen is filled with useful information, like your fortress's net worth, and how much food and drink you have left.
* '''Animals''' A list of all tame [[creature|animals]] in your fort.
* '''Kitchen''' From here you can specify what [[food|foods]] can be [[cook|cooked]] or [[brew|brewed]].
* '''Stone''' Controls the use of [[ore|ores]] and [[economic stone|economic stones]]
* '''Stocks''' This is an in-depth listing of every item, down to every rotting rat corpse. The accuracy of the your item count depends on your [[bookkeeper]].
* '''Justice''' Shows the details of the dwarven [[justice]] system, once you have a [[Sheriff]].
* '''Health''' Shows an overview of the health status of the fortress, once you have a [[Chief medical dwarf]].
See [[Status]] for more details.

===Redefining hotkeys===
[[File:Settings-keybindings-tab.png|thumb|Keybindings settings (Esc -> Settings -> Keybindings tab)]]
Hotkeys can be redefined in the Settings menu, under the keybindings tab.

{{Category|Guides}}
{{Category|Interface}}

File:Creatures-tab.png

2023-01-07T05:14:49Z

Kelvie:

The creatures tab.

Controls guide

2023-01-07T05:13:21Z

Kelvie: Update for v50. I think I got most of it.

{{migrated article}}
{{Quality|Unrated}}
{{av}}
This is a beginner's guide to [[fortress mode|Fortress Mode]] interface [[controls]]. This page assumes the default [[key bindings]].

As a beginner it is recommended that you familiarize yourself with the '''(View Unit - Preferences - Labor)''' submenu, the '''Query buildings''' menu, the '''Designate''' menu, and the '''Build''' menu.

==Viewing menus==
[[File:Df-menu-keys.png|thumb|Shortcut keys for the top-level menus]]

The buttons on the bottom-left of the screen all have shortcut keys that allow you to access them.

===Creatures, u===
The Creat{{key|u}}res command gives detailed information on creatures: a [[dwarf]], an [[creature|animal]], a [[goblin]], etc.
This command has several different tabs:
* Citizens
* Pets/Livestock
* Others
* Dead/Missing

===Tasks, t===
[[File:Tasks-tab.png|thumb|The tasks tab.]]
A list of the tasks that your dwarves are doing, as well as pending tasks. You can jump to the specific dwarves, or go to their information pages from here.

===Places, P===
The {{k|P}}laces command allows you to view various places, with tabs for:
* [[Zone]]s, such as refuse, pastures, clay gathering, [[room]]s, and meeting halls.
**You can also assign a [[room]] to belong to a specific dwarf here.
* Named [[location]]s designated in your fortress (libraries, temples, guildhalls, taverns)
** In this tab you can control the supplies desired for your locations, as well as designate a worker/workers for the location as appropriate.
* [[Stockpile]]s where you can change what types of objects are stored there, how many [[barrel|barrels]] are used, etc.
* [[Workshop]]s where you can change what tasks are being worked on, set a particular task to repeat or be suspended, or change who is allowed to use the workshop.
* [[Farm plot]] you can change what crops are being planted.

===Labor, y===
Here you can assign what dwarves do what type of labor.

===Options & Orders, o===
{{key|o}} Access the [[Standing orders]]

===Nobles & Administrators, n===
{{key|n}} Access the [[Nobles screen]]

===Objects, O===

===Justice, j===

===Burrows, U===
{{k|U}} Opens the [[burrow]]s menu

===Hauling, H===
The {{k|H}}auling command allows you to designate and configure [[minecart]] routes and stops.

===Traffic, T===
The {{h|T}}raffic command allows you to assign high and low traffic areas so your dwarves can try to avoid certain tiles.

==Order your Dwarves==
These commands affect what your dwarves do.
===Build, b===
Use this command to {{key|b}}uild rooms, place [[furniture]], start [[Farm plot|farm]] plots, and such. In addition to a long list of items which can be scrolled through with the {{k|+}}/{{k|-}} keys, there are also a few sub-menus:
*{{key|w}} '''[[Workshop|Workshops]]'''
*{{k|e}} '''[[Furnace|Furnaces]]'''
*{{key|C}} '''[[Construction]]'''
*{{key|T}} '''[[Trap|Traps]]'''
*{{key|M}} '''[[Machine component|Machine components]]'''
===Designate, d===
{{key|d}} [[Designations]] menu
*{{k|d}} Mine - Mark solid walls to [[mining|mine]]
*{{k|h}} Channel - Mark to solid walls or floors to [[channel]] downwards. This will create a ramp on the Z-level below the miner.
*{{k|z}} Remove Upstairs/Ramps - Mark stairs and ramps to remove them.
*{{k|u}} Upward Stairway - Mark to dig up [[stairs]] into solid wall.
*{{k|j}} Downward Stairway - Mark to dig down stairs into either a solid wall or a floor.
*{{k|i}} Up/Down Stairway - Mark to dig up/down stairs into a solid wall.
*{{k|r}} Upward Ramp - Mark to dig a [[ramp]] into a solid wall
*{{k|t}} Chop Down Trees - Mark trees to be [[wood cutter|cut]]
*{{k|p}} Gather Plants - Mark [[plant|plants]] to be [[herbalist|gathered]]
*{{k|s}} Smooth Stone - Mark walls or floor for an [[engraver]] to smooth. This must be done before you can engrave or carve fortifications.
*{{k|e}} Engrave Stone - Mark smoothed walls or floors to [[engraving|engrave]] art into.
*{{k|a}} Carve Fortifications - Mark smoothed walls to carve [[fortification]]s into.
*{{k|V}} Toggle Engravings - Mark engraved tiles to toggles their display.
*{{k|x}} Remove Designation - Removes any designation that was made with the {{k|d}} menu
*{{k|n}} Remove Constructions - Marks constructions for removal.

===Designate, i===
*{{k|b}} Set Building/Item Properties - Used to mass designate entire areas for the following:
**{{k|c}} Claim Items/Buildings
**{{k|f}} Forbid Items/Buildings
**{{k|m}} Melt
**{{k|M}} Remove Melt
**{{k|d}} Dump
**{{k|D}} Remove Dump
**{{k|h}} Hide Items/Buildings
**{{k|H}} Unhide Items/Buildings

===Zones, z===
{{key|z}} Mark an [[activity zone]] for drinking [[water]], [[fishing]], [[dump]], [[pasture|pen/pasture]], [[Activity zone#Pit/Pond|pit/pond]], [[sand]] collection, [[clay]] collection, [[meeting hall]], [[hospital]], [[animal training]]. This interface is the reverse of designate and stockpile commands: you mark out the rectangular area first, and define what it does afterward.

===Squads, q===
This menu is used to control your military squads. You have to select what squads you want to apply what orders to using the checkboxes. The orders are:
* Attack - Selected squad will attack the selected enemies.
* Station - Selected squad will station to a specific location you choose.
* Patrol - Order the entire squad(s) to patrol a specified set of waypoints
* Defend [[burrow]] - Defend a specific burrow
* Train - Order your squad(s) to train immediately
* Cancel orders - Cancels any of the above orders.
* Equip - Opens the equipment screen for the selected squad(s).
* Schedule - Brings up the military scheduling screen.

==Fortress Information==

These commands take you away from the map, to an informational screen. Some of them also let you give orders.

===World map, Y===
====Civilizations====
A list of other civilizations that you have personally encountered (and thus within distance for [[trade]] or [[siege|war]]). Civilizations are marked with a ''P'' if you are at peace with them, or with a ''W'' if you are at war. Pressing {{key|Tab}} lets you check total exports and imports, and standing trade agreements.

===Military===
'''No longer existent in v50'''

{{key|m}} Access the [[military]] screen
* {{key|p}} '''Positions''' Create and remove squads and assign dwarves to them.
* {{key|a}} '''Alerts''' Create configure alerts. Used in conjunction with burrows to define a '''CIV Alert''', a safe place that dwarves will be forced to go when turned on. Can also be used to change the active alert schedule for your squads.
* {{key|e}} '''Equip''' Assign armor and weapons to military squads.
* {{key|n}} '''Uniforms''' Create or modify uniform templates which can be assigned using the Equip screen.
* {{key|u}} '''Supplies''' Controls if a squad carries food and drink.
* {{key|f}} '''Ammunition''' Assigns ammunition to squads.
* {{key|s}} '''Schedule''' Used to modify the [[schedule|orders]] for an alert.

===Fortress Overview, z===
''' No longer existent in v50'''
{{key|z}} This screen is filled with useful information, like your fortress's net worth, and how much food and drink you have left.
* '''Animals''' A list of all tame [[creature|animals]] in your fort.
* '''Kitchen''' From here you can specify what [[food|foods]] can be [[cook|cooked]] or [[brew|brewed]].
* '''Stone''' Controls the use of [[ore|ores]] and [[economic stone|economic stones]]
* '''Stocks''' This is an in-depth listing of every item, down to every rotting rat corpse. The accuracy of the your item count depends on your [[bookkeeper]].
* '''Justice''' Shows the details of the dwarven [[justice]] system, once you have a [[Sheriff]].
* '''Health''' Shows an overview of the health status of the fortress, once you have a [[Chief medical dwarf]].
See [[Status]] for more details.

===Redefining hotkeys===
[[File:Settings-keybindings-tab.png|thumb|Keybindings settings (Esc -> Settings -> Keybindings tab)]]
Hotkeys can be redefined in the Settings menu, under the keybindings tab.

{{Category|Guides}}
{{Category|Interface}}

File:Tasks-tab.png

2023-01-07T05:13:01Z

Kelvie:

The tasks tab.

Controls guide

2023-01-07T05:04:25Z

Kelvie: Add a screenshot of the keybindings tab.

{{migrated article}}
{{Quality|Unrated}}
{{av}}
This is a beginner's guide to [[fortress mode|Fortress Mode]] interface [[controls]]. This page assumes the default [[key bindings]].

As a beginner it is recommended that you familiarize yourself with the '''(View Unit - Preferences - Labor)''' submenu, the '''Query buildings''' menu, the '''Designate''' menu, and the '''Build''' menu.

==Viewing menus==
[[File:Df-menu-keys.png|thumb|Shortcut keys for the top-level menus]]

The buttons on the bottom-left of the screen all have shortcut keys that allow you to access them.

===Creatures, u===
The Creat{{key|u}}res command gives detailed information on creatures: a [[dwarf]], an [[creature|animal]], a [[goblin]], etc.
This command has several different tabs:
* Citizens
* Pets/Livestock
* Others
* Dead/Missing

===Tasks, t===

===Places, P===
The {{k|P}}laces command allows you to view various places, with tabs for:
* [[Zone]]s, such as refuse, pastures, clay gathering, [[room]]s, and meeting halls.
**You can also assign a [[room]] to belong to a specific dwarf here.
* Named [[location]]s such as hospitals, taverns, temples, and guild halls
* [[Stockpile]]s where you can change what types of objects are stored there, how many [[barrel|barrels]] are used, etc.
* [[Workshop]]s where you can change what tasks are being worked on, set a particular task to repeat or be suspended, or change who is allowed to use the workshop.
* [[Farm plot]] you can change what crops are being planted.

===Labor, y===
Here you can assign what dwarves do what type of labor.

===Options & Orders, o===
{{key|o}} Access the [[Standing orders]]

===Nobles & Administrators, n===
{{key|n}} Access the [[Nobles screen]]

===Objects, O===

===Justice, j===

===Burrows, U===
{{k|U}} Opens the [[burrow]]s menu

===Hauling, H===
The {{k|H}}auling command allows you to designate and configure [[minecart]] routes and stops.

===Traffic, T===
The {{h|T}}raffic command allows you to assign high and low traffic areas so your dwarves can try to avoid certain tiles.

==Order your Dwarves==
These commands affect what your dwarves do.
===Build, b===
Use this command to {{key|b}}uild rooms, place [[furniture]], start [[Farm plot|farm]] plots, and such. In addition to a long list of items which can be scrolled through with the {{k|+}}/{{k|-}} keys, there are also a few sub-menus:
*{{key|w}} '''[[Workshop|Workshops]]'''
*{{k|e}} '''[[Furnace|Furnaces]]'''
*{{key|C}} '''[[Construction]]'''
*{{key|T}} '''[[Trap|Traps]]'''
*{{key|M}} '''[[Machine component|Machine components]]'''
===Designate, d===
{{key|d}} [[Designations]] menu
*{{k|d}} Mine - Mark solid walls to [[mining|mine]]
*{{k|h}} Channel - Mark to solid walls or floors to [[channel]] downwards. This will create a ramp on the Z-level below the miner.
*{{k|z}} Remove Upstairs/Ramps - Mark stairs and ramps to remove them.
*{{k|u}} Upward Stairway - Mark to dig up [[stairs]] into solid wall.
*{{k|j}} Downward Stairway - Mark to dig down stairs into either a solid wall or a floor.
*{{k|i}} Up/Down Stairway - Mark to dig up/down stairs into a solid wall.
*{{k|r}} Upward Ramp - Mark to dig a [[ramp]] into a solid wall
*{{k|t}} Chop Down Trees - Mark trees to be [[wood cutter|cut]]
*{{k|p}} Gather Plants - Mark [[plant|plants]] to be [[herbalist|gathered]]
*{{k|s}} Smooth Stone - Mark walls or floor for an [[engraver]] to smooth. This must be done before you can engrave or carve fortifications.
*{{k|e}} Engrave Stone - Mark smoothed walls or floors to [[engraving|engrave]] art into.
*{{k|a}} Carve Fortifications - Mark smoothed walls to carve [[fortification]]s into.
*{{k|V}} Toggle Engravings - Mark engraved tiles to toggles their display.
*{{k|x}} Remove Designation - Removes any designation that was made with the {{k|d}} menu
*{{k|n}} Remove Constructions - Marks constructions for removal.

*{{k|b}} Set Building/Item Properties - Used to mass designate entire areas for the following:
**{{k|c}} Claim Items/Buildings
**{{k|f}} Forbid Items/Buildings
**{{k|m}} Melt
**{{k|M}} Remove Melt
**{{k|d}} Dump
**{{k|D}} Remove Dump
**{{k|h}} Hide Items/Buildings
**{{k|H}} Unhide Items/Buildings

*{{k|o}} Set Traffic Areas - Set [[traffic]] areas.

===Stockpile, p===
{{key|p}} Used to create [[stockpile|stockpiles]].
*{{k|a}} Animal
*{{k|u}} Furniture Storage
*{{k|y}} Corpses
*{{k|s}} Stone
*{{k|e}} Gem
*{{k|h}} Cloth
*{{k|z}} Ammo
*{{k|g}} Finished Goods
*{{k|p}} Weapons
*{{k|f}} Food
*{{k|w}} Wood
*{{k|b}} Bar/Block
*{{k|l}} Leather
*{{k|n}} Coins
*{{k|d}} Armor
===Zones, i===
{{key|i}} Mark an [[activity zone]] for drinking [[water]], [[fishing]], [[dump]], [[pasture|pen/pasture]], [[Activity zone#Pit/Pond|pit/pond]], [[sand]] collection, [[clay]] collection, [[meeting hall]], [[hospital]], [[animal training]]. This interface is the reverse of designate and stockpile commands: you mark out the rectangular area first, and define what it does afterward.
===Squads, s===
{{k|s}} This command is used to control your military squads. The options are:
*{{k|k}} Attack - Selected squad will attack the selected enemies.
*{{k|m}} Move - Selected squad will station to a specific location you choose.
*{{k|o}} Cancel orders - Cancels a station or kill order.
*{{k|z}} Center on Squad - Zooms to the commander of the squad.
*{{k|s}} View Schedule - Brings up the military scheduling screen.
*{{k|t}} Sched - Toggles between all available schedules.
*{{k|p}} Select Individuals - Lets you issue orders to individual soldiers instead of the entire squad.

==Fortress Information==

These commands take you away from the map, to an informational screen. Some of them also let you give orders.
===Announcements, a===
{{key|a}} This screen logs the announcements that appear at the bottom of the screen. Use it to see any you missed, or scroll up the early history of your fortress.

===Civilizations, c===
{{key|c}} A list of other civilizations that you have personally encountered (and thus within distance for [[trade]] or [[siege|war]]). Civilizations are marked with a ''P'' if you are at peace with them, or with a ''W'' if you are at war. Pressing {{key|Tab}} lets you check total exports and imports, and standing trade agreements.

===Unit List, u===
{{key|u}} A list of every creature on the map. Dwarves are listed first, then [[tame]] animals, then hostile creatures, then wild animals. Even dead creatures are listed here, so you can track your fallen dwarves.
* {{key|z}} '''Zoom to Creature''' This takes you to [[#View_Units.2C_v|View Creature]] mode, with the cursor centered on the selected creature.
* {{key|v}} '''View Profile'''
* {{key|b}} '''Zoom to Building''' Takes you to the [[building]] associated with the dwarf's current task. For hauling tasks, this is the destination [[stockpile]].
* {{key|m}} '''Manager''' Takes you to the [[Manager#Setting_up_work_orders|job manager]] screen.

===Military, m===
{{key|m}} Access the [[military]] screen
* {{key|p}} '''Positions''' Create and remove squads and assign dwarves to them.
* {{key|a}} '''Alerts''' Create configure alerts. Used in conjunction with burrows to define a '''CIV Alert''', a safe place that dwarves will be forced to go when turned on. Can also be used to change the active alert schedule for your squads.
* {{key|e}} '''Equip''' Assign armor and weapons to military squads.
* {{key|n}} '''Uniforms''' Create or modify uniform templates which can be assigned using the Equip screen.
* {{key|u}} '''Supplies''' Controls if a squad carries food and drink.
* {{key|f}} '''Ammunition''' Assigns ammunition to squads.
* {{key|s}} '''Schedule''' Used to modify the [[schedule|orders]] for an alert.

===Room List, R===
{{key|R}} Lists all [[Room|Rooms]], [[Building|Buildings]], [[Stockpile|Stockpiles]], and even [[Activity zone|Activity zones]] in the fortress. For rooms, it includes the room's quality and the owner's name. It includes quick access to each room's {{k|q}} and {{k|t}} menus.

===Locations and Occupations, l===
{{key|l}} A list of the [[location|locations]] designated in your fortress (libraries, temples, & taverns). In this screen you can control the supplies desired for your locations, as well as designate a worker/workers for the location as appropriate.

===Fortress Overview, z===
''' No longer existent in v50'''
{{key|z}} This screen is filled with useful information, like your fortress's net worth, and how much food and drink you have left.
* '''Animals''' A list of all tame [[creature|animals]] in your fort.
* '''Kitchen''' From here you can specify what [[food|foods]] can be [[cook|cooked]] or [[brew|brewed]].
* '''Stone''' Controls the use of [[ore|ores]] and [[economic stone|economic stones]]
* '''Stocks''' This is an in-depth listing of every item, down to every rotting rat corpse. The accuracy of the your item count depends on your [[bookkeeper]].
* '''Justice''' Shows the details of the dwarven [[justice]] system, once you have a [[Sheriff]].
* '''Health''' Shows an overview of the health status of the fortress, once you have a [[Chief medical dwarf]].
See [[Status]] for more details.

==Miscellaneous==

===Redefining hotkeys===
[[File:Settings-keybindings-tab.png|thumb|Keybindings settings (Esc -> Settings -> Keybindings tab)]]
Hotkeys can be redefined in the Settings menu, under the keybindings tab.

{{Category|Guides}}
{{Category|Interface}}

File:Settings-keybindings-tab.png

2023-01-07T05:04:02Z

Kelvie:

A screenshot of the keybindings tab in settings

Controls guide

2023-01-07T04:53:20Z

Kelvie: Mark old docs

{{migrated article}}
{{Quality|Unrated}}
{{av}}
This is a beginner's guide to [[fortress mode|Fortress Mode]] interface [[controls]]. This page assumes the default [[key bindings]].

As a beginner it is recommended that you familiarize yourself with the '''(View Unit - Preferences - Labor)''' submenu, the '''Query buildings''' menu, the '''Designate''' menu, and the '''Build''' menu.

==Viewing menus==
[[File:Df-menu-keys.png|thumb|Shortcut keys for the top-level menus]]

The buttons on the bottom-left of the screen all have shortcut keys that allow you to access them.

===Creatures, u===
The Creat{{key|u}}res command gives detailed information on creatures: a [[dwarf]], an [[creature|animal]], a [[goblin]], etc.
This command has several different tabs:
* Citizens
* Pets/Livestock
* Others
* Dead/Missing

===Tasks, t===

===Places, P===
The {{k|P}}laces command allows you to view various places, with tabs for:
* [[Zone]]s, such as refuse, pastures, clay gathering, [[room]]s, and meeting halls.
**You can also assign a [[room]] to belong to a specific dwarf here.
* Named [[location]]s such as hospitals, taverns, temples, and guild halls
* [[Stockpile]]s where you can change what types of objects are stored there, how many [[barrel|barrels]] are used, etc.
* [[Workshop]]s where you can change what tasks are being worked on, set a particular task to repeat or be suspended, or change who is allowed to use the workshop.
* [[Farm plot]] you can change what crops are being planted.

===Labor, y===
Here you can assign what dwarves do what type of labor.

===Options & Orders, o===
{{key|o}} Access the [[Standing orders]]

===Nobles & Administrators, n===
{{key|n}} Access the [[Nobles screen]]

===Objects, O===

===Justice, j===

===Burrows, U===
{{k|U}} Opens the [[burrow]]s menu

===Hauling, H===
The {{k|H}}auling command allows you to designate and configure [[minecart]] routes and stops.

===Traffic, T===
The {{h|T}}raffic command allows you to assign high and low traffic areas so your dwarves can try to avoid certain tiles.

==Order your Dwarves==
These commands affect what your dwarves do.
===Build, b===
Use this command to {{key|b}}uild rooms, place [[furniture]], start [[Farm plot|farm]] plots, and such. In addition to a long list of items which can be scrolled through with the {{k|+}}/{{k|-}} keys, there are also a few sub-menus:
*{{key|w}} '''[[Workshop|Workshops]]'''
*{{k|e}} '''[[Furnace|Furnaces]]'''
*{{key|C}} '''[[Construction]]'''
*{{key|T}} '''[[Trap|Traps]]'''
*{{key|M}} '''[[Machine component|Machine components]]'''
===Designate, d===
{{key|d}} [[Designations]] menu
*{{k|d}} Mine - Mark solid walls to [[mining|mine]]
*{{k|h}} Channel - Mark to solid walls or floors to [[channel]] downwards. This will create a ramp on the Z-level below the miner.
*{{k|z}} Remove Upstairs/Ramps - Mark stairs and ramps to remove them.
*{{k|u}} Upward Stairway - Mark to dig up [[stairs]] into solid wall.
*{{k|j}} Downward Stairway - Mark to dig down stairs into either a solid wall or a floor.
*{{k|i}} Up/Down Stairway - Mark to dig up/down stairs into a solid wall.
*{{k|r}} Upward Ramp - Mark to dig a [[ramp]] into a solid wall
*{{k|t}} Chop Down Trees - Mark trees to be [[wood cutter|cut]]
*{{k|p}} Gather Plants - Mark [[plant|plants]] to be [[herbalist|gathered]]
*{{k|s}} Smooth Stone - Mark walls or floor for an [[engraver]] to smooth. This must be done before you can engrave or carve fortifications.
*{{k|e}} Engrave Stone - Mark smoothed walls or floors to [[engraving|engrave]] art into.
*{{k|a}} Carve Fortifications - Mark smoothed walls to carve [[fortification]]s into.
*{{k|V}} Toggle Engravings - Mark engraved tiles to toggles their display.
*{{k|x}} Remove Designation - Removes any designation that was made with the {{k|d}} menu
*{{k|n}} Remove Constructions - Marks constructions for removal.

*{{k|b}} Set Building/Item Properties - Used to mass designate entire areas for the following:
**{{k|c}} Claim Items/Buildings
**{{k|f}} Forbid Items/Buildings
**{{k|m}} Melt
**{{k|M}} Remove Melt
**{{k|d}} Dump
**{{k|D}} Remove Dump
**{{k|h}} Hide Items/Buildings
**{{k|H}} Unhide Items/Buildings

*{{k|o}} Set Traffic Areas - Set [[traffic]] areas.

===Stockpile, p===
{{key|p}} Used to create [[stockpile|stockpiles]].
*{{k|a}} Animal
*{{k|u}} Furniture Storage
*{{k|y}} Corpses
*{{k|s}} Stone
*{{k|e}} Gem
*{{k|h}} Cloth
*{{k|z}} Ammo
*{{k|g}} Finished Goods
*{{k|p}} Weapons
*{{k|f}} Food
*{{k|w}} Wood
*{{k|b}} Bar/Block
*{{k|l}} Leather
*{{k|n}} Coins
*{{k|d}} Armor
===Zones, i===
{{key|i}} Mark an [[activity zone]] for drinking [[water]], [[fishing]], [[dump]], [[pasture|pen/pasture]], [[Activity zone#Pit/Pond|pit/pond]], [[sand]] collection, [[clay]] collection, [[meeting hall]], [[hospital]], [[animal training]]. This interface is the reverse of designate and stockpile commands: you mark out the rectangular area first, and define what it does afterward.
===Squads, s===
{{k|s}} This command is used to control your military squads. The options are:
*{{k|k}} Attack - Selected squad will attack the selected enemies.
*{{k|m}} Move - Selected squad will station to a specific location you choose.
*{{k|o}} Cancel orders - Cancels a station or kill order.
*{{k|z}} Center on Squad - Zooms to the commander of the squad.
*{{k|s}} View Schedule - Brings up the military scheduling screen.
*{{k|t}} Sched - Toggles between all available schedules.
*{{k|p}} Select Individuals - Lets you issue orders to individual soldiers instead of the entire squad.

==Fortress Information==

These commands take you away from the map, to an informational screen. Some of them also let you give orders.
===Announcements, a===
{{key|a}} This screen logs the announcements that appear at the bottom of the screen. Use it to see any you missed, or scroll up the early history of your fortress.

===Civilizations, c===
{{key|c}} A list of other civilizations that you have personally encountered (and thus within distance for [[trade]] or [[siege|war]]). Civilizations are marked with a ''P'' if you are at peace with them, or with a ''W'' if you are at war. Pressing {{key|Tab}} lets you check total exports and imports, and standing trade agreements.

===Unit List, u===
{{key|u}} A list of every creature on the map. Dwarves are listed first, then [[tame]] animals, then hostile creatures, then wild animals. Even dead creatures are listed here, so you can track your fallen dwarves.
* {{key|z}} '''Zoom to Creature''' This takes you to [[#View_Units.2C_v|View Creature]] mode, with the cursor centered on the selected creature.
* {{key|v}} '''View Profile'''
* {{key|b}} '''Zoom to Building''' Takes you to the [[building]] associated with the dwarf's current task. For hauling tasks, this is the destination [[stockpile]].
* {{key|m}} '''Manager''' Takes you to the [[Manager#Setting_up_work_orders|job manager]] screen.

===Military, m===
{{key|m}} Access the [[military]] screen
* {{key|p}} '''Positions''' Create and remove squads and assign dwarves to them.
* {{key|a}} '''Alerts''' Create configure alerts. Used in conjunction with burrows to define a '''CIV Alert''', a safe place that dwarves will be forced to go when turned on. Can also be used to change the active alert schedule for your squads.
* {{key|e}} '''Equip''' Assign armor and weapons to military squads.
* {{key|n}} '''Uniforms''' Create or modify uniform templates which can be assigned using the Equip screen.
* {{key|u}} '''Supplies''' Controls if a squad carries food and drink.
* {{key|f}} '''Ammunition''' Assigns ammunition to squads.
* {{key|s}} '''Schedule''' Used to modify the [[schedule|orders]] for an alert.

===Room List, R===
{{key|R}} Lists all [[Room|Rooms]], [[Building|Buildings]], [[Stockpile|Stockpiles]], and even [[Activity zone|Activity zones]] in the fortress. For rooms, it includes the room's quality and the owner's name. It includes quick access to each room's {{k|q}} and {{k|t}} menus.

===Locations and Occupations, l===
{{key|l}} A list of the [[location|locations]] designated in your fortress (libraries, temples, & taverns). In this screen you can control the supplies desired for your locations, as well as designate a worker/workers for the location as appropriate.

===Fortress Overview, z===
''' No longer existent in v50'''
{{key|z}} This screen is filled with useful information, like your fortress's net worth, and how much food and drink you have left.
* '''Animals''' A list of all tame [[creature|animals]] in your fort.
* '''Kitchen''' From here you can specify what [[food|foods]] can be [[cook|cooked]] or [[brew|brewed]].
* '''Stone''' Controls the use of [[ore|ores]] and [[economic stone|economic stones]]
* '''Stocks''' This is an in-depth listing of every item, down to every rotting rat corpse. The accuracy of the your item count depends on your [[bookkeeper]].
* '''Justice''' Shows the details of the dwarven [[justice]] system, once you have a [[Sheriff]].
* '''Health''' Shows an overview of the health status of the fortress, once you have a [[Chief medical dwarf]].
See [[Status]] for more details.

==Miscellaneous==

===Hot keys, h===
{{key|h}} Define or redefine [[Hotkeys]]

{{Category|Guides}}
{{Category|Interface}}

Controls guide

2023-01-07T04:52:18Z

Kelvie: Add all the menus from the bottom bar

{{migrated article}}
{{Quality|Unrated}}
{{av}}
This is a beginner's guide to [[fortress mode|Fortress Mode]] interface [[controls]]. This page assumes the default [[key bindings]].

As a beginner it is recommended that you familiarize yourself with the '''(View Unit - Preferences - Labor)''' submenu, the '''Query buildings''' menu, the '''Designate''' menu, and the '''Build''' menu.

==Viewing menus==
[[File:Df-menu-keys.png|thumb|Shortcut keys for the top-level menus]]

The buttons on the bottom-left of the screen all have shortcut keys that allow you to access them.

===Creatures, u===
The Creat{{key|u}}res command gives detailed information on creatures: a [[dwarf]], an [[creature|animal]], a [[goblin]], etc.
This command has several different tabs:
* Citizens
* Pets/Livestock
* Others
* Dead/Missing

===Tasks, t===

===Places, P===
The {{k|P}}laces command allows you to view various places, with tabs for:
* [[Zone]]s, such as refuse, pastures, clay gathering, [[room]]s, and meeting halls.
**You can also assign a [[room]] to belong to a specific dwarf here.
* Named [[location]]s such as hospitals, taverns, temples, and guild halls
* [[Stockpile]]s where you can change what types of objects are stored there, how many [[barrel|barrels]] are used, etc.
* [[Workshop]]s where you can change what tasks are being worked on, set a particular task to repeat or be suspended, or change who is allowed to use the workshop.
* [[Farm plot]] you can change what crops are being planted.

===Labor, y===
Here you can assign what dwarves do what type of labor.

===Options & Orders, o===
{{key|o}} Access the [[Standing orders]]

===Nobles & Administrators, n===
{{key|n}} Access the [[Nobles screen]]

===Objects, O===

===Justice, j===

===Burrows, U===
{{k|U}} Opens the [[burrow]]s menu

===Hauling, H===
The {{k|H}}auling command allows you to designate and configure [[minecart]] routes and stops.

===Traffic, T===
The {{h|T}}raffic command allows you to assign high and low traffic areas so your dwarves can try to avoid certain tiles.

==Order your Dwarves==
These commands affect what your dwarves do.
===Build, b===
Use this command to {{key|b}}uild rooms, place [[furniture]], start [[Farm plot|farm]] plots, and such. In addition to a long list of items which can be scrolled through with the {{k|+}}/{{k|-}} keys, there are also a few sub-menus:
*{{key|w}} '''[[Workshop|Workshops]]'''
*{{k|e}} '''[[Furnace|Furnaces]]'''
*{{key|C}} '''[[Construction]]'''
*{{key|T}} '''[[Trap|Traps]]'''
*{{key|M}} '''[[Machine component|Machine components]]'''
===Designate, d===
{{key|d}} [[Designations]] menu
*{{k|d}} Mine - Mark solid walls to [[mining|mine]]
*{{k|h}} Channel - Mark to solid walls or floors to [[channel]] downwards. This will create a ramp on the Z-level below the miner.
*{{k|z}} Remove Upstairs/Ramps - Mark stairs and ramps to remove them.
*{{k|u}} Upward Stairway - Mark to dig up [[stairs]] into solid wall.
*{{k|j}} Downward Stairway - Mark to dig down stairs into either a solid wall or a floor.
*{{k|i}} Up/Down Stairway - Mark to dig up/down stairs into a solid wall.
*{{k|r}} Upward Ramp - Mark to dig a [[ramp]] into a solid wall
*{{k|t}} Chop Down Trees - Mark trees to be [[wood cutter|cut]]
*{{k|p}} Gather Plants - Mark [[plant|plants]] to be [[herbalist|gathered]]
*{{k|s}} Smooth Stone - Mark walls or floor for an [[engraver]] to smooth. This must be done before you can engrave or carve fortifications.
*{{k|e}} Engrave Stone - Mark smoothed walls or floors to [[engraving|engrave]] art into.
*{{k|a}} Carve Fortifications - Mark smoothed walls to carve [[fortification]]s into.
*{{k|V}} Toggle Engravings - Mark engraved tiles to toggles their display.
*{{k|x}} Remove Designation - Removes any designation that was made with the {{k|d}} menu
*{{k|n}} Remove Constructions - Marks constructions for removal.

*{{k|b}} Set Building/Item Properties - Used to mass designate entire areas for the following:
**{{k|c}} Claim Items/Buildings
**{{k|f}} Forbid Items/Buildings
**{{k|m}} Melt
**{{k|M}} Remove Melt
**{{k|d}} Dump
**{{k|D}} Remove Dump
**{{k|h}} Hide Items/Buildings
**{{k|H}} Unhide Items/Buildings

*{{k|o}} Set Traffic Areas - Set [[traffic]] areas.

===Stockpile, p===
{{key|p}} Used to create [[stockpile|stockpiles]].
*{{k|a}} Animal
*{{k|u}} Furniture Storage
*{{k|y}} Corpses
*{{k|s}} Stone
*{{k|e}} Gem
*{{k|h}} Cloth
*{{k|z}} Ammo
*{{k|g}} Finished Goods
*{{k|p}} Weapons
*{{k|f}} Food
*{{k|w}} Wood
*{{k|b}} Bar/Block
*{{k|l}} Leather
*{{k|n}} Coins
*{{k|d}} Armor
===Zones, i===
{{key|i}} Mark an [[activity zone]] for drinking [[water]], [[fishing]], [[dump]], [[pasture|pen/pasture]], [[Activity zone#Pit/Pond|pit/pond]], [[sand]] collection, [[clay]] collection, [[meeting hall]], [[hospital]], [[animal training]]. This interface is the reverse of designate and stockpile commands: you mark out the rectangular area first, and define what it does afterward.
===Squads, s===
{{k|s}} This command is used to control your military squads. The options are:
*{{k|k}} Attack - Selected squad will attack the selected enemies.
*{{k|m}} Move - Selected squad will station to a specific location you choose.
*{{k|o}} Cancel orders - Cancels a station or kill order.
*{{k|z}} Center on Squad - Zooms to the commander of the squad.
*{{k|s}} View Schedule - Brings up the military scheduling screen.
*{{k|t}} Sched - Toggles between all available schedules.
*{{k|p}} Select Individuals - Lets you issue orders to individual soldiers instead of the entire squad.

==Fortress Information==

These commands take you away from the map, to an informational screen. Some of them also let you give orders.
===Announcements, a===
{{key|a}} This screen logs the announcements that appear at the bottom of the screen. Use it to see any you missed, or scroll up the early history of your fortress.

===Civilizations, c===
{{key|c}} A list of other civilizations that you have personally encountered (and thus within distance for [[trade]] or [[siege|war]]). Civilizations are marked with a ''P'' if you are at peace with them, or with a ''W'' if you are at war. Pressing {{key|Tab}} lets you check total exports and imports, and standing trade agreements.

===Unit List, u===
{{key|u}} A list of every creature on the map. Dwarves are listed first, then [[tame]] animals, then hostile creatures, then wild animals. Even dead creatures are listed here, so you can track your fallen dwarves.
* {{key|z}} '''Zoom to Creature''' This takes you to [[#View_Units.2C_v|View Creature]] mode, with the cursor centered on the selected creature.
* {{key|v}} '''View Profile'''
* {{key|b}} '''Zoom to Building''' Takes you to the [[building]] associated with the dwarf's current task. For hauling tasks, this is the destination [[stockpile]].
* {{key|m}} '''Manager''' Takes you to the [[Manager#Setting_up_work_orders|job manager]] screen.

===Military, m===
{{key|m}} Access the [[military]] screen
* {{key|p}} '''Positions''' Create and remove squads and assign dwarves to them.
* {{key|a}} '''Alerts''' Create configure alerts. Used in conjunction with burrows to define a '''CIV Alert''', a safe place that dwarves will be forced to go when turned on. Can also be used to change the active alert schedule for your squads.
* {{key|e}} '''Equip''' Assign armor and weapons to military squads.
* {{key|n}} '''Uniforms''' Create or modify uniform templates which can be assigned using the Equip screen.
* {{key|u}} '''Supplies''' Controls if a squad carries food and drink.
* {{key|f}} '''Ammunition''' Assigns ammunition to squads.
* {{key|s}} '''Schedule''' Used to modify the [[schedule|orders]] for an alert.

===Room List, R===
{{key|R}} Lists all [[Room|Rooms]], [[Building|Buildings]], [[Stockpile|Stockpiles]], and even [[Activity zone|Activity zones]] in the fortress. For rooms, it includes the room's quality and the owner's name. It includes quick access to each room's {{k|q}} and {{k|t}} menus.

===Locations and Occupations, l===
{{key|l}} A list of the [[location|locations]] designated in your fortress (libraries, temples, & taverns). In this screen you can control the supplies desired for your locations, as well as designate a worker/workers for the location as appropriate.

===Fortress Overview, z===
{{key|z}} This screen is filled with useful information, like your fortress's net worth, and how much food and drink you have left.
* '''Animals''' A list of all tame [[creature|animals]] in your fort.
* '''Kitchen''' From here you can specify what [[food|foods]] can be [[cook|cooked]] or [[brew|brewed]].
* '''Stone''' Controls the use of [[ore|ores]] and [[economic stone|economic stones]]
* '''Stocks''' This is an in-depth listing of every item, down to every rotting rat corpse. The accuracy of the your item count depends on your [[bookkeeper]].
* '''Justice''' Shows the details of the dwarven [[justice]] system, once you have a [[Sheriff]].
* '''Health''' Shows an overview of the health status of the fortress, once you have a [[Chief medical dwarf]].
See [[Status]] for more details.

==Miscellaneous==

===Hot keys, h===
{{key|h}} Define or redefine [[Hotkeys]]

{{Category|Guides}}
{{Category|Interface}}

Controls guide

2023-01-07T04:39:01Z

Kelvie: Add a screenshot of the various keys.

{{migrated article}}
{{Quality|Unrated}}
{{av}}
This is a beginner's guide to [[fortress mode|Fortress Mode]] interface [[controls]]. This page assumes the default [[key bindings]].

As a beginner it is recommended that you familiarize yourself with the '''(View Unit - Preferences - Labor)''' submenu, the '''Query buildings''' menu, the '''Designate''' menu, and the '''Build''' menu.

==Viewing menus==
There are four menus for gaining more information about the map and the creatures that inhabit it. When used a yellow X-shaped cursor appears which you can move around the map using the numberpad to gain information.

[[File:Df-menu-keys.png|thumb|From the Interface Tweaks mod on Steam workshop]]

===Creatures, u===
The Creat{{key|u}}res command gives detailed information on creatures: a [[dwarf]], an [[creature|animal]], a [[goblin]], etc.
This command has several different tabs:
* Citizens
* Pets/Livestock
* Others
* Dead/Missing

===Places, P===
The {{k|P}}laces command allows you to view various places, with tabs for:
* [[Zone]]s, such as refuse, pastures, clay gathering, [[room]]s, and meeting halls.
**You can also assign a [[room]] to belong to a specific dwarf here.
* Named [[location]]s such as hospitals, taverns, temples, and guild halls
* [[Stockpile]]s where you can change what types of objects are stored there, how many [[barrel|barrels]] are used, etc.
* [[Workshop]]s where you can change what tasks are being worked on, set a particular task to repeat or be suspended, or change who is allowed to use the workshop.
* [[Farm plot]] you can change what crops are being planted.

===Hauling, H===
The {{k|H}}auling command allows you to designate and configure [[minecart]] routes and stops.

===Traffic, T===
The {{h|T}}raffic command allows you to assign high and low traffic areas so your dwarves can try to avoid certain tiles.

==Order your Dwarves==
These commands affect what your dwarves do.
===Build, b===
Use this command to {{key|b}}uild rooms, place [[furniture]], start [[Farm plot|farm]] plots, and such. In addition to a long list of items which can be scrolled through with the {{k|+}}/{{k|-}} keys, there are also a few sub-menus:
*{{key|w}} '''[[Workshop|Workshops]]'''
*{{k|e}} '''[[Furnace|Furnaces]]'''
*{{key|C}} '''[[Construction]]'''
*{{key|T}} '''[[Trap|Traps]]'''
*{{key|M}} '''[[Machine component|Machine components]]'''
===Designate, d===
{{key|d}} [[Designations]] menu
*{{k|d}} Mine - Mark solid walls to [[mining|mine]]
*{{k|h}} Channel - Mark to solid walls or floors to [[channel]] downwards. This will create a ramp on the Z-level below the miner.
*{{k|z}} Remove Upstairs/Ramps - Mark stairs and ramps to remove them.
*{{k|u}} Upward Stairway - Mark to dig up [[stairs]] into solid wall.
*{{k|j}} Downward Stairway - Mark to dig down stairs into either a solid wall or a floor.
*{{k|i}} Up/Down Stairway - Mark to dig up/down stairs into a solid wall.
*{{k|r}} Upward Ramp - Mark to dig a [[ramp]] into a solid wall
*{{k|t}} Chop Down Trees - Mark trees to be [[wood cutter|cut]]
*{{k|p}} Gather Plants - Mark [[plant|plants]] to be [[herbalist|gathered]]
*{{k|s}} Smooth Stone - Mark walls or floor for an [[engraver]] to smooth. This must be done before you can engrave or carve fortifications.
*{{k|e}} Engrave Stone - Mark smoothed walls or floors to [[engraving|engrave]] art into.
*{{k|a}} Carve Fortifications - Mark smoothed walls to carve [[fortification]]s into.
*{{k|V}} Toggle Engravings - Mark engraved tiles to toggles their display.
*{{k|x}} Remove Designation - Removes any designation that was made with the {{k|d}} menu
*{{k|n}} Remove Constructions - Marks constructions for removal.

*{{k|b}} Set Building/Item Properties - Used to mass designate entire areas for the following:
**{{k|c}} Claim Items/Buildings
**{{k|f}} Forbid Items/Buildings
**{{k|m}} Melt
**{{k|M}} Remove Melt
**{{k|d}} Dump
**{{k|D}} Remove Dump
**{{k|h}} Hide Items/Buildings
**{{k|H}} Unhide Items/Buildings

*{{k|o}} Set Traffic Areas - Set [[traffic]] areas.

===Stockpile, p===
{{key|p}} Used to create [[stockpile|stockpiles]].
*{{k|a}} Animal
*{{k|u}} Furniture Storage
*{{k|y}} Corpses
*{{k|s}} Stone
*{{k|e}} Gem
*{{k|h}} Cloth
*{{k|z}} Ammo
*{{k|g}} Finished Goods
*{{k|p}} Weapons
*{{k|f}} Food
*{{k|w}} Wood
*{{k|b}} Bar/Block
*{{k|l}} Leather
*{{k|n}} Coins
*{{k|d}} Armor
===Zones, i===
{{key|i}} Mark an [[activity zone]] for drinking [[water]], [[fishing]], [[dump]], [[pasture|pen/pasture]], [[Activity zone#Pit/Pond|pit/pond]], [[sand]] collection, [[clay]] collection, [[meeting hall]], [[hospital]], [[animal training]]. This interface is the reverse of designate and stockpile commands: you mark out the rectangular area first, and define what it does afterward.
===Squads, s===
{{k|s}} This command is used to control your military squads. The options are:
*{{k|k}} Attack - Selected squad will attack the selected enemies.
*{{k|m}} Move - Selected squad will station to a specific location you choose.
*{{k|o}} Cancel orders - Cancels a station or kill order.
*{{k|z}} Center on Squad - Zooms to the commander of the squad.
*{{k|s}} View Schedule - Brings up the military scheduling screen.
*{{k|t}} Sched - Toggles between all available schedules.
*{{k|p}} Select Individuals - Lets you issue orders to individual soldiers instead of the entire squad.
===Burrows, U===
{{k|U}} Opens the [[burrow]]s menu

==Fortress Information==

These commands take you away from the map, to an informational screen. Some of them also let you give orders.
===Announcements, a===
{{key|a}} This screen logs the announcements that appear at the bottom of the screen. Use it to see any you missed, or scroll up the early history of your fortress.

===Civilizations, c===
{{key|c}} A list of other civilizations that you have personally encountered (and thus within distance for [[trade]] or [[siege|war]]). Civilizations are marked with a ''P'' if you are at peace with them, or with a ''W'' if you are at war. Pressing {{key|Tab}} lets you check total exports and imports, and standing trade agreements.

===Unit List, u===
{{key|u}} A list of every creature on the map. Dwarves are listed first, then [[tame]] animals, then hostile creatures, then wild animals. Even dead creatures are listed here, so you can track your fallen dwarves.
* {{key|z}} '''Zoom to Creature''' This takes you to [[#View_Units.2C_v|View Creature]] mode, with the cursor centered on the selected creature.
* {{key|v}} '''View Profile'''
* {{key|b}} '''Zoom to Building''' Takes you to the [[building]] associated with the dwarf's current task. For hauling tasks, this is the destination [[stockpile]].
* {{key|m}} '''Manager''' Takes you to the [[Manager#Setting_up_work_orders|job manager]] screen.

===Military, m===
{{key|m}} Access the [[military]] screen
* {{key|p}} '''Positions''' Create and remove squads and assign dwarves to them.
* {{key|a}} '''Alerts''' Create configure alerts. Used in conjunction with burrows to define a '''CIV Alert''', a safe place that dwarves will be forced to go when turned on. Can also be used to change the active alert schedule for your squads.
* {{key|e}} '''Equip''' Assign armor and weapons to military squads.
* {{key|n}} '''Uniforms''' Create or modify uniform templates which can be assigned using the Equip screen.
* {{key|u}} '''Supplies''' Controls if a squad carries food and drink.
* {{key|f}} '''Ammunition''' Assigns ammunition to squads.
* {{key|s}} '''Schedule''' Used to modify the [[schedule|orders]] for an alert.

===Room List, R===
{{key|R}} Lists all [[Room|Rooms]], [[Building|Buildings]], [[Stockpile|Stockpiles]], and even [[Activity zone|Activity zones]] in the fortress. For rooms, it includes the room's quality and the owner's name. It includes quick access to each room's {{k|q}} and {{k|t}} menus.

===Locations and Occupations, l===
{{key|l}} A list of the [[location|locations]] designated in your fortress (libraries, temples, & taverns). In this screen you can control the supplies desired for your locations, as well as designate a worker/workers for the location as appropriate.

===Nobles & Administrators, n===
{{key|n}} Access the [[Nobles screen]]

===Fortress Overview, z===
{{key|z}} This screen is filled with useful information, like your fortress's net worth, and how much food and drink you have left.
* '''Animals''' A list of all tame [[creature|animals]] in your fort.
* '''Kitchen''' From here you can specify what [[food|foods]] can be [[cook|cooked]] or [[brew|brewed]].
* '''Stone''' Controls the use of [[ore|ores]] and [[economic stone|economic stones]]
* '''Stocks''' This is an in-depth listing of every item, down to every rotting rat corpse. The accuracy of the your item count depends on your [[bookkeeper]].
* '''Justice''' Shows the details of the dwarven [[justice]] system, once you have a [[Sheriff]].
* '''Health''' Shows an overview of the health status of the fortress, once you have a [[Chief medical dwarf]].
See [[Status]] for more details.

==Miscellaneous==

===Options & Orders, o===
{{key|o}} Access the [[Standing orders]]

===Hot keys, h===
{{key|h}} Define or redefine [[Hotkeys]]

{{Category|Guides}}
{{Category|Interface}}

File:Df-menu-keys.png

2023-01-07T04:38:34Z

Kelvie:

From the Interface Tweaks mod on Steam workshop

Controls guide

2023-01-07T04:13:18Z

Kelvie: Add Hauling and Traffic

{{migrated article}}
{{Quality|Unrated}}
{{av}}
This is a beginner's guide to [[fortress mode|Fortress Mode]] interface [[controls]]. This page assumes the default [[key bindings]].

As a beginner it is recommended that you familiarize yourself with the '''(View Unit - Preferences - Labor)''' submenu, the '''Query buildings''' menu, the '''Designate''' menu, and the '''Build''' menu.

==Viewing menus==
There are four menus for gaining more information about the map and the creatures that inhabit it. When used a yellow X-shaped cursor appears which you can move around the map using the numberpad to gain information.

===Creatures, u===
The Creat{{key|u}}res command gives detailed information on creatures: a [[dwarf]], an [[creature|animal]], a [[goblin]], etc.
This command has several different tabs:
* Citizens
* Pets/Livestock
* Others
* Dead/Missing

===Places, P===
The {{k|P}}laces command allows you to view various places, with tabs for:
* [[Zone]]s, such as refuse, pastures, clay gathering, [[room]]s, and meeting halls.
**You can also assign a [[room]] to belong to a specific dwarf here.
* Named [[location]]s such as hospitals, taverns, temples, and guild halls
* [[Stockpile]]s where you can change what types of objects are stored there, how many [[barrel|barrels]] are used, etc.
* [[Workshop]]s where you can change what tasks are being worked on, set a particular task to repeat or be suspended, or change who is allowed to use the workshop.
* [[Farm plot]] you can change what crops are being planted.

===Hauling, H===
The {{k|H}}auling command allows you to designate and configure [[minecart]] routes and stops.

===Traffic, T===
The {{h|T}}raffic command allows you to assign high and low traffic areas so your dwarves can try to avoid certain tiles.

==Order your Dwarves==
These commands affect what your dwarves do.
===Build, b===
Use this command to {{key|b}}uild rooms, place [[furniture]], start [[Farm plot|farm]] plots, and such. In addition to a long list of items which can be scrolled through with the {{k|+}}/{{k|-}} keys, there are also a few sub-menus:
*{{key|w}} '''[[Workshop|Workshops]]'''
*{{k|e}} '''[[Furnace|Furnaces]]'''
*{{key|C}} '''[[Construction]]'''
*{{key|T}} '''[[Trap|Traps]]'''
*{{key|M}} '''[[Machine component|Machine components]]'''
===Designate, d===
{{key|d}} [[Designations]] menu
*{{k|d}} Mine - Mark solid walls to [[mining|mine]]
*{{k|h}} Channel - Mark to solid walls or floors to [[channel]] downwards. This will create a ramp on the Z-level below the miner.
*{{k|z}} Remove Upstairs/Ramps - Mark stairs and ramps to remove them.
*{{k|u}} Upward Stairway - Mark to dig up [[stairs]] into solid wall.
*{{k|j}} Downward Stairway - Mark to dig down stairs into either a solid wall or a floor.
*{{k|i}} Up/Down Stairway - Mark to dig up/down stairs into a solid wall.
*{{k|r}} Upward Ramp - Mark to dig a [[ramp]] into a solid wall
*{{k|t}} Chop Down Trees - Mark trees to be [[wood cutter|cut]]
*{{k|p}} Gather Plants - Mark [[plant|plants]] to be [[herbalist|gathered]]
*{{k|s}} Smooth Stone - Mark walls or floor for an [[engraver]] to smooth. This must be done before you can engrave or carve fortifications.
*{{k|e}} Engrave Stone - Mark smoothed walls or floors to [[engraving|engrave]] art into.
*{{k|a}} Carve Fortifications - Mark smoothed walls to carve [[fortification]]s into.
*{{k|V}} Toggle Engravings - Mark engraved tiles to toggles their display.
*{{k|x}} Remove Designation - Removes any designation that was made with the {{k|d}} menu
*{{k|n}} Remove Constructions - Marks constructions for removal.

*{{k|b}} Set Building/Item Properties - Used to mass designate entire areas for the following:
**{{k|c}} Claim Items/Buildings
**{{k|f}} Forbid Items/Buildings
**{{k|m}} Melt
**{{k|M}} Remove Melt
**{{k|d}} Dump
**{{k|D}} Remove Dump
**{{k|h}} Hide Items/Buildings
**{{k|H}} Unhide Items/Buildings

*{{k|o}} Set Traffic Areas - Set [[traffic]] areas.

===Stockpile, p===
{{key|p}} Used to create [[stockpile|stockpiles]].
*{{k|a}} Animal
*{{k|u}} Furniture Storage
*{{k|y}} Corpses
*{{k|s}} Stone
*{{k|e}} Gem
*{{k|h}} Cloth
*{{k|z}} Ammo
*{{k|g}} Finished Goods
*{{k|p}} Weapons
*{{k|f}} Food
*{{k|w}} Wood
*{{k|b}} Bar/Block
*{{k|l}} Leather
*{{k|n}} Coins
*{{k|d}} Armor
===Zones, i===
{{key|i}} Mark an [[activity zone]] for drinking [[water]], [[fishing]], [[dump]], [[pasture|pen/pasture]], [[Activity zone#Pit/Pond|pit/pond]], [[sand]] collection, [[clay]] collection, [[meeting hall]], [[hospital]], [[animal training]]. This interface is the reverse of designate and stockpile commands: you mark out the rectangular area first, and define what it does afterward.
===Squads, s===
{{k|s}} This command is used to control your military squads. The options are:
*{{k|k}} Attack - Selected squad will attack the selected enemies.
*{{k|m}} Move - Selected squad will station to a specific location you choose.
*{{k|o}} Cancel orders - Cancels a station or kill order.
*{{k|z}} Center on Squad - Zooms to the commander of the squad.
*{{k|s}} View Schedule - Brings up the military scheduling screen.
*{{k|t}} Sched - Toggles between all available schedules.
*{{k|p}} Select Individuals - Lets you issue orders to individual soldiers instead of the entire squad.
===Burrows, U===
{{k|U}} Opens the [[burrow]]s menu

==Fortress Information==

These commands take you away from the map, to an informational screen. Some of them also let you give orders.
===Announcements, a===
{{key|a}} This screen logs the announcements that appear at the bottom of the screen. Use it to see any you missed, or scroll up the early history of your fortress.

===Civilizations, c===
{{key|c}} A list of other civilizations that you have personally encountered (and thus within distance for [[trade]] or [[siege|war]]). Civilizations are marked with a ''P'' if you are at peace with them, or with a ''W'' if you are at war. Pressing {{key|Tab}} lets you check total exports and imports, and standing trade agreements.

===Unit List, u===
{{key|u}} A list of every creature on the map. Dwarves are listed first, then [[tame]] animals, then hostile creatures, then wild animals. Even dead creatures are listed here, so you can track your fallen dwarves.
* {{key|z}} '''Zoom to Creature''' This takes you to [[#View_Units.2C_v|View Creature]] mode, with the cursor centered on the selected creature.
* {{key|v}} '''View Profile'''
* {{key|b}} '''Zoom to Building''' Takes you to the [[building]] associated with the dwarf's current task. For hauling tasks, this is the destination [[stockpile]].
* {{key|m}} '''Manager''' Takes you to the [[Manager#Setting_up_work_orders|job manager]] screen.

===Military, m===
{{key|m}} Access the [[military]] screen
* {{key|p}} '''Positions''' Create and remove squads and assign dwarves to them.
* {{key|a}} '''Alerts''' Create configure alerts. Used in conjunction with burrows to define a '''CIV Alert''', a safe place that dwarves will be forced to go when turned on. Can also be used to change the active alert schedule for your squads.
* {{key|e}} '''Equip''' Assign armor and weapons to military squads.
* {{key|n}} '''Uniforms''' Create or modify uniform templates which can be assigned using the Equip screen.
* {{key|u}} '''Supplies''' Controls if a squad carries food and drink.
* {{key|f}} '''Ammunition''' Assigns ammunition to squads.
* {{key|s}} '''Schedule''' Used to modify the [[schedule|orders]] for an alert.

===Room List, R===
{{key|R}} Lists all [[Room|Rooms]], [[Building|Buildings]], [[Stockpile|Stockpiles]], and even [[Activity zone|Activity zones]] in the fortress. For rooms, it includes the room's quality and the owner's name. It includes quick access to each room's {{k|q}} and {{k|t}} menus.

===Locations and Occupations, l===
{{key|l}} A list of the [[location|locations]] designated in your fortress (libraries, temples, & taverns). In this screen you can control the supplies desired for your locations, as well as designate a worker/workers for the location as appropriate.

===Nobles & Administrators, n===
{{key|n}} Access the [[Nobles screen]]

===Fortress Overview, z===
{{key|z}} This screen is filled with useful information, like your fortress's net worth, and how much food and drink you have left.
* '''Animals''' A list of all tame [[creature|animals]] in your fort.
* '''Kitchen''' From here you can specify what [[food|foods]] can be [[cook|cooked]] or [[brew|brewed]].
* '''Stone''' Controls the use of [[ore|ores]] and [[economic stone|economic stones]]
* '''Stocks''' This is an in-depth listing of every item, down to every rotting rat corpse. The accuracy of the your item count depends on your [[bookkeeper]].
* '''Justice''' Shows the details of the dwarven [[justice]] system, once you have a [[Sheriff]].
* '''Health''' Shows an overview of the health status of the fortress, once you have a [[Chief medical dwarf]].
See [[Status]] for more details.

==Miscellaneous==

===Options & Orders, o===
{{key|o}} Access the [[Standing orders]]

===Hot keys, h===
{{key|h}} Define or redefine [[Hotkeys]]

{{Category|Guides}}
{{Category|Interface}}

Controls guide

2023-01-07T04:10:17Z

Kelvie: Update some new controls for v50

{{migrated article}}
{{Quality|Unrated}}
{{av}}
This is a beginner's guide to [[fortress mode|Fortress Mode]] interface [[controls]]. This page assumes the default [[key bindings]].

As a beginner it is recommended that you familiarize yourself with the '''(View Unit - Preferences - Labor)''' submenu, the '''Query buildings''' menu, the '''Designate''' menu, and the '''Build''' menu.

==Viewing menus==
There are four menus for gaining more information about the map and the creatures that inhabit it. When used a yellow X-shaped cursor appears which you can move around the map using the numberpad to gain information.

===Creatures, u===
The Creat{{key|u}}res command gives detailed information on creatures: a [[dwarf]], an [[creature|animal]], a [[goblin]], etc.
This command has several different tabs:
* Citizens
* Pets/Livestock
* Others
* Dead/Missing

===Places, P===
The {{k|P}}laces command allows you to view various places, with tabs for:
* [[Zone]]s, such as refuse, pastures, clay gathering, [[room]]s, and meeting halls.
**You can also assign a [[room]] to belong to a specific dwarf here.
* Named [[location]]s such as hospitals, taverns, temples, and guild halls
* [[Stockpile]]s where you can change what types of objects are stored there, how many [[barrel|barrels]] are used, etc.
* [[Workshop]]s where you can change what tasks are being worked on, set a particular task to repeat or be suspended, or change who is allowed to use the workshop.
* [[Farm plot]] you can change what crops are being planted.

==Order your Dwarves==
These commands affect what your dwarves do.
===Build, b===
Use this command to {{key|b}}uild rooms, place [[furniture]], start [[Farm plot|farm]] plots, and such. In addition to a long list of items which can be scrolled through with the {{k|+}}/{{k|-}} keys, there are also a few sub-menus:
*{{key|w}} '''[[Workshop|Workshops]]'''
*{{k|e}} '''[[Furnace|Furnaces]]'''
*{{key|C}} '''[[Construction]]'''
*{{key|T}} '''[[Trap|Traps]]'''
*{{key|M}} '''[[Machine component|Machine components]]'''
===Designate, d===
{{key|d}} [[Designations]] menu
*{{k|d}} Mine - Mark solid walls to [[mining|mine]]
*{{k|h}} Channel - Mark to solid walls or floors to [[channel]] downwards. This will create a ramp on the Z-level below the miner.
*{{k|z}} Remove Upstairs/Ramps - Mark stairs and ramps to remove them.
*{{k|u}} Upward Stairway - Mark to dig up [[stairs]] into solid wall.
*{{k|j}} Downward Stairway - Mark to dig down stairs into either a solid wall or a floor.
*{{k|i}} Up/Down Stairway - Mark to dig up/down stairs into a solid wall.
*{{k|r}} Upward Ramp - Mark to dig a [[ramp]] into a solid wall
*{{k|t}} Chop Down Trees - Mark trees to be [[wood cutter|cut]]
*{{k|p}} Gather Plants - Mark [[plant|plants]] to be [[herbalist|gathered]]
*{{k|s}} Smooth Stone - Mark walls or floor for an [[engraver]] to smooth. This must be done before you can engrave or carve fortifications.
*{{k|e}} Engrave Stone - Mark smoothed walls or floors to [[engraving|engrave]] art into.
*{{k|a}} Carve Fortifications - Mark smoothed walls to carve [[fortification]]s into.
*{{k|V}} Toggle Engravings - Mark engraved tiles to toggles their display.
*{{k|x}} Remove Designation - Removes any designation that was made with the {{k|d}} menu
*{{k|n}} Remove Constructions - Marks constructions for removal.

*{{k|b}} Set Building/Item Properties - Used to mass designate entire areas for the following:
**{{k|c}} Claim Items/Buildings
**{{k|f}} Forbid Items/Buildings
**{{k|m}} Melt
**{{k|M}} Remove Melt
**{{k|d}} Dump
**{{k|D}} Remove Dump
**{{k|h}} Hide Items/Buildings
**{{k|H}} Unhide Items/Buildings

*{{k|o}} Set Traffic Areas - Set [[traffic]] areas.

===Stockpile, p===
{{key|p}} Used to create [[stockpile|stockpiles]].
*{{k|a}} Animal
*{{k|u}} Furniture Storage
*{{k|y}} Corpses
*{{k|s}} Stone
*{{k|e}} Gem
*{{k|h}} Cloth
*{{k|z}} Ammo
*{{k|g}} Finished Goods
*{{k|p}} Weapons
*{{k|f}} Food
*{{k|w}} Wood
*{{k|b}} Bar/Block
*{{k|l}} Leather
*{{k|n}} Coins
*{{k|d}} Armor
===Zones, i===
{{key|i}} Mark an [[activity zone]] for drinking [[water]], [[fishing]], [[dump]], [[pasture|pen/pasture]], [[Activity zone#Pit/Pond|pit/pond]], [[sand]] collection, [[clay]] collection, [[meeting hall]], [[hospital]], [[animal training]]. This interface is the reverse of designate and stockpile commands: you mark out the rectangular area first, and define what it does afterward.
===Squads, s===
{{k|s}} This command is used to control your military squads. The options are:
*{{k|k}} Attack - Selected squad will attack the selected enemies.
*{{k|m}} Move - Selected squad will station to a specific location you choose.
*{{k|o}} Cancel orders - Cancels a station or kill order.
*{{k|z}} Center on Squad - Zooms to the commander of the squad.
*{{k|s}} View Schedule - Brings up the military scheduling screen.
*{{k|t}} Sched - Toggles between all available schedules.
*{{k|p}} Select Individuals - Lets you issue orders to individual soldiers instead of the entire squad.
===Burrows, U===
{{k|U}} Opens the [[burrow]]s menu:

==Fortress Information==

These commands take you away from the map, to an informational screen. Some of them also let you give orders.
===Announcements, a===
{{key|a}} This screen logs the announcements that appear at the bottom of the screen. Use it to see any you missed, or scroll up the early history of your fortress.

===Civilizations, c===
{{key|c}} A list of other civilizations that you have personally encountered (and thus within distance for [[trade]] or [[siege|war]]). Civilizations are marked with a ''P'' if you are at peace with them, or with a ''W'' if you are at war. Pressing {{key|Tab}} lets you check total exports and imports, and standing trade agreements.

===Unit List, u===
{{key|u}} A list of every creature on the map. Dwarves are listed first, then [[tame]] animals, then hostile creatures, then wild animals. Even dead creatures are listed here, so you can track your fallen dwarves.
* {{key|z}} '''Zoom to Creature''' This takes you to [[#View_Units.2C_v|View Creature]] mode, with the cursor centered on the selected creature.
* {{key|v}} '''View Profile'''
* {{key|b}} '''Zoom to Building''' Takes you to the [[building]] associated with the dwarf's current task. For hauling tasks, this is the destination [[stockpile]].
* {{key|m}} '''Manager''' Takes you to the [[Manager#Setting_up_work_orders|job manager]] screen.

===Military, m===
{{key|m}} Access the [[military]] screen
* {{key|p}} '''Positions''' Create and remove squads and assign dwarves to them.
* {{key|a}} '''Alerts''' Create configure alerts. Used in conjunction with burrows to define a '''CIV Alert''', a safe place that dwarves will be forced to go when turned on. Can also be used to change the active alert schedule for your squads.
* {{key|e}} '''Equip''' Assign armor and weapons to military squads.
* {{key|n}} '''Uniforms''' Create or modify uniform templates which can be assigned using the Equip screen.
* {{key|u}} '''Supplies''' Controls if a squad carries food and drink.
* {{key|f}} '''Ammunition''' Assigns ammunition to squads.
* {{key|s}} '''Schedule''' Used to modify the [[schedule|orders]] for an alert.

===Room List, R===
{{key|R}} Lists all [[Room|Rooms]], [[Building|Buildings]], [[Stockpile|Stockpiles]], and even [[Activity zone|Activity zones]] in the fortress. For rooms, it includes the room's quality and the owner's name. It includes quick access to each room's {{k|q}} and {{k|t}} menus.

===Locations and Occupations, l===
{{key|l}} A list of the [[location|locations]] designated in your fortress (libraries, temples, & taverns). In this screen you can control the supplies desired for your locations, as well as designate a worker/workers for the location as appropriate.

===Nobles & Administrators, n===
{{key|n}} Access the [[Nobles screen]]

===Fortress Overview, z===
{{key|z}} This screen is filled with useful information, like your fortress's net worth, and how much food and drink you have left.
* '''Animals''' A list of all tame [[creature|animals]] in your fort.
* '''Kitchen''' From here you can specify what [[food|foods]] can be [[cook|cooked]] or [[brew|brewed]].
* '''Stone''' Controls the use of [[ore|ores]] and [[economic stone|economic stones]]
* '''Stocks''' This is an in-depth listing of every item, down to every rotting rat corpse. The accuracy of the your item count depends on your [[bookkeeper]].
* '''Justice''' Shows the details of the dwarven [[justice]] system, once you have a [[Sheriff]].
* '''Health''' Shows an overview of the health status of the fortress, once you have a [[Chief medical dwarf]].
See [[Status]] for more details.

==Miscellaneous==

===Options & Orders, o===
{{key|o}} Access the [[Standing orders]]

===Hot keys, h===
{{key|h}} Define or redefine [[Hotkeys]]

{{Category|Guides}}
{{Category|Interface}}

Controls guide

2023-01-07T04:03:25Z

Kelvie: Update the burrows controls. Sadly, it's mostly mouse based now.

{{migrated article}}
{{Quality|Unrated}}
{{av}}
This is a beginner's guide to [[fortress mode|Fortress Mode]] interface [[controls]]. This page assumes the default [[key bindings]].

As a beginner it is recommended that you familiarize yourself with the '''(View Unit - Preferences - Labor)''' submenu, the '''Query buildings''' menu, the '''Designate''' menu, and the '''Build''' menu.

==Viewing menus==
There are four menus for gaining more information about the map and the creatures that inhabit it. When used a yellow X-shaped cursor appears which you can move around the map using the numberpad to gain information.

===Look Around, k===
The loo{{k|k}} command shows you individual map tiles and what is standing/resting upon them. The menu displays [[Creatures]], Objects, [[Building|Buildings]], [[Map tile]]s in that order. You can use the {{k|+}} {{k|-}} keys to browse these things and press {{k|Enter}} to gain more detailed information.

You can also designate an item to be [[forbid|forbidden]], [[dump|dumped]], or [[melt|melted]] from this menu, if it is allowed (You can't designate a loaf of bread to be melted, for example!).

===View Units, v===
The {{key|v}}iew command gives detailed information on creatures: a [[dwarf]], an [[creature|animal]], a [[goblin]], etc. You do not need to place the cursor directly over the creature, information is given on the nearest creature. If multiple creatures are the same distance from the cursor (usually due to occupying the same tile), use {{key|v}} to cycle through them.

This command has several different menu views:
* {{key|g}}eneral - Name, occupation, and [[skill|skills]].
* {{key|i}}nventory - Shows all the items the creature is carrying. Also shows the bloodstains, mud and goo that accumulates on creatures.
* {{key|p}}references - This menu includes two sub-menus:
** {{key|l}}abor - This lists which types of [[job|jobs]] the dwarf will accept. Very important for controlling their behavior.
** {{key|e}} Work Animals - Assign [[Animal training|trained]] animals to this dwarf.
* {{key|w}} [[Wound|ounds]] - Shows the creature's health. Bright white means the body part is unharmed. Effects like "Thirsty" and "Unconscious" are also listed here.
* {{key|z}} View Profile - Views a dwarf's profile. From here, you can view [[thought|thoughts]] and [[preference|preferences]], view his [[relationship]]s, and give him a custom nickname or profession title.
* {{key|Enter}} View Job - Shows the creature's current job, if they have one. (Some jobs/activities are unviewable.)

===Query Rooms/Buildings, q===
The {{k|q}}uery command allows you to {{k|s}}uspend construction of a room or object, mark it for {{k|r}}emoval, or interact with its specific functionality.
*If you query a [[workshop]] you can change what tasks are being worked on, set a particular task to repeat or be suspended, or change who is allowed to use the workshop.
*If you query a piece of [[furniture]] you can define a [[room]] from it (e.g. a [[bed]] into a [[bedroom]], a [[chair]] into an [[office]], etc.). Depending on the type of furniture there are additional options (e.g. a [[door]] can be locked, a [[coffin]] can be used for either [[pet]] or citizen burial).
*You can also assign a [[room]] to belong to a specific dwarf.
*If you query a [[farm plot]] you can change what crops are being planted.
*If you query a [[stockpile]] you can change what types of objects are stored there, how many [[barrel|barrels]] are used, etc.

===View items in buildings, t===
The i{{key|t}}ems command is used to see items that are inside buildings, such as [[workshop|workshops]], [[Trade depot|depots]], and [[trap|traps]].

==Order your Dwarves==
These commands affect what your dwarves do.
===Build, b===
Use this command to {{key|b}}uild rooms, place [[furniture]], start [[Farm plot|farm]] plots, and such. In addition to a long list of items which can be scrolled through with the {{k|+}}/{{k|-}} keys, there are also a few sub-menus:
*{{key|w}} '''[[Workshop|Workshops]]'''
*{{k|e}} '''[[Furnace|Furnaces]]'''
*{{key|C}} '''[[Construction]]'''
*{{key|T}} '''[[Trap|Traps]]'''
*{{key|M}} '''[[Machine component|Machine components]]'''
===Designate, d===
{{key|d}} [[Designations]] menu
*{{k|d}} Mine - Mark solid walls to [[mining|mine]]
*{{k|h}} Channel - Mark to solid walls or floors to [[channel]] downwards. This will create a ramp on the Z-level below the miner.
*{{k|z}} Remove Upstairs/Ramps - Mark stairs and ramps to remove them.
*{{k|u}} Upward Stairway - Mark to dig up [[stairs]] into solid wall.
*{{k|j}} Downward Stairway - Mark to dig down stairs into either a solid wall or a floor.
*{{k|i}} Up/Down Stairway - Mark to dig up/down stairs into a solid wall.
*{{k|r}} Upward Ramp - Mark to dig a [[ramp]] into a solid wall
*{{k|t}} Chop Down Trees - Mark trees to be [[wood cutter|cut]]
*{{k|p}} Gather Plants - Mark [[plant|plants]] to be [[herbalist|gathered]]
*{{k|s}} Smooth Stone - Mark walls or floor for an [[engraver]] to smooth. This must be done before you can engrave or carve fortifications.
*{{k|e}} Engrave Stone - Mark smoothed walls or floors to [[engraving|engrave]] art into.
*{{k|a}} Carve Fortifications - Mark smoothed walls to carve [[fortification]]s into.
*{{k|V}} Toggle Engravings - Mark engraved tiles to toggles their display.
*{{k|x}} Remove Designation - Removes any designation that was made with the {{k|d}} menu
*{{k|n}} Remove Constructions - Marks constructions for removal.

*{{k|b}} Set Building/Item Properties - Used to mass designate entire areas for the following:
**{{k|c}} Claim Items/Buildings
**{{k|f}} Forbid Items/Buildings
**{{k|m}} Melt
**{{k|M}} Remove Melt
**{{k|d}} Dump
**{{k|D}} Remove Dump
**{{k|h}} Hide Items/Buildings
**{{k|H}} Unhide Items/Buildings

*{{k|o}} Set Traffic Areas - Set [[traffic]] areas.

===Stockpile, p===
{{key|p}} Used to create [[stockpile|stockpiles]].
*{{k|a}} Animal
*{{k|u}} Furniture Storage
*{{k|y}} Corpses
*{{k|s}} Stone
*{{k|e}} Gem
*{{k|h}} Cloth
*{{k|z}} Ammo
*{{k|g}} Finished Goods
*{{k|p}} Weapons
*{{k|f}} Food
*{{k|w}} Wood
*{{k|b}} Bar/Block
*{{k|l}} Leather
*{{k|n}} Coins
*{{k|d}} Armor
===Zones, i===
{{key|i}} Mark an [[activity zone]] for drinking [[water]], [[fishing]], [[dump]], [[pasture|pen/pasture]], [[Activity zone#Pit/Pond|pit/pond]], [[sand]] collection, [[clay]] collection, [[meeting hall]], [[hospital]], [[animal training]]. This interface is the reverse of designate and stockpile commands: you mark out the rectangular area first, and define what it does afterward.
===Squads, s===
{{k|s}} This command is used to control your military squads. The options are:
*{{k|k}} Attack - Selected squad will attack the selected enemies.
*{{k|m}} Move - Selected squad will station to a specific location you choose.
*{{k|o}} Cancel orders - Cancels a station or kill order.
*{{k|z}} Center on Squad - Zooms to the commander of the squad.
*{{k|s}} View Schedule - Brings up the military scheduling screen.
*{{k|t}} Sched - Toggles between all available schedules.
*{{k|p}} Select Individuals - Lets you issue orders to individual soldiers instead of the entire squad.
===Burrows, U===
{{k|U}} Opens the [[burrow]]s menu:

==Fortress Information==

These commands take you away from the map, to an informational screen. Some of them also let you give orders.
===Announcements, a===
{{key|a}} This screen logs the announcements that appear at the bottom of the screen. Use it to see any you missed, or scroll up the early history of your fortress.

===Civilizations, c===
{{key|c}} A list of other civilizations that you have personally encountered (and thus within distance for [[trade]] or [[siege|war]]). Civilizations are marked with a ''P'' if you are at peace with them, or with a ''W'' if you are at war. Pressing {{key|Tab}} lets you check total exports and imports, and standing trade agreements.

===Unit List, u===
{{key|u}} A list of every creature on the map. Dwarves are listed first, then [[tame]] animals, then hostile creatures, then wild animals. Even dead creatures are listed here, so you can track your fallen dwarves.
* {{key|z}} '''Zoom to Creature''' This takes you to [[#View_Units.2C_v|View Creature]] mode, with the cursor centered on the selected creature.
* {{key|v}} '''View Profile'''
* {{key|b}} '''Zoom to Building''' Takes you to the [[building]] associated with the dwarf's current task. For hauling tasks, this is the destination [[stockpile]].
* {{key|m}} '''Manager''' Takes you to the [[Manager#Setting_up_work_orders|job manager]] screen.

===Military, m===
{{key|m}} Access the [[military]] screen
* {{key|p}} '''Positions''' Create and remove squads and assign dwarves to them.
* {{key|a}} '''Alerts''' Create configure alerts. Used in conjunction with burrows to define a '''CIV Alert''', a safe place that dwarves will be forced to go when turned on. Can also be used to change the active alert schedule for your squads.
* {{key|e}} '''Equip''' Assign armor and weapons to military squads.
* {{key|n}} '''Uniforms''' Create or modify uniform templates which can be assigned using the Equip screen.
* {{key|u}} '''Supplies''' Controls if a squad carries food and drink.
* {{key|f}} '''Ammunition''' Assigns ammunition to squads.
* {{key|s}} '''Schedule''' Used to modify the [[schedule|orders]] for an alert.

===Room List, R===
{{key|R}} Lists all [[Room|Rooms]], [[Building|Buildings]], [[Stockpile|Stockpiles]], and even [[Activity zone|Activity zones]] in the fortress. For rooms, it includes the room's quality and the owner's name. It includes quick access to each room's {{k|q}} and {{k|t}} menus.

===Locations and Occupations, l===
{{key|l}} A list of the [[location|locations]] designated in your fortress (libraries, temples, & taverns). In this screen you can control the supplies desired for your locations, as well as designate a worker/workers for the location as appropriate.

===Nobles & Administrators, n===
{{key|n}} Access the [[Nobles screen]]

===Fortress Overview, z===
{{key|z}} This screen is filled with useful information, like your fortress's net worth, and how much food and drink you have left.
* '''Animals''' A list of all tame [[creature|animals]] in your fort.
* '''Kitchen''' From here you can specify what [[food|foods]] can be [[cook|cooked]] or [[brew|brewed]].
* '''Stone''' Controls the use of [[ore|ores]] and [[economic stone|economic stones]]
* '''Stocks''' This is an in-depth listing of every item, down to every rotting rat corpse. The accuracy of the your item count depends on your [[bookkeeper]].
* '''Justice''' Shows the details of the dwarven [[justice]] system, once you have a [[Sheriff]].
* '''Health''' Shows an overview of the health status of the fortress, once you have a [[Chief medical dwarf]].
See [[Status]] for more details.

==Miscellaneous==

===Options & Orders, o===
{{key|o}} Access the [[Standing orders]]

===Hot keys, h===
{{key|h}} Define or redefine [[Hotkeys]]

{{Category|Guides}}
{{Category|Interface}}

Grate

2023-01-05T22:55:57Z

Kelvie: /* Floor grate */ Add info about mist.

{{migrated article}}
{{Quality|Unrated}}
{{av}}

{{buggy|bugsection=Bugs}}

{{furniture|name=Grate
|tile=#
|wood=y
|stonecarve=y
|metal=y
|glass=y
}}
A '''grate''' is a [[furniture]]-type item. It is used as a construction material for wall grates and floor grates. Grates can be constructed from [[stone]] or [[ore]] (with the [[masonry]] [[labor]] at a [[mason's workshop]]), wood (with the [[carpentry]] labor in a [[carpenter's workshop]]), [[Metal|metal bar]]s (with the [[blacksmithing]] labor at a [[forge]]), or [[glass]] (with the [[glassmaking]] labor at a [[glass furnace]]).

== Wall grate ==
A '''wall grate''' is basically a [[fortification]], but with two differences:
* It is a [[building]] instead of a [[construction]]. It doesn't overwrite the tile below it, and it can be smashed by [[building destroyer]]s.
* It can be linked to a [[lever]] or [[pressure plate]]. Once linked, it works like a linked [[door]] which doesn't stop fluids, [[arrow]]s or [[Miasma]] when closed.

Wall grates act as boundaries for rooms being resized, but they do not provide support for doors.

Unlike a constructed wall, grates have quality levels and can be decorated.

== Floor grate ==
[[File:grate_preview.png|thumb|210px|right|Where the unwanted liquids go.]]A '''floor grate''' is similar to a floor or a closed [[floor hatch]] in that it can be walked upon and blocks [[creature]] and item movement between Z-levels. However, it lets [[water]] and [[magma]] through like an open tile. Floor grates block projectiles, unlike wall grates. They do not block line of sight. Floor grates can be linked to a [[lever]] or a [[pressure plate]]. When triggered, a floor grate opens like a hatch, but with a 100-tick delay.

Floor grates must be attached [[orthogonal]]ly (i.e. not diagonally) to firm ground or some solid construction (a [[wall]], [[floor]], etc.), not (just) other grates. Floor grates placed directly on top of a floor or [[stairs|staircase]] still require orthogonal support, even though their own tile should be able to provide support. Attempting to construct a floor grate supported only by its own tile will display the message "Surrounded by empty space". Removing the orthogonal support from a constructed floor grate will cause it to harmlessly deconstruct.

A floor grate does NOT count as solid construction. It will not support any buildings or constructions. However, you can designate a construction to be built orthogonally to it with no other supports. This will cause the construction to [[cave-in]] immediately after being completed. This can be useful for controlled cave-ins.

[[Stockpile]]s cannot be placed over floor grates.

Like [[bridge]]s and [[floor hatch]]es, floor grates will mark areas beneath them as being "inside", even if they are retracted.

If a floor grate is placed right on top of a [[soil]] floor or [[mud]]dy floor it will prevent [[grass]], [[shrub]]s and [[tree|saplings]] from growing.

Floor grates do not block [[fishing]] or taking water directly from a [[activity zone#Water_Source|water source]], nor do they block collecting [[sand]] or [[clay]], though they do prevent [[well]]s from working if between the well and the water.

Floor grates over empty space block [[miasma]] and [[mist]] from rising through them (miasma will normally flow upward through empty space).

== Bars vs. grates ==
Vertical/horizontal [[bars]] are largely identical to wall/floor grates. There are just a few notable differences between them:

* Grates are finished goods (which must be produced from raw materials) and have [[quality]] levels (and thus boost your fortress's architecture value significantly), while bars are simply raw materials that can be thrown into place at a moment's notice and then deconstructed later should they be needed later for other jobs.

* Building destroyers will topple bars, destroying them in seconds compared to minutes with grates.

* Grates can be made from wood and stone, both of which are generally much more plentiful than the materials for bars.

== Notes ==
* Floor grates can be very useful in preventing fortress floods. This is done by [[channel|channeling]] out holes in multiple layers of a fortress and covering them with floor grates, which will just keep the liquid flowing down each level through the grates instead of building up on a Z-level. This is assuming there is a reservoir of some sort that the water can flow into and not dangerously build up.
* If you wish to remove a floor piece that is linked to a grate, make sure that the dwarf that carries out the job does not stand on the grate, or remove all grates first. The grate will not be supported, and fall (with your non-careful dwarf on it), and you will experience the famous idiom: "It's not the fall that kills you, it's the sudden stop at the end."
* This can also happen vice versa when building multiple floor tiles at a time with floor grates directly beside them. Dwarves will attempt to build the floor supported by just the floor grate regardless of how the game treats it. This can be very unfortunate if Urist McNotPhysicist builds a floor under these circumstances over a lake, experiencing a cave-in resulting in them most likely getting knocked over from the dust, drowning and you ending up with a hard-to-reach corpse.
* On a similar note, be cautious when removing a large number of grates next to each other, as a dwarf trying to remove a grate ''will'' stand on one his neighbor is about to yank out from under his feet. This can be largely avoided by removing them in batches of alternating grates (IE: Grates 1, 3, 5 then 2, 4, 6, etc...)
* Floor grates can be used in watchtowers: place a locked-in animal on top of them, and let them observe possible intruders from above. Since no alternative route to the watcher exists, building destroyers cannot destroy the grate. Getting the animal in place can be tricky, if the floor is all grates - pitting is an option. Bonus points for combining this with an automated magma release valve.

== Bugs ==

* Creatures and dwarves pushed by water flow can be pushed through wall grates. {{Bug|5458}}

{{buildings}}

Mist

2023-01-05T22:55:09Z

Kelvie: /* Ring generator */ Move diagrams

{{migrated article}}
{{Quality|Unrated}}
{{av}}
[[File:mist_example.jpg|thumb|270px|right|If skin pores could orgasm.]]
'''Mist''' is created by [[water]] [[Waterfall|falling]] from one [[Z-level]] to another, from [[DF2014:Ocean#Ocean_waves|ocean waves]], items or creatures skipping across water or just standard splashing. The mist is generated on levels below the top level (from which the water drops), but spreads out similarly to [[miasma]] and, therefore, can appear even on the top level, and lingers and spreads for a short time after any water stops falling. Walking through mist generates a happy [[thought]] for a dwarf, and can act to [[Cleaning|clean]] various contaminants off of dwarves.

Mist is separate from [[magma mist]] and [[steam]].

[[File:mist_preview.png|thumb|120px|right|Rampant [[screw pump]]s are a great mist source.]]

==Generating Mist==
=== Constructed waterfall ===
The easiest method is simply to use a constant source of water ([[Screw pump|pumped]] or [[channel]]ed) and let it fall more than 1 z-level next to a path that dwarves use regularly. The actual tile (you only need one) that the water drops should not be part of the path, as dwarves will believe they are in 7/7 water and cancel jobs - a statue on that tile will prevent this nicely, or place the fall itself to the side of the path and make that a [[Traffic#Setting Traffic Areas|restricted traffic]] tile.

[[Floor grate]]s or [[bars]] on every* tile adjacent to the water flow should be used as part of the drainage system (which should be larger than the intake system, just to be safe!), and to avoid [[mud]] on adjacent tiles. Use a door, hatch, floodgate or bridge linked to a [[lever]] to turn off the flow if/when desired.

: (* when designing this, remember that grates/bars [[Cave-in|do not support]] floor tiles!)

The problem with this setup is that this amount of constantly falling/flowing water can have a negative impact on your fps rate. Using a [[repeater]] to allow a non-constant flow, or linking the flow to a [[pressure plate]], where it will only fall when dwarves approach, will help this.

=== Ring generator ===
[[File:Mist-ring-generator-z0.png|thumb|Mist ring generator (z = 1)]]
[[File:Mist-ring-generator-z-1.png|thumb|Mist ring generator (z = 0)]]

AncientEnemy [http://www.bay12forums.com/smf/index.php?topic=34407.0] devised a convenient way to generate mist. This method relies on the fact that [[screw pump|screw pumps]] pump [[water]] faster than water spreads out.[[Image:newmist.jpg|thumb|AncientEnemy's original simple mist generator.]]

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

Below is an example of a simple mist generator. The Z=0 level can be anything, a booze stockpile, [[barracks]] or even your [[Dwarven_atom_smasher|atom smasher]]. The z=-1 layer can also be identical to the z=0 level. Mist will also be generated there. Because the water never touches the floor there, you don't have to worry about muddy tiles.
<diagram>
Pump Floor (z=1)
▒▒▒▒▒▒
▒.[#2:0]÷[#2:1]÷[#].▒
▒[#2:1]÷ [#2:0]÷[#]▒ The water can go clockwise or counter clockwise.
▒[#2:0]÷ [#2:1]÷[#]▒ Make sure your pumps are correctly aligned.
▒.[#2:1]÷[#2:0]÷[#].▒
▒▒▒▒▒▒
</diagram>

A movie [http://mkv25.net/dfma/movie-1292-ubermistgenerator] best illustrates the operation.

It is advisable to put statues under the holes in the bottom layer, so dwarves cannot go under the water, to displace the water, requiring a refill.

Note that if you put grates on the z = 1 layer, the mist will not spread upward, if that is desired.

=== Stack generator ===

A two-pump-stack can be used to lift a single tile of water and drop it back into the reservoir, generating mist (and [[Cleaning#Dwarven_Shower|cleaning dwarves]], if desired).

<diagram>

sideview

[#2:0]%%[#]_
[#6:0]%%[#]_
░░░░[#1:0]▄[#]░░░
░░░░░░░░

</diagram>

The lower (brown) pump (pumping right to left) raises the water from the reservoir on the right to floor level on the left, then the upper (green) pump (pumping left to right) raises that water to the air +2 z-levels above the reservoir. The water then falls through the floor grates ( _ ) into the reservoir, and the cycle can be repeated. Pump build order is important; build the green pump first, then the brown pump, to ensure the water is raised in a single tick. Since the water never sits at floor level, no containment walls are necessary (though mud will be created in the tile left of the brown pump). You can toggle power to the pumps as often as desired to provide happy thoughts without constant lag. If used for dwarf-cleaning, a water level of 2/7 or 3/7 will avoid job cancellations.

=== Light aquifer ===
If your embark location has a light aquifer, it is possible to build an unpowered mist generator-plus-bathing unit combination. You need two floors under the aquifer - lowest floor is for dwarves, second floor is for water to fall a z-level to create mist and to control the amount of water flow. It is also possible to dig out more of the aquifer to increase water flow if needed. You can use this water elsewhere or let it evaporate.{{Verify}}

== General comments ==

* Evaporation is nonexistent as long as the pumps are working and the water is moving, even above ground.{{Verify}}

* Job cancellation spam is possible if the water is filled to 4/7 or greater and a dwarf walks where the water falls. Even then, this can be greatly reduced by setting them as [[traffic#Setting Traffic Areas|restricted traffic]] areas, or completely prevented by blocking access to these tiles without blocking the water, such as by placing a [[statue]] underneath.

* Mud will form wherever the water falls. Subterranean [[tree]]s can sprout up and clog the system. Solutions to this problem include: [[statue]]s, [[road|paved roads]], constructed floors or [[fortification]]s, or to simply channel out the space once the mist generator is running.

* These systems work best with a single tile of water (7/7, at most) due to the way water descends z-levels. Any additional water will overflow into nearby tiles.

* Automated mist generators may significantly lower your [[Frames per second|FPS]], particularly if multiple generators are used.{{Verify}} This might be remedied by triggering via a [[repeater]] with a long delay or by one or more [[pressure plate]]s (perhaps set to activate by a passing dwarf).{{Verify}}

{{Translation
| dwarven = sôd
| elvish = enure
| goblin = guslo
| human = sitsu
}}

{{Category|Thoughts}}
{{Category|World}}
{{Category|Physics}}
[[Ru:Mist]]

Mist

2023-01-05T22:54:45Z

Kelvie: /* Ring generator */ Add information about the z=0 layer.

{{migrated article}}
{{Quality|Unrated}}
{{av}}
[[File:mist_example.jpg|thumb|270px|right|If skin pores could orgasm.]]
'''Mist''' is created by [[water]] [[Waterfall|falling]] from one [[Z-level]] to another, from [[DF2014:Ocean#Ocean_waves|ocean waves]], items or creatures skipping across water or just standard splashing. The mist is generated on levels below the top level (from which the water drops), but spreads out similarly to [[miasma]] and, therefore, can appear even on the top level, and lingers and spreads for a short time after any water stops falling. Walking through mist generates a happy [[thought]] for a dwarf, and can act to [[Cleaning|clean]] various contaminants off of dwarves.

Mist is separate from [[magma mist]] and [[steam]].

[[File:mist_preview.png|thumb|120px|right|Rampant [[screw pump]]s are a great mist source.]]

==Generating Mist==
=== Constructed waterfall ===
The easiest method is simply to use a constant source of water ([[Screw pump|pumped]] or [[channel]]ed) and let it fall more than 1 z-level next to a path that dwarves use regularly. The actual tile (you only need one) that the water drops should not be part of the path, as dwarves will believe they are in 7/7 water and cancel jobs - a statue on that tile will prevent this nicely, or place the fall itself to the side of the path and make that a [[Traffic#Setting Traffic Areas|restricted traffic]] tile.

[[Floor grate]]s or [[bars]] on every* tile adjacent to the water flow should be used as part of the drainage system (which should be larger than the intake system, just to be safe!), and to avoid [[mud]] on adjacent tiles. Use a door, hatch, floodgate or bridge linked to a [[lever]] to turn off the flow if/when desired.

: (* when designing this, remember that grates/bars [[Cave-in|do not support]] floor tiles!)

The problem with this setup is that this amount of constantly falling/flowing water can have a negative impact on your fps rate. Using a [[repeater]] to allow a non-constant flow, or linking the flow to a [[pressure plate]], where it will only fall when dwarves approach, will help this.

=== Ring generator ===
AncientEnemy [http://www.bay12forums.com/smf/index.php?topic=34407.0] devised a convenient way to generate mist. This method relies on the fact that [[screw pump|screw pumps]] pump [[water]] faster than water spreads out.[[Image:newmist.jpg|thumb|AncientEnemy's original simple mist generator.]]

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

Below is an example of a simple mist generator. The Z=0 level can be anything, a booze stockpile, [[barracks]] or even your [[Dwarven_atom_smasher|atom smasher]]. The z=-1 layer can also be identical to the z=0 level. Mist will also be generated there. Because the water never touches the floor there, you don't have to worry about muddy tiles.
<diagram>
Pump Floor (z=1)
▒▒▒▒▒▒
▒.[#2:0]÷[#2:1]÷[#].▒
▒[#2:1]÷ [#2:0]÷[#]▒ The water can go clockwise or counter clockwise.
▒[#2:0]÷ [#2:1]÷[#]▒ Make sure your pumps are correctly aligned.
▒.[#2:1]÷[#2:0]÷[#].▒
▒▒▒▒▒▒
</diagram>

A movie [http://mkv25.net/dfma/movie-1292-ubermistgenerator] best illustrates the operation.
[[File:Mist-ring-generator-z0.png|thumb|Mist ring generator (z = 1)]]
[[File:Mist-ring-generator-z-1.png|thumb|Mist ring generator (z = 0)]]

It is advisable to put statues under the holes in the bottom layer, so dwarves cannot go under the water, to displace the water, requiring a refill.

Note that if you put grates on the z = 1 layer, the mist will not spread upward, if that is desired.

=== Stack generator ===

A two-pump-stack can be used to lift a single tile of water and drop it back into the reservoir, generating mist (and [[Cleaning#Dwarven_Shower|cleaning dwarves]], if desired).

<diagram>

sideview

[#2:0]%%[#]_
[#6:0]%%[#]_
░░░░[#1:0]▄[#]░░░
░░░░░░░░

</diagram>

The lower (brown) pump (pumping right to left) raises the water from the reservoir on the right to floor level on the left, then the upper (green) pump (pumping left to right) raises that water to the air +2 z-levels above the reservoir. The water then falls through the floor grates ( _ ) into the reservoir, and the cycle can be repeated. Pump build order is important; build the green pump first, then the brown pump, to ensure the water is raised in a single tick. Since the water never sits at floor level, no containment walls are necessary (though mud will be created in the tile left of the brown pump). You can toggle power to the pumps as often as desired to provide happy thoughts without constant lag. If used for dwarf-cleaning, a water level of 2/7 or 3/7 will avoid job cancellations.

=== Light aquifer ===
If your embark location has a light aquifer, it is possible to build an unpowered mist generator-plus-bathing unit combination. You need two floors under the aquifer - lowest floor is for dwarves, second floor is for water to fall a z-level to create mist and to control the amount of water flow. It is also possible to dig out more of the aquifer to increase water flow if needed. You can use this water elsewhere or let it evaporate.{{Verify}}

== General comments ==

* Evaporation is nonexistent as long as the pumps are working and the water is moving, even above ground.{{Verify}}

* Job cancellation spam is possible if the water is filled to 4/7 or greater and a dwarf walks where the water falls. Even then, this can be greatly reduced by setting them as [[traffic#Setting Traffic Areas|restricted traffic]] areas, or completely prevented by blocking access to these tiles without blocking the water, such as by placing a [[statue]] underneath.

* Mud will form wherever the water falls. Subterranean [[tree]]s can sprout up and clog the system. Solutions to this problem include: [[statue]]s, [[road|paved roads]], constructed floors or [[fortification]]s, or to simply channel out the space once the mist generator is running.

* These systems work best with a single tile of water (7/7, at most) due to the way water descends z-levels. Any additional water will overflow into nearby tiles.

* Automated mist generators may significantly lower your [[Frames per second|FPS]], particularly if multiple generators are used.{{Verify}} This might be remedied by triggering via a [[repeater]] with a long delay or by one or more [[pressure plate]]s (perhaps set to activate by a passing dwarf).{{Verify}}

{{Translation
| dwarven = sôd
| elvish = enure
| goblin = guslo
| human = sitsu
}}

{{Category|Thoughts}}
{{Category|World}}
{{Category|Physics}}
[[Ru:Mist]]

Mist

2023-01-05T22:53:15Z

Kelvie: /* Ring generator */ Add v40 diagram for ring generator

{{migrated article}}
{{Quality|Unrated}}
{{av}}
[[File:mist_example.jpg|thumb|270px|right|If skin pores could orgasm.]]
'''Mist''' is created by [[water]] [[Waterfall|falling]] from one [[Z-level]] to another, from [[DF2014:Ocean#Ocean_waves|ocean waves]], items or creatures skipping across water or just standard splashing. The mist is generated on levels below the top level (from which the water drops), but spreads out similarly to [[miasma]] and, therefore, can appear even on the top level, and lingers and spreads for a short time after any water stops falling. Walking through mist generates a happy [[thought]] for a dwarf, and can act to [[Cleaning|clean]] various contaminants off of dwarves.

Mist is separate from [[magma mist]] and [[steam]].

[[File:mist_preview.png|thumb|120px|right|Rampant [[screw pump]]s are a great mist source.]]

==Generating Mist==
=== Constructed waterfall ===
The easiest method is simply to use a constant source of water ([[Screw pump|pumped]] or [[channel]]ed) and let it fall more than 1 z-level next to a path that dwarves use regularly. The actual tile (you only need one) that the water drops should not be part of the path, as dwarves will believe they are in 7/7 water and cancel jobs - a statue on that tile will prevent this nicely, or place the fall itself to the side of the path and make that a [[Traffic#Setting Traffic Areas|restricted traffic]] tile.

[[Floor grate]]s or [[bars]] on every* tile adjacent to the water flow should be used as part of the drainage system (which should be larger than the intake system, just to be safe!), and to avoid [[mud]] on adjacent tiles. Use a door, hatch, floodgate or bridge linked to a [[lever]] to turn off the flow if/when desired.

: (* when designing this, remember that grates/bars [[Cave-in|do not support]] floor tiles!)

The problem with this setup is that this amount of constantly falling/flowing water can have a negative impact on your fps rate. Using a [[repeater]] to allow a non-constant flow, or linking the flow to a [[pressure plate]], where it will only fall when dwarves approach, will help this.

=== Ring generator ===
AncientEnemy [http://www.bay12forums.com/smf/index.php?topic=34407.0] devised a convenient way to generate mist. This method relies on the fact that [[screw pump|screw pumps]] pump [[water]] faster than water spreads out.[[Image:newmist.jpg|thumb|AncientEnemy's original simple mist generator.]]

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

Below is an example of a simple mist generator. The Z=0 level can be anything, a booze stockpile, [[barracks]] or even your [[Dwarven_atom_smasher|atom smasher]]. The z=-1 layer can also be identical to the z=0 level. Mist will also be generated there. Because the water never touches the floor there, you don't have to worry about muddy tiles.
<diagram>
Pump Floor (z=1)
▒▒▒▒▒▒
▒.[#2:0]÷[#2:1]÷[#].▒
▒[#2:1]÷ [#2:0]÷[#]▒ The water can go clockwise or counter clockwise.
▒[#2:0]÷ [#2:1]÷[#]▒ Make sure your pumps are correctly aligned.
▒.[#2:1]÷[#2:0]÷[#].▒
▒▒▒▒▒▒
</diagram>

A movie [http://mkv25.net/dfma/movie-1292-ubermistgenerator] best illustrates the operation.
[[File:Mist-ring-generator-z0.png|thumb|Mist ring generator (z = 0)]]
[[File:Mist-ring-generator-z-1.png|thumb|Mist ring generator (z = -1)]]

=== Stack generator ===

A two-pump-stack can be used to lift a single tile of water and drop it back into the reservoir, generating mist (and [[Cleaning#Dwarven_Shower|cleaning dwarves]], if desired).

<diagram>

sideview

[#2:0]%%[#]_
[#6:0]%%[#]_
░░░░[#1:0]▄[#]░░░
░░░░░░░░

</diagram>

The lower (brown) pump (pumping right to left) raises the water from the reservoir on the right to floor level on the left, then the upper (green) pump (pumping left to right) raises that water to the air +2 z-levels above the reservoir. The water then falls through the floor grates ( _ ) into the reservoir, and the cycle can be repeated. Pump build order is important; build the green pump first, then the brown pump, to ensure the water is raised in a single tick. Since the water never sits at floor level, no containment walls are necessary (though mud will be created in the tile left of the brown pump). You can toggle power to the pumps as often as desired to provide happy thoughts without constant lag. If used for dwarf-cleaning, a water level of 2/7 or 3/7 will avoid job cancellations.

=== Light aquifer ===
If your embark location has a light aquifer, it is possible to build an unpowered mist generator-plus-bathing unit combination. You need two floors under the aquifer - lowest floor is for dwarves, second floor is for water to fall a z-level to create mist and to control the amount of water flow. It is also possible to dig out more of the aquifer to increase water flow if needed. You can use this water elsewhere or let it evaporate.{{Verify}}

== General comments ==

* Evaporation is nonexistent as long as the pumps are working and the water is moving, even above ground.{{Verify}}

* Job cancellation spam is possible if the water is filled to 4/7 or greater and a dwarf walks where the water falls. Even then, this can be greatly reduced by setting them as [[traffic#Setting Traffic Areas|restricted traffic]] areas, or completely prevented by blocking access to these tiles without blocking the water, such as by placing a [[statue]] underneath.

* Mud will form wherever the water falls. Subterranean [[tree]]s can sprout up and clog the system. Solutions to this problem include: [[statue]]s, [[road|paved roads]], constructed floors or [[fortification]]s, or to simply channel out the space once the mist generator is running.

* These systems work best with a single tile of water (7/7, at most) due to the way water descends z-levels. Any additional water will overflow into nearby tiles.

* Automated mist generators may significantly lower your [[Frames per second|FPS]], particularly if multiple generators are used.{{Verify}} This might be remedied by triggering via a [[repeater]] with a long delay or by one or more [[pressure plate]]s (perhaps set to activate by a passing dwarf).{{Verify}}

{{Translation
| dwarven = sôd
| elvish = enure
| goblin = guslo
| human = sitsu
}}

{{Category|Thoughts}}
{{Category|World}}
{{Category|Physics}}
[[Ru:Mist]]

File:Mist-ring-generator-z-1.png

2023-01-05T22:50:41Z

Kelvie: Mist ring generator (z = -1)

== Summary ==
Mist ring generator (z = -1)
== Licensing ==
{{Non-free Dwarf Fortress Screenshot}}

File:Mist-ring-generator-z0.png

2023-01-05T22:50:17Z

Kelvie: Mist ring generator (z=0)

== Summary ==
Mist ring generator (z=0)
== Licensing ==
{{Non-free Dwarf Fortress Screenshot}}

Keeping your dwarves unstressed

2023-01-05T06:25:05Z

Kelvie: Move incompatible advice to the bottom

{{migrated article}}
{{Quality|Unrated}}
{{av}}

Some tips on how to '''keep your [[Dwarf|dwarves]] [[stress]]-free''', thus reducing the chances of [[tantrum]]s, [[depression]]s and [[oblivious]]ness:

==General Tips==
* It is more important to keep your dwarves free from negative thoughts than it is to overwhelm them with positive thoughts. Showering Urist McFisherdwarf with ☼jaguar meat roast☼ does not mean a happy dwarf if Urist keeps dwelling over their grouchiness at being caught in the rain.

* Stressed dwarves with a high [[Personality trait|ANGER_PROPENSITY]] may lash out in a [[tantrum]], and severely injure or kill others; a corpse in your dining room will lead to horrified thoughts from any dwarf taking a quick booze stop. Make sure to de-stress these dwarves first, or, if lacking the ability to do so, [[expel]] them, [[Solitary confinement|lock them in their own rooms]], or experiment with [[Magma|radical cures]].

==Specific Dwarves==
* Dwarves that are highly prone to stress, i.e. a high [[Personality trait|STRESS_VULNERABILITY]] trait, are not suitable for the military or as [[nobles]]. You will have to remove them from these duties and, in extreme cases, isolate them with burrows to insulate them from [[Thought|stress-inducing stimuli]]. You might be able to get away with giving high-stress dwarves a "vacation" by disabling their labors or demote them for example from a captain to a mere soldier. Also, don't give high-stress dwarves the Refuse Hauling labor, since they often handle dead bodies.
* Dwarves who have to go outside for extended periods of time (like [[Fisherdwarf|fisherdwarves]] who work near the local [[lake]] or [[river]]) become stressed due to constant exposure to [[rain]] and long periods away from fun (not [[Fun|that kind]]) and their friends. You can give these workers their own little vacation by disabling their labors and letting them spend some time inside at the [[tavern]] until they regain their composure. Let an unstressed dwarf take care of the job for a while.
* Unless an overstressed dwarf is particularly important, it's often better to [[Emigration|retire]] them to one of your [[holding]]s and replace them with a fresh, unstressed migrant.
* '''Dwarf Therapist does not work with v50 as of 2023-01-04.''' Using a tool such as [[Utilities#Dwarf Therapist|Dwarf Therapist]], you can sort dwarves by stress level. There you can hold the mouse over the stress square to see the reasons why the dwarves are stressed and address them. Look up their preferences, assign them jobs that match their preferences, and build stuff they like, especially in their rooms.

==Living Quarters==
* Give your dwarves individual [[bedroom]]s rather than making them live in a communal [[dormitory]]. Not only will they get a good thought from sleeping in their own bedroom, they'll get good thoughts from admiring the furniture they own. Even a minimalist bedroom - a 1x1 grid containing only a bed, within a communal dormitory - helps significantly.
* Give them a bedroom to sleep in anyway, as dwarves do not enjoy sleeping on the ground.
* Improve the bedrooms by making them of respectable size, smoothing/engraving the ground, and adding basic furniture such as [[coffer]]s.
* If you still wish to use a communal bedroom to protect your dwarves from [[vampire]]s, designate each bed as a room itself. This way dwarves can keep an eye on each other and still have their own rooms.
** Overlapping the bedrooms will reduce the overall value of each "room" by a fixed percentage, but enough valuable furniture can easily compensate for this reduction. It is quite easy to give everyone great bedrooms this way.
** Alternatively, you can make the shared suites large enough that the bedroom designations do not overlap.
* Make Nobles' rooms better than other rooms. They have the telepathic ability to tell if the peasantry has slept better than them and it makes them unhappy.

==Locations==
* [[Temple]]s provide some of the strongest happy thoughts available. Conversely, the lack of a temple will produce constant stress in religious dwarves. You should always define a temple, even if it's just an empty room.
** Placing common destinations inside the temple will encourage dwarves to pray "while they're there". For example, storing clothing in a temple zone will give your dwarves a reason to visit and a chance to pray several times per year.
* [[Library|Libraries]] don't provide the same caliber of happy thoughts, but they can produce many more low-level happy thoughts.
** Be careful which dwarves you assign as scholars; some enjoy intellectual work, while others become stressed.
* [[Tavern]]s provide happy thoughts for otherwise idle dwarves. Smaller taverns will ensure that dwarves spend more time socializing and less time standing alone with a "Socialize" job.
** Make your tavern high [[room#quality|quality]]. You can increase its quality by adding high quality [[chair]]s and [[throne]]s, [[smoothing]] and [[engraving]] it, and putting in valuable [[instrument]]s, [[furniture]] like [[gold]] [[statue]]s, and [[artifact]]s.
** Make sure you never run out of [[booze]], since a sober dwarf is a stressed dwarf.
*** Make sure to have at least two different kinds of booze on hand, since dwarves will get bored if there's no variety in their drinks.
*** Try to have multiple different varieties of booze on hand, since dwarves get a happy thought when they drink their [[preference|preferred]] booze.
** [[Cook]]ing booze into prepared meals will satisfy a need for a "decent meal" and provide a happy thought to any dwarf that prefers that type of booze.
** Drinking without a [[goblet]] provides frequent negative thoughts; make sure you have enough goblets.

==Needs==
* Unmet [[need]]s may, depending on personality, cause an ever-growing burden of stress. Unfortunately, dwarves are not particularly good at meeting their own needs (and are incapable of meeting some), leaving you to awkwardly encourage them to do the thing they absolutely need to do but can't ever manage to find the time for.
* Individually profiled workshops with a linked repeating [[manager]] job can satisfy crafting, creative, and staying occupied needs. Placing those workshops in a temple will also encourage the dwarves to pray regularly.
* Acquiring trinkets occurs automatically when performing a "Store item in stockpile" job; creating a large, bin-less [[trade good]] stockpile and ensuring all your dwarves have the item hauling labor enabled will give them all a chance to acquire something. Dwarves who are too busy with other tasks, though, may never satisfy this need. You can lock problem dwarves in a room with trinkets and force them to haul items back and forth until they "acquire" one, but the necessary micromanagement is quite tedious.
* Wandering requires plant gathering, fishing (successfully), or hunting (successfully). Of the three, fishing appears to have the highest priority (making it more likely that busy dwarves will participate), though leaving fishing enabled on multiple dwarves risks [[extinction|depopulating your site]].
* The need to help somebody is difficult to fulfill when nobody is in need of help. Assigning particularly hardy dwarves to operate pumps continuously will create regular opportunities for "helpful" dwarves to bring them water, though ensuring that all the needy dwarves get a turn being "helpful" is difficult to automate.
* Needs to spend time with friends and family will occur even when dwarves have no friends or family in the fortress. The frustrated overseer, then, must arrange friendships and [[marriage]]s, respectively, in order to fulfill these needs.

==Fortress Improvements==
* Place highly valuable [[furniture]], if possible artifacts, in a high traffic area of your fort since dwarves get a positive thought if they pass right next to or over expensive furniture.
* Dwarves who [[cave adaptation|spend most of their time underground]] will become stressed when exposed to sunlight. Unfortunately, short of preventing cave adaptation in the first place, there isn't a good way to reduce the stress from being outside. Building a roof, particularly over commonly-traveled areas, can help limit the number of dwarves exposed to sunlight (and weather).
* Dwarves don't like to be out in rain, snow, or freakish weather. Build a roof to protect them from it.
* Keep at least a few [[cat]]s around to hunt down irritating [[vermin]]. [[Pasture]] some in with your food stockpiles. Note that this will create vermin remains, which need to be hauled to a refuse stockpile or dumped. Alternatively, use a [[trapper]] or two.
* Put a [[cage]] in a high traffic area (like the meeting area) and stuff it full of (non-[[pasture|grazing]]) tame animals so your dwarves can enjoy seeing their [[preferences|favorite]] type of animal.
** The [[elf|elven]] [[caravan]]s bring random animals, and you can request specific domestic animals from the dwarven caravan.
** You can use [[cage trap]]s to capture wild animals, [[Animal trainer|train them]].
** You can raid sites for tame animals. Elven, goblin, and kobold sites often have exotic creatures.
* Create a [[waterfall]] or [[mist|mist generator]] in a location all dwarves frequent regularly.
* Keep your fortress clean and avoid [[miasma]], or at least confine it to your refuse stockpile if it is underground.
* Most dwarves do not enjoy the sight of death, be it whole [[corpse]]s or small dismembered body parts like teeth and toes. Keep your refuse stockpile somewhere infrequently traveled, enclosed by doors so that passing dwarves do not see dead bodies, especially those of sentient creatures.
** Even better, build a [[garbage disposal]] to destroy refuse or dump it down a pit where no dwarf is likely to see it.

==Miscellaneous==
* Keep your dwarves [[clothes|clothed]]. A naked dwarf is a stressed dwarf. Specifically, they will need something to cover the upper body, such as a shirt, something to cover the lower body, such as trousers, and something on each foot, such as a sock or shoe.
* If a dwarf dies, [[coffin|bury them]] or [[memorial|engrave a memorial in their name]]. This will prevent even more stress for their friends, and [[ghost]]s to haunt your dwarves or your FPS.
* [[Pasture]] all dwarf [[pet]]s somewhere safe. Wandering pets are likely to die from goblins or construction accidents.
* Instead of [[Dwarven atom smasher|vaporising]] old dwarven clothes, rather sell them to the caravan. Otherwise, every destroyed masterpiece sock will stress its creator.
* Be careful with cooking masterpiece dishes. Dwarves tend to drop their ☼dog intestines roast☼ somewhere, and if it withers the cook becomes agitated.
* Restrict your mayor/expedition leader to low-stress areas. Overstressed dwarves will chase them down, outside in the rain if necessary, to complain about how utterly traumatized they are from being rained on.

{{Category|Thoughts}}
[[ru:Keeping your dwarves unstressed]]

Keeping your dwarves unstressed

2023-01-05T06:24:07Z

Kelvie: Add note about v50 compatibility

{{migrated article}}
{{Quality|Unrated}}
{{av}}

Some tips on how to '''keep your [[Dwarf|dwarves]] [[stress]]-free''', thus reducing the chances of [[tantrum]]s, [[depression]]s and [[oblivious]]ness:

==General Tips==
* It is more important to keep your dwarves free from negative thoughts than it is to overwhelm them with positive thoughts. Showering Urist McFisherdwarf with ☼jaguar meat roast☼ does not mean a happy dwarf if Urist keeps dwelling over their grouchiness at being caught in the rain.

* Stressed dwarves with a high [[Personality trait|ANGER_PROPENSITY]] may lash out in a [[tantrum]], and severely injure or kill others; a corpse in your dining room will lead to horrified thoughts from any dwarf taking a quick booze stop. Make sure to de-stress these dwarves first, or, if lacking the ability to do so, [[expel]] them, [[Solitary confinement|lock them in their own rooms]], or experiment with [[Magma|radical cures]].

==Specific Dwarves==
* '''Dwarf Therapist does not work with v50 as of 2023-01-04.''' Using a tool such as [[Utilities#Dwarf Therapist|Dwarf Therapist]], you can sort dwarves by stress level. There you can hold the mouse over the stress square to see the reasons why the dwarves are stressed and address them. Look up their preferences, assign them jobs that match their preferences, and build stuff they like, especially in their rooms.
* Dwarves that are highly prone to stress, i.e. a high [[Personality trait|STRESS_VULNERABILITY]] trait, are not suitable for the military or as [[nobles]]. You will have to remove them from these duties and, in extreme cases, isolate them with burrows to insulate them from [[Thought|stress-inducing stimuli]]. You might be able to get away with giving high-stress dwarves a "vacation" by disabling their labors or demote them for example from a captain to a mere soldier. Also, don't give high-stress dwarves the Refuse Hauling labor, since they often handle dead bodies.
* Dwarves who have to go outside for extended periods of time (like [[Fisherdwarf|fisherdwarves]] who work near the local [[lake]] or [[river]]) become stressed due to constant exposure to [[rain]] and long periods away from fun (not [[Fun|that kind]]) and their friends. You can give these workers their own little vacation by disabling their labors and letting them spend some time inside at the [[tavern]] until they regain their composure. Let an unstressed dwarf take care of the job for a while.
* Unless an overstressed dwarf is particularly important, it's often better to [[Emigration|retire]] them to one of your [[holding]]s and replace them with a fresh, unstressed migrant.

==Living Quarters==
* Give your dwarves individual [[bedroom]]s rather than making them live in a communal [[dormitory]]. Not only will they get a good thought from sleeping in their own bedroom, they'll get good thoughts from admiring the furniture they own. Even a minimalist bedroom - a 1x1 grid containing only a bed, within a communal dormitory - helps significantly.
* Give them a bedroom to sleep in anyway, as dwarves do not enjoy sleeping on the ground.
* Improve the bedrooms by making them of respectable size, smoothing/engraving the ground, and adding basic furniture such as [[coffer]]s.
* If you still wish to use a communal bedroom to protect your dwarves from [[vampire]]s, designate each bed as a room itself. This way dwarves can keep an eye on each other and still have their own rooms.
** Overlapping the bedrooms will reduce the overall value of each "room" by a fixed percentage, but enough valuable furniture can easily compensate for this reduction. It is quite easy to give everyone great bedrooms this way.
** Alternatively, you can make the shared suites large enough that the bedroom designations do not overlap.
* Make Nobles' rooms better than other rooms. They have the telepathic ability to tell if the peasantry has slept better than them and it makes them unhappy.

==Locations==
* [[Temple]]s provide some of the strongest happy thoughts available. Conversely, the lack of a temple will produce constant stress in religious dwarves. You should always define a temple, even if it's just an empty room.
** Placing common destinations inside the temple will encourage dwarves to pray "while they're there". For example, storing clothing in a temple zone will give your dwarves a reason to visit and a chance to pray several times per year.
* [[Library|Libraries]] don't provide the same caliber of happy thoughts, but they can produce many more low-level happy thoughts.
** Be careful which dwarves you assign as scholars; some enjoy intellectual work, while others become stressed.
* [[Tavern]]s provide happy thoughts for otherwise idle dwarves. Smaller taverns will ensure that dwarves spend more time socializing and less time standing alone with a "Socialize" job.
** Make your tavern high [[room#quality|quality]]. You can increase its quality by adding high quality [[chair]]s and [[throne]]s, [[smoothing]] and [[engraving]] it, and putting in valuable [[instrument]]s, [[furniture]] like [[gold]] [[statue]]s, and [[artifact]]s.
** Make sure you never run out of [[booze]], since a sober dwarf is a stressed dwarf.
*** Make sure to have at least two different kinds of booze on hand, since dwarves will get bored if there's no variety in their drinks.
*** Try to have multiple different varieties of booze on hand, since dwarves get a happy thought when they drink their [[preference|preferred]] booze.
** [[Cook]]ing booze into prepared meals will satisfy a need for a "decent meal" and provide a happy thought to any dwarf that prefers that type of booze.
** Drinking without a [[goblet]] provides frequent negative thoughts; make sure you have enough goblets.

==Needs==
* Unmet [[need]]s may, depending on personality, cause an ever-growing burden of stress. Unfortunately, dwarves are not particularly good at meeting their own needs (and are incapable of meeting some), leaving you to awkwardly encourage them to do the thing they absolutely need to do but can't ever manage to find the time for.
* Individually profiled workshops with a linked repeating [[manager]] job can satisfy crafting, creative, and staying occupied needs. Placing those workshops in a temple will also encourage the dwarves to pray regularly.
* Acquiring trinkets occurs automatically when performing a "Store item in stockpile" job; creating a large, bin-less [[trade good]] stockpile and ensuring all your dwarves have the item hauling labor enabled will give them all a chance to acquire something. Dwarves who are too busy with other tasks, though, may never satisfy this need. You can lock problem dwarves in a room with trinkets and force them to haul items back and forth until they "acquire" one, but the necessary micromanagement is quite tedious.
* Wandering requires plant gathering, fishing (successfully), or hunting (successfully). Of the three, fishing appears to have the highest priority (making it more likely that busy dwarves will participate), though leaving fishing enabled on multiple dwarves risks [[extinction|depopulating your site]].
* The need to help somebody is difficult to fulfill when nobody is in need of help. Assigning particularly hardy dwarves to operate pumps continuously will create regular opportunities for "helpful" dwarves to bring them water, though ensuring that all the needy dwarves get a turn being "helpful" is difficult to automate.
* Needs to spend time with friends and family will occur even when dwarves have no friends or family in the fortress. The frustrated overseer, then, must arrange friendships and [[marriage]]s, respectively, in order to fulfill these needs.

==Fortress Improvements==
* Place highly valuable [[furniture]], if possible artifacts, in a high traffic area of your fort since dwarves get a positive thought if they pass right next to or over expensive furniture.
* Dwarves who [[cave adaptation|spend most of their time underground]] will become stressed when exposed to sunlight. Unfortunately, short of preventing cave adaptation in the first place, there isn't a good way to reduce the stress from being outside. Building a roof, particularly over commonly-traveled areas, can help limit the number of dwarves exposed to sunlight (and weather).
* Dwarves don't like to be out in rain, snow, or freakish weather. Build a roof to protect them from it.
* Keep at least a few [[cat]]s around to hunt down irritating [[vermin]]. [[Pasture]] some in with your food stockpiles. Note that this will create vermin remains, which need to be hauled to a refuse stockpile or dumped. Alternatively, use a [[trapper]] or two.
* Put a [[cage]] in a high traffic area (like the meeting area) and stuff it full of (non-[[pasture|grazing]]) tame animals so your dwarves can enjoy seeing their [[preferences|favorite]] type of animal.
** The [[elf|elven]] [[caravan]]s bring random animals, and you can request specific domestic animals from the dwarven caravan.
** You can use [[cage trap]]s to capture wild animals, [[Animal trainer|train them]].
** You can raid sites for tame animals. Elven, goblin, and kobold sites often have exotic creatures.
* Create a [[waterfall]] or [[mist|mist generator]] in a location all dwarves frequent regularly.
* Keep your fortress clean and avoid [[miasma]], or at least confine it to your refuse stockpile if it is underground.
* Most dwarves do not enjoy the sight of death, be it whole [[corpse]]s or small dismembered body parts like teeth and toes. Keep your refuse stockpile somewhere infrequently traveled, enclosed by doors so that passing dwarves do not see dead bodies, especially those of sentient creatures.
** Even better, build a [[garbage disposal]] to destroy refuse or dump it down a pit where no dwarf is likely to see it.

==Miscellaneous==
* Keep your dwarves [[clothes|clothed]]. A naked dwarf is a stressed dwarf. Specifically, they will need something to cover the upper body, such as a shirt, something to cover the lower body, such as trousers, and something on each foot, such as a sock or shoe.
* If a dwarf dies, [[coffin|bury them]] or [[memorial|engrave a memorial in their name]]. This will prevent even more stress for their friends, and [[ghost]]s to haunt your dwarves or your FPS.
* [[Pasture]] all dwarf [[pet]]s somewhere safe. Wandering pets are likely to die from goblins or construction accidents.
* Instead of [[Dwarven atom smasher|vaporising]] old dwarven clothes, rather sell them to the caravan. Otherwise, every destroyed masterpiece sock will stress its creator.
* Be careful with cooking masterpiece dishes. Dwarves tend to drop their ☼dog intestines roast☼ somewhere, and if it withers the cook becomes agitated.
* Restrict your mayor/expedition leader to low-stress areas. Overstressed dwarves will chase them down, outside in the rain if necessary, to complain about how utterly traumatized they are from being rained on.

{{Category|Thoughts}}
[[ru:Keeping your dwarves unstressed]]

Dwarf Fortress Wiki talk:Versions

2023-01-02T19:41:45Z

Kelvie: /* Is there an easy way to just paste images from the clipboard? */ forgot signature

{{archive|
# [[DF Talk:Versions/Archive 1|Page 1]]}}

== Version 0.31.19 starts a new DF generation? ==

My reading of Toady's comments on the release of 0.31.19 is that it came out basically because he felt it would take too long to get DF all the way to 0.32. With the ore changes, the sitefinder changes, the addition of grazing and several different industries, there's a lot of changes between 31.18 and 31.19. So I'm thinking it might be a good idea to call it the first release of DF2011 - and what we refer to as "DF2010" would then become 0.31.18.

Thoughts? --[[User:DeMatt|DeMatt]] 07:06, 28 February 2011 (UTC)

==Revisiting Redirects==

I wasn't around when the redirect policy was created, and I'm having trouble understanding the rationale. The example claims that linking [[Main:Cheese]] to [[cv:Cheese maker]] is problematic...but mainspace only ever redirects to the current version. If the best target in the current version is cheese maker, why not link to it directly? (It's not, at least for Cheese, since [[DF2012:Cheese]] exists now.) The explanation seems to be claiming that 40d articles that link to Cheese will follow the Mainspace link--but that hasn't been the case for a long while now. Articles in 40d automatically link against other articles in 40d, so that version remains internally consistent no matter where mainspace links to in the current version. For a current example, what do we gain by linking [[Main:Mead]] to [[cv:Mead]] and linking [[DF2012:Mead]] to [[DF2012:Alcohol]]?

If this really is just an outdated procedure, I recommend we drop the mummery and allow mainspace to link to cv:(best target). Double redirects ''may'' work (sometimes, but [[Main:Mead]] demonstrates a common problem where automatic redirection fails), but if they are unnecessary I think they should be avoided, partly because of problems like [[Main:Mead]] and partly because of the effort required to protect double redirects from users who believe they are problematic.--[[User:Loci|Loci]] ([[User talk:Loci|talk]]) 20:16, 8 January 2014 (UTC)

:I was just thinking that. I'm currently attempting to write a basic extension to eliminate the need for mainspace redirects entirely, although Mediawiki's class structure may make this more difficult than I had hoped (the only method I've found for resolving redirects takes the ''article text'' instead of a title, e.g. "#REDIRECT ..."). I do agree that the current situation with redirects isn't ideal, so I'm hoping this will work better (once I get it to work). --[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 20:42, 8 January 2014 (UTC)

Okay, that wasn't quite as clear as I meant it to be. In general, I think this is a tricky situation. Mediawiki wasn't designed to have five content namespaces, and certainly not chains of redirects between them. The problem that was pointed out in the [[DF:REDIR|policy]] is the fact that with:
Main:Foo -> cv:Bar
pages in the cv: namespace can't use [[<nowiki/>foo]], since the namespace links modification causes it to be treated as [[<nowiki/>cv:foo]] instead, which doesn't exist. The current suggested solution is this:
Main:Foo -> cv:Foo -> cv:Bar
This fixes the problem of [[<nowiki/>foo]] not working on cv pages, but creates issues with double redirects not always working. Another solution, which is more intuitive to new editors, is:
Main:Foo -> cv:Bar
cv:Foo -> cv:Bar
Both require creating two redirects. The first method has the advantage of ''ensuring'' that the cv redirect exists (otherwise, main:foo would be a redlink), while the second has the advantage of working more reliably in a couple cases.

What I'm trying to do is make main:Foo "jump" to cv:Foo when cv:foo exists, ''even if main:foo doesn't exist'' (basically it would treat all mainspace pages as redirects to cv pages, but only if the cv page exists and not the mainspace page). I had main:Bar jumping to cv:Bar fine, but if cv:Foo redirected to cv:Bar, accessing main:Foo would mysteriously stop at cv:Foo even if I increased the redirect limit. What I'm trying to do now is follow the redirects internally, without relying on Mediawiki to do it automatically - unfortunately, that has proved to be harder than I had hoped (and I sent my web server into an infinite loop while trying). I will try to work on this some more when I get a chance, although I'm not sure when that'll be yet :(. For now, feel free to fix broken double mainspace redirects as necessary, as long as redirects in the DF2012 namespace stay pointing to the right page (and new mainspace redirects get added in the DF2012 namespace too). --[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 04:21, 9 January 2014 (UTC)

:You're treating cv like a namespace--it's not. It is simply shorthand for "fill in the current version here". [http://dwarffortresswiki.org/index.php?title=User_talk:Briess&diff=182404&oldid=181281 As I discovered a long time ago on a server not far away], linking from Main:Foo to cv:Foo tends to break redirection chains. If, instead of linking to cv:Foo, you link to DF2012:Foo, it might just work. It would, of course, be better if your patch could evaluate cv itself, but even if you have to hardcode the current version it's a single point of maintenance that requires update very infrequently. (For that matter, we could probably dispense with the cv hack entirely and just have a bot update mainspace links from DF2012 to DF201X when we switch to a new version.)--[[User:Loci|Loci]] ([[User talk:Loci|talk]]) 20:05, 9 January 2014 (UTC)
::I know cv isn't a namespace - I was just trying to avoid future confusion when the DF2012 namespace changes. It's interesting that changing "cv" to "DF2012" fixes some broken redirects, although I've found that simply making an edit to a broken redirect can usually fix it as well. I've actually had the most problems with double redirects when the second one (in the DF2012 namespace) doesn't use the DF2012 prefix (e.g. main:Foo containing <nowiki>[[cv:Foo]] and DF2012:Foo containing [[Bar]]</nowiki>). I'd rather keep the cv alias even if it isn't necessary for mainspace redirects when I get the patch to work, since it makes it easier to refer to the current version of the page (for example, several MDF articles contain links to a vanilla page for things that don't change in the mod).
::Also, using aliases like "cv" is supported by Mediawiki; in fact, several WMF wikis use them (for example, "[[wikipedia:WP:Redirects|WP:Redirects]]" on Wikipedia). It's quite likely that Mediawiki isn't processing double redirects using aliases correctly, though, since that's uncommon on most wikis. --[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 21:35, 9 January 2014 (UTC)

In light of the lack of support for the current redirect policy, I propose we replace the current redirect section with:

:Mainspace article pages should use the cv: alias when redirecting to a versioned page, which will automatically update the link when a new version is released. For example, page "Main:Foo" should redirect to page "cv:Bar" (where "Bar" is the page that best describes the topic Foo in the current version).

:Pages in mainspace should only redirect to an older versioned page if that content no longer exists in the current version of the game (e.g. [[Cave river]], [[Chunk]]). In these cases the cv: alias cannot be used.

:Pages inside a versioned namespace should not use the cv: alias. Instead, they should redirect to the best page within that versioned namespace (e.g. [[DF2012:Dodging]], [[v0.31:Drink]]).

:Due to limitations of the wiki software, double redirects should be avoided if possible. When fixing double redirects in mainspace, please make sure to use the cv: alias as appropriate.

If no one objects, I will make this change in a few days.--[[User:Loci|Loci]] ([[User talk:Loci|talk]]) 20:21, 15 January 2014 (UTC)

:Okay with me. It may be worth mentioning that double redirects only really need to be changed when they don't work (since changing a lot of redirects that work isn't necessary), but I think it's clearer and more relevant than the current policy. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 00:26, 16 January 2014 (UTC)

Done.--[[User:Loci|Loci]] ([[User talk:Loci|talk]]) 20:55, 22 January 2014 (UTC)

I was finally able to get my extension to work after being motivated by one too many malfunctioning redirects. It now causes nonexistent pages in the main namespace to behave exactly like redirects to their DF2012 counterparts (when linked to, accessed directly, and transcluded). Double redirects also work (up to 100, in fact, although that was a temporary safety measure that I'll probably change). This means we'll be able to safely get rid of all mainspace redirects (redirects that redirect to something other than "cv" will still function if not deleted). —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 01:20, 14 March 2014 (UTC)
:What about articles which don't exist in the current version but do exist in older versions? Will those still need mainspace redirects, or will your extension be able to automatically redirect them to v0.31/40d/23a? --[[User:Quietust|Quietust]] ([[User talk:Quietust|talk]]) 01:29, 14 March 2014 (UTC)
::It ignores all mainspace pages that actually have content, including redirects, so pages like [[masons guild]] won't be affected (unless deleted). —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 01:47, 14 March 2014 (UTC)

Done and deployed. [[Cat]] is still treated as a redirect, even though I just deleted it (try clicking on the "redirected from" link). Pages that exist are ignored, so [[Masons guild]] and [[History of Dwarf Fortress]] still function normally (as a redirect to a 23a page and a non-redirect, respectively). —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 18:57, 14 April 2014 (UTC)

I'm sending around a bot right now to delete all redirects of the format "foo -> cv:foo" (a surprising number don't fit this format, so I'm leaving them alone for now). —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 20:43, 14 April 2014 (UTC)

:I'm confused. Do we use double redirects or not? Is there a single place we define our linking policy (including redirects), and is it updated?
:I had trouble linking to [[Consolidated_development]] in [[v0.34:Dragon]]. It kept pointing to v0.34:Consolidated_development, which does not exist. I ended up linking to Main:Consolidated_development to make it work. --[[User:Nahno|Nahno]] ([[User talk:Nahno|talk]]) 10:18, 1 July 2014 (UTC)

::That's a separate problem altogether - links in the versioned namespaces (v0.34, v0.31, 40d, 23a) automatically link to pages within their namespace. I may be able to set up a fallback to mainspace once I'm able to deploy again, but for now the "main:" alias is the intended solution. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 11:36, 1 July 2014 (UTC)

== Google often directs people to the 0.31 page ==

I've noticed a couple of times that finding a wiki page from an external search will often drop me onto a page from an older version. Is it possible to mitigate this somehow for new players? I could imagine something like redirecting old:Bar -> cv:Bar unless the user has come from old:Foo; no idea if that would actually work though. [[User:PeridexisErrant|PeridexisErrant]] ([[User talk:PeridexisErrant|talk]]) 11:48, 4 May 2014 (UTC)

:As a temporary solution, I could write a script that displays a banner of some kind if the user came from an external site. I'll ask Briess if he can do anything on the server level to increase the weighting of the current version's pages. (Obviously there are situations where people are looking for old pages, like [[23a:dungeon master]], so we don't want to disable indexing entirely on old pages.) —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 17:03, 4 May 2014 (UTC)

== DF2014? ==

As Toady [http://www.bay12games.com/dwarves/ draws closer to a new release], it might be worthwhile to discuss the addition of a new version to the wiki. The upcoming release covers two years of changes and introduces a number of new plants, foods, drinks, multi-tile trees, climbing, jumping, etc., so it is likely to have significant changes from the current DF2012. To avoid having people start new pages (and lose all the effort spent refining the prior version's page), I think it would be best to have a bot automatically copy over the DF2012 pages as a starting point for DF2014. I would suggest that these copied pages include a noticebox template mentioning that the content may be outdated, so that we can easily track which pages have been reviewed. I think either the {{tl|version check}} or {{tl|old}} template would work. --[[User:Loci|Loci]] ([[User talk:Loci|talk]]) 19:43, 5 May 2014 (UTC)

:This is what [[User:QuietBot]] did after the 0.34 release, so it's certainly possible to use the same script to migrate to DF2014. I would like a way of tagging migrated pages, since inaccuracies in some pages went unnoticed for months after they were migrated. Since {{tl|old}} is already in use, {{tl|version check}} may be a better solution (it can be reworded slightly, or we can make a separate template for DF2014 migration). —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 19:23, 1 June 2014 (UTC)
:Made [[Template:DF2014 migrated]] as an example. Any thoughts? —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 19:32, 1 June 2014 (UTC)

== Redirects inconsistency ==

Following a redirect is supposed to be exactly the same as going straight to the page it redirects to, but this actually isn't the case:
* Go to [[Seeds]] and you get [[v0.34:Seed]] (outdated)
* Go to http://dwarffortresswiki.org/index.php?title=Seeds&redirect=no and click on the link and you get to [[DF2014:Seed]] (current)
So if you search for "seed", the top result is the DF2014 version. But search for "seeds" and you get the redirect, which sends you to the outdated page instead. [[User:Hairy Dude|Hairy Dude]] ([[User talk:Hairy Dude|talk]]) 23:22, 22 February 2015 (UTC)

While I'm talking about redirects, it seems redirects to sections don't work: see [[DF2014:How do I manage my seeds and crops]]. I know MediaWiki is capable of this trick because Wikipedia does it. [[User:Hairy Dude|Hairy Dude]] ([[User talk:Hairy Dude|talk]]) 23:32, 22 February 2015 (UTC)

:I have absolutely no idea why [[seeds]] redirects to a v0.34 page - it could be a Mediawiki bug. The section links issue is due to a known issue in the redirect extension we use, which has yet to be fixed. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 00:01, 23 February 2015 (UTC)
:It looks like deleting both [[Seeds]] and [[DF2014:Seeds]] fixed things (by allowing AutoRedirect to handle the redirects instead). Feel free to tag any others with {{tl|bad redirect}}. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 00:03, 23 February 2015 (UTC)
::It gets stranger. [[Vial]] redirects explicitly to [[cv:Flask]] which displays (when you look at it with &redirect=no) as [[DF2014:Flask]], but still goes to the v0.34 version. It seems redirects interpret the cv: pseudo-namespace (or whatever it's called) in an outdated way. [[User:Hairy Dude|Hairy Dude]] ([[User talk:Hairy Dude|talk]]) 18:08, 23 February 2015 (UTC)
::I've added a note to this page about this issue. If it gets resolved, the note should be removed. [[User:Hairy Dude|Hairy Dude]] ([[User talk:Hairy Dude|talk]]) 21:04, 23 February 2015 (UTC)

==Reorganizing versions==

The internet deals with moved content... poorly. Google is still linking to v0.34 pages more than a year after the switch to "DF2014", and even the wiki software still has cached links pointing to the old version pages.

I propose reorganizing versions on the wiki to avoid moving content whenever possible. Instead of having a temporary "current version" namespace that changes occasionally, all the current information gets promoted to the Main namespace. When the next version split occurs, the Main articles as of a certain revision number can be copied to the newly-created permanent "old version" namespace, while all the current information remains in Main. This not only fixes the link rot issue, but it has a few other benefits as well: fewer administrative tasks, no lockdown (a historical version of the Main pages can be copied at any point, even if the Main articles are already modified for the new version), almost all the article history is maintained in the Main article (instead of being spread unevenly across multiple versions), no "temporary" namespaces are needed, fewer problematic long redirect chains, and hopefully less user confusion (since Main gets priority in search results, etc.).

As an example, today we would not have a DF2014 namespace (which is good because "temporary" namespaces historically disappear anyway). If you ran a search for [[seed]] you'd end up at Main:seed, which would have all the current information on seeds. The version box at the top of the page would still link to the older versions of the seed article. When a new version is released, an admin would choose a revision number and copy the Main:seed article as it exists at that revision number to v0.40:seed. That's it. One historical copy that needs little to no new editing, and zero redirections/moves.--[[User:Loci|Loci]] ([[User talk:Loci|talk]]) 19:02, 27 July 2015 (UTC)

:Makes sense to me. It would involve a lot of work, though (e.g. fixing templates and categories to account for the current version being in mainspace), although that should be doable thanks to {{tl|category}}, {{tl|version switch}}, etc.. A bot could be set up to copy revisions from before a release date as well, which would be more difficult (and maybe slower) than a direct copy, but not severely. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 17:24, 30 July 2015 (UTC)

:Actually, there are a few issues with that, namely that there wouldn't be an easy way to distinguish between versioned and non-versioned mainspace pages. There are ways to resolve Google search priority (we can exclude pages from older versions from search engine results if there are newer versions of those pages available, for example). —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 19:47, 6 August 2015 (UTC)

::There aren't very many non-versioned mainspace pages, and determining if a page is versioned is as simple as looking for the version template and/or categories added by the version template (e.g. copy [http://dwarffortresswiki.org/index.php/Category:Current this category] instead of Main:*). The problem with "suggesting" newer pages to Google is that they obviously aren't crawling our wiki regularly (if they were, the fact that the mainspace redirects point to new pages would automatically be picked up). Even if your Google hints worked they wouldn't do anything for all the other broken links out on the 'net.--[[User:Loci|Loci]] ([[User talk:Loci|talk]]) 20:35, 6 August 2015 (UTC)

::: Google actually crawls the wiki constantly - we probably get crawl hits from google for a continuous block of 2-3 hours per day, each and every day. Why they are slow to update is beyond me though. I can't remember why we didn't do this initially, but there was a technical limitation involved if I remember correctly. --[[User:Briess|Briess]] ([[User talk:Briess|talk]]) 22:05, 6 August 2015 (UTC)

::: There are <meta> tags that can be used to hide pages from search results (for search engines that recognize them, that is). Searching for {{tl|av}} or [[:Category:Current]] might work, although we'd have to make sure all of the DF2014 pages include that (some pages don't, particularly some disambiguation pages, although all of them should). —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 22:53, 6 August 2015 (UTC)

:Is there a particular reason main and current are separate to begin with?—[[User:CLA|CLA]] ([[User talk:CLA|talk]]) 00:17, 7 August 2015 (UTC)

::It's mostly intended to distinguish between versioned and non-versioned pages and make version-related templates simpler to work with, since every versioned page has a namespace. I wasn't active here in 2010 when this system was created, so Briess and Emi would know more.
::Another issue I just thought of with Loci's suggestion is categories - currently, categories like [[:Category:Animals]] are used to organize the versioned sub-categories. Sure, we can change {{tl|Category}} to categorize mainspace pages in [[:Category:v0.40:Animals]] or [[:Category:DF2014:Animals]], but that would be less straightforward because there wouldn't be a namespace with that name (until pages are migrated when a newer major version is released). —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 13:05, 7 August 2015 (UTC)

:Moving current pages to the main namespace sounds like a great idea. -[[User:Jecowa|Jecowa]] ([[User talk:Jecowa|talk]]) 20:47, 4 January 2018 (UTC)

Another thought: dealing with migrating redirects could be difficult with this proposal - specifically, determining which redirects should be migrated to a versioned namespace. Redirects can't contain {{tl|av}}, at least not before ``#REDIRECT``. I ''think'' it would be possible to copy pages in two stages, though - all non-redirects first, then all redirects whose targets were also copied. Thoughts? Anything I'm missing? —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 23:41, 27 June 2019 (UTC)

Some subpages (particularly /raw and /Edit notice) also deliberately lack {{tl|av}}, although those shouldn't be too hard to handle. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 00:35, 9 July 2019 (UTC)

:Redirect pages (and all other edge cases I've looked at) can be included in categories (like [[:Category:Current]]) to determine whether or not they should be copied into an archival version. But if the redirects are "properly qualified" then they can all be copied over blindly. Mainspace redirects pointing to versioned information should use a blank namespace (which will be automatically constrained to the archival namespace); mainspace redirects pointing to unversioned information should use an explicit "Main" (which will automatically link back to the unversioned page). Then, when [[[[Toady]]]] gets copied to [[[[v0.4x:Toady]]]] it will point back to [[[[Main:Toady One]]]]. Meanwhile, [[[[Beer]]]], copied to [[[[v0.4x:Beer]]]], will properly point to [[[[v0.4x:Alcohol]]]].--[[User:Loci|Loci]] ([[User talk:Loci|talk]]) 20:00, 14 July 2019 (UTC)

::I think qualifying redirects is the best solution here - categorizing redirects manually is another possible source of errors, since categories (or a lack thereof) would only be visible on the redirect page itself, and [[:Category:Current]] is a hidden category. Copying over mainspace redirects into versioned namespaces would also resolve some issues that have come up due to those not reliably existing currently. I should be able to set up a bot script to add "main:" to current mainspace redirects (and it shouldn't break anything, since those redirects go to other mainspace pages anyway). —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 21:57, 14 July 2019 (UTC)

(Note: I wrote all of this without noticing the previous discussion above.) I was wondering, when the wiki creates a new namespace for a major release again, if it is possible to ''not'' create a namespace for the next current version (e.g. "DF202x") and instead have the mainspace articles (which are currently redirects) become the new cv and move the content there. Therefore, [[cv:Cat]] would just be "[[Cat]]" (or [[Main:Cat]]).

Certain namespace-related templates like [[Template:Ns/0]] would need to be changed, though nothing significant as far as I know. For most cases, any "DF2014" would be replaced with "Main" or even blank. There's also multiple extensions handling the current namespace system and they may need to be modified too, though I'm not sure if or how much. I'm guessing based on the discussions above that it will change stuff up.

My reason is the current namespace is increasingly becoming more anachronistic. "DF2014" could be misinterpreted as "this page is about the 2014 version of the game" or "this page was last updated in 2014", which I've seen a few people in forums mention. Granted that [[Template:Av]] is on the top of very article, I still think the namespace is inconsistent with the recentness of the article. But how is this related to what I'm asking for? Let's say we continue the current system: if we happen to do a new namespace change this year and create DF2020, the next major release (after graphics/UI) will be mythgen, which is estimated to take several years to develop (the Big Wait), and so the anachronism will start over again. The proposed way will prevent this from occurring for the next major release and every release thereafter.

I think the confusion with having a namespace that becomes old-fashioned overtime supersedes the confusion with not marking current versioned articles with a namespace. Most users just search "Cat" on the search bar and naturally expect to get information about the latest release of DF. So if users go a page that's just titled "Cat", they won't expect outdated info about cats from a previous release. That's how the current system works anyways. We'll be skipping the two-step process that we have now. It'll make several wiki tasks much simpler as well. Editors can create new articles for current versions without remembering to add a namespace. It'll fix any existing issues with (double) redirects; instead of [[Main:Kitten]] redirecting to [[cv:Kitten]], which goes to [[DF2014:Kitten]], which then redirects to [[DF2014:Cat]], [[Main:Kitten]] would just redirect to [[Main:Cat]]. And the cv: alias will no longer be necessary since "cv:" = "Main:" and will be forever.

There's no need to differentiate the current version and previous versions with a namespace for the current version is what I'm saying. Articles of previous versions will retain their respective namespaces. Users will still type "40d:Cat" to go to the 40d version of the article, but if they want the current version, they'll just type "Cat" (like now). The mainspace containing the "live" version of an article is natural and would create no uncertainty when browsing the wiki. And it would simplify the wiki somewhat and future-proof this anachronism problem. As a bonus, this change will also prevent web search engines from showing previous version pages when typing "DF cat" or something. (This isn't happening right now as DF2014 has been the current namespace for ~6 years, but it'll happen again when everything moves to a new namespace.)

This is the gist of it, and I may have ignored most of the problems with this proposal. I have personally wished for the whole version namespacing be made less complicated and have been seeking for a solution, and I feel like this is the best way to go about in the future. – [[User:Doorkeeper|Doorkeeper]] 21:27, 14 August 2020 (UTC)

:<s>Whoops, looks like Loci already proposed this exact thing long ago. I definitely missed that discussion and should have checked first. My apologies. I'll move my text to that section and remove this one. – [[User:Doorkeeper|Doorkeeper]] 21:36, 14 August 2020 (UTC)</s> Done. – [[User:Doorkeeper|Doorkeeper]] 21:40, 14 August 2020 (UTC)

:The main issue I have with that is that putting pages about the current version in a namespace also differentiates between those pages and pages not about ''any'' version (for example, [[Toady One]] does not need a 40d or v0.34 page). Yes, we can use {{tl|av}} to mark versioned pages, but people often forget to add that to new pages. The current system also allows determining whether a page is versioned or not from its title, which makes migrations a lot faster. Relying on {{tl|av}} would require either reading the content of every page (which would slow scripts down significantly) or cross-checking with the list of all pages including the template (feasible, but a bit more complicated, and still susceptible to missing templates). I suppose that manually fixing and migrating pages missing {{tl|av}} later wouldn't be too much work, though.
:I am definitely in favor of changing "DF2014" (or a new namespace) to "Current", though. I was in favor of "DF2014" in 2014, but I don't think it makes sense anymore, and "Current" seemed to be a popular alternative in both the DF2012 and DF2014 discussions on the matter. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 04:02, 16 August 2020 (UTC)

== Weird redirect behaviour ==

[[Pump stack]] redirects to [[cv:Screw pump#Pump stack]]. If you look at the redirect itself it says it redirects to DF2014 namespace, which is correct. But if you actually follow the redirect, it goes to v0.34 namespace. [[User:Hairy Dude|Hairy Dude]] ([[User talk:Hairy Dude|talk]]) 16:10, 20 August 2018 (UTC)
:Yeah, that's part of the issue described in the above section (the wiki caching part, not on Google's end.) —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 15:00, 21 August 2018 (UTC)

== v50 organization ==

Some wiki admins have had a talk on Discord and decided that the most sustainable path forward is to put content for all future versions of DF in the main namespace. We will be working on a bot to do this in the next few days. Feel free to chime in with suggestions here. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 22:56, 14 December 2022 (UTC)

:Is it maybe possible to do backwards-namespacing? Like we have a "Main" namespace, which people are free to update, and whenever there's a new version of DF the "Main" namespace is copied into a namespace for the then old version, much like how you'd branch a stable branch from a development branch when working with a git-project? [[User:Therahedwig|Therahedwig]] ([[User talk:Therahedwig|talk]]) 23:13, 14 December 2022 (UTC)

::Yeah, we could do that if we decide to. We were talking about doing that for v50, actually, and might still do something similar to preserve edit history if it doesn't end up being too hard to automate. Our hope is that we will not introduce new namespaces for v50 -> v5x, unless there is a serious breaking change (and hopefully there isn't one). But if we change our mind, one advantage of the type of migration you mentioned is that it can be done retroactively - we can copy historical revisions that were current at the time of the release, and would only lose some typo fixes made after the release that apply to earlier versions as well. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 02:11, 15 December 2022 (UTC)

ETA is < 24 hours. Doing some final checks on a migration script. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 07:08, 19 December 2022 (UTC)

: We should really have a task list as there are many things that change and need updating. Including but not limited to:
:* Most templates that used the previous namespace convention broke, including nav templates.
:* Many game files changed locations and their pages need to be updated.
:* Raws need to be updated.
:* Various features added, changed, removed.
:* UI has been changed -- though I am more inclined to wait for classic release to avoid extra work --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 06:56, 20 December 2022 (UTC)

"''Raws need to be updated.''" Including applying text wraparound where necessary, I suppose - more than a few of them have proven to be that special kind of...''difficult'' to navigate otherwise, shall we say? [[User:Silverwing235|Silverwing235]] ([[User talk:Silverwing235|talk]]) 12:52, 20 December 2022 (UTC)

:There is already a task list in the [[#v50 migration|section below]] that includes templates and raws, with an explanation. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 16:25, 20 December 2022 (UTC)

== v50 migration ==

The initial migration script is done. New content is in the '''main''' namespace, e.g. [[Cat]]. Old content is still at [[DF2014:Cat]]. History was migrated to the ''new'' (main namespace) articles.

I know several things are broken still. Please reply if you find any others:
<div style="border-left: 2px solid red">
* <s>Versioned templates haven't been migrated yet (e.g. {{tl|vermin}} on [[Ant]])</s>
** Fixed. Most were migrated by a bot.
* Raws are missing on all pages that use them.
** This also affects sidebars, such as on [[Cat]] and [[Microcline]].
** Update: The DFRawFunctions extension has been upgraded to include v50 raws, using the "v50:" prefix for filenames instead of "DF2014:". I haven't finished a migration script to create the /raw pages themselves, but they can typically be created manually by copying the DF2014 /raw pages and changing "DF2014" to "v50" everywhere. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 20:20, 1 January 2023 (UTC)
* Some pages where the DF2014 page was a redirect to a main namespace page that contained content were migrated incorrectly.
** In this case, the main namespace page is usually a redirect to itself. This can be fixed by undoing LethosorBot's edit to the main namespace page, then copying the content to the DF2014 page.
** Update: most seem to have been fixed manually - thanks! —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 19:41, 21 December 2022 (UTC)
* <s>Some main-namespace talk pages redirect to DF2014 talk pages. Some of these redirects work, and some (usually older ones) do not.</s>
** Fixed with a bot. Some redirects from talk pages to other deleted talk pages are now broken, e.g. [[Talk:Above_ground]] (exists) -> [[Talk:Tile attributes]] (redlink). I am leaving them like that because they redirect to where the talk page should be created, but I'm also fine with people deleting them if they really want to. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 19:41, 21 December 2022 (UTC)
* {{tl|quality}} for new articles is disabled (see below)
* Some links from DF2014 to Main weren't working: e.g. the version selector [[DF2014:Mason's workshop]] was linking to [[DF2014:Main:Mason's workshop]] instead of [[Main:Mason's workshop]]. I'm not sure exactly why, but I fixed it with a change to the NamespaceLinks extension. Let me know if you spot similar broken links. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 23:19, 21 December 2022 (UTC)
</div>

—[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 04:54, 20 December 2022 (UTC)
:The quality levels of the 50.03 pages seem to be missing. I'm not sure if that's covered under that first point. [[User:Trainzack|Trainzack]] ([[User talk:Trainzack|talk]]) 06:47, 20 December 2022 (UTC)
::If the the [[Dwarf Fortress Wiki:Quality]] feature can be made to work with namespace scheme change, I suggest to automatically assign the lowest quality rating to all pages, alternately add the {{tl|old}} to all pages. Otherwise there will be a lot of pages that will fall through the cracks. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 09:12, 20 December 2022 (UTC)
:::I disabled {{tl|quality}} in the main namespace because it would require some rework to make the rating script and the template work properly there. Feel free to take a stab at the template. I will see what can be done on the extension side. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 21:14, 20 December 2022 (UTC)
::::What needs to be done on the template side? I'm not sure I see too big of an issue leaving pages as "unknown-quality" for now (or just change the default to tattered) until we get the rating script working. Is that script up anywhere, anything that could be helped with? [[User:Vallode|Vallode]] ([[User talk:Vallode|talk]]) 11:10, 2 January 2023 (UTC)

It appears some pages are redirecting recursively and never resolving correctly, like the [[https://dwarffortresswiki.org/index.php?title=Character_table&redirect=no|character table]] and [[tileset repository]] 07:35, 20 December 2022 (UTC)
: Indeed, these can be caught here: [[Special:DoubleRedirects]] --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 07:51, 20 December 2022 (UTC)

It might be useful to change the notice title to "release information '''for editors'''" --[[Special:Contributions/142.59.195.176|142.59.195.176]] 10:26, 20 December 2022 (UTC)
:Can do. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 16:27, 20 December 2022 (UTC)
::New here, hello. Should we set a date where we remove/only show the banner for logged in users. There are (some) pages that have 4 different notices about the upgrade. [[Engraving]] is one such page, the top banner states "information for editors", we then have the "this page was migrated" banner, a version selection which warns the article might be inaccurate, and a smaller banner saying the page might need to be updated. Quite a lot of screen space, I think we can start to slowly reduce the amount of warnings this coming month? [[User:Vallode|Vallode]] ([[User talk:Vallode|talk]]) 10:07, 2 January 2023 (UTC)
Main talkpages seem to redirect to DF2014 talk. Not sure if it is intentional but I like it, though we should pay attention when creating new discussion relating to v50 ending up there.--[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 14:18, 20 December 2022 (UTC)
:That's unintentional. I specifically wrote the migration script to not move talk pages, but that has the side-effect of leaving any previously-created "Talk -> DF2014 talk" redirects intact. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 16:27, 20 December 2022 (UTC)

Yo Lethosor, are we adding graphic sprites for the pages in some way? Or are we waiting for you to add some sort of new template or something? I'm sure you don't need me to tell you that the current templates don't allow that. Not sure if I'm allowed to change/create any templates either, as I don't want to break things for hundreds of pages. Edit: And IF the icons are allowed, should they be left alone, or 2×-3× sized like how the Minecraft wiki does it? --[[User:Zippy|Zippy]] ([[User talk:Zippy|talk]]) 14:29, 20 December 2022 (UTC)
:Depends on which templates you mean. There are copyright concerns with uploading a premium sprite sheet, for instance. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 16:27, 20 December 2022 (UTC)
::I'm not talking about uploading an entire sprite sheet. I'm just talking about individual icons for each respective page. One image for cows, one for horses, one for werebeasts, etc. --[[User:Zippy|Zippy]] ([[User talk:Zippy|talk]]) 16:50, 20 December 2022 (UTC)
:::If we do that for every creature in the sprite sheet, that's not much different (in terms of copyright) from uploading the entire sprite sheet. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 17:09, 20 December 2022 (UTC)
::::Is there someone we can talk to about that? We finally get this new game with graphics, and then we can't use the very graphics of the game? No matter what the rules are, I'd say that would be the stupidest thing ever. I know I'm infamous here when it comes to copyright and images and stuff, but about 80% of game wikis out there are completely unofficial, and use game file images like no one's business. I can't imagine anyone's door being knocked on if we used the game's sprites, but I won't add any here until we have a go-ahead. --[[User:Zippy|Zippy]] ([[User talk:Zippy|talk]]) 17:14, 20 December 2022 (UTC)

:::::...I've made noise in Mayday's direction on this matter, at least (prob an incorrect maneuver, ''but'').[[User:Silverwing235|Silverwing235]] ([[User talk:Silverwing235|talk]]) 17:55, 20 December 2022 (UTC)
:::::: I hope some sort of arrangement can be made so we can use the new sprites with permission/limits, just as we are using the raw files. Otherwise we are all (devs and editors alike) shooting ourselves in the foot here.--[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 21:07, 20 December 2022 (UTC)

:::::::I just thought of something. We're supposedly not allowed to upload entire sprite sheets, right? What if - for the time being - we just use a few of them for the purpose of testing out new infoboxes? --[[User:Zippy|Zippy]] ([[User talk:Zippy|talk]]) 21:46, 20 December 2022 (UTC)
::::::::I don't know. If someone could ask Kitfox and post the response here, that would be great. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 21:47, 20 December 2022 (UTC)

:::::::::I've reached out to Alexandra, but she hasn't answered yet. Until then I found these old approvals from the previous community manager, Feeona: ([http://www.bay12forums.com/smf/index.php?topic=173474.msg8243633#msg8243633 link1], [http://www.bay12forums.com/smf/index.php?topic=176640.msg8243642#msg8243642 link2]). Waiting for a newer response until we begin mass uploads is probably the politer option, but like Zippy said, it is also standard for wikis to use game sprites with less approval. I second their idea of trying it out with a few images to test the infoboxes. On the extreme off-chance (and I do think it is) Kitfox protests we can always remove these few. --[[User:Voliol|Voliol]] ([[User talk:Voliol|talk]]) 22:19, 20 December 2022 (UTC)
:::::::::And here is a third, more official statement: ([http://www.bay12forums.com/smf/index.php?topic=173474.msg8249718#msg8249718 link3]). Perhaps that address of info@kitfoxgames.com is the better channel to ask for a confirmation, rather than Discord DMs, but I will be going to bed, so it is best if someone else does that. --[[User:Voliol|Voliol]] ([[User talk:Voliol|talk]]) 22:29, 20 December 2022 (UTC)
::::::::::Thanks for tracking this down! Ok, sprites should be fine, but let's avoid uploading the entire premium tileset as a single image, for instance (as the forum thread says, "use common sense"). —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 00:21, 21 December 2022 (UTC)
::::::::::: Looks good, permission is always preferable over fairuse, I think it is a win win for all involved. I agree that we shouldn't upload entire sprite sheets (e.g. there is no reason to upload the windmill from every direction or whole construction phase for workshops) and that there are a lot of details that needs to be ironed out through testing. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 05:07, 21 December 2022 (UTC)
:::::::::We have a green light on uploading all and any sprites. Their response to me can be seen [https://i.imgur.com/BhmHjzC.png here]. I'm sure someone else confirmed it before me. --[[User:Zippy|Zippy]] ([[User talk:Zippy|talk]]) 19:00, 21 December 2022 (UTC)

Shifting temporarily to a new issue, is the documentation of [[Template:ArticleVersion]] outdated? It would seem so to me, since the current version no longer has its own namespace, with the templates needing updating being different ones. --[[User:Voliol|Voliol]] ([[User talk:Voliol|talk]]) 18:30, 20 December 2022 (UTC)
:I think it is still accurate enough. We left open the possibility of making another namespace in the future, albeit with a different migration strategy - see [[#v50 organization|above]]. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 21:52, 20 December 2022 (UTC)

Some Changes to infoboxes might be needed. Too bad [[User:Doorkeeper]] isn't around. He did a great work with navbox project--[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 20:52, 21 December 2022 (UTC)

I just realized that raw files aren't stored as regular wiki pages but loaded via the DFRawFunctions extension (hence the need to update). Good news it's going to be handled in bulk, consistently and relatively easy to updated. Even better it's Lethosor problem ;) Also I just realized that all the "raw files" (txt files in the new vanilla folder) are released into the public domain. Both are probably not news to the vets but I'll leave it here for those who less up to date like myself. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 07:35, 22 December 2022 (UTC)

: I noticed that some templates aren't working properly in the new namespace, e.g. [[Basalt]] entry had its raw updated manually but the infobox fail to show any details. Cursory look suggest {{t|layerlookup/0}} need a minor tweak. This should do the work
:: Replace: <nowiki>{{layerlookup/aux|{{{{FULLPAGENAME}}/raw}}|uses={{{uses|}}}|wiki={{{wiki|}}}}}</nowiki>
:: With___: <nowiki>{{layerlookup/aux|{{</nowiki>:<nowiki>{{FULLPAGENAME}}/raw}}|uses={{{uses|}}}|wiki={{{wiki|}}}}}</nowiki>
: Not sure what the plan and ETA with raws update so I didn't touch this high usage template for now. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 08:11, 24 December 2022 (UTC)

::Please do feel free to make this update. I am still working on a script to create the <code>/raw</code> pages themselves. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 03:12, 1 January 2023 (UTC)

Wouldn't it be an idea to add to the Sitenotice to remove the {{tl|migrated article}} tag when an article has been fully updated? I see many articles that seem to be updated still have the tag. And/or advise to make use of the {{tl|verify}} for sections still in need of checking? --[[User:Halavus|Halavus]] ([[User talk:Halavus|talk]]) 10:12, 2 January 2023 (UTC)
:Probably a good shout. The "see this page" link does include the detail on removing but we should more explicitly encourage removing the banner once a page has at least been looked over. [[User:Vallode|Vallode]] ([[User talk:Vallode|talk]]) 11:01, 2 January 2023 (UTC)

== v50 specific issues ==
=== Graphics===
Follow up on the use of game sprites and the need to trying it out with a few images to test the infoboxes. First sprite [[:File:Beds v50.png]] was uploaded and used on [[Bed]] entry. Any thoughts? --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 18:06, 21 December 2022 (UTC)
:Seems like it should be rearranged to be horizontal. Also, has there been a serious discussion about copyright? Full screenshots are 100% fine, but you start going into a grey area when you upload pieces of a spritesheet. I'm of the opinion that it's all fine as long as it's inconvenient to reconstruct the full sheet from the individual images. Maybe a further restriction could be you shouldn't upload any of the art unless it's used in an infobox (maybe an exception for pieces of the UI). And one more restriction could be you shouldn't show everything, like in your bed example, maybe just the wooden bed is good enough, leave out the stone and metal, especially since those can only be made from strange moods. [[User:Brightgalrs|Brightgalrs]] ([[User talk:Brightgalrs|talk]]) 18:43, 21 December 2022 (UTC)
::Actually, your bed image is kinda bad for showing off what a bed looks like because it doesn't show the pillow/blankets. That might point to cropped screenshots being the best path, although less convenient for the uploader, as you don't get details left out. [[User:Brightgalrs|Brightgalrs]] ([[User talk:Brightgalrs|talk]]) 18:46, 21 December 2022 (UTC)
::I created a new license template [[Template:Copyright game]], based it on the way the RimWorld wiki does things. Call it a prototype, but it's probably how your bed image should be labelled. Indeed, I added it to it already. [[User:Brightgalrs|Brightgalrs]] ([[User talk:Brightgalrs|talk]])

::: I agree that the horizontal arrangement would suit better here and that we should strive to represent how things look in-game. Otherwise, I am not too concerned about people being able to reconstruct anything (lets just say that ''anyone'' interested in that can get the real thing from the game files), also it seem we have permission to use the sprits on top of fairuse. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 19:55, 21 December 2022 (UTC)

::: Modifying the existing template to allow the inclusion of the new sprites is easy (Something like [https://ibb.co/zFXCrjd this]?) The big question is the matter of consistency is there any exceptions that will break the format (size wise with variant bloat for example), the sprite naming format, etc --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 20:44, 21 December 2022 (UTC)
::: If we are going to show a variant for each material type, then maybe these should be added as separate images so we can add a tooltip for each image. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 20:49, 21 December 2022 (UTC)

:I've got another prototype going here and here: [[User:Brightgalrs/vector.css]] and [[User:Brightgalrs/Sandbox]]. (You'll need to add the css stuff to your own /vector.css). Basically it's a way to recolor images using css classes. No idea if there's a better way. Also, the real implementation would require a change to [[MediaWiki:Common.css]]. [[User:Brightgalrs|Brightgalrs]] ([[User talk:Brightgalrs|talk]]) 22:41, 21 December 2022 (UTC)
:Should mention, there ''is'' a different way, just upload each image 16 times, one for each coloring. But maybe that's not very elegant. [[User:Brightgalrs|Brightgalrs]] ([[User talk:Brightgalrs|talk]]) 22:45, 21 December 2022 (UTC)

: It should be noted that soon the classic edition will be released, hence one should plan to have both the Premium and classic alongside in that little space --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 03:14, 22 December 2022 (UTC)
::I'm looking into a tab extension to potentially support this in infoboxes. Perhaps [https://www.mediawiki.org/wiki/Extension:Tabs Extension:Tabs]? I tried [https://www.mediawiki.org/wiki/Extension:TabberNeue Extension:TabberNeue], but it displays a placeholder if JavaScript is disabled, which isn't great. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 04:22, 22 December 2022 (UTC)
::: The Neue Tabber seem to works pretty much like the old one (which fandom [https://coding-help.fandom.com/wiki/Tabber#Adding_images_into_tabbers still use]) defaulting to showing the first tab only. Quick look suggest that neue work the same, plus the notice that 'Tabber requires Javascript to function' warning? if so, and if it is a bother, then you should be able to edit out the tabberneue-noscript string in code. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 06:29, 22 December 2022 (UTC)
::: I much prefer your tabber solution, but if that fails we can also use the gallery slideshow mode. If so, beware it has no way to control image size so the images have to be maliciously uploaded using the exact same size. example:
<gallery mode="slideshow">
File:SteelSample.png
File:TinSample.png
File:ZincSample.png
File:GoldSample.png
</gallery> --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 10:19, 22 December 2022 (UTC)

==== adding premium set to Infobox ====
I am unclear where are we going with this? 
1) Will (A) tabs be implemented, (B) we be using mediawiki toggle [[Template_talk:V50_workshop|example]] for premium and classic/blocked, (c) put images side by side, or (d) something else? 
2) Also [[silver]] and [[Pig iron]] use very different image style for example. 
3) Anything else you want ? --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 12:32, 30 December 2022 (UTC)

: Personally, I would love tabs to be implemented, but I think that side by side might be best for most. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 12:32, 30 December 2022 (UTC)
: Here is rough layout we can use. It should fit most buildings given the default sprite size. There is also a different floor plan for both (inspired by reddit)

{|
|- valign=top
|
{| style="width:200px; background-color:#eaecf0; border-collapse: collapse; "
|+ 5x5
|- style="border-bottom:2px solid #3366cc; "
|<div class="mw-customtoggle-infoboxtab mw-ui-button mw-ui-progressive" style="border-top-right-radius: 10px; border-top-left-radius:10px;">toggle</div>
|{{Tooltip|Hotkey|adasdasdasd}}: {{Key|b|o|g}}
|- valign=top
|colspan=2|<div class="mw-collapsible" id="mw-customcollapsible-infoboxtab">
[[File:Siege workshop.png|center|160px]]</div>
<div class="mw-collapsible mw-collapsed" id="mw-customcollapsible-infoboxtab"">
{|
|rowspan=2 style="width:50%; font-size: 125%;"|<center>{{Template:Picture Siege workshop}}</center>
|style="line-height: 1em; font-size: 125%;"|
{| style="border-spacing:4px;"
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
|-
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#86878a; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#86878a; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#86878a; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
|-
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
|-
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#86878a; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#86878a; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#86878a; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
|-
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
|}
|-
| style="text-align: center;" | Layout
|}
</div>
|}
|
{| style="width:200px; background-color:#eaecf0; border-collapse: collapse; "
|+ 3x3
|- style="border-bottom:2px solid #3366cc; "
|colspan=2 style="text-align: right;"|<div class="mw-customtoggle-infoboxtab mw-ui-button mw-ui-progressive" style="float:left; border-top-right-radius: 10px; border-top-left-radius:10px;">toggle</div>{{Tooltip|Hotkey|adasdasdasd}}: {{Key|b|o|g}}
|- valign=top
|rowspan=2 style="width:50%;"|
<div class="mw-collapsible" id="mw-customcollapsible-infoboxtab">[[File:Carpenter's workshop.png]]</div>
<div class="mw-collapsible mw-collapsed" id="mw-customcollapsible-infoboxtab""><center>
{| style="font-size: 175%; border-spacing: 0; background-color: black; border: 2px solid black"
|- 
| style="padding: 0; line-height: 1em"|
| style="padding: 0; line-height: 1em"| {{Raw Tile|"|7:0:0}}
| style="padding: 0; line-height: 1em"| {{Raw Tile|{{=}}|6:0:0}}
|-
| style="padding: 0; line-height: 1em"| {{Raw Tile|░|0:7:1}}
| style="padding: 0; line-height: 1em"|
| style="padding: 0; line-height: 1em"|
|-
| style="padding: 0; line-height: 1em"| {{Raw Tile|░|0:7:1}}
| style="padding: 0; line-height: 1em"| {{Raw Tile|]|0:0:1}}
| style="padding: 0; line-height: 1em"| {{Raw Tile|░|0:7:1}}
|}</center></div>
|
{| style="border-spacing:5px;"
| style="width:18px; height:18px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:18px; height:18px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:18px; height:18px; background-color:#b7b9bd; border:1px solid #545557;"|
|-
| style="width:18px; height:18px; background-color:#86878a; border:1px solid #545557;"|
| style="width:18px; height:18px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:18px; height:18px; background-color:#b7b9bd; border:1px solid #545557;"|
|-
| style="width:18px; height:18px; background-color:#86878a; border:1px solid #545557;"|
| style="width:18px; height:18px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:18px; height:18px; background-color:#86878a; border:1px solid #545557;"|
|}
|-
| style="text-align: center;" | Layout
|}
</div>
|
{| style="width:200px; height:100px; padding:10px; background-color:#eaecf0; border-collapse: collapse;"
|+ 1x1
|- style="border-bottom:2px solid #3366cc;"
| colspan=3 style="text-align:center;"|{{Tooltip|Hotkey|adasdasdasd}}: {{Key|b|o|g}}
|-
| style="border-right: 1px dotted #545557;"|[[File:Screw_press.png|32px|center|link=]]
| style="font-size:125%;"|<center>{{Template:Picture Screw press}}</center>
| style="border-left: 1px dotted #545557;"|<center>{{Template:Floor Plan Screw press}}</center>
|}
|
{| style="width:200px; height:100px; padding:10px; background-color:#eaecf0; border-collapse: collapse;"
|+ 1x3
|- style="border-bottom:2px solid #3366cc;"
| colspan=3 style="text-align:center;"|{{Tooltip|Hotkey|adasdasdasd}}: {{Key|b|o|g}}
|-
| style="border-right: 1px dotted #545557;"|[[File:water_wheel.png|32px|center|link=]]
| style="font-size:125%;"|<center>{{Template:Picture Water wheel}}</center>
| style="border-left: 1px dotted #545557;line-height:normal;"|<center>{{Template:Floor Plan Water wheel}}</center>
|}
|}
:Any thoughts on the direction and or any and all of its elements? --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 10:16, 31 December 2022 (UTC)

::I kind of like side-by-side, if it fits. If anyone wants to implement a toggle button or tabs, I would ask that that be implemented in a template for now, so that e.g. we could change a toggle button to tabs in a single place if we decide to install an extension to support that. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 03:14, 1 January 2023 (UTC)

::: I noticed a comment saying that [[impassable tile]] are no longer used in v50, is that true for all constructions? If so, floor plans are no longer needed, making things much easier as we can fit everything in except the 5v5 constructions like trade depot (and even these can be placed one above the other if so desired). If not, any thought on the alternative floor plan design? --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 07:46, 1 January 2023 (UTC)

:::: None of the constructions have blocking tiles any more from my experience playing. I haven't tested siege weaponry with that stuff, but none of the workshops have it, nor does any furniture. (walls and fortifications will of course obstruct movement [[User:AndrielChaoti|AndrielChaoti]] ([[User talk:AndrielChaoti|talk]]) 18:47, 1 January 2023 (UTC)
::::: Ok, I have removed them from v50. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 23:48, 1 January 2023 (UTC)

I have added a basic side by side variant to [[Template:V50 workshop]] and [[Template:Building]] for testing, let us know if there any issues. Few notes:
* The default image naming scheme of <code>workshop-name.png</code> will likely conflict with existing images here or on commons, maybe another naming scheme should be used like <code>v50 workshop-name.png</code> as it is with ascii pictures.
* There is inconsistency in image size. If you want to use large zoomed images then toggle is best, otherwise they need to be all in native size (96px for 3x3).
* In the current version the code roughly centers the images and if there is a big image like with [[Siege workshop]] it drops to a new line --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 23:48, 1 January 2023 (UTC)

==== Bizarre palette-swapping idea/prototype ====
No idea if this is a good idea, since it takes a bit of time to set up, and there might be some performance issues... and maybe display issues?

But take a look at this:
{{User:Brightgalrs/Sandbox/PaletteSwitch|templatename=User:Brightgalrs/Sandbox/Rock|palette-name=amber}}

It's way to swap palettes on an image, although the image itself is a table, with each cell representing a pixel. The template itself looks like this:
<code><nowiki>{{User:Brightgalrs/Sandbox/PaletteSwitch|templatename=User:Brightgalrs/Sandbox/Rock|palette-name=saffron}}</nowiki></code>
Input the pattern and desired palette name.

I've got a larger showcase here: [[User:Brightgalrs/Sandbox/PaletteSwapShowcase]]. Only did a rock pattern so far, but all palettes are implemented.
The major use for this would be on each stone, metal, wood, etc. type's page. The palette could be read directly from the raws. [[User:Brightgalrs|Brightgalrs]] ([[User talk:Brightgalrs|talk]]) 03:22, 24 December 2022 (UTC)

:From a technical perspective, my primary concern is indeed performance. Both on the server side and client side, a large number of tables that large (in terms of markup and cell count, that is) tend to be resource-intensive to generate and render. I saw your image-filtering experiments on [[User:Brightgalrs/vector.css]], and while that strikes me as a newer and less-backwards-compatible approach, it would probably be more resource-friendly.
:Is this color adjustment something the game is doing natively? i.e. does this accurately match what the game displays? I bet we could slap together an image-filtering extension (or find an existing one?) that can do this if needed. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 03:49, 24 December 2022 (UTC)
::Yeah that's what I suspected. The images the template creates are spot on, checked it against a screenshot I took of some mica rocks in-game. The css stuff is unfortunately totally incorrect, was cool to learn about it though, so not a complete waste of my time :p. The premium, in-game graphics are true sprites, basically patterns of indexed colors. Each of the in-game colors (which are significantly expanded over the 16 ascii colors, there's 116/117) there is a palette defined in "\Dwarf Fortress\data\vanilla\vanilla_descriptors_graphics\graphics\images\palettes.png". Each indexed color of the sprite is swapped for the corresponding color in the palette. Because of that, the css stuff doesn't work since it's doing the hue/saturation/brightness changes to the entire sprite.
::I've looked into an existing mediawiki extension, couldn't find anything. One thing I did't really look at is some type of lua script/module that would basically emulate what the game is doing. So some function that takes in the base image as well as the desired palette, and based on that finds and replaces each color. No idea what mediawiki's capabilities are on that front. [[User:Brightgalrs|Brightgalrs]] ([[User talk:Brightgalrs|talk]]) 05:31, 24 December 2022 (UTC)
:::We do have Scribunto installed now, so it's totally possible to do something in Lua too - forgot about that. I can add you to the group that grants access to edit the Module namespace if you want to give that a shot. If we use an extension, we'd probably need a custom one, similar to DFDiagram (or perhaps DFDiagram could be extended - it's in dire need of a rewrite anyway). —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 05:43, 24 December 2022 (UTC)
::::I asked around on the mediawiki irc, I think scribunto/lua is a deadend, at least for taking an uploaded image and doing stuff to it with a lua script. However I did come up with this even more bizarre solution, using block elements. [[User:Brightgalrs/Sandbox/PaletteSwapShowcase2]], maybe less resource intensive? Definitely displays a lot worse though, probably unusable.
::::{{User:Brightgalrs/Sandbox/PaletteSwitch|templatename=User:Brightgalrs/Sandbox/Rock2|palette-name=saffron}}
::::I dunno, maybe none of this is worth it and we should just write some external program to put all the images together offline, and then just mass upload. It wouldn't be ''that'' many... [[User:Brightgalrs|Brightgalrs]] ([[User talk:Brightgalrs|talk]]) 06:37, 24 December 2022 (UTC)

====Is there an easy way to just paste images from the clipboard?====

I use KDE spectacle to take screenshots straight to the clipboard (after cropping) -- is there an easy way to just paste (and auto-upload) an image into an article? It would make it a lot easier to contribute images. [[User:Kelvie|Kelvie]] ([[User talk:Kelvie|talk]]) 23:35, 1 January 2023 (UTC)
:Unfortunately there is not. I would be open to a MediaWiki extension to support this if someone finds one. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 00:32, 2 January 2023 (UTC)
:: Looks like this could do it, but I haven't used it before: https://www.mediawiki.org/wiki/Extension:SimpleBatchUpload [[User:Kelvie|Kelvie]] ([[User talk:Kelvie|talk]]) 19:41, 2 January 2023 (UTC)

=== Hotkeys/Menu navigation ===
Most key bindings and menus have changed. Should the article reflect a) only the old version, b) only the GUI version or c) both? For example, [[Bridge|bridges]] used to be built via {{k|b}} -> {{k|g}}, but now it's in Place strucutures {{k|b}} -> Constructions {{k|n}} -> Bridge {{k|b}}. What should be written in the article? Currently, it's {{k|b}} -> {{k|g}}. I ''think'' it should be only b), but I am not sure if there will be differences regarding hotkeys or menus between the premium version and the free version and then, c) would be the most appropriate option. --[[User:Prometherus|Prometherus]] ([[User talk:Prometherus|talk]]) 10:16, 22 December 2022 (UTC)

: Not sure. I wish the classic release soon --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 16:45, 22 December 2022 (UTC)
:: Are you Toady's herald? Looks like it was just released! [[User:Brightgalrs|Brightgalrs]] ([[User talk:Brightgalrs|talk]]) 18:18, 22 December 2022 (UTC)
:: And our questions are answered, the old hotkeys seem to have been thrown out. Part of me is disappointed (useless muscle memory) but also relieved (unified UI for both versions is good in general and for the wiki). [[User:Brightgalrs|Brightgalrs]] ([[User talk:Brightgalrs|talk]]) 18:25, 22 December 2022 (UTC)
::: According to info, in a sort of 'demo version' at that. I'll wait a little while longer, for myself.[[User:Silverwing235|Silverwing235]] ([[User talk:Silverwing235|talk]]) 18:22, 22 December 2022 (UTC)
::::It's unlikely that keybindings in it will change significantly. My vote is that we should include information for both premium and classic, everywhere. Hopefully the keybindings are not different between versions. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 18:26, 22 December 2022 (UTC)
:::Shouldn't it be based on the 50 or what verion the article is written for? [[User:Dominick|Dominick]] [[User_talk:dominick|(TALK)]] 18:42, 22 December 2022 (UTC)
:::: The keybindings seem to be consistent between versions, (haven't checked exhausitvely, but since the menu layout is the same I think it is a good assumption). Should also keep in mind/consider that not all actions have keybindings. An option would be write 'Click on the <Example Text> icon or press {{k|E}}' [[User:Koos|Koos]] ([[User talk:Koos|talk]]) 23:14, 23 December 2022 (UTC)

=== Removed features & concepts ===

Since they're removed concepts, I've set [[Room]] to be a redirect for [[DF2014:Room]] and created [[Template:Activity zones]] for the nav bar bedrooms, etc, and made the necessary changes to [[Bedroom]] for it. Is this the correct approach, before I go on much further? (also a note, if it is, then [[Template:v50_rooms]] probably needs to be deleted) I also imagine that considering the number of changes in the interface, that things like [[Adventure mode]] and related pages might best be truncated to "not in 50.03" and when it does make it across, being more deliberately brought over in pieces? [[User:HawkOwl|HawkOwl]] ([[User talk:HawkOwl|talk]]) 06:23, 23 December 2022 (UTC)

:Usually it is marked with [[Template:Removed_feature]]. For example: [[Dipscript]] or [[Party]]. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 07:45, 23 December 2022 (UTC)

:: Ah, that's fair. Should that be mentioned in [[Dwarf_Fortress_Wiki:Versions#Redirects]]? [[User:HawkOwl|HawkOwl]] ([[User talk:HawkOwl|talk]]) 10:03, 23 December 2022 (UTC)

:::I think the redirect policy mostly had in mind things that were removed a ''long'' time ago, like [[Tax collector]] and [[Economy]] (and the latter actually has a stub page as well). I guess we could clarify. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 19:34, 23 December 2022 (UTC)

:::: The "current" redirects also cause the version box to incorrectly show that the current version has a page - e.g. [[23a:Cave_river]] shows a v50.04 version, but it's just a redirect back to that version. Similarly, what should happen to redirects like [[Clothes maker]], where a concept has evolved? It currently goes to [[23a:Clothes maker]] - that's correct if the user is trying to look up a very old concept, but if a new user is looking for "how to make clothes", they should be directed to [[Clothier]]. --[[User:Danny252|Danny252]] ([[User talk:Danny252|talk]]) 12:16, 26 December 2022 (UTC)

:::: One should be careful with cv redirects. Most that were recently adjusted were unused plural forms (that should probably be deleted) but few like [[Crown]] needed that for backward compatibility. Removing the [https://dwarffortresswiki.org/index.php?title=Crown&type=revision&diff=279966&oldid=219482 cv part] means the the link on [[v0.31:Tilesets]] is now broken. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 22:30, 26 December 2022 (UTC)

:::::If [[v0.31:Tilesets]] is about v0.31, it should not be using "main:" in its links - ''all'' of those links are going to pages about v50, not v0.31, regardless of whether the target is a redirect or not. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 23:37, 26 December 2022 (UTC)
:::::: You right, I removed it. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 17:55, 27 December 2022 (UTC)

Crown cv redir issue is now fixed, I believe. As goes with such cases where one can simply revert the troublesome edit, unless I've mistepped, myself? [[User:Silverwing235|Silverwing235]] ([[User talk:Silverwing235|talk]]) 23:52, 26 December 2022 (UTC)
:Both [https://dwarffortresswiki.org/index.php?title=Crown&diff=prev&oldid=280026] and [https://dwarffortresswiki.org/index.php?title=Crown&diff=prev&oldid=279966] should not have had any effect, because "cv" is an alias to the main namespace now, just like "main". Proof: [[Crown]], [[cv:Crown]], [[main:Crown]]. It's possible caching is coming into play here, although I purged the redirect cache after making that alias change earlier this month... —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 00:02, 27 December 2022 (UTC)

I think there have been some changes not captured, but as a newb, I'm afraid to edit the page(s). A good example is Strawberry. I'm playing the Steam version right now and Strawberry plants are "not relevant to brewing" in Labor > kitchen > veg / fruit / leaves. Unless I'm mistaken and need to process them? Another example is the trade caravan = it seems the 3 square pathing no longer happens; it's just yak(s). 12:31, 28 December 2022 (UTC) 12:29, 28 December 2022 (UTC)
:Strawberries should be brewable according to the Raws.
:Trade wagons has been modified in v50. The first wagons will arrive at the same time your fort is becoming a barony. Until then, it's only pack animals and stairs are indeed fine. The [[Trading]] page needs a huge rework anyway... I'll try to do that next week. --[[User:Halavus|Halavus]] ([[User talk:Halavus|talk]]) 13:40, 2 January 2023 (UTC)

<s>As far as I can tell, none of the workshop buildings in v50 have blocking tiles any more. There's a comment to the like in data/vanilla/vanilla_buildings/objects/building_custom.txt that says this "[BLOCK:1:0:0:0] workbenches no longer block". Hesitant to update that template as I'm not sure if it's referenced for all of the old versions too. </s> [[User:AndrielChaoti|AndrielChaoti]] ([[User talk:AndrielChaoti|talk]]) 05:54, 29 December 2022 (UTC)
: A new template has been created: {{tl|V50 workshop}} --[[User:Halavus|Halavus]] ([[User talk:Halavus|talk]]) 13:40, 2 January 2023 (UTC)

=== creature infobox prototype (moved) ===

Check it out, I made a temporary template and added it to the [[cow]]s page. Now it shows the sprites (but not the zombified versions yet). I wanted to show everyone a prototype of what v50 creature infoboxes should look like. Or at least something similar to it. --[[User:Zippy|Zippy]] ([[User talk:Zippy|talk]]) 19:11, 27 December 2022 (UTC)
:Hi, I'm new to editing wikis but I have done a bit of work with sprite sheets and I've been going through the DF data files to find the different graphics hoping to help with the animal pages. I've thrown together a template with grass and a few nature sprites (plants, a tree, and a rock) for size reference but I'm unsure how large the 'display' tiles in the middle of the template should be to suit all animals. I can see in the sprite sheets that some land animals have an adult and child sprite, so two tiles. Others have a male, female, and child, but after seeing you include the zombie cows I'm unsure if I should make it twice the size to add them too. Alternatively, I could grab some tiles from the haunted biomes for the zombie animals and make a separate template for a side-by-side comparison. Either way, let me know if this helps. I'd like to help with other graphics too as we add the premium tilesets but the animals seemed the easiest to tackle with me being new to wiki editing. ~~[[User:UristTheSeventh|UristTheSeventh]]

=== When do we remove the migration note on specific pages? ===

At what point can we remove the "this page was auto migrated from v47" warning? There are a bunch of small pages that are more or less accurate, if I've reviewed them, can I go ahead and remove the warning? [[User:Kelvie|Kelvie]] ([[User talk:Kelvie|talk]]) 23:33, 1 January 2023 (UTC)
:Yes, feel free to remove it if you think all content is accurate. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 00:31, 2 January 2023 (UTC)

== Toggleable image ==

Any objections/comments to using this template for now for toggling between classic and premium images? I'd probably rename it to "Template:Premium-classic thumb image". I'm sure someone can come up with a better UI eventually, but should be easy to migrate at that point. I also think we should use the same customtoggle class for this and for the infobox. [[User:NiftyManiac|NiftyManiac]] ([[User talk:NiftyManiac|talk]]) 23:12, 1 January 2023 (UTC)

{{User:NiftyManiac/Sandbox/TemplateDualImage|
premium=File:Quickstart-finder.png|
classic=File:Quickstart-finder-partial.png
}}

{{User:NiftyManiac/Sandbox/TemplateDualImage|
premium=File:Quickstart-finder.png|
classic=File:Quickstart-finder-partial.png|
caption=My caption|
width=100px
}}

:This looks nice to me! —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 00:30, 2 January 2023 (UTC)

: Good initiative. From the top of my head:
:* I suggest using a shorthand, no one wants to type 'Premium-classic thumb image'.
:* If we end up using toggle for infoboxes (not sure where we headed there), then I agree definitely same custom toggle class should be used for all, thus allowing to switch premium-classic view on the whole page at a click.
:* The button part on a separate row isn't pretty, creating a lot of dead space that can be used by the text. Are we set on the label 'toggle ascii'? Classic isn't Ascii per se, maybe we can use a 'toggle' with a tooltip {{tooltip|for example|does bla bla bla}}, or maybe we can get rid of the text and have a smaller icon button ([[User:Jan/sandbox#Metal_example|two examples]]).
: I hope that helps. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 11:21, 2 January 2023 (UTC)

:: I added [[Template:Dual image]] with some of your suggestions. Agree that it's not super pretty, feel free to try something different.

::* I put the toggle in the caption mostly because I gave up on trying to make a more sophisticated replacement for the default thumb image behavior, I'm sure someone with better wiki-fu could put together something more intelligent.
::* I cut the text down to just "Toggle"; I think the best solution would be a small graphic showing the old and new dwarf icons with arrows between them. [[User:NiftyManiac|NiftyManiac]] ([[User talk:NiftyManiac|talk]]) 19:21, 2 January 2023 (UTC)

{{Dual image|
premium=File:DFwiki5by53by3farm.png|
classic=File:Quickstart_layout_3.png|
width=100px|
caption=A 5x5 room with a 3x3 farm plot
}}

Mud

2023-01-02T19:41:22Z

Kelvie: Remove migration warning

{{Quality|Unrated}}
{{av}}

[[File:mud2.jpg|thumb|312px|right|Not fit for wearing your best shoes.]]'''Mud''' is a [[contaminant]] produced when an area is covered with [[water]], and colors tiles brown. It is essentially just running wet dirt. Mud also occurs naturally in deep [[cavern|caverns]]. Muddied stone can be used for [[farming]], [[Pasture|grazing]], [[Herbalist|plant gathering]], and [[Tree#Growing_trees|growing subterranean trees]]. "A pile of mud" in water sources can result in "[[Water#Water_laced_with_mud|water laced with mud]]" which can lead to problems if your dwarves use it.

''Note: Upon [[reclaim fortress mode|reclaiming a fortress]], '''every single bit of mud will disappear''', including even mud in the caverns.''

[[Mud man|Mud men]] are (obviously) made of mud, as are [[titan]]s, [[forgotten beast]]s, and [[demon]]s on occasion.

== Farming and spontaneous growth on mud ==

The plants that can be [[farming|farmed]] on mud are the same as those that would grow on soil in the same place. Biome-appropriate grass (useful for [[Pasture|grazing]]) and plants (and, if underground, trees) will also spontaneously grow on muddy stone just like any other soil tile. [[Tile_attributes|Above-ground]] plants can't grow or be farmed on underground tiles, and vice versa, though tiles can be made permanently "above-ground" by exposing them to light. And perhaps unfortunately, muddying stone won't allow farming of different above-ground crops from other biomes. Note that underground plants won't spontaneously grow until a [[cavern]] has been breached, though farming from seeds is still possible. Note also that saplings need more than 1 z-level to mature into adult, wood-bearing trees. (see [[tree farming]] for more.)

Constructed floors behave differently - plants won't spontaneously grow on them, but farms will grow fine. Muddied smoothed floors might behave differently from muddied rough floors also, but more information is needed.{{verify}}

== Muddying areas ==

See [[irrigation]] for some methods. One common way of creating mud is to [[irrigation|flood]] a good-sized area from a lake, thus making mud. Another way is to use a pit/pond from the [[Activity zone|activity zone menu]] and have a dwarf throw water over a channeled area into a dug-out area below.

Initial water contact with a clean surface will leave "a dusting of mud", not "a pile of mud". This is sufficient for farming and grazing, but not enough to cause any water-contamination problems in reservoirs.

Dumping water on an already-muddy area may result in more mud accumulating there, up to "a pile of mud".

== Removing mud ==

Mud can be removed by constructing something over the mud (including furniture), then deconstructing it, or by smoothing/engraving stone. Mud on soil is removed easily by constructing a dirt road.

Dwarves will not clean mud as a [[cleaning|cleaning labor]], though they will at least sometimes clean blood and possibly other contaminants from muddied surfaces. (needs more info)

Magma will remove mud if it evaporates on a tile.

== Muddy water ==

Using "water laced with mud" can cause health and happiness problems, see the [[Water#Water_laced_with_mud|water page]] for more details. Drinking muddy water is better than dying of thirst, though.

Dug-out reservoirs should be able to store water without contaminating it with mud, since initial flooding with water leaves only "a dusting of mud". However, under some circumstances the reservoir can end up with piles of mud on its floor anyway, especially if slowly filled using buckets. (more information needed.)

Natural [[cavern]] pools have floors covered with "a pile of mud", so make sub-optimal water sources, unless they're deep enough that water can be drawn from a tile that doesn't contain "a pile of mud".

=== A dusting of mud ===
"A dusting of mud" is always displayed even when pumping clean water onto the floor. This water is completely sufficient to drink, and acts the same as clean water.

{{Translation
| dwarven = ol
| elvish = salapa
| goblin = gob
| human = vum
}}

{{gamedata|{{raw|DF2014:hardcoded_materials.txt|MATERIAL|MUD}}}}
{{materials}}

{{Category|Materials}}
[[Ru:Mud]]

Mud

2023-01-02T19:41:06Z

Kelvie: /* Muddy water */ clarify "A dusting of mud"

{{migrated article}}
{{Quality|Unrated}}
{{av}}

[[File:mud2.jpg|thumb|312px|right|Not fit for wearing your best shoes.]]'''Mud''' is a [[contaminant]] produced when an area is covered with [[water]], and colors tiles brown. It is essentially just running wet dirt. Mud also occurs naturally in deep [[cavern|caverns]]. Muddied stone can be used for [[farming]], [[Pasture|grazing]], [[Herbalist|plant gathering]], and [[Tree#Growing_trees|growing subterranean trees]]. "A pile of mud" in water sources can result in "[[Water#Water_laced_with_mud|water laced with mud]]" which can lead to problems if your dwarves use it.

''Note: Upon [[reclaim fortress mode|reclaiming a fortress]], '''every single bit of mud will disappear''', including even mud in the caverns.''

[[Mud man|Mud men]] are (obviously) made of mud, as are [[titan]]s, [[forgotten beast]]s, and [[demon]]s on occasion.

== Farming and spontaneous growth on mud ==

The plants that can be [[farming|farmed]] on mud are the same as those that would grow on soil in the same place. Biome-appropriate grass (useful for [[Pasture|grazing]]) and plants (and, if underground, trees) will also spontaneously grow on muddy stone just like any other soil tile. [[Tile_attributes|Above-ground]] plants can't grow or be farmed on underground tiles, and vice versa, though tiles can be made permanently "above-ground" by exposing them to light. And perhaps unfortunately, muddying stone won't allow farming of different above-ground crops from other biomes. Note that underground plants won't spontaneously grow until a [[cavern]] has been breached, though farming from seeds is still possible. Note also that saplings need more than 1 z-level to mature into adult, wood-bearing trees. (see [[tree farming]] for more.)

Constructed floors behave differently - plants won't spontaneously grow on them, but farms will grow fine. Muddied smoothed floors might behave differently from muddied rough floors also, but more information is needed.{{verify}}

== Muddying areas ==

See [[irrigation]] for some methods. One common way of creating mud is to [[irrigation|flood]] a good-sized area from a lake, thus making mud. Another way is to use a pit/pond from the [[Activity zone|activity zone menu]] and have a dwarf throw water over a channeled area into a dug-out area below.

Initial water contact with a clean surface will leave "a dusting of mud", not "a pile of mud". This is sufficient for farming and grazing, but not enough to cause any water-contamination problems in reservoirs.

Dumping water on an already-muddy area may result in more mud accumulating there, up to "a pile of mud".

== Removing mud ==

Mud can be removed by constructing something over the mud (including furniture), then deconstructing it, or by smoothing/engraving stone. Mud on soil is removed easily by constructing a dirt road.

Dwarves will not clean mud as a [[cleaning|cleaning labor]], though they will at least sometimes clean blood and possibly other contaminants from muddied surfaces. (needs more info)

Magma will remove mud if it evaporates on a tile.

== Muddy water ==

Using "water laced with mud" can cause health and happiness problems, see the [[Water#Water_laced_with_mud|water page]] for more details. Drinking muddy water is better than dying of thirst, though.

Dug-out reservoirs should be able to store water without contaminating it with mud, since initial flooding with water leaves only "a dusting of mud". However, under some circumstances the reservoir can end up with piles of mud on its floor anyway, especially if slowly filled using buckets. (more information needed.)

Natural [[cavern]] pools have floors covered with "a pile of mud", so make sub-optimal water sources, unless they're deep enough that water can be drawn from a tile that doesn't contain "a pile of mud".

=== A dusting of mud ===
"A dusting of mud" is always displayed even when pumping clean water onto the floor. This water is completely sufficient to drink, and acts the same as clean water.

{{Translation
| dwarven = ol
| elvish = salapa
| goblin = gob
| human = vum
}}

{{gamedata|{{raw|DF2014:hardcoded_materials.txt|MATERIAL|MUD}}}}
{{materials}}

{{Category|Materials}}
[[Ru:Mud]]

Floor fungus

2023-01-02T19:38:44Z

Kelvie: Clarify prevention.

{{Quality|Unrated}}
{{av}}
[[File:fungus_growth_v50.png|thumb|270px|right|Floor fungus is the yellow one.]]
'''Floor fungus''' is functionally identical to [[cave moss]] and [[underlichen]], differing only in texture.

As with [[Caverns#Benefits|most underground grasses]], floor fungus only appears after a [[cavern]] containing floor fungus has been discovered. It spreads anywhere there is mud and can potentially be used for [[Farm plots]], unless a mushroom has grown on it. As you cannot gather mushrooms until they are fully grown, it would be wise to create your farm plots before mushrooms start showing up on the floor fungus.

To prevent the spread of floor fungus, construct non-soil floors, i.e. don't use a material like clay for the flooring.

It is mostly harmless and can be used to graze animals, like an underground form of [[grass]]. Mushrooms may occasionally grow from the fungus.

You can set up a plant gathering zone to automatically harvest the mushrooms as they grow inside your fortress, to not take up space.

[[File:yellow_moss.jpg|thumb|250px|center|Not Guano.]]

{{Translation| dwarven = dakost muz | elvish = mere arari | goblin = ublu ësmor | human = dolak meplul}}

{{gamedata}}
{{Plants}}

Cave moss

2023-01-02T19:36:59Z

Kelvie: Remove the migration warning.

{{Quality|Unrated}}
{{av}}
[[File:fungus_growth_v50.png|thumb|270px|right|Cave moss is the teal one.]]
'''Cave moss''' is a peculiar [[grass]]-like growth that occurs in underground [[caverns]]. Animals such as [[cow|cattle]] or [[yak]]s can be designated to graze on it via [[pasture]]s.

Cave moss is functionally identical to [[floor fungus]] and [[underlichen]], but should not be confused with normal [[moss]]. As with [[Caverns#Benefits|most underground grasses]], cave moss only appears after a [[caverns|cavern]] containing cave moss has been discovered.

Cave moss will grow on a below ground [[soil]] surface or on a muddied stone surface that has not been smoothed. The amount of mud on the surface does not affect the distribution or growth rate of subterranean plants [http://www.bay12forums.com/smf/index.php?topic=122150].

Cave moss is harmless.

[[File:cave_moss.jpg|thumb|260px|center|Beautifully lit cave moss.]]

{{Translation| dwarven = äs daros | elvish = garetho vema | goblin = omo ozosm | human = ngethac zih}}

{{gamedata}}
{{Plants}}

Floor fungus

2023-01-02T19:35:53Z

Kelvie: Remove migration tag from article (and expand).

{{Quality|Unrated}}
{{av}}
[[File:fungus_growth_v50.png|thumb|270px|right|Floor fungus is the yellow one.]]
'''Floor fungus''' is functionally identical to [[cave moss]] and [[underlichen]], differing only in texture.

As with [[Caverns#Benefits|most underground grasses]], floor fungus only appears after a [[cavern]] containing floor fungus has been discovered. It spreads anywhere there is mud and can potentially be used for [[Farm plots]].

It is mostly harmless and can be used to graze animals, like an underground form of [[grass]]. Mushrooms may occasionally grow from the fungus, which can block farm plots until they are mature and ready to be harvested.

You can set up a plant gathering zone to automatically harvest the mushrooms as they grow inside your fortress, to not take up space.

[[File:yellow_moss.jpg|thumb|250px|center|Not Guano.]]

{{Translation| dwarven = dakost muz | elvish = mere arari | goblin = ublu ësmor | human = dolak meplul}}

{{gamedata}}
{{Plants}}

Necromancer

2023-01-02T05:33:26Z

Kelvie: Change woding

{{migrated article}}
{{Quality|Unrated}}
{{av}}
[[File:necromancer_sprite_preview.png|right]]'''Necromancers''' {{Tile|Ñ|5:1}} are [[immortal]] beings blessed with the [[secret]]s of life and death. These [[night creature]]s are [[magic]] users who raise legions of [[undead]] and seclude themselves in [[Tower_(necromancy)|tower]]s. Most [[creatures]] that are necromancers will have their sprite appear with pale purple-like skin.

==The Origin of Necromancers==
Necromancers initially begin as normal [[historical figure]]s who are [[Creature_token#MAXAGE|mortal]], [[Creature_token#CAN_SPEAK|can speak]], [[Creature_token#CAN_LEARN| learn]] and are also part of an [[civilization|entity]]; in unmodded games these are [[dwarf|dwarves]], [[human]]s and civilized [[animal people]]. At some point in its life, one of these creatures may suddenly become "obsessed with his/her/its own mortality" and seek to become immortal. Shortly afterwards, it will begin (if it does not do so already) worshiping a [[deity]] (or a creature with the {{token|SUPERNATURAL|c}} tag) who has a [[sphere|DEATH sphere]]. Once the deity/supernatural creature becomes an object of ardent worship to the figure, it will reward the worshipper with an artifact [[slab]] containing the secrets of life and death, which is then swiftly claimed by the recipient for diligent learning, thus becoming a necromancer. This original necromancer may then take as apprentice one or more fellow immortality-seekers, who will obtain the knowledge of their master.

==Description==
Having mastered the secrets of life and death, necromancers have reached their goal of [[immortality]], in that they do not [[age]], need to [[food|eat]], [[thirst|drink]], or require [[sleep]], as they [[No Exert|never get tired or exhausted]]. However, they ''do'' need to breathe, unlike [[vampire]]s. Necromancers are still fertile, and in fortress mode, female dwarf necromancers can give birth. Their {{token|ANXIETY_PROPENSITY}} is raised by 50, while their {{token|TRUST}} is lowered by 50, and some necromancer secrets add {{token|LIKES_FIGHTING}}.

The defining characteristic of necromancers is that they know the secrets of life and death, which gives them extra powers. However, not all secrets are created equal - different secrets will yield different powers.

== Secrets ==
[[File:necromancer_preview.jpg|thumb|360px|One of the worst ways to deal with grief. ''Art by ChrisCold''.]]Each secret gives a combination of magical abilities, which come in the form of [[interaction token]]s. These abilities may vary widely in type and power level, but will always include the ability to raise corpses and [[intelligent undead]]. Depending on their [[sphere]]s (which stem from the spheres of the original [[deity]] that granted those secrets) secrets may also grant the ability to summon [[nightmare]]s, [[bogeymen]], and also the ability to "ghoulify" a living creature (in effect, giving it a [[syndrome]] that turns it into a [[thrall]], much like [[evil]] clouds). In addition, the intelligent undead will also be granted powers of their own, which may range from raising blisters to rotting nerves, to even being able to raise the dead themselves. The [[Advanced_world_generation#Number_of_Secret_Types|number of secrets]], and [[Advanced_world_generation#Allow_Divination.2C_Experiments.2C_and_Necromancy_types|which advanced powers]] they can convey, can be set in advanced world generation.

A single necromancer can learn multiple strains of necromancy by reading different sources. Ambitious necromancers tend to create more towers of the same strain via proxy, so you might find your world populated by a single strain. Usually it’s easier when you know which tower houses what kind of undead, or when you go after the source slabs via legends mode. Recovery is also easier when you have a sneaky squad of artifact raiders in fort mode.

=== Raise corpse/intelligent undead ===
Necromancers always have the [[interaction token|power]] to animate [[corpse]]s of organic creatures, which can include heads or any body parts which have a {{token|GRASP}} token or are attached to body parts which do ([[skin]], and [[hair]]). Corpses must be within the necromancer's line of sight – about 15 tiles – to be animated. Necromancers do this by gesturing; raising of the dead is reported in the [[reports|combat log]]:

{{gametext|[Necromancer] gestures!|3:1}}
{{gametext|[Corpse] shudders and begins to move!|3:1}}

Once a dead being is animated, it will become [[Adventure mode#Companions|enslaved]] to the necromancer and {{token|OPPOSED_TO_LIFE}}, regardless of previous allegiances. Unless the necromancer attacks their new undead minions, they will remain companions in Adventure mode. If you are a necromancer and attack one of your undead companions, all of them will turn neutral. Animated corpses are also neutral toward creatures that are {{token|NON_LIVING}}. Necromancers will also, occasionally, revive corpses as [[intelligent undead]] – in this case, the revived creature will retain most of its personality and existing loyalties. The name "undead" never quite appears as such in the game – instead, a procedurally-generated name like "lost butcher" or "risen zombie" is used. These undead have special powers but won't be enslaved or {{token|OPPOSED_TO_LIFE}}. In fortress mode, this means that intelligent undead raised by necromancer citizens of your fortress will stay citizens, if they were such when they died. It also means putting necromancers in military squads very risky, as they might accidentally revive your enemies with fun new powers. In adventure mode, if you attempt to raise someone you killed as an intelligent undead, they will remember you attacked and killed them, and will be hostile to you.

=== Summon [[nightmare]]s/[[bogeymen]] ===
Secrets aligned with the nightmare sphere will grant the ability to summon nightmares or bogeymen at a random location near the target to haunt it. In-game, necromancers with this ability will "call upon the night" to do so. These summons are large and freakish, but last a short amount of time. Nightmares are neutral toward creatures with {{token|NO_FEAR}}.

=== Ghoulification ===
Certain necromancers may also turn living creatures into [[infected ghoul]]s. The victims will be said to have "been infected with a contagious ghoulish condition". In adventure mode, you cannot make ghouls even if the announcement after reading a secret-containing book says you learned the power. Ghouls are opposed to life and attack/infect all living creatures who aren’t ghouls through bites. They still retain their sentience and can still bleed to death, but they maintain their gear and abilities, are immune to drowning, do not tire, and have extravision.

== In world generation ==
[[File:Secrets.png|thumb|Secrets of life and death.]]In world generation, necromancers may raise suspicions from their fellow citizens due to not aging, which can lead them to be expelled. This does not apply to necromancers living in goblin and elven civilizations since both goblins and elves are already immortal. Upon being expelled, the necromancer may form a grudge against the civilization and turn to [[villain]]y, and they will generally take refuge in a site of their own.

Necromancers who have a sufficient following may use their undead minions to build dark [[Tower (necromancy)|tower]]s, a task that requires at least 50 followers; younger necromancers may take over [[town]]s or camps instead. Necromancers will also raise a few [[intelligent undead]] as lieutenants. The building of a tower is carried out by the original necromancer of a group (the one who was given the slab) as apprentices join the group after the tower is built. Therefore, each necromancy group has one tower.

Necromancers can make zombies build their tower up a bit to increase the site's zombie cap. If the necromancer is at their zombie cap, they can still raise more zombies, but they are added to a wilderness population instead. The wilderness population can still be used for invasions, but they are also able to roam on to player forts in the region and also encounter adventurers.

Necromancers may conduct experiments on civilians and their [[domestic animal|livestock]], turning them into night creatures known as [[experiment]]s. Eventually, these experiments may leave the necromancer that made them and join other civilizations. In older worlds, many civilizations will likely have significant populations of escaped experiments. In adventure mode, it is not currently possible to create necromancer experiments.

Necromancers can also turn intelligent creatures into [[infected ghoul]]s. The ghouls can then be found around necromancer towers, but it is not currently possible to turn a creature into a ghoul in adventure mode.

Since the secrets of life and death are generated with a {{token|MUNDANE_RECORDING_POSSIBLE}} tag, necromancers will often write numerous [[book]]s during world generation, some concern the secrets of life and death (''blessed, or mayhap, cursed'') so that anyone who reads them will become a necromancer. Like the slab, all (''first-edition, not copies'') books, even those that do not contain secrets, are considered [[artifact]]s, and as such can be viewed in the "Codices and scrolls" list in [[legends|legends mode]]. Books containing the secrets of life and death will include any of the following words in their title: Annihilation, Bereavement, Death, Demise, Departure, Doom, Dying, Eternal Rest, Expiration, Extinction, Mortality, Immortality, Loss, Oblivion, Parting, Ruin, Ruination, Sleep, the Afterlife, the End, the Grave. (Note: "the End" can also turn up in mundane titles as well, typically as part of the phrase "after the end")

It is possible to ensure that a world is generated devoid of necromancers by setting the '''Number of Secret Types''' to '''0''' in [[advanced world generation]]. To the contrary, creating a world with a high number of secret types will increase the probability of there being multiple necromancers in the world. Since necromancers in unmodded games are usually humans or dwarves, having a large amount of neutral plains and/or mountains will further increase this probability, as it means that these civilizations will have more space to expand, and thus the amount of historical figures eligible for necromancy will increase.

Necromancer towers spread death-[[sphere|aligned]] [[evil]] regions around them. Destroying the tower and killing the necromancers in it (e.g. through a [[raid]] to raze the site) will reverse the evil-spreading.

Necromancer towers seem to be treated as a type of criminal government{{verify}} and as such function similarly to a regular civilization. Necromancers from opposing entities will attack each other, but amusingly, their undead armies will be neutral to everyone. Due to their ability to amass large armies quickly, necromancers are currently one of the most powerful geopolitical forces in the game, often declaring war on and destroying even powerful goblin civilizations in older worlds.

==Fortress mode==
===Sieges===
{{DFtext|The dead walk. Hide while you still can!|5:1}}
{{main|Siege#Necromancer sieges}}

Necromancers can lay [[siege]] to your fortress at any stage, including before the first [[immigration|migrant wave]], but only if their tower or town is within 20 tiles of your fortress. As such, picking a location within that distance of such a tower is regarded as a sure way to have an extra helping of [[fun]], and can be checked with {{k|tab}} during world gen. Note that if no tower is present during embark, no necromancer sieges will ever arrive (they may still show up as migrants and/or visitors), except if you [[mission|attack]] them. The sieges are structured much like normal sieges, except that the numbers tend to be much larger and much more disorganized, consisting not of individual squads but of masses of zombies coming from every side. The necromancer (or necromancers, if the former has an apprentice) may or may not arrive with the siege; if they do, and are captured or killed, you can expect to see no more activity from that particular tower. Undead are hostile to everything that breathes as well as to enemy necromancer hordes, meaning that other sieges or [[ambush]]es (or, indeed, caravans) that happen to arrive when a necromancer siege is milling about will always result in a battle. They may also send small squads or armies of experiments to attack you, sometimes stealthily acompanying their minions.

The easiest way to deal with a zombie siege is through the application of [[dwarven atom smasher|particle physics]] to grind the zombies into nothingness. Anything that obliterates any trace of the zombie will prevent raising; a drop into [[magma]] or [[semi-molten rock]] or encasing in [[obsidian]] are more creative alternatives. The jury is still out on whether slashing weapons are better or worse against necromancer sieges; although they tend to separate zombies into many parts, these parts can all be raised, leaving the question of whether the whole zombie or an arm here and a leg there is more dangerous. The undead that the necromancer(s) will bring will be sapient creatures, but if you killed some [[elephant]]s in a combat exercise and a necromancer happens upon them, the danger is magnified.

If you have a [[vampire]] and haven't walled them in yet, you can draft them and take a leisurely walk through town, as undead will ignore them (unless attacked), and the necromancer, has one arrived, is an easy, valid game for a clobbering.

Necromancers that are idle during a siege used to occasionally start [[campfire]]s.

===Ambushes===
Necromancers can arrive under cover, alone, in [[ambush]]es, and raise the dead without being seen. This is much more difficult, as you cannot see the necromancers in question, only their products. Potential necromancer ambushes can be dealt with by internalizing all corpse/remains stockpiles behind heavily trafficked areas, and posting sentries if possible.

===Residents/citizens===

Residents and citizens alike can also become necromancers if they happen to read material (such as [[codex|codexes]]/[[quire|quires]]) that contain the secrets of life and death. One way to acquire such materials is by trading for them from a [[caravan]].

Necromancers may occasionally arrive with their slab in hand. It is possible to add necromantic texts as part of your library, allowing you to turn your dwarves into necromancers once they read them. It is also possible to use the world map to send military squads to raid necromancer towers for the reading material contained in them. Dwarven necromancers no longer age, need to eat, or sleep, but they will also no longer need to drink, which can slow them down tremendously for it to be worth it. They ''may'' also raise the occasional corpse, which will often attack non-necromancers, while this might not sound like a big deal if you already have a fort full of necromancer dwarves, the real [[fun]] comes when diplomats, trade caravans, and outpost liaisons show up and if you have the dead walking among your populace. Also, be wary of sending necromancers out in melee, as intelligent undead invaders may remain hostile to your necromancers, who are ceaseless in bashing their heads in before killing them again in an endless, FPS-killing cycle.

Another way of getting necromantic reading material into your library is to "liberate" it in adventure mode, then drop the book off at a retired fortress. This will then be able to be picked up by your dwarves to read at their leisure.

A necromancer may raise the dead when threatened, which is fun when your battlefield is full of previously hostile sentients. This is why you should almost always manually control the necromancer in fortress mode.
There does not appear to be many disadvantages to having necromancer residents, however if you have too many during battle, they may raise too much undead and cause

===Applications===
Necromancers can be made useful by applying them in [[training]] schemes. Necromancers trapped in a room with line of sight to, say, the contents of the corpse stockpile, can be used to generate an infinite amount of hostile creatures to fight; when you get tired of the sport (or your dwarves start getting beat up), simply block their line of sight with a bridge and put down the remaining enemies, and your military can walk out of training with more experience.

Capturing necromancers is simple: build a tunnel near the necromancer, link floodgates or bridges within so that it can be sealed off, and then poke a hole into the surface. Assuming the necromancer was the nearest creature to where you opened the tunnel, they will be the first one in, and you can then seal off the tunnel and trap them inside. It's difficult to get the necromancer in there alone, without a few zombies following, but it shouldn't matter. [[Cage trap]]s will work too; however, caged necromancers do not appear to revive stuff. You must put necromancers on a restraint afterwards if you want them to be able to.

They can also be weaponized. Replace the militia training room with a room full of goblins, and fun will result. Upright spike [[trap]]s can "kill" the corpses after each use so that the resulting [[goblinite]] can be gathered, and the trap reused. Given enough time and enough bodies, such a trap can even best the [[HFS|circus]].

Much like [[vampire]]s, necromancers may seize control of a [[civilization]] and become its [[monarch|king/queen]]. In that case, the dwarf in question must be isolated from any corpses, as ''they'' may be friendly, but the zombies they tend to create... will be of the dwarven-arm-ripping variety. They should be either isolated from the dead with a [[burrow]], or applied to training/killing. Either way, necromancers are very [[fun]].

===Visitors or immigrants===

Necromancers may also casually arrive as [[visitor]]s or [[immigrant]]s in your fortress. When visiting, they won't attack you or attempt to raise any corpse they see – they came to relax, and just happen to know the secrets of life and death (the visitors are normally, though not necessarily always, schemeing something). They ''will'', however, use their powers in combat (for instance, if they enlist as mercenaries in your squads), but not necessarily mindless corpse-raising – they may revive one of your dwarves that just died as an [[intelligent undead]], who is loyal to your fortress and has extra powers. Necromancer immigrants can be put to work like any other immigrant dwarf - this may be bad for your meat supply when they practice their craft on the corpses produced by your hunters, however.

==Adventurer Mode==
In [[adventurer mode]], necromancers are most commonly found in towers {{Tile|I|5:0}}, but can very rarely be found in towns and camps, due to reasons explained earlier in this article. Towers will contain all the necromancers that are part of the necromancer group to whom the tower belongs, as well as a horde of undead. Towers require abundant human populations (low savagery, large tracts of neutral land) and a high number of secrets to be generated in world generation. Elves or goblins cannot become necromancers through normal means (bestowed by a death god) as their immortality means they cannot become obsessed with their own mortality. They can still learn the secrets of life and death by reading them, however.

It is possible to become a necromancer yourself in adventurer mode by [[reader|reading]] the slab or one of the books containing the secrets of life and death. Both will be found on the tables scattered around the tower, often amongst a pile of other, less useful books.

So, becoming an immortal being who doesn't need to worry about petty things like eating, drinking and sleeping and can also raise and control an undead army merely requires you to read some slab or book. Sounds simple, doesn't it? Unfortunately, it isn't. The tower is stuffed with undead monstrosities who would probably like nothing better than to tear your poor adventurer to shreds. If that isn't bad enough, the necromancers to whom the slab and books belong will raise their
servants each time you strike them down, if they can see the corpses.

So, what can we do to get at those secrets? Well, there are methods:

* '''1. Storm the tower'''
This is probably the most obvious solution, and is also the most likely to get inexperienced adventurers killed. Once you have become powerful enough, attack the tower head-on, preferably bringing with you an army of <s>meatshields</s> soldiers (who will likely get themselves killed, but will provide a distraction for you). It is advisable for you to lure the undead out of the tower first, away from the necromancers' gaze. This will make dealing with them far easier, and will give you a lot more space to dodge (or run if things get bad). If a necromancer is in the midst of the horde, try to move around so that the necromancer is exposed, then go in for the kill. Proceed until everyone (excluding yourself) is dead. Alternatively, just run into the tower and begin hitting everything like a madman. Eventually, either you or all of the tower's occupants will be dead. Then just take the slab/book and do what you will with it.

* '''2. Sneaking'''
Since [[ambusher|sneaking]] in the current version basically makes you invisible{{verify}}, and due to the fact that lighting barely exists yet, sneaking into the tower with a high enough skill and [[thrower|throwing]] stuff will allow you to kill everyone with minimal damage done to yourself. There is, however, the risk of being spotted, in which case you are advised to run away as quickly as you can. Alternatively, you could try to sneak around the tower and steal the slab/book without killing anything, but, because of the high density of enemies in a tower, it is extremely likely that you will be spotted, swarmed and killed.

* '''3. Being a Night Creature'''
Visiting the tower as a [[night creature]] [[Faction#Faction relative hostility|to whom undead are friendly]], such as a [[vampire]], [[undead|husk/thrall]] or, of course, a fellow necromancer, is by far the easiest way to obtain the slab/a book. Seriously. The undead are {{token|OPPOSED_TO_LIFE}}, but these night creatures are {{token|NOT_LIVING}}, so they will ignore you completely. Since undead will not attack necromancers, making a mad dash for the slab/book is also a viable option, but you will risk being killed/severely wounded before you get the chance to become a necromancer. If you are already one of these night creatures, you can just skip gleefully past the undead, read the slab/book and get out. You may also want to have a chat with the necromancers, who are actually quite friendly once you get to know them. In fact, night creatures who are shunned by society will often still be accepted by necromancers, who you can even ask for [[Adventure mode#Quests|quests]]! That is, of course, unless you are an enemy of their group, in which case they will attempt to kill you. Be advised that you cannot become a necromancer as an [[experiment]].

* '''4. Fire. A lot of fire.'''
The undead hordes will not cross small fires. The aspiring adventurer can outrun undead, leading them away from the tower, then run for the entrance. If there are more undead inside, run away. Repeat this until the undead have emptied from the tower, outrunning them and herding them. Run to the tower entrance and light fires around it, sealing them out. Take your time, enjoy the books, maybe mess with a necromancer. When you're ready to leave, scale the wall or jump over the fire. Bonus points: completely enclose the undead in a fire circle they cannot escape from. Side note: while running from undead, igniting the grass in clever places will slow them down even further.

* '''5. Vampire recruit'''
Another strategy, which may not always be available but can work well, is recruiting a vampire. Undead creatures and vampires won't bother each other, but the vampire will attack any hostile necromancers present. Once the necromancers are all dead, you will be left with the far simpler task of killing the undead without having to worry about any of the corpses reanimating.

* '''6. Leapfrog'''
{{k|j}}umping is an often overlooked but fairly powerful combat tool, especially against large hordes of very stupid zombies. Huge numbers have no impact of how effective jumping is, and zombies don't really try all that hard to get out of your way. It's fairly easy to just leap through entire hordes of zombies until you get to the tower proper, at which point you can just dash up some stairs and wait a bit for the zombies to forget you. The actual sentient inhabitants of the tower are strangely hospitable (even to the living) and don't seem to mind you that much, although some experiments seem to turn aggressive if you try talking to them. Once you've found the secret the zombies have probably forgotten about you and will ignore you now that you're also a night creature, and any that still remember you can be dispatched easily without causing any more trouble.

===Playing as a necromancer===

As a necromancer, you:

*don't need to eat or drink, so you don't need to worry about running out of food/water and can get rid of the extra weight such objects produce.
*don't need to sleep, and can't get tired or exhausted, so you'll never again feel the negative effects of these statuses.
*are immortal, as necromancers do not age. This will ensure that your adventurer will not die of old age if your world goes on until its natural {{token|MAXAGE}} is reached (such as if you retire an adventurer and play fortress mode for a while).
*can reanimate corpses to create undead companions. This can be done as many times as you want, with a small [[time]] limit between each reanimation, and only requires a corpse/body part.

Becoming a necromancer also freezes your physical [[attribute]]s so that they cannot rust or be increased. Therefore, it might be wise to raise them to a high level before becoming a necromancer. (However, this does not seem to be happening in the current version, including 0.47.05, probably due to a bug, or it's a design choice. Because let's be honest, just because you're a necromancer doesn't mean you can't learn new things, right?)

==== Reanimating dead creatures ====
1.Open the actions menu by pressing {{k|x}}. 
2.Press {{k|p}} or scroll to "acquired power". 
3.Select ({{k|→}} {{k|Enter}}) "Animate corpse". 
4.Now move the cursor onto the corpse(s) you wish to animate, press the letter that they are represented by on the items screen (such as {{k|a}}) and press {{k|Enter}}. Note that you can animate more than one corpse at a time, and that you can also animate corpses that are in your inventory. 
[[File:Animatecorpsemenu.jpeg]]

It is worth noting that you can only raise corpses with intact heads or grasping body parts (hands). That is, if the creature's head and hands explodes into gore, collapses into gore, or otherwise is pulped via damage to the head or torso, then that corpse cannot be raised. It is still possible, however, to raise a corpse that has had its head completely severed. The arms and head of a single individual can also be raised as different zombies, granted they are separated properly to begin with.

Besides acting as reusable and easily-replenishable soldiers, undead hold potential usage as training dummies for weapons and wrestling skills and can be used to build for you, including animated body parts. A crafty adventurer may cut the limbs off their undead slaves and reanimate them, counting as an additional companion, and reducing build time. However, while a necromancer can still be friendly to mortals, its minions will attack everything living in sight.

For combat, because raised dead lose all their skills as well as the ability to learn, only the attributes and size of the creature at the time of their death are important.

As in fortress mode, necromancer companions and NPCs will automatically raise the dead when in the heat of battle. To counter this in adventure combat, mangle a sentient being using a blunt weapon so they can never be raised, or butcher them once and mangle the raised skin. Butchering doesn’t take time, so it doesn’t hurt to immediately butcher someone you killed.

Alternatively, you can destroy someone’s soul by raising a corpse as a non-intelligent undead. This rewrites their faction and soul traits, and any subsequent resurrection will raise them as a soulless creature loyal to you. This is very useful when you are in mass combat.

Be warned that raising a corpse in front of a lot of people who are already in combat will cause a lag spike.

==[[Object testing arena]]==
Necromancy can be assigned to any creature by simply changing the "effect" of the spawned creature to "necromancer" by pressing {{k|u}}. As expected, necromancers will reanimate dead creatures and severed body parts, though, depending on which team the player has set for the spawned necromancer and that of any creature that died that said necromancer chose to resurrect, strange behaviors can occur.

For example, a necromancer revives the body parts of a dead, dismembered dwarf in an effort to aid itself in fighting, but because the dwarf was on the "independent" team (or just a different one from the necromancer), the body parts just end up attacking the necromancer that raised them. So said necromancer may end up killing what it resurrected, only to keep resurrecting what it just killed to fight it again, which can happen over and over in an endless loop - all due to the clashing of how the arena handles teams/sides and the necromancer's natural AI in raising the dead to help itself.

==Modding==
{{mod}}
It is entirely possible to create your own unique secret class, with powers ranging from material emission (fireballs, firebreath, syndrome-inducing materials) to turning corpses into enthralled creatures, such as giant lions.
This can be accomplished by creating an "interaction_secretnamehere" raw file with the appropriate tokens.

It is also possible to improve the number of necromancers, and therefore towers, by permitting more races to have necromancers. This can be done by adding mortality to races that are not mortal ([[Elf|Elves]] and [[Goblin]]s) with the {{token|MAXAGE}} token, or by adding intelligence to other creature tokens. Even having the ability to pray seems to add yet more original necromancers (that have discovered the secret by worshiping). This could be done by giving religion to races that don't have it, like goblins (see some digging on these subjects here: http://www.bay12forums.com/smf/index.php?topic=161352.0, http://www.bay12forums.com/smf/index.php?topic=154533.0). It also seems that having a DEATH [[Entity_token#RELIGION_SPHERE|sphere]] in the religion of the race vastly improves the ability to discover the secret of life and death.

Example:
Modded goblin race with:
<nowiki>
[RELIGION:PANTHEON]
[RELIGION_SPHERE:DEATH]
</nowiki>
in entity_default and:[MAXAGE:200:250] in creature_standard, will generate a lot of tower-building necromancers.

Doing this for all races with massive population amounts in your world will ensure that towers, and, therefore, undead, are present in large numbers for more [[fun]].

{{gamedata|title=Example raws (as extracted from world.dat in version 0.47.04)|
[INTERACTION:SECRET_11]
[GENERATED]
[I_SOURCE:SECRET]
[IS_NAME:the secrets of life and death]
[IS_SPHERE:DEATH]
[IS_SPHERE:NIGHTMARES]
[IS_SECRET_GOAL:IMMORTALITY]
[IS_SECRET:SUPERNATURAL_LEARNING_POSSIBLE]
[IS_SECRET:MUNDANE_RESEARCH_POSSIBLE]
[IS_SECRET:MUNDANE_TEACHING_POSSIBLE]
[IS_SECRET:MUNDANE_RECORDING_POSSIBLE:objects/text/book_instruction.txt:objects/text/secret_death.txt]
[I_TARGET:A:CREATURE]
[IT_LOCATION:CONTEXT_CREATURE]
[IT_REQUIRES:MORTAL]
[IT_REQUIRES:CAN_LEARN]
[IT_REQUIRES:CAN_SPEAK]
[I_EFFECT:ADD_SYNDROME]
[IE_TARGET:A]
[IE_IMMEDIATE]
[SYNDROME]
[SYN_CONCENTRATION_ADDED:1000:0]
[CE_DISPLAY_TILE:TILE:165:5:0:1:START:0:ABRUPT]
[CE_DISPLAY_NAME:NAME:necromancer:necromancers:necromantic:START:0:ABRUPT]
[CE_ADD_TAG:NOEXERT:NO_AGING:NO_EAT:NO_DRINK:NO_SLEEP:NO_PHYS_ATT_GAIN:NO_PHYS_ATT_RUST:START:0:ABRUPT]
[CE_CHANGE_PERSONALITY:FACET:ANXIETY_PROPENSITY:50:FACET:TRUST:-50:START:0:ABRUPT]
[CE_CAN_DO_INTERACTION:START:0:ABRUPT]
[CDI:ADV_NAME:Animate corpse]
[CDI:INTERACTION:SECRET_ANIMATE_11]
[CDI:TARGET:A:LINE_OF_SIGHT]
[CDI:TARGET_RANGE:A:10]
[CDI:VERB:gesture:gestures:NA]
[CDI:TARGET_VERB:shudder and begin to move:shudders and begins to move]
[CDI:WAIT_PERIOD:10]
[CE_CAN_DO_INTERACTION:START:0:ABRUPT]
[CDI:ADV_NAME:Raise damned butcher]
[CDI:INTERACTION:SECRET_UNDEAD_RES_11]
[CDI:TARGET:A:LINE_OF_SIGHT]
[CDI:TARGET_RANGE:A:10]
[CDI:VERB:gesture:gestures:NA]
[CDI:TARGET_VERB:shudder and begin to move:shudders and begins to move]
[CDI:WAIT_PERIOD:10]
[CE_CAN_DO_INTERACTION:START:0:ABRUPT]
[CDI:ADV_NAME:Summon bogeymen]
[CDI:INTERACTION:SECRET_SUMMON_B_11]
[CDI:VERB:call upon the night:calls upon the night:NA]
[CDI:WAIT_PERIOD:100]
[CE_CAN_DO_INTERACTION:START:0:ABRUPT]
[CDI:ADV_NAME:Summon nightmare]
[CDI:INTERACTION:SECRET_SUMMON_N_11]
[CDI:VERB:call upon the night:calls upon the night:NA]
[CDI:WAIT_PERIOD:12000]
[CE_CAN_DO_INTERACTION:START:0:ABRUPT]
[CDI:ADV_NAME:Create ghoul]
[CDI:INTERACTION:SECRET_GHOUL_11]

[INTERACTION:SECRET_ANIMATE_11]
[GENERATED]
[I_TARGET:A:CORPSE]
[IT_LOCATION:CONTEXT_ITEM]
[IT_AFFECTED_CLASS:GENERAL_POISON]
[IT_REQUIRES:FIT_FOR_ANIMATION]
[IT_FORBIDDEN:NOT_LIVING]
[IT_MANUAL_INPUT:corpses]
[I_EFFECT:ANIMATE]
[IE_TARGET:A]
[IE_IMMEDIATE]
[SYNDROME]
[SYN_CONCENTRATION_ADDED:1000:0]
[CE_FLASH_TILE:TILE:165:3:0:0:FREQUENCY:2000:1000:START:0:ABRUPT]
[CE_PHYS_ATT_CHANGE:STRENGTH:130:0:TOUGHNESS:300:1000:START:0:ABRUPT]
[CE_SPEED_CHANGE:SPEED_PERC:60:START:0:ABRUPT]
[CE_ADD_TAG:NO_AGING:NOT_LIVING:OPPOSED_TO_LIFE:EXTRAVISION:NOEXERT:NOPAIN:NOBREATHE:NOSTUN:NONAUSEA:NO_DIZZINESS:NO_FEVERS:NOEMOTION:PARALYZEIMMUNE:NOFEAR:NO_EAT:NO_DRINK:NO_SLEEP:NO_PHYS_ATT_GAIN:NO_PHYS_ATT_RUST:NOTHOUGHT:NO_THOUGHT_CENTER_FOR_MOVEMENT:NO_CONNECTIONS_FOR_MOVEMENT:START:0:ABRUPT]
[CE_REMOVE_TAG:HAS_BLOOD:TRANCES:MISCHIEVOUS:START:0:ABRUPT]

[INTERACTION:SECRET_UNDEAD_RAISE_11]
[GENERATED]
[I_TARGET:A:CORPSE]
[IT_LOCATION:CONTEXT_ITEM]
[IT_AFFECTED_CLASS:GENERAL_POISON]
[IT_REQUIRES:FIT_FOR_RESURRECTION]
[IT_REQUIRES:CAN_LEARN]
[IT_FORBIDDEN:NOT_LIVING]
[IT_MANUAL_INPUT:corpses]
[IT_CANNOT_HAVE_SYNDROME_CLASS:WERECURSE]
[IT_CANNOT_HAVE_SYNDROME_CLASS:VAMPCURSE]
[IT_CANNOT_HAVE_SYNDROME_CLASS:DISTURBANCE_CURSE]
[IT_CANNOT_HAVE_SYNDROME_CLASS:RAISED_UNDEAD]
[IT_CANNOT_HAVE_SYNDROME_CLASS:RAISED_GHOST]
[IT_CANNOT_HAVE_SYNDROME_CLASS:GHOUL]
[I_EFFECT:RESURRECT]
[IE_TARGET:A]
[IE_IMMEDIATE]
[SYNDROME]
[SYN_CONCENTRATION_ADDED:1000:0]
[SYN_CLASS:RAISED_UNDEAD]
[CE_DISPLAY_TILE:TILE:165:3:0:1:START:0:ABRUPT]
[CE_DISPLAY_NAME:NAME:damned butcher:damned butchers:damned butcher:START:0:ABRUPT]
[CE_PHYS_ATT_CHANGE:STRENGTH:200:1000:TOUGHNESS:200:1000:START:0:ABRUPT]
[CE_ADD_TAG:NO_AGING:NOT_LIVING:STERILE:EXTRAVISION:NOEXERT:NOPAIN:NOBREATHE:NOSTUN:NONAUSEA:NO_DIZZINESS:NO_FEVERS:NOEMOTION:PARALYZEIMMUNE:NOFEAR:NO_EAT:NO_DRINK:NO_SLEEP:NO_PHYS_ATT_GAIN:NO_PHYS_ATT_RUST:NOTHOUGHT:NO_THOUGHT_CENTER_FOR_MOVEMENT:NO_CONNECTIONS_FOR_MOVEMENT:START:0:ABRUPT]
[CE_REMOVE_TAG:HAS_BLOOD:TRANCES:MISCHIEVOUS:START:0:ABRUPT]
[CE_CAN_DO_INTERACTION:START:0:ABRUPT]
[CDI:ADV_NAME:Propel away]
[CDI:INTERACTION:SECRET_RES_POWER_11_1]
[CDI:TARGET:B:LINE_OF_SIGHT]
[CDI:TARGET_RANGE:B:25]
[CDI:BP_REQUIRED:BY_TYPE:GRASP]
[CDI:USAGE_HINT:ATTACK]
[CDI:VERB:make a flicking motion:makes a flicking motion:NA]
[CDI:MAX_TARGET_NUMBER:B:1]
[CDI:WAIT_PERIOD:50]

[INTERACTION:SECRET_RES_POWER_11_1]
[GENERATED]
[I_TARGET:A:LOCATION]
[IT_LOCATION:CONTEXT_LOCATION]
[I_TARGET:B:CREATURE]
[IT_LOCATION:CONTEXT_CREATURE]
[IT_MANUAL_INPUT:target]
[I_EFFECT:PROPEL_UNIT]
[IE_PROPEL_FORCE:100000]
[IE_TARGET:A]
[IE_TARGET:B]
[IE_IMMEDIATE]

[INTERACTION:SECRET_SUMMON_B_11]
[GENERATED]
[I_TARGET:A:LOCATION]
[IT_LOCATION:CONTEXT_LOCATION]
[I_TARGET:B:LOCATION]
[IT_LOCATION:RANDOM_NEARBY_LOCATION:A:5]
[I_EFFECT:SUMMON_UNIT]
[IE_TARGET:B]
[IE_IMMEDIATE]
[IE_CREATURE_CASTE_FLAG:NIGHT_CREATURE_BOGEYMAN]
[IE_TIME_RANGE:200:300]

[INTERACTION:SECRET_SUMMON_N_11]
[GENERATED]
[I_TARGET:A:LOCATION]
[IT_LOCATION:CONTEXT_LOCATION]
[I_TARGET:B:LOCATION]
[IT_LOCATION:RANDOM_NEARBY_LOCATION:A:5]
[I_EFFECT:SUMMON_UNIT]
[IE_TARGET:B]
[IE_IMMEDIATE]
[IE_CREATURE_CASTE_FLAG:NIGHT_CREATURE_NIGHTMARE]
[IE_TIME_RANGE:200:300]

[INTERACTION:SECRET_GHOUL_11]
[GENERATED]
[EXPERIMENT_ONLY]
[I_SOURCE:EXPERIMENT]
[IS_HIST_STRING_1: infected ]
[IS_HIST_STRING_2: with a contagious ghoulish condition]
[IS_TRIGGER_STRING_SECOND:have]
[IS_TRIGGER_STRING_THIRD:has]
[IS_TRIGGER_STRING:been infected with a contagious ghoulish condition]
[I_SOURCE:ATTACK]
[IS_HIST_STRING_1: bit ]
[IS_HIST_STRING_2:, passing on the ghoulish condition]
[I_TARGET:A:CREATURE]
[IT_LOCATION:CONTEXT_CREATURE]
[IT_AFFECTED_CLASS:GENERAL_POISON]
[IT_FORBIDDEN:NOT_LIVING]
[IT_CANNOT_HAVE_SYNDROME_CLASS:WERECURSE]
[IT_CANNOT_HAVE_SYNDROME_CLASS:VAMPCURSE]
[IT_CANNOT_HAVE_SYNDROME_CLASS:DISTURBANCE_CURSE]
[IT_CANNOT_HAVE_SYNDROME_CLASS:RAISED_UNDEAD]
[IT_CANNOT_HAVE_SYNDROME_CLASS:RAISED_GHOST]
[IT_CANNOT_HAVE_SYNDROME_CLASS:GHOUL]
[IT_MANUAL_INPUT:victim]
[I_EFFECT:ADD_SYNDROME]
[IE_TARGET:A]
[SYNDROME]
[SYN_CONCENTRATION_ADDED:1000:0]
[SYN_CLASS:GHOUL]
[CE_FLASH_TILE:TILE:165:4:0:1:FREQUENCY:2000:1000:START:0:ABRUPT]
[CE_DISPLAY_NAME:NAME:diseased ghoul:diseased ghouls:diseased ghoul:START:0:ABRUPT]
[CE_ADD_TAG:NO_AGING:NOT_LIVING:OPPOSED_TO_LIFE:EXTRAVISION:NOEXERT:NOPAIN:NOBREATHE:NOSTUN:NONAUSEA:NO_DIZZINESS:NO_FEVERS:NOEMOTION:PARALYZEIMMUNE:NOFEAR:NO_EAT:NO_DRINK:NO_SLEEP:NO_PHYS_ATT_GAIN:NO_PHYS_ATT_RUST:NOTHOUGHT:NO_THOUGHT_CENTER_FOR_MOVEMENT:NO_CONNECTIONS_FOR_MOVEMENT:START:0:ABRUPT]
[CE_REMOVE_TAG:TRANCES:MISCHIEVOUS:START:0:ABRUPT]
[CE_SPECIAL_ATTACK_INTERACTION:INTERACTION:SECRET_GHOUL_11:BP:BY_CATEGORY:MOUTH:BP:BY_CATEGORY:TOOTH:START:0:ABRUPT]

}}
{{Creatures}}
{{category|humanoids}}

[[ru:Necromancer]]

Dwarf Fortress Wiki talk:Versions

2023-01-02T05:05:51Z

Kelvie: /* Graphics */

{{archive|
# [[DF Talk:Versions/Archive 1|Page 1]]}}

== Version 0.31.19 starts a new DF generation? ==

My reading of Toady's comments on the release of 0.31.19 is that it came out basically because he felt it would take too long to get DF all the way to 0.32. With the ore changes, the sitefinder changes, the addition of grazing and several different industries, there's a lot of changes between 31.18 and 31.19. So I'm thinking it might be a good idea to call it the first release of DF2011 - and what we refer to as "DF2010" would then become 0.31.18.

Thoughts? --[[User:DeMatt|DeMatt]] 07:06, 28 February 2011 (UTC)

==Revisiting Redirects==

I wasn't around when the redirect policy was created, and I'm having trouble understanding the rationale. The example claims that linking [[Main:Cheese]] to [[cv:Cheese maker]] is problematic...but mainspace only ever redirects to the current version. If the best target in the current version is cheese maker, why not link to it directly? (It's not, at least for Cheese, since [[DF2012:Cheese]] exists now.) The explanation seems to be claiming that 40d articles that link to Cheese will follow the Mainspace link--but that hasn't been the case for a long while now. Articles in 40d automatically link against other articles in 40d, so that version remains internally consistent no matter where mainspace links to in the current version. For a current example, what do we gain by linking [[Main:Mead]] to [[cv:Mead]] and linking [[DF2012:Mead]] to [[DF2012:Alcohol]]?

If this really is just an outdated procedure, I recommend we drop the mummery and allow mainspace to link to cv:(best target). Double redirects ''may'' work (sometimes, but [[Main:Mead]] demonstrates a common problem where automatic redirection fails), but if they are unnecessary I think they should be avoided, partly because of problems like [[Main:Mead]] and partly because of the effort required to protect double redirects from users who believe they are problematic.--[[User:Loci|Loci]] ([[User talk:Loci|talk]]) 20:16, 8 January 2014 (UTC)

:I was just thinking that. I'm currently attempting to write a basic extension to eliminate the need for mainspace redirects entirely, although Mediawiki's class structure may make this more difficult than I had hoped (the only method I've found for resolving redirects takes the ''article text'' instead of a title, e.g. "#REDIRECT ..."). I do agree that the current situation with redirects isn't ideal, so I'm hoping this will work better (once I get it to work). --[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 20:42, 8 January 2014 (UTC)

Okay, that wasn't quite as clear as I meant it to be. In general, I think this is a tricky situation. Mediawiki wasn't designed to have five content namespaces, and certainly not chains of redirects between them. The problem that was pointed out in the [[DF:REDIR|policy]] is the fact that with:
Main:Foo -> cv:Bar
pages in the cv: namespace can't use [[<nowiki/>foo]], since the namespace links modification causes it to be treated as [[<nowiki/>cv:foo]] instead, which doesn't exist. The current suggested solution is this:
Main:Foo -> cv:Foo -> cv:Bar
This fixes the problem of [[<nowiki/>foo]] not working on cv pages, but creates issues with double redirects not always working. Another solution, which is more intuitive to new editors, is:
Main:Foo -> cv:Bar
cv:Foo -> cv:Bar
Both require creating two redirects. The first method has the advantage of ''ensuring'' that the cv redirect exists (otherwise, main:foo would be a redlink), while the second has the advantage of working more reliably in a couple cases.

What I'm trying to do is make main:Foo "jump" to cv:Foo when cv:foo exists, ''even if main:foo doesn't exist'' (basically it would treat all mainspace pages as redirects to cv pages, but only if the cv page exists and not the mainspace page). I had main:Bar jumping to cv:Bar fine, but if cv:Foo redirected to cv:Bar, accessing main:Foo would mysteriously stop at cv:Foo even if I increased the redirect limit. What I'm trying to do now is follow the redirects internally, without relying on Mediawiki to do it automatically - unfortunately, that has proved to be harder than I had hoped (and I sent my web server into an infinite loop while trying). I will try to work on this some more when I get a chance, although I'm not sure when that'll be yet :(. For now, feel free to fix broken double mainspace redirects as necessary, as long as redirects in the DF2012 namespace stay pointing to the right page (and new mainspace redirects get added in the DF2012 namespace too). --[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 04:21, 9 January 2014 (UTC)

:You're treating cv like a namespace--it's not. It is simply shorthand for "fill in the current version here". [http://dwarffortresswiki.org/index.php?title=User_talk:Briess&diff=182404&oldid=181281 As I discovered a long time ago on a server not far away], linking from Main:Foo to cv:Foo tends to break redirection chains. If, instead of linking to cv:Foo, you link to DF2012:Foo, it might just work. It would, of course, be better if your patch could evaluate cv itself, but even if you have to hardcode the current version it's a single point of maintenance that requires update very infrequently. (For that matter, we could probably dispense with the cv hack entirely and just have a bot update mainspace links from DF2012 to DF201X when we switch to a new version.)--[[User:Loci|Loci]] ([[User talk:Loci|talk]]) 20:05, 9 January 2014 (UTC)
::I know cv isn't a namespace - I was just trying to avoid future confusion when the DF2012 namespace changes. It's interesting that changing "cv" to "DF2012" fixes some broken redirects, although I've found that simply making an edit to a broken redirect can usually fix it as well. I've actually had the most problems with double redirects when the second one (in the DF2012 namespace) doesn't use the DF2012 prefix (e.g. main:Foo containing <nowiki>[[cv:Foo]] and DF2012:Foo containing [[Bar]]</nowiki>). I'd rather keep the cv alias even if it isn't necessary for mainspace redirects when I get the patch to work, since it makes it easier to refer to the current version of the page (for example, several MDF articles contain links to a vanilla page for things that don't change in the mod).
::Also, using aliases like "cv" is supported by Mediawiki; in fact, several WMF wikis use them (for example, "[[wikipedia:WP:Redirects|WP:Redirects]]" on Wikipedia). It's quite likely that Mediawiki isn't processing double redirects using aliases correctly, though, since that's uncommon on most wikis. --[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 21:35, 9 January 2014 (UTC)

In light of the lack of support for the current redirect policy, I propose we replace the current redirect section with:

:Mainspace article pages should use the cv: alias when redirecting to a versioned page, which will automatically update the link when a new version is released. For example, page "Main:Foo" should redirect to page "cv:Bar" (where "Bar" is the page that best describes the topic Foo in the current version).

:Pages in mainspace should only redirect to an older versioned page if that content no longer exists in the current version of the game (e.g. [[Cave river]], [[Chunk]]). In these cases the cv: alias cannot be used.

:Pages inside a versioned namespace should not use the cv: alias. Instead, they should redirect to the best page within that versioned namespace (e.g. [[DF2012:Dodging]], [[v0.31:Drink]]).

:Due to limitations of the wiki software, double redirects should be avoided if possible. When fixing double redirects in mainspace, please make sure to use the cv: alias as appropriate.

If no one objects, I will make this change in a few days.--[[User:Loci|Loci]] ([[User talk:Loci|talk]]) 20:21, 15 January 2014 (UTC)

:Okay with me. It may be worth mentioning that double redirects only really need to be changed when they don't work (since changing a lot of redirects that work isn't necessary), but I think it's clearer and more relevant than the current policy. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 00:26, 16 January 2014 (UTC)

Done.--[[User:Loci|Loci]] ([[User talk:Loci|talk]]) 20:55, 22 January 2014 (UTC)

I was finally able to get my extension to work after being motivated by one too many malfunctioning redirects. It now causes nonexistent pages in the main namespace to behave exactly like redirects to their DF2012 counterparts (when linked to, accessed directly, and transcluded). Double redirects also work (up to 100, in fact, although that was a temporary safety measure that I'll probably change). This means we'll be able to safely get rid of all mainspace redirects (redirects that redirect to something other than "cv" will still function if not deleted). —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 01:20, 14 March 2014 (UTC)
:What about articles which don't exist in the current version but do exist in older versions? Will those still need mainspace redirects, or will your extension be able to automatically redirect them to v0.31/40d/23a? --[[User:Quietust|Quietust]] ([[User talk:Quietust|talk]]) 01:29, 14 March 2014 (UTC)
::It ignores all mainspace pages that actually have content, including redirects, so pages like [[masons guild]] won't be affected (unless deleted). —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 01:47, 14 March 2014 (UTC)

Done and deployed. [[Cat]] is still treated as a redirect, even though I just deleted it (try clicking on the "redirected from" link). Pages that exist are ignored, so [[Masons guild]] and [[History of Dwarf Fortress]] still function normally (as a redirect to a 23a page and a non-redirect, respectively). —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 18:57, 14 April 2014 (UTC)

I'm sending around a bot right now to delete all redirects of the format "foo -> cv:foo" (a surprising number don't fit this format, so I'm leaving them alone for now). —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 20:43, 14 April 2014 (UTC)

:I'm confused. Do we use double redirects or not? Is there a single place we define our linking policy (including redirects), and is it updated?
:I had trouble linking to [[Consolidated_development]] in [[v0.34:Dragon]]. It kept pointing to v0.34:Consolidated_development, which does not exist. I ended up linking to Main:Consolidated_development to make it work. --[[User:Nahno|Nahno]] ([[User talk:Nahno|talk]]) 10:18, 1 July 2014 (UTC)

::That's a separate problem altogether - links in the versioned namespaces (v0.34, v0.31, 40d, 23a) automatically link to pages within their namespace. I may be able to set up a fallback to mainspace once I'm able to deploy again, but for now the "main:" alias is the intended solution. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 11:36, 1 July 2014 (UTC)

== Google often directs people to the 0.31 page ==

I've noticed a couple of times that finding a wiki page from an external search will often drop me onto a page from an older version. Is it possible to mitigate this somehow for new players? I could imagine something like redirecting old:Bar -> cv:Bar unless the user has come from old:Foo; no idea if that would actually work though. [[User:PeridexisErrant|PeridexisErrant]] ([[User talk:PeridexisErrant|talk]]) 11:48, 4 May 2014 (UTC)

:As a temporary solution, I could write a script that displays a banner of some kind if the user came from an external site. I'll ask Briess if he can do anything on the server level to increase the weighting of the current version's pages. (Obviously there are situations where people are looking for old pages, like [[23a:dungeon master]], so we don't want to disable indexing entirely on old pages.) —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 17:03, 4 May 2014 (UTC)

== DF2014? ==

As Toady [http://www.bay12games.com/dwarves/ draws closer to a new release], it might be worthwhile to discuss the addition of a new version to the wiki. The upcoming release covers two years of changes and introduces a number of new plants, foods, drinks, multi-tile trees, climbing, jumping, etc., so it is likely to have significant changes from the current DF2012. To avoid having people start new pages (and lose all the effort spent refining the prior version's page), I think it would be best to have a bot automatically copy over the DF2012 pages as a starting point for DF2014. I would suggest that these copied pages include a noticebox template mentioning that the content may be outdated, so that we can easily track which pages have been reviewed. I think either the {{tl|version check}} or {{tl|old}} template would work. --[[User:Loci|Loci]] ([[User talk:Loci|talk]]) 19:43, 5 May 2014 (UTC)

:This is what [[User:QuietBot]] did after the 0.34 release, so it's certainly possible to use the same script to migrate to DF2014. I would like a way of tagging migrated pages, since inaccuracies in some pages went unnoticed for months after they were migrated. Since {{tl|old}} is already in use, {{tl|version check}} may be a better solution (it can be reworded slightly, or we can make a separate template for DF2014 migration). —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 19:23, 1 June 2014 (UTC)
:Made [[Template:DF2014 migrated]] as an example. Any thoughts? —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 19:32, 1 June 2014 (UTC)

== Redirects inconsistency ==

Following a redirect is supposed to be exactly the same as going straight to the page it redirects to, but this actually isn't the case:
* Go to [[Seeds]] and you get [[v0.34:Seed]] (outdated)
* Go to http://dwarffortresswiki.org/index.php?title=Seeds&redirect=no and click on the link and you get to [[DF2014:Seed]] (current)
So if you search for "seed", the top result is the DF2014 version. But search for "seeds" and you get the redirect, which sends you to the outdated page instead. [[User:Hairy Dude|Hairy Dude]] ([[User talk:Hairy Dude|talk]]) 23:22, 22 February 2015 (UTC)

While I'm talking about redirects, it seems redirects to sections don't work: see [[DF2014:How do I manage my seeds and crops]]. I know MediaWiki is capable of this trick because Wikipedia does it. [[User:Hairy Dude|Hairy Dude]] ([[User talk:Hairy Dude|talk]]) 23:32, 22 February 2015 (UTC)

:I have absolutely no idea why [[seeds]] redirects to a v0.34 page - it could be a Mediawiki bug. The section links issue is due to a known issue in the redirect extension we use, which has yet to be fixed. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 00:01, 23 February 2015 (UTC)
:It looks like deleting both [[Seeds]] and [[DF2014:Seeds]] fixed things (by allowing AutoRedirect to handle the redirects instead). Feel free to tag any others with {{tl|bad redirect}}. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 00:03, 23 February 2015 (UTC)
::It gets stranger. [[Vial]] redirects explicitly to [[cv:Flask]] which displays (when you look at it with &redirect=no) as [[DF2014:Flask]], but still goes to the v0.34 version. It seems redirects interpret the cv: pseudo-namespace (or whatever it's called) in an outdated way. [[User:Hairy Dude|Hairy Dude]] ([[User talk:Hairy Dude|talk]]) 18:08, 23 February 2015 (UTC)
::I've added a note to this page about this issue. If it gets resolved, the note should be removed. [[User:Hairy Dude|Hairy Dude]] ([[User talk:Hairy Dude|talk]]) 21:04, 23 February 2015 (UTC)

==Reorganizing versions==

The internet deals with moved content... poorly. Google is still linking to v0.34 pages more than a year after the switch to "DF2014", and even the wiki software still has cached links pointing to the old version pages.

I propose reorganizing versions on the wiki to avoid moving content whenever possible. Instead of having a temporary "current version" namespace that changes occasionally, all the current information gets promoted to the Main namespace. When the next version split occurs, the Main articles as of a certain revision number can be copied to the newly-created permanent "old version" namespace, while all the current information remains in Main. This not only fixes the link rot issue, but it has a few other benefits as well: fewer administrative tasks, no lockdown (a historical version of the Main pages can be copied at any point, even if the Main articles are already modified for the new version), almost all the article history is maintained in the Main article (instead of being spread unevenly across multiple versions), no "temporary" namespaces are needed, fewer problematic long redirect chains, and hopefully less user confusion (since Main gets priority in search results, etc.).

As an example, today we would not have a DF2014 namespace (which is good because "temporary" namespaces historically disappear anyway). If you ran a search for [[seed]] you'd end up at Main:seed, which would have all the current information on seeds. The version box at the top of the page would still link to the older versions of the seed article. When a new version is released, an admin would choose a revision number and copy the Main:seed article as it exists at that revision number to v0.40:seed. That's it. One historical copy that needs little to no new editing, and zero redirections/moves.--[[User:Loci|Loci]] ([[User talk:Loci|talk]]) 19:02, 27 July 2015 (UTC)

:Makes sense to me. It would involve a lot of work, though (e.g. fixing templates and categories to account for the current version being in mainspace), although that should be doable thanks to {{tl|category}}, {{tl|version switch}}, etc.. A bot could be set up to copy revisions from before a release date as well, which would be more difficult (and maybe slower) than a direct copy, but not severely. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 17:24, 30 July 2015 (UTC)

:Actually, there are a few issues with that, namely that there wouldn't be an easy way to distinguish between versioned and non-versioned mainspace pages. There are ways to resolve Google search priority (we can exclude pages from older versions from search engine results if there are newer versions of those pages available, for example). —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 19:47, 6 August 2015 (UTC)

::There aren't very many non-versioned mainspace pages, and determining if a page is versioned is as simple as looking for the version template and/or categories added by the version template (e.g. copy [http://dwarffortresswiki.org/index.php/Category:Current this category] instead of Main:*). The problem with "suggesting" newer pages to Google is that they obviously aren't crawling our wiki regularly (if they were, the fact that the mainspace redirects point to new pages would automatically be picked up). Even if your Google hints worked they wouldn't do anything for all the other broken links out on the 'net.--[[User:Loci|Loci]] ([[User talk:Loci|talk]]) 20:35, 6 August 2015 (UTC)

::: Google actually crawls the wiki constantly - we probably get crawl hits from google for a continuous block of 2-3 hours per day, each and every day. Why they are slow to update is beyond me though. I can't remember why we didn't do this initially, but there was a technical limitation involved if I remember correctly. --[[User:Briess|Briess]] ([[User talk:Briess|talk]]) 22:05, 6 August 2015 (UTC)

::: There are <meta> tags that can be used to hide pages from search results (for search engines that recognize them, that is). Searching for {{tl|av}} or [[:Category:Current]] might work, although we'd have to make sure all of the DF2014 pages include that (some pages don't, particularly some disambiguation pages, although all of them should). —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 22:53, 6 August 2015 (UTC)

:Is there a particular reason main and current are separate to begin with?—[[User:CLA|CLA]] ([[User talk:CLA|talk]]) 00:17, 7 August 2015 (UTC)

::It's mostly intended to distinguish between versioned and non-versioned pages and make version-related templates simpler to work with, since every versioned page has a namespace. I wasn't active here in 2010 when this system was created, so Briess and Emi would know more.
::Another issue I just thought of with Loci's suggestion is categories - currently, categories like [[:Category:Animals]] are used to organize the versioned sub-categories. Sure, we can change {{tl|Category}} to categorize mainspace pages in [[:Category:v0.40:Animals]] or [[:Category:DF2014:Animals]], but that would be less straightforward because there wouldn't be a namespace with that name (until pages are migrated when a newer major version is released). —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 13:05, 7 August 2015 (UTC)

:Moving current pages to the main namespace sounds like a great idea. -[[User:Jecowa|Jecowa]] ([[User talk:Jecowa|talk]]) 20:47, 4 January 2018 (UTC)

Another thought: dealing with migrating redirects could be difficult with this proposal - specifically, determining which redirects should be migrated to a versioned namespace. Redirects can't contain {{tl|av}}, at least not before ``#REDIRECT``. I ''think'' it would be possible to copy pages in two stages, though - all non-redirects first, then all redirects whose targets were also copied. Thoughts? Anything I'm missing? —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 23:41, 27 June 2019 (UTC)

Some subpages (particularly /raw and /Edit notice) also deliberately lack {{tl|av}}, although those shouldn't be too hard to handle. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 00:35, 9 July 2019 (UTC)

:Redirect pages (and all other edge cases I've looked at) can be included in categories (like [[:Category:Current]]) to determine whether or not they should be copied into an archival version. But if the redirects are "properly qualified" then they can all be copied over blindly. Mainspace redirects pointing to versioned information should use a blank namespace (which will be automatically constrained to the archival namespace); mainspace redirects pointing to unversioned information should use an explicit "Main" (which will automatically link back to the unversioned page). Then, when [[[[Toady]]]] gets copied to [[[[v0.4x:Toady]]]] it will point back to [[[[Main:Toady One]]]]. Meanwhile, [[[[Beer]]]], copied to [[[[v0.4x:Beer]]]], will properly point to [[[[v0.4x:Alcohol]]]].--[[User:Loci|Loci]] ([[User talk:Loci|talk]]) 20:00, 14 July 2019 (UTC)

::I think qualifying redirects is the best solution here - categorizing redirects manually is another possible source of errors, since categories (or a lack thereof) would only be visible on the redirect page itself, and [[:Category:Current]] is a hidden category. Copying over mainspace redirects into versioned namespaces would also resolve some issues that have come up due to those not reliably existing currently. I should be able to set up a bot script to add "main:" to current mainspace redirects (and it shouldn't break anything, since those redirects go to other mainspace pages anyway). —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 21:57, 14 July 2019 (UTC)

(Note: I wrote all of this without noticing the previous discussion above.) I was wondering, when the wiki creates a new namespace for a major release again, if it is possible to ''not'' create a namespace for the next current version (e.g. "DF202x") and instead have the mainspace articles (which are currently redirects) become the new cv and move the content there. Therefore, [[cv:Cat]] would just be "[[Cat]]" (or [[Main:Cat]]).

Certain namespace-related templates like [[Template:Ns/0]] would need to be changed, though nothing significant as far as I know. For most cases, any "DF2014" would be replaced with "Main" or even blank. There's also multiple extensions handling the current namespace system and they may need to be modified too, though I'm not sure if or how much. I'm guessing based on the discussions above that it will change stuff up.

My reason is the current namespace is increasingly becoming more anachronistic. "DF2014" could be misinterpreted as "this page is about the 2014 version of the game" or "this page was last updated in 2014", which I've seen a few people in forums mention. Granted that [[Template:Av]] is on the top of very article, I still think the namespace is inconsistent with the recentness of the article. But how is this related to what I'm asking for? Let's say we continue the current system: if we happen to do a new namespace change this year and create DF2020, the next major release (after graphics/UI) will be mythgen, which is estimated to take several years to develop (the Big Wait), and so the anachronism will start over again. The proposed way will prevent this from occurring for the next major release and every release thereafter.

I think the confusion with having a namespace that becomes old-fashioned overtime supersedes the confusion with not marking current versioned articles with a namespace. Most users just search "Cat" on the search bar and naturally expect to get information about the latest release of DF. So if users go a page that's just titled "Cat", they won't expect outdated info about cats from a previous release. That's how the current system works anyways. We'll be skipping the two-step process that we have now. It'll make several wiki tasks much simpler as well. Editors can create new articles for current versions without remembering to add a namespace. It'll fix any existing issues with (double) redirects; instead of [[Main:Kitten]] redirecting to [[cv:Kitten]], which goes to [[DF2014:Kitten]], which then redirects to [[DF2014:Cat]], [[Main:Kitten]] would just redirect to [[Main:Cat]]. And the cv: alias will no longer be necessary since "cv:" = "Main:" and will be forever.

There's no need to differentiate the current version and previous versions with a namespace for the current version is what I'm saying. Articles of previous versions will retain their respective namespaces. Users will still type "40d:Cat" to go to the 40d version of the article, but if they want the current version, they'll just type "Cat" (like now). The mainspace containing the "live" version of an article is natural and would create no uncertainty when browsing the wiki. And it would simplify the wiki somewhat and future-proof this anachronism problem. As a bonus, this change will also prevent web search engines from showing previous version pages when typing "DF cat" or something. (This isn't happening right now as DF2014 has been the current namespace for ~6 years, but it'll happen again when everything moves to a new namespace.)

This is the gist of it, and I may have ignored most of the problems with this proposal. I have personally wished for the whole version namespacing be made less complicated and have been seeking for a solution, and I feel like this is the best way to go about in the future. – [[User:Doorkeeper|Doorkeeper]] 21:27, 14 August 2020 (UTC)

:<s>Whoops, looks like Loci already proposed this exact thing long ago. I definitely missed that discussion and should have checked first. My apologies. I'll move my text to that section and remove this one. – [[User:Doorkeeper|Doorkeeper]] 21:36, 14 August 2020 (UTC)</s> Done. – [[User:Doorkeeper|Doorkeeper]] 21:40, 14 August 2020 (UTC)

:The main issue I have with that is that putting pages about the current version in a namespace also differentiates between those pages and pages not about ''any'' version (for example, [[Toady One]] does not need a 40d or v0.34 page). Yes, we can use {{tl|av}} to mark versioned pages, but people often forget to add that to new pages. The current system also allows determining whether a page is versioned or not from its title, which makes migrations a lot faster. Relying on {{tl|av}} would require either reading the content of every page (which would slow scripts down significantly) or cross-checking with the list of all pages including the template (feasible, but a bit more complicated, and still susceptible to missing templates). I suppose that manually fixing and migrating pages missing {{tl|av}} later wouldn't be too much work, though.
:I am definitely in favor of changing "DF2014" (or a new namespace) to "Current", though. I was in favor of "DF2014" in 2014, but I don't think it makes sense anymore, and "Current" seemed to be a popular alternative in both the DF2012 and DF2014 discussions on the matter. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 04:02, 16 August 2020 (UTC)

== Weird redirect behaviour ==

[[Pump stack]] redirects to [[cv:Screw pump#Pump stack]]. If you look at the redirect itself it says it redirects to DF2014 namespace, which is correct. But if you actually follow the redirect, it goes to v0.34 namespace. [[User:Hairy Dude|Hairy Dude]] ([[User talk:Hairy Dude|talk]]) 16:10, 20 August 2018 (UTC)
:Yeah, that's part of the issue described in the above section (the wiki caching part, not on Google's end.) —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 15:00, 21 August 2018 (UTC)

== v50 organization ==

Some wiki admins have had a talk on Discord and decided that the most sustainable path forward is to put content for all future versions of DF in the main namespace. We will be working on a bot to do this in the next few days. Feel free to chime in with suggestions here. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 22:56, 14 December 2022 (UTC)

:Is it maybe possible to do backwards-namespacing? Like we have a "Main" namespace, which people are free to update, and whenever there's a new version of DF the "Main" namespace is copied into a namespace for the then old version, much like how you'd branch a stable branch from a development branch when working with a git-project? [[User:Therahedwig|Therahedwig]] ([[User talk:Therahedwig|talk]]) 23:13, 14 December 2022 (UTC)

::Yeah, we could do that if we decide to. We were talking about doing that for v50, actually, and might still do something similar to preserve edit history if it doesn't end up being too hard to automate. Our hope is that we will not introduce new namespaces for v50 -> v5x, unless there is a serious breaking change (and hopefully there isn't one). But if we change our mind, one advantage of the type of migration you mentioned is that it can be done retroactively - we can copy historical revisions that were current at the time of the release, and would only lose some typo fixes made after the release that apply to earlier versions as well. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 02:11, 15 December 2022 (UTC)

ETA is < 24 hours. Doing some final checks on a migration script. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 07:08, 19 December 2022 (UTC)

: We should really have a task list as there are many things that change and need updating. Including but not limited to:
:* Most templates that used the previous namespace convention broke, including nav templates.
:* Many game files changed locations and their pages need to be updated.
:* Raws need to be updated.
:* Various features added, changed, removed.
:* UI has been changed -- though I am more inclined to wait for classic release to avoid extra work --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 06:56, 20 December 2022 (UTC)

"''Raws need to be updated.''" Including applying text wraparound where necessary, I suppose - more than a few of them have proven to be that special kind of...''difficult'' to navigate otherwise, shall we say? [[User:Silverwing235|Silverwing235]] ([[User talk:Silverwing235|talk]]) 12:52, 20 December 2022 (UTC)

:There is already a task list in the [[#v50 migration|section below]] that includes templates and raws, with an explanation. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 16:25, 20 December 2022 (UTC)

== v50 migration ==

The initial migration script is done. New content is in the '''main''' namespace, e.g. [[Cat]]. Old content is still at [[DF2014:Cat]]. History was migrated to the ''new'' (main namespace) articles.

I know several things are broken still. Please reply if you find any others:
<div style="border-left: 2px solid red">
* <s>Versioned templates haven't been migrated yet (e.g. {{tl|vermin}} on [[Ant]])</s>
** Fixed. Most were migrated by a bot.
* Raws are missing on all pages that use them.
** This also affects sidebars, such as on [[Cat]] and [[Microcline]].
** Update: The DFRawFunctions extension has been upgraded to include v50 raws, using the "v50:" prefix for filenames instead of "DF2014:". I haven't finished a migration script to create the /raw pages themselves, but they can typically be created manually by copying the DF2014 /raw pages and changing "DF2014" to "v50" everywhere. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 20:20, 1 January 2023 (UTC)
* Some pages where the DF2014 page was a redirect to a main namespace page that contained content were migrated incorrectly.
** In this case, the main namespace page is usually a redirect to itself. This can be fixed by undoing LethosorBot's edit to the main namespace page, then copying the content to the DF2014 page.
** Update: most seem to have been fixed manually - thanks! —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 19:41, 21 December 2022 (UTC)
* <s>Some main-namespace talk pages redirect to DF2014 talk pages. Some of these redirects work, and some (usually older ones) do not.</s>
** Fixed with a bot. Some redirects from talk pages to other deleted talk pages are now broken, e.g. [[Talk:Above_ground]] (exists) -> [[Talk:Tile attributes]] (redlink). I am leaving them like that because they redirect to where the talk page should be created, but I'm also fine with people deleting them if they really want to. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 19:41, 21 December 2022 (UTC)
* {{tl|quality}} for new articles is disabled (see below)
* Some links from DF2014 to Main weren't working: e.g. the version selector [[DF2014:Mason's workshop]] was linking to [[DF2014:Main:Mason's workshop]] instead of [[Main:Mason's workshop]]. I'm not sure exactly why, but I fixed it with a change to the NamespaceLinks extension. Let me know if you spot similar broken links. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 23:19, 21 December 2022 (UTC)
</div>

—[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 04:54, 20 December 2022 (UTC)
:The quality levels of the 50.03 pages seem to be missing. I'm not sure if that's covered under that first point. [[User:Trainzack|Trainzack]] ([[User talk:Trainzack|talk]]) 06:47, 20 December 2022 (UTC)
::If the the [[Dwarf Fortress Wiki:Quality]] feature can be made to work with namespace scheme change, I suggest to automatically assign the lowest quality rating to all pages, alternately add the {{tl|old}} to all pages. Otherwise there will be a lot of pages that will fall through the cracks. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 09:12, 20 December 2022 (UTC)
:::I disabled {{tl|quality}} in the main namespace because it would require some rework to make the rating script and the template work properly there. Feel free to take a stab at the template. I will see what can be done on the extension side. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 21:14, 20 December 2022 (UTC)

It appears some pages are redirecting recursively and never resolving correctly, like the [[https://dwarffortresswiki.org/index.php?title=Character_table&redirect=no|character table]] and [[tileset repository]] 07:35, 20 December 2022 (UTC)
: Indeed, these can be caught here: [[Special:DoubleRedirects]] --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 07:51, 20 December 2022 (UTC)

It might be useful to change the notice title to "release information '''for editors'''" --[[Special:Contributions/142.59.195.176|142.59.195.176]] 10:26, 20 December 2022 (UTC)
:Can do. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 16:27, 20 December 2022 (UTC)

Main talkpages seem to redirect to DF2014 talk. Not sure if it is intentional but I like it, though we should pay attention when creating new discussion relating to v50 ending up there.--[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 14:18, 20 December 2022 (UTC)
:That's unintentional. I specifically wrote the migration script to not move talk pages, but that has the side-effect of leaving any previously-created "Talk -> DF2014 talk" redirects intact. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 16:27, 20 December 2022 (UTC)

Yo Lethosor, are we adding graphic sprites for the pages in some way? Or are we waiting for you to add some sort of new template or something? I'm sure you don't need me to tell you that the current templates don't allow that. Not sure if I'm allowed to change/create any templates either, as I don't want to break things for hundreds of pages. Edit: And IF the icons are allowed, should they be left alone, or 2×-3× sized like how the Minecraft wiki does it? --[[User:Zippy|Zippy]] ([[User talk:Zippy|talk]]) 14:29, 20 December 2022 (UTC)
:Depends on which templates you mean. There are copyright concerns with uploading a premium sprite sheet, for instance. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 16:27, 20 December 2022 (UTC)
::I'm not talking about uploading an entire sprite sheet. I'm just talking about individual icons for each respective page. One image for cows, one for horses, one for werebeasts, etc. --[[User:Zippy|Zippy]] ([[User talk:Zippy|talk]]) 16:50, 20 December 2022 (UTC)
:::If we do that for every creature in the sprite sheet, that's not much different (in terms of copyright) from uploading the entire sprite sheet. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 17:09, 20 December 2022 (UTC)
::::Is there someone we can talk to about that? We finally get this new game with graphics, and then we can't use the very graphics of the game? No matter what the rules are, I'd say that would be the stupidest thing ever. I know I'm infamous here when it comes to copyright and images and stuff, but about 80% of game wikis out there are completely unofficial, and use game file images like no one's business. I can't imagine anyone's door being knocked on if we used the game's sprites, but I won't add any here until we have a go-ahead. --[[User:Zippy|Zippy]] ([[User talk:Zippy|talk]]) 17:14, 20 December 2022 (UTC)

:::::...I've made noise in Mayday's direction on this matter, at least (prob an incorrect maneuver, ''but'').[[User:Silverwing235|Silverwing235]] ([[User talk:Silverwing235|talk]]) 17:55, 20 December 2022 (UTC)
:::::: I hope some sort of arrangement can be made so we can use the new sprites with permission/limits, just as we are using the raw files. Otherwise we are all (devs and editors alike) shooting ourselves in the foot here.--[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 21:07, 20 December 2022 (UTC)

:::::::I just thought of something. We're supposedly not allowed to upload entire sprite sheets, right? What if - for the time being - we just use a few of them for the purpose of testing out new infoboxes? --[[User:Zippy|Zippy]] ([[User talk:Zippy|talk]]) 21:46, 20 December 2022 (UTC)
::::::::I don't know. If someone could ask Kitfox and post the response here, that would be great. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 21:47, 20 December 2022 (UTC)

:::::::::I've reached out to Alexandra, but she hasn't answered yet. Until then I found these old approvals from the previous community manager, Feeona: ([http://www.bay12forums.com/smf/index.php?topic=173474.msg8243633#msg8243633 link1], [http://www.bay12forums.com/smf/index.php?topic=176640.msg8243642#msg8243642 link2]). Waiting for a newer response until we begin mass uploads is probably the politer option, but like Zippy said, it is also standard for wikis to use game sprites with less approval. I second their idea of trying it out with a few images to test the infoboxes. On the extreme off-chance (and I do think it is) Kitfox protests we can always remove these few. --[[User:Voliol|Voliol]] ([[User talk:Voliol|talk]]) 22:19, 20 December 2022 (UTC)
:::::::::And here is a third, more official statement: ([http://www.bay12forums.com/smf/index.php?topic=173474.msg8249718#msg8249718 link3]). Perhaps that address of info@kitfoxgames.com is the better channel to ask for a confirmation, rather than Discord DMs, but I will be going to bed, so it is best if someone else does that. --[[User:Voliol|Voliol]] ([[User talk:Voliol|talk]]) 22:29, 20 December 2022 (UTC)
::::::::::Thanks for tracking this down! Ok, sprites should be fine, but let's avoid uploading the entire premium tileset as a single image, for instance (as the forum thread says, "use common sense"). —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 00:21, 21 December 2022 (UTC)
::::::::::: Looks good, permission is always preferable over fairuse, I think it is a win win for all involved. I agree that we shouldn't upload entire sprite sheets (e.g. there is no reason to upload the windmill from every direction or whole construction phase for workshops) and that there are a lot of details that needs to be ironed out through testing. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 05:07, 21 December 2022 (UTC)
:::::::::We have a green light on uploading all and any sprites. Their response to me can be seen [https://i.imgur.com/BhmHjzC.png here]. I'm sure someone else confirmed it before me. --[[User:Zippy|Zippy]] ([[User talk:Zippy|talk]]) 19:00, 21 December 2022 (UTC)

Shifting temporarily to a new issue, is the documentation of [[Template:ArticleVersion]] outdated? It would seem so to me, since the current version no longer has its own namespace, with the templates needing updating being different ones. --[[User:Voliol|Voliol]] ([[User talk:Voliol|talk]]) 18:30, 20 December 2022 (UTC)
:I think it is still accurate enough. We left open the possibility of making another namespace in the future, albeit with a different migration strategy - see [[#v50 organization|above]]. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 21:52, 20 December 2022 (UTC)

Some Changes to infoboxes might be needed. Too bad [[User:Doorkeeper]] isn't around. He did a great work with navbox project--[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 20:52, 21 December 2022 (UTC)

I just realized that raw files aren't stored as regular wiki pages but loaded via the DFRawFunctions extension (hence the need to update). Good news it's going to be handled in bulk, consistently and relatively easy to updated. Even better it's Lethosor problem ;) Also I just realized that all the "raw files" (txt files in the new vanilla folder) are released into the public domain. Both are probably not news to the vets but I'll leave it here for those who less up to date like myself. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 07:35, 22 December 2022 (UTC)

: I noticed that some templates aren't working properly in the new namespace, e.g. [[Basalt]] entry had its raw updated manually but the infobox fail to show any details. Cursory look suggest {{t|layerlookup/0}} need a minor tweak. This should do the work
:: Replace: <nowiki>{{layerlookup/aux|{{{{FULLPAGENAME}}/raw}}|uses={{{uses|}}}|wiki={{{wiki|}}}}}</nowiki>
:: With___: <nowiki>{{layerlookup/aux|{{</nowiki>:<nowiki>{{FULLPAGENAME}}/raw}}|uses={{{uses|}}}|wiki={{{wiki|}}}}}</nowiki>
: Not sure what the plan and ETA with raws update so I didn't touch this high usage template for now. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 08:11, 24 December 2022 (UTC)

::Please do feel free to make this update. I am still working on a script to create the <code>/raw</code> pages themselves. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 03:12, 1 January 2023 (UTC)

== v50 specific issues ==
=== Graphics===
Follow up on the use of game sprites and the need to trying it out with a few images to test the infoboxes. First sprite [[:File:Beds v50.png]] was uploaded and used on [[Bed]] entry. Any thoughts? --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 18:06, 21 December 2022 (UTC)
:Seems like it should be rearranged to be horizontal. Also, has there been a serious discussion about copyright? Full screenshots are 100% fine, but you start going into a grey area when you upload pieces of a spritesheet. I'm of the opinion that it's all fine as long as it's inconvenient to reconstruct the full sheet from the individual images. Maybe a further restriction could be you shouldn't upload any of the art unless it's used in an infobox (maybe an exception for pieces of the UI). And one more restriction could be you shouldn't show everything, like in your bed example, maybe just the wooden bed is good enough, leave out the stone and metal, especially since those can only be made from strange moods. [[User:Brightgalrs|Brightgalrs]] ([[User talk:Brightgalrs|talk]]) 18:43, 21 December 2022 (UTC)
::Actually, your bed image is kinda bad for showing off what a bed looks like because it doesn't show the pillow/blankets. That might point to cropped screenshots being the best path, although less convenient for the uploader, as you don't get details left out. [[User:Brightgalrs|Brightgalrs]] ([[User talk:Brightgalrs|talk]]) 18:46, 21 December 2022 (UTC)
::I created a new license template [[Template:Copyright game]], based it on the way the RimWorld wiki does things. Call it a prototype, but it's probably how your bed image should be labelled. Indeed, I added it to it already. [[User:Brightgalrs|Brightgalrs]] ([[User talk:Brightgalrs|talk]])

::: I agree that the horizontal arrangement would suit better here and that we should strive to represent how things look in-game. Otherwise, I am not too concerned about people being able to reconstruct anything (lets just say that ''anyone'' interested in that can get the real thing from the game files), also it seem we have permission to use the sprits on top of fairuse. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 19:55, 21 December 2022 (UTC)

::: Modifying the existing template to allow the inclusion of the new sprites is easy (Something like [https://ibb.co/zFXCrjd this]?) The big question is the matter of consistency is there any exceptions that will break the format (size wise with variant bloat for example), the sprite naming format, etc --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 20:44, 21 December 2022 (UTC)
::: If we are going to show a variant for each material type, then maybe these should be added as separate images so we can add a tooltip for each image. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 20:49, 21 December 2022 (UTC)

:I've got another prototype going here and here: [[User:Brightgalrs/vector.css]] and [[User:Brightgalrs/Sandbox]]. (You'll need to add the css stuff to your own /vector.css). Basically it's a way to recolor images using css classes. No idea if there's a better way. Also, the real implementation would require a change to [[MediaWiki:Common.css]]. [[User:Brightgalrs|Brightgalrs]] ([[User talk:Brightgalrs|talk]]) 22:41, 21 December 2022 (UTC)
:Should mention, there ''is'' a different way, just upload each image 16 times, one for each coloring. But maybe that's not very elegant. [[User:Brightgalrs|Brightgalrs]] ([[User talk:Brightgalrs|talk]]) 22:45, 21 December 2022 (UTC)

: It should be noted that soon the classic edition will be released, hence one should plan to have both the Premium and classic alongside in that little space --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 03:14, 22 December 2022 (UTC)
::I'm looking into a tab extension to potentially support this in infoboxes. Perhaps [https://www.mediawiki.org/wiki/Extension:Tabs Extension:Tabs]? I tried [https://www.mediawiki.org/wiki/Extension:TabberNeue Extension:TabberNeue], but it displays a placeholder if JavaScript is disabled, which isn't great. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 04:22, 22 December 2022 (UTC)
::: The Neue Tabber seem to works pretty much like the old one (which fandom [https://coding-help.fandom.com/wiki/Tabber#Adding_images_into_tabbers still use]) defaulting to showing the first tab only. Quick look suggest that neue work the same, plus the notice that 'Tabber requires Javascript to function' warning? if so, and if it is a bother, then you should be able to edit out the tabberneue-noscript string in code. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 06:29, 22 December 2022 (UTC)
::: I much prefer your tabber solution, but if that fails we can also use the gallery slideshow mode. If so, beware it has no way to control image size so the images have to be maliciously uploaded using the exact same size. example:
<gallery mode="slideshow">
File:SteelSample.png
File:TinSample.png
File:ZincSample.png
File:GoldSample.png
</gallery> --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 10:19, 22 December 2022 (UTC)

==== adding premium set to Infobox ====
I am unclear where are we going with this? 
1) Will (A) tabs be implemented, (B) we be using mediawiki toggle [[Template_talk:V50_workshop|example]] for premium and classic/blocked, (c) put images side by side, or (d) something else? 
2) Also [[silver]] and [[Pig iron]] use very different image style for example. 
3) Anything else you want ? --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 12:32, 30 December 2022 (UTC)

: Personally, I would love tabs to be implemented, but I think that side by side might be best for most. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 12:32, 30 December 2022 (UTC)
: Here is rough layout we can use. It should fit most buildings given the default sprite size. There is also a different floor plan for both (inspired by reddit)

{|
|- valign=top
|
{| style="width:200px; background-color:#eaecf0; border-collapse: collapse; "
|+ 5x5
|- style="border-bottom:2px solid #3366cc; "
|<div class="mw-customtoggle-infoboxtab mw-ui-button mw-ui-progressive" style="border-top-right-radius: 10px; border-top-left-radius:10px;">toggle</div>
|{{Tooltip|Hotkey|adasdasdasd}}: {{Key|b|o|g}}
|- valign=top
|colspan=2|<div class="mw-collapsible" id="mw-customcollapsible-infoboxtab">
[[File:Siege workshop.png|center|160px]]</div>
<div class="mw-collapsible mw-collapsed" id="mw-customcollapsible-infoboxtab"">
{|
|rowspan=2 style="width:50%; font-size: 125%;"|<center>{{Template:Picture Siege workshop}}</center>
|style="line-height: 1em; font-size: 125%;"|
{| style="border-spacing:4px;"
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
|-
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#86878a; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#86878a; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#86878a; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
|-
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
|-
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#86878a; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#86878a; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#86878a; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
|-
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
|}
|-
| style="text-align: center;" | Layout
|}
</div>
|}
|
{| style="width:200px; background-color:#eaecf0; border-collapse: collapse; "
|+ 3x3
|- style="border-bottom:2px solid #3366cc; "
|colspan=2 style="text-align: right;"|<div class="mw-customtoggle-infoboxtab mw-ui-button mw-ui-progressive" style="float:left; border-top-right-radius: 10px; border-top-left-radius:10px;">toggle</div>{{Tooltip|Hotkey|adasdasdasd}}: {{Key|b|o|g}}
|- valign=top
|rowspan=2 style="width:50%;"|
<div class="mw-collapsible" id="mw-customcollapsible-infoboxtab">[[File:Carpenter's workshop.png]]</div>
<div class="mw-collapsible mw-collapsed" id="mw-customcollapsible-infoboxtab""><center>
{| style="font-size: 175%; border-spacing: 0; background-color: black; border: 2px solid black"
|- 
| style="padding: 0; line-height: 1em"|
| style="padding: 0; line-height: 1em"| {{Raw Tile|"|7:0:0}}
| style="padding: 0; line-height: 1em"| {{Raw Tile|{{=}}|6:0:0}}
|-
| style="padding: 0; line-height: 1em"| {{Raw Tile|░|0:7:1}}
| style="padding: 0; line-height: 1em"|
| style="padding: 0; line-height: 1em"|
|-
| style="padding: 0; line-height: 1em"| {{Raw Tile|░|0:7:1}}
| style="padding: 0; line-height: 1em"| {{Raw Tile|]|0:0:1}}
| style="padding: 0; line-height: 1em"| {{Raw Tile|░|0:7:1}}
|}</center></div>
|
{| style="border-spacing:5px;"
| style="width:18px; height:18px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:18px; height:18px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:18px; height:18px; background-color:#b7b9bd; border:1px solid #545557;"|
|-
| style="width:18px; height:18px; background-color:#86878a; border:1px solid #545557;"|
| style="width:18px; height:18px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:18px; height:18px; background-color:#b7b9bd; border:1px solid #545557;"|
|-
| style="width:18px; height:18px; background-color:#86878a; border:1px solid #545557;"|
| style="width:18px; height:18px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:18px; height:18px; background-color:#86878a; border:1px solid #545557;"|
|}
|-
| style="text-align: center;" | Layout
|}
</div>
|
{| style="width:200px; height:100px; padding:10px; background-color:#eaecf0; border-collapse: collapse;"
|+ 1x1
|- style="border-bottom:2px solid #3366cc;"
| colspan=3 style="text-align:center;"|{{Tooltip|Hotkey|adasdasdasd}}: {{Key|b|o|g}}
|-
| style="border-right: 1px dotted #545557;"|[[File:Screw_press.png|32px|center|link=]]
| style="font-size:125%;"|<center>{{Template:Picture Screw press}}</center>
| style="border-left: 1px dotted #545557;"|<center>{{Template:Floor Plan Screw press}}</center>
|}
|
{| style="width:200px; height:100px; padding:10px; background-color:#eaecf0; border-collapse: collapse;"
|+ 1x3
|- style="border-bottom:2px solid #3366cc;"
| colspan=3 style="text-align:center;"|{{Tooltip|Hotkey|adasdasdasd}}: {{Key|b|o|g}}
|-
| style="border-right: 1px dotted #545557;"|[[File:water_wheel.png|32px|center|link=]]
| style="font-size:125%;"|<center>{{Template:Picture Water wheel}}</center>
| style="border-left: 1px dotted #545557;line-height:normal;"|<center>{{Template:Floor Plan Water wheel}}</center>
|}
|}
:Any thoughts on the direction and or any and all of its elements? --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 10:16, 31 December 2022 (UTC)

::I kind of like side-by-side, if it fits. If anyone wants to implement a toggle button or tabs, I would ask that that be implemented in a template for now, so that e.g. we could change a toggle button to tabs in a single place if we decide to install an extension to support that. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 03:14, 1 January 2023 (UTC)

::: I noticed a comment saying that [[impassable tile]] are no longer used in v50, is that true for all constructions? If so, floor plans are no longer needed, making things much easier as we can fit everything in except the 5v5 constructions like trade depot (and even these can be placed one above the other if so desired). If not, any thought on the alternative floor plan design? --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 07:46, 1 January 2023 (UTC)

:::: None of the constructions have blocking tiles any more from my experience playing. I haven't tested siege weaponry with that stuff, but none of the workshops have it, nor does any furniture. (walls and fortifications will of course obstruct movement [[User:AndrielChaoti|AndrielChaoti]] ([[User talk:AndrielChaoti|talk]]) 18:47, 1 January 2023 (UTC)
::::: Ok, I have removed them from v50. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 23:48, 1 January 2023 (UTC)

I have added a basic side by side variant to [[Template:V50 workshop]] and [[Template:Building]] for testing, let us know if there any issues. Few notes:
* The default image naming scheme of <code>workshop-name.png</code> will likely conflict with existing images here or on commons, maybe another naming scheme should be used like <code>v50 workshop-name.png</code> as it is with ascii pictures.
* There is inconsistency in image size. If you want to use large zoomed images then toggle is best, otherwise they need to be all in native size (96px for 3x3).
* In the current version the code roughly centers the images and if there is a big image like with [[Siege workshop]] it drops to a new line --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 23:48, 1 January 2023 (UTC)

==== Bizarre palette-swapping idea/prototype ====
No idea if this is a good idea, since it takes a bit of time to set up, and there might be some performance issues... and maybe display issues?

But take a look at this:
{{User:Brightgalrs/Sandbox/PaletteSwitch|templatename=User:Brightgalrs/Sandbox/Rock|palette-name=amber}}

It's way to swap palettes on an image, although the image itself is a table, with each cell representing a pixel. The template itself looks like this:
<code><nowiki>{{User:Brightgalrs/Sandbox/PaletteSwitch|templatename=User:Brightgalrs/Sandbox/Rock|palette-name=saffron}}</nowiki></code>
Input the pattern and desired palette name.

I've got a larger showcase here: [[User:Brightgalrs/Sandbox/PaletteSwapShowcase]]. Only did a rock pattern so far, but all palettes are implemented.
The major use for this would be on each stone, metal, wood, etc. type's page. The palette could be read directly from the raws. [[User:Brightgalrs|Brightgalrs]] ([[User talk:Brightgalrs|talk]]) 03:22, 24 December 2022 (UTC)

:From a technical perspective, my primary concern is indeed performance. Both on the server side and client side, a large number of tables that large (in terms of markup and cell count, that is) tend to be resource-intensive to generate and render. I saw your image-filtering experiments on [[User:Brightgalrs/vector.css]], and while that strikes me as a newer and less-backwards-compatible approach, it would probably be more resource-friendly.
:Is this color adjustment something the game is doing natively? i.e. does this accurately match what the game displays? I bet we could slap together an image-filtering extension (or find an existing one?) that can do this if needed. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 03:49, 24 December 2022 (UTC)
::Yeah that's what I suspected. The images the template creates are spot on, checked it against a screenshot I took of some mica rocks in-game. The css stuff is unfortunately totally incorrect, was cool to learn about it though, so not a complete waste of my time :p. The premium, in-game graphics are true sprites, basically patterns of indexed colors. Each of the in-game colors (which are significantly expanded over the 16 ascii colors, there's 116/117) there is a palette defined in "\Dwarf Fortress\data\vanilla\vanilla_descriptors_graphics\graphics\images\palettes.png". Each indexed color of the sprite is swapped for the corresponding color in the palette. Because of that, the css stuff doesn't work since it's doing the hue/saturation/brightness changes to the entire sprite.
::I've looked into an existing mediawiki extension, couldn't find anything. One thing I did't really look at is some type of lua script/module that would basically emulate what the game is doing. So some function that takes in the base image as well as the desired palette, and based on that finds and replaces each color. No idea what mediawiki's capabilities are on that front. [[User:Brightgalrs|Brightgalrs]] ([[User talk:Brightgalrs|talk]]) 05:31, 24 December 2022 (UTC)
:::We do have Scribunto installed now, so it's totally possible to do something in Lua too - forgot about that. I can add you to the group that grants access to edit the Module namespace if you want to give that a shot. If we use an extension, we'd probably need a custom one, similar to DFDiagram (or perhaps DFDiagram could be extended - it's in dire need of a rewrite anyway). —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 05:43, 24 December 2022 (UTC)
::::I asked around on the mediawiki irc, I think scribunto/lua is a deadend, at least for taking an uploaded image and doing stuff to it with a lua script. However I did come up with this even more bizarre solution, using block elements. [[User:Brightgalrs/Sandbox/PaletteSwapShowcase2]], maybe less resource intensive? Definitely displays a lot worse though, probably unusable.
::::{{User:Brightgalrs/Sandbox/PaletteSwitch|templatename=User:Brightgalrs/Sandbox/Rock2|palette-name=saffron}}
::::I dunno, maybe none of this is worth it and we should just write some external program to put all the images together offline, and then just mass upload. It wouldn't be ''that'' many... [[User:Brightgalrs|Brightgalrs]] ([[User talk:Brightgalrs|talk]]) 06:37, 24 December 2022 (UTC)

====Is there an easy way to just paste images from the clipboard?====

I use KDE spectacle to take screenshots straight to the clipboard (after cropping) -- is there an easy way to just paste (and auto-upload) an image into an article? It would make it a lot easier to contribute images. [[User:Kelvie|Kelvie]] ([[User talk:Kelvie|talk]]) 23:35, 1 January 2023 (UTC)
:Unfortunately there is not. I would be open to a MediaWiki extension to support this if someone finds one. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 00:32, 2 January 2023 (UTC)
:: Looks like this could do it, but I haven't used it before: https://www.mediawiki.org/wiki/Extension:SimpleBatchUpload

=== Hotkeys/Menu navigation ===
Most key bindings and menus have changed. Should the article reflect a) only the old version, b) only the GUI version or c) both? For example, [[Bridge|bridges]] used to be built via {{k|b}} -> {{k|g}}, but now it's in Place strucutures {{k|b}} -> Constructions {{k|n}} -> Bridge {{k|b}}. What should be written in the article? Currently, it's {{k|b}} -> {{k|g}}. I ''think'' it should be only b), but I am not sure if there will be differences regarding hotkeys or menus between the premium version and the free version and then, c) would be the most appropriate option. --[[User:Prometherus|Prometherus]] ([[User talk:Prometherus|talk]]) 10:16, 22 December 2022 (UTC)

: Not sure. I wish the classic release soon --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 16:45, 22 December 2022 (UTC)
:: Are you Toady's herald? Looks like it was just released! [[User:Brightgalrs|Brightgalrs]] ([[User talk:Brightgalrs|talk]]) 18:18, 22 December 2022 (UTC)
:: And our questions are answered, the old hotkeys seem to have been thrown out. Part of me is disappointed (useless muscle memory) but also relieved (unified UI for both versions is good in general and for the wiki). [[User:Brightgalrs|Brightgalrs]] ([[User talk:Brightgalrs|talk]]) 18:25, 22 December 2022 (UTC)
::: According to info, in a sort of 'demo version' at that. I'll wait a little while longer, for myself.[[User:Silverwing235|Silverwing235]] ([[User talk:Silverwing235|talk]]) 18:22, 22 December 2022 (UTC)
::::It's unlikely that keybindings in it will change significantly. My vote is that we should include information for both premium and classic, everywhere. Hopefully the keybindings are not different between versions. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 18:26, 22 December 2022 (UTC)
:::Shouldn't it be based on the 50 or what verion the article is written for? [[User:Dominick|Dominick]] [[User_talk:dominick|(TALK)]] 18:42, 22 December 2022 (UTC)
:::: The keybindings seem to be consistent between versions, (haven't checked exhausitvely, but since the menu layout is the same I think it is a good assumption). Should also keep in mind/consider that not all actions have keybindings. An option would be write 'Click on the <Example Text> icon or press {{k|E}}' [[User:Koos|Koos]] ([[User talk:Koos|talk]]) 23:14, 23 December 2022 (UTC)

=== Removed features & concepts ===

Since they're removed concepts, I've set [[Room]] to be a redirect for [[DF2014:Room]] and created [[Template:Activity zones]] for the nav bar bedrooms, etc, and made the necessary changes to [[Bedroom]] for it. Is this the correct approach, before I go on much further? (also a note, if it is, then [[Template:v50_rooms]] probably needs to be deleted) I also imagine that considering the number of changes in the interface, that things like [[Adventure mode]] and related pages might best be truncated to "not in 50.03" and when it does make it across, being more deliberately brought over in pieces? [[User:HawkOwl|HawkOwl]] ([[User talk:HawkOwl|talk]]) 06:23, 23 December 2022 (UTC)

:Usually it is marked with [[Template:Removed_feature]]. For example: [[Dipscript]] or [[Party]]. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 07:45, 23 December 2022 (UTC)

:: Ah, that's fair. Should that be mentioned in [[Dwarf_Fortress_Wiki:Versions#Redirects]]? [[User:HawkOwl|HawkOwl]] ([[User talk:HawkOwl|talk]]) 10:03, 23 December 2022 (UTC)

:::I think the redirect policy mostly had in mind things that were removed a ''long'' time ago, like [[Tax collector]] and [[Economy]] (and the latter actually has a stub page as well). I guess we could clarify. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 19:34, 23 December 2022 (UTC)

:::: The "current" redirects also cause the version box to incorrectly show that the current version has a page - e.g. [[23a:Cave_river]] shows a v50.04 version, but it's just a redirect back to that version. Similarly, what should happen to redirects like [[Clothes maker]], where a concept has evolved? It currently goes to [[23a:Clothes maker]] - that's correct if the user is trying to look up a very old concept, but if a new user is looking for "how to make clothes", they should be directed to [[Clothier]]. --[[User:Danny252|Danny252]] ([[User talk:Danny252|talk]]) 12:16, 26 December 2022 (UTC)

:::: One should be careful with cv redirects. Most that were recently adjusted were unused plural forms (that should probably be deleted) but few like [[Crown]] needed that for backward compatibility. Removing the [https://dwarffortresswiki.org/index.php?title=Crown&type=revision&diff=279966&oldid=219482 cv part] means the the link on [[v0.31:Tilesets]] is now broken. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 22:30, 26 December 2022 (UTC)

:::::If [[v0.31:Tilesets]] is about v0.31, it should not be using "main:" in its links - ''all'' of those links are going to pages about v50, not v0.31, regardless of whether the target is a redirect or not. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 23:37, 26 December 2022 (UTC)
:::::: You right, I removed it. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 17:55, 27 December 2022 (UTC)

Crown cv redir issue is now fixed, I believe. As goes with such cases where one can simply revert the troublesome edit, unless I've mistepped, myself? [[User:Silverwing235|Silverwing235]] ([[User talk:Silverwing235|talk]]) 23:52, 26 December 2022 (UTC)
:Both [https://dwarffortresswiki.org/index.php?title=Crown&diff=prev&oldid=280026] and [https://dwarffortresswiki.org/index.php?title=Crown&diff=prev&oldid=279966] should not have had any effect, because "cv" is an alias to the main namespace now, just like "main". Proof: [[Crown]], [[cv:Crown]], [[main:Crown]]. It's possible caching is coming into play here, although I purged the redirect cache after making that alias change earlier this month... —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 00:02, 27 December 2022 (UTC)

I think there have been some changes not captured, but as a newb, I'm afraid to edit the page(s). A good example is Strawberry. I'm playing the Steam version right now and Strawberry plants are "not relevant to brewing" in Labor > kitchen > veg / fruit / leaves. Unless I'm mistaken and need to process them? Another example is the trade caravan = it seems the 3 square pathing no longer happens; it's just yak(s). 12:31, 28 December 2022 (UTC) 12:29, 28 December 2022 (UTC)

As far as I can tell, none of the workshop buildings in v50 have blocking tiles any more. There's a comment to the like in data/vanilla/vanilla_buildings/objects/building_custom.txt that says this "[BLOCK:1:0:0:0] workbenches no longer block". Hesitant to update that template as I'm not sure if it's referenced for all of the old versions too. [[User:AndrielChaoti|AndrielChaoti]] ([[User talk:AndrielChaoti|talk]]) 05:54, 29 December 2022 (UTC)

=== creature infobox prototype (moved) ===

Check it out, I made a temporary template and added it to the [[cow]]s page. Now it shows the sprites (but not the zombified versions yet). I wanted to show everyone a prototype of what v50 creature infoboxes should look like. Or at least something similar to it. --[[User:Zippy|Zippy]] ([[User talk:Zippy|talk]]) 19:11, 27 December 2022 (UTC)
:Hi, I'm new to editing wikis but I have done a bit of work with sprite sheets and I've been going through the DF data files to find the different graphics hoping to help with the animal pages. I've thrown together a template with grass and a few nature sprites (plants, a tree, and a rock) for size reference but I'm unsure how large the 'display' tiles in the middle of the template should be to suit all animals. I can see in the sprite sheets that some land animals have an adult and child sprite, so two tiles. Others have a male, female, and child, but after seeing you include the zombie cows I'm unsure if I should make it twice the size to add them too. Alternatively, I could grab some tiles from the haunted biomes for the zombie animals and make a separate template for a side-by-side comparison. Either way, let me know if this helps. I'd like to help with other graphics too as we add the premium tilesets but the animals seemed the easiest to tackle with me being new to wiki editing. ~~[[User:UristTheSeventh|UristTheSeventh]]

=== When do we remove the migration note on specific pages? ===

At what point can we remove the "this page was auto migrated from v47" warning? There are a bunch of small pages that are more or less accurate, if I've reviewed them, can I go ahead and remove the warning? [[User:Kelvie|Kelvie]] ([[User talk:Kelvie|talk]]) 23:33, 1 January 2023 (UTC)
:Yes, feel free to remove it if you think all content is accurate. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 00:31, 2 January 2023 (UTC)

== Toggleable image ==

Any objections/comments to using this template for now for toggling between classic and premium images? I'd probably rename it to "Template:Premium-classic thumb image". I'm sure someone can come up with a better UI eventually, but should be easy to migrate at that point. I also think we should use the same customtoggle class for this and for the infobox. [[User:NiftyManiac|NiftyManiac]] ([[User talk:NiftyManiac|talk]]) 23:12, 1 January 2023 (UTC)

{{User:NiftyManiac/Sandbox/TemplateDualImage|
premium=File:Quickstart-finder.png|
classic=File:Quickstart-finder-partial.png
}}

{{User:NiftyManiac/Sandbox/TemplateDualImage|
premium=File:Quickstart-finder.png|
classic=File:Quickstart-finder-partial.png|
caption=My caption|
width=100px
}}

:This looks nice to me! —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 00:30, 2 January 2023 (UTC)

Dwarf Fortress Wiki talk:Versions

2023-01-01T23:35:43Z

Kelvie: /* Graphics */

{{archive|
# [[DF Talk:Versions/Archive 1|Page 1]]}}

== Version 0.31.19 starts a new DF generation? ==

My reading of Toady's comments on the release of 0.31.19 is that it came out basically because he felt it would take too long to get DF all the way to 0.32. With the ore changes, the sitefinder changes, the addition of grazing and several different industries, there's a lot of changes between 31.18 and 31.19. So I'm thinking it might be a good idea to call it the first release of DF2011 - and what we refer to as "DF2010" would then become 0.31.18.

Thoughts? --[[User:DeMatt|DeMatt]] 07:06, 28 February 2011 (UTC)

==Revisiting Redirects==

I wasn't around when the redirect policy was created, and I'm having trouble understanding the rationale. The example claims that linking [[Main:Cheese]] to [[cv:Cheese maker]] is problematic...but mainspace only ever redirects to the current version. If the best target in the current version is cheese maker, why not link to it directly? (It's not, at least for Cheese, since [[DF2012:Cheese]] exists now.) The explanation seems to be claiming that 40d articles that link to Cheese will follow the Mainspace link--but that hasn't been the case for a long while now. Articles in 40d automatically link against other articles in 40d, so that version remains internally consistent no matter where mainspace links to in the current version. For a current example, what do we gain by linking [[Main:Mead]] to [[cv:Mead]] and linking [[DF2012:Mead]] to [[DF2012:Alcohol]]?

If this really is just an outdated procedure, I recommend we drop the mummery and allow mainspace to link to cv:(best target). Double redirects ''may'' work (sometimes, but [[Main:Mead]] demonstrates a common problem where automatic redirection fails), but if they are unnecessary I think they should be avoided, partly because of problems like [[Main:Mead]] and partly because of the effort required to protect double redirects from users who believe they are problematic.--[[User:Loci|Loci]] ([[User talk:Loci|talk]]) 20:16, 8 January 2014 (UTC)

:I was just thinking that. I'm currently attempting to write a basic extension to eliminate the need for mainspace redirects entirely, although Mediawiki's class structure may make this more difficult than I had hoped (the only method I've found for resolving redirects takes the ''article text'' instead of a title, e.g. "#REDIRECT ..."). I do agree that the current situation with redirects isn't ideal, so I'm hoping this will work better (once I get it to work). --[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 20:42, 8 January 2014 (UTC)

Okay, that wasn't quite as clear as I meant it to be. In general, I think this is a tricky situation. Mediawiki wasn't designed to have five content namespaces, and certainly not chains of redirects between them. The problem that was pointed out in the [[DF:REDIR|policy]] is the fact that with:
Main:Foo -> cv:Bar
pages in the cv: namespace can't use [[<nowiki/>foo]], since the namespace links modification causes it to be treated as [[<nowiki/>cv:foo]] instead, which doesn't exist. The current suggested solution is this:
Main:Foo -> cv:Foo -> cv:Bar
This fixes the problem of [[<nowiki/>foo]] not working on cv pages, but creates issues with double redirects not always working. Another solution, which is more intuitive to new editors, is:
Main:Foo -> cv:Bar
cv:Foo -> cv:Bar
Both require creating two redirects. The first method has the advantage of ''ensuring'' that the cv redirect exists (otherwise, main:foo would be a redlink), while the second has the advantage of working more reliably in a couple cases.

What I'm trying to do is make main:Foo "jump" to cv:Foo when cv:foo exists, ''even if main:foo doesn't exist'' (basically it would treat all mainspace pages as redirects to cv pages, but only if the cv page exists and not the mainspace page). I had main:Bar jumping to cv:Bar fine, but if cv:Foo redirected to cv:Bar, accessing main:Foo would mysteriously stop at cv:Foo even if I increased the redirect limit. What I'm trying to do now is follow the redirects internally, without relying on Mediawiki to do it automatically - unfortunately, that has proved to be harder than I had hoped (and I sent my web server into an infinite loop while trying). I will try to work on this some more when I get a chance, although I'm not sure when that'll be yet :(. For now, feel free to fix broken double mainspace redirects as necessary, as long as redirects in the DF2012 namespace stay pointing to the right page (and new mainspace redirects get added in the DF2012 namespace too). --[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 04:21, 9 January 2014 (UTC)

:You're treating cv like a namespace--it's not. It is simply shorthand for "fill in the current version here". [http://dwarffortresswiki.org/index.php?title=User_talk:Briess&diff=182404&oldid=181281 As I discovered a long time ago on a server not far away], linking from Main:Foo to cv:Foo tends to break redirection chains. If, instead of linking to cv:Foo, you link to DF2012:Foo, it might just work. It would, of course, be better if your patch could evaluate cv itself, but even if you have to hardcode the current version it's a single point of maintenance that requires update very infrequently. (For that matter, we could probably dispense with the cv hack entirely and just have a bot update mainspace links from DF2012 to DF201X when we switch to a new version.)--[[User:Loci|Loci]] ([[User talk:Loci|talk]]) 20:05, 9 January 2014 (UTC)
::I know cv isn't a namespace - I was just trying to avoid future confusion when the DF2012 namespace changes. It's interesting that changing "cv" to "DF2012" fixes some broken redirects, although I've found that simply making an edit to a broken redirect can usually fix it as well. I've actually had the most problems with double redirects when the second one (in the DF2012 namespace) doesn't use the DF2012 prefix (e.g. main:Foo containing <nowiki>[[cv:Foo]] and DF2012:Foo containing [[Bar]]</nowiki>). I'd rather keep the cv alias even if it isn't necessary for mainspace redirects when I get the patch to work, since it makes it easier to refer to the current version of the page (for example, several MDF articles contain links to a vanilla page for things that don't change in the mod).
::Also, using aliases like "cv" is supported by Mediawiki; in fact, several WMF wikis use them (for example, "[[wikipedia:WP:Redirects|WP:Redirects]]" on Wikipedia). It's quite likely that Mediawiki isn't processing double redirects using aliases correctly, though, since that's uncommon on most wikis. --[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 21:35, 9 January 2014 (UTC)

In light of the lack of support for the current redirect policy, I propose we replace the current redirect section with:

:Mainspace article pages should use the cv: alias when redirecting to a versioned page, which will automatically update the link when a new version is released. For example, page "Main:Foo" should redirect to page "cv:Bar" (where "Bar" is the page that best describes the topic Foo in the current version).

:Pages in mainspace should only redirect to an older versioned page if that content no longer exists in the current version of the game (e.g. [[Cave river]], [[Chunk]]). In these cases the cv: alias cannot be used.

:Pages inside a versioned namespace should not use the cv: alias. Instead, they should redirect to the best page within that versioned namespace (e.g. [[DF2012:Dodging]], [[v0.31:Drink]]).

:Due to limitations of the wiki software, double redirects should be avoided if possible. When fixing double redirects in mainspace, please make sure to use the cv: alias as appropriate.

If no one objects, I will make this change in a few days.--[[User:Loci|Loci]] ([[User talk:Loci|talk]]) 20:21, 15 January 2014 (UTC)

:Okay with me. It may be worth mentioning that double redirects only really need to be changed when they don't work (since changing a lot of redirects that work isn't necessary), but I think it's clearer and more relevant than the current policy. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 00:26, 16 January 2014 (UTC)

Done.--[[User:Loci|Loci]] ([[User talk:Loci|talk]]) 20:55, 22 January 2014 (UTC)

I was finally able to get my extension to work after being motivated by one too many malfunctioning redirects. It now causes nonexistent pages in the main namespace to behave exactly like redirects to their DF2012 counterparts (when linked to, accessed directly, and transcluded). Double redirects also work (up to 100, in fact, although that was a temporary safety measure that I'll probably change). This means we'll be able to safely get rid of all mainspace redirects (redirects that redirect to something other than "cv" will still function if not deleted). —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 01:20, 14 March 2014 (UTC)
:What about articles which don't exist in the current version but do exist in older versions? Will those still need mainspace redirects, or will your extension be able to automatically redirect them to v0.31/40d/23a? --[[User:Quietust|Quietust]] ([[User talk:Quietust|talk]]) 01:29, 14 March 2014 (UTC)
::It ignores all mainspace pages that actually have content, including redirects, so pages like [[masons guild]] won't be affected (unless deleted). —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 01:47, 14 March 2014 (UTC)

Done and deployed. [[Cat]] is still treated as a redirect, even though I just deleted it (try clicking on the "redirected from" link). Pages that exist are ignored, so [[Masons guild]] and [[History of Dwarf Fortress]] still function normally (as a redirect to a 23a page and a non-redirect, respectively). —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 18:57, 14 April 2014 (UTC)

I'm sending around a bot right now to delete all redirects of the format "foo -> cv:foo" (a surprising number don't fit this format, so I'm leaving them alone for now). —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 20:43, 14 April 2014 (UTC)

:I'm confused. Do we use double redirects or not? Is there a single place we define our linking policy (including redirects), and is it updated?
:I had trouble linking to [[Consolidated_development]] in [[v0.34:Dragon]]. It kept pointing to v0.34:Consolidated_development, which does not exist. I ended up linking to Main:Consolidated_development to make it work. --[[User:Nahno|Nahno]] ([[User talk:Nahno|talk]]) 10:18, 1 July 2014 (UTC)

::That's a separate problem altogether - links in the versioned namespaces (v0.34, v0.31, 40d, 23a) automatically link to pages within their namespace. I may be able to set up a fallback to mainspace once I'm able to deploy again, but for now the "main:" alias is the intended solution. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 11:36, 1 July 2014 (UTC)

== Google often directs people to the 0.31 page ==

I've noticed a couple of times that finding a wiki page from an external search will often drop me onto a page from an older version. Is it possible to mitigate this somehow for new players? I could imagine something like redirecting old:Bar -> cv:Bar unless the user has come from old:Foo; no idea if that would actually work though. [[User:PeridexisErrant|PeridexisErrant]] ([[User talk:PeridexisErrant|talk]]) 11:48, 4 May 2014 (UTC)

:As a temporary solution, I could write a script that displays a banner of some kind if the user came from an external site. I'll ask Briess if he can do anything on the server level to increase the weighting of the current version's pages. (Obviously there are situations where people are looking for old pages, like [[23a:dungeon master]], so we don't want to disable indexing entirely on old pages.) —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 17:03, 4 May 2014 (UTC)

== DF2014? ==

As Toady [http://www.bay12games.com/dwarves/ draws closer to a new release], it might be worthwhile to discuss the addition of a new version to the wiki. The upcoming release covers two years of changes and introduces a number of new plants, foods, drinks, multi-tile trees, climbing, jumping, etc., so it is likely to have significant changes from the current DF2012. To avoid having people start new pages (and lose all the effort spent refining the prior version's page), I think it would be best to have a bot automatically copy over the DF2012 pages as a starting point for DF2014. I would suggest that these copied pages include a noticebox template mentioning that the content may be outdated, so that we can easily track which pages have been reviewed. I think either the {{tl|version check}} or {{tl|old}} template would work. --[[User:Loci|Loci]] ([[User talk:Loci|talk]]) 19:43, 5 May 2014 (UTC)

:This is what [[User:QuietBot]] did after the 0.34 release, so it's certainly possible to use the same script to migrate to DF2014. I would like a way of tagging migrated pages, since inaccuracies in some pages went unnoticed for months after they were migrated. Since {{tl|old}} is already in use, {{tl|version check}} may be a better solution (it can be reworded slightly, or we can make a separate template for DF2014 migration). —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 19:23, 1 June 2014 (UTC)
:Made [[Template:DF2014 migrated]] as an example. Any thoughts? —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 19:32, 1 June 2014 (UTC)

== Redirects inconsistency ==

Following a redirect is supposed to be exactly the same as going straight to the page it redirects to, but this actually isn't the case:
* Go to [[Seeds]] and you get [[v0.34:Seed]] (outdated)
* Go to http://dwarffortresswiki.org/index.php?title=Seeds&redirect=no and click on the link and you get to [[DF2014:Seed]] (current)
So if you search for "seed", the top result is the DF2014 version. But search for "seeds" and you get the redirect, which sends you to the outdated page instead. [[User:Hairy Dude|Hairy Dude]] ([[User talk:Hairy Dude|talk]]) 23:22, 22 February 2015 (UTC)

While I'm talking about redirects, it seems redirects to sections don't work: see [[DF2014:How do I manage my seeds and crops]]. I know MediaWiki is capable of this trick because Wikipedia does it. [[User:Hairy Dude|Hairy Dude]] ([[User talk:Hairy Dude|talk]]) 23:32, 22 February 2015 (UTC)

:I have absolutely no idea why [[seeds]] redirects to a v0.34 page - it could be a Mediawiki bug. The section links issue is due to a known issue in the redirect extension we use, which has yet to be fixed. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 00:01, 23 February 2015 (UTC)
:It looks like deleting both [[Seeds]] and [[DF2014:Seeds]] fixed things (by allowing AutoRedirect to handle the redirects instead). Feel free to tag any others with {{tl|bad redirect}}. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 00:03, 23 February 2015 (UTC)
::It gets stranger. [[Vial]] redirects explicitly to [[cv:Flask]] which displays (when you look at it with &redirect=no) as [[DF2014:Flask]], but still goes to the v0.34 version. It seems redirects interpret the cv: pseudo-namespace (or whatever it's called) in an outdated way. [[User:Hairy Dude|Hairy Dude]] ([[User talk:Hairy Dude|talk]]) 18:08, 23 February 2015 (UTC)
::I've added a note to this page about this issue. If it gets resolved, the note should be removed. [[User:Hairy Dude|Hairy Dude]] ([[User talk:Hairy Dude|talk]]) 21:04, 23 February 2015 (UTC)

==Reorganizing versions==

The internet deals with moved content... poorly. Google is still linking to v0.34 pages more than a year after the switch to "DF2014", and even the wiki software still has cached links pointing to the old version pages.

I propose reorganizing versions on the wiki to avoid moving content whenever possible. Instead of having a temporary "current version" namespace that changes occasionally, all the current information gets promoted to the Main namespace. When the next version split occurs, the Main articles as of a certain revision number can be copied to the newly-created permanent "old version" namespace, while all the current information remains in Main. This not only fixes the link rot issue, but it has a few other benefits as well: fewer administrative tasks, no lockdown (a historical version of the Main pages can be copied at any point, even if the Main articles are already modified for the new version), almost all the article history is maintained in the Main article (instead of being spread unevenly across multiple versions), no "temporary" namespaces are needed, fewer problematic long redirect chains, and hopefully less user confusion (since Main gets priority in search results, etc.).

As an example, today we would not have a DF2014 namespace (which is good because "temporary" namespaces historically disappear anyway). If you ran a search for [[seed]] you'd end up at Main:seed, which would have all the current information on seeds. The version box at the top of the page would still link to the older versions of the seed article. When a new version is released, an admin would choose a revision number and copy the Main:seed article as it exists at that revision number to v0.40:seed. That's it. One historical copy that needs little to no new editing, and zero redirections/moves.--[[User:Loci|Loci]] ([[User talk:Loci|talk]]) 19:02, 27 July 2015 (UTC)

:Makes sense to me. It would involve a lot of work, though (e.g. fixing templates and categories to account for the current version being in mainspace), although that should be doable thanks to {{tl|category}}, {{tl|version switch}}, etc.. A bot could be set up to copy revisions from before a release date as well, which would be more difficult (and maybe slower) than a direct copy, but not severely. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 17:24, 30 July 2015 (UTC)

:Actually, there are a few issues with that, namely that there wouldn't be an easy way to distinguish between versioned and non-versioned mainspace pages. There are ways to resolve Google search priority (we can exclude pages from older versions from search engine results if there are newer versions of those pages available, for example). —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 19:47, 6 August 2015 (UTC)

::There aren't very many non-versioned mainspace pages, and determining if a page is versioned is as simple as looking for the version template and/or categories added by the version template (e.g. copy [http://dwarffortresswiki.org/index.php/Category:Current this category] instead of Main:*). The problem with "suggesting" newer pages to Google is that they obviously aren't crawling our wiki regularly (if they were, the fact that the mainspace redirects point to new pages would automatically be picked up). Even if your Google hints worked they wouldn't do anything for all the other broken links out on the 'net.--[[User:Loci|Loci]] ([[User talk:Loci|talk]]) 20:35, 6 August 2015 (UTC)

::: Google actually crawls the wiki constantly - we probably get crawl hits from google for a continuous block of 2-3 hours per day, each and every day. Why they are slow to update is beyond me though. I can't remember why we didn't do this initially, but there was a technical limitation involved if I remember correctly. --[[User:Briess|Briess]] ([[User talk:Briess|talk]]) 22:05, 6 August 2015 (UTC)

::: There are <meta> tags that can be used to hide pages from search results (for search engines that recognize them, that is). Searching for {{tl|av}} or [[:Category:Current]] might work, although we'd have to make sure all of the DF2014 pages include that (some pages don't, particularly some disambiguation pages, although all of them should). —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 22:53, 6 August 2015 (UTC)

:Is there a particular reason main and current are separate to begin with?—[[User:CLA|CLA]] ([[User talk:CLA|talk]]) 00:17, 7 August 2015 (UTC)

::It's mostly intended to distinguish between versioned and non-versioned pages and make version-related templates simpler to work with, since every versioned page has a namespace. I wasn't active here in 2010 when this system was created, so Briess and Emi would know more.
::Another issue I just thought of with Loci's suggestion is categories - currently, categories like [[:Category:Animals]] are used to organize the versioned sub-categories. Sure, we can change {{tl|Category}} to categorize mainspace pages in [[:Category:v0.40:Animals]] or [[:Category:DF2014:Animals]], but that would be less straightforward because there wouldn't be a namespace with that name (until pages are migrated when a newer major version is released). —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 13:05, 7 August 2015 (UTC)

:Moving current pages to the main namespace sounds like a great idea. -[[User:Jecowa|Jecowa]] ([[User talk:Jecowa|talk]]) 20:47, 4 January 2018 (UTC)

Another thought: dealing with migrating redirects could be difficult with this proposal - specifically, determining which redirects should be migrated to a versioned namespace. Redirects can't contain {{tl|av}}, at least not before ``#REDIRECT``. I ''think'' it would be possible to copy pages in two stages, though - all non-redirects first, then all redirects whose targets were also copied. Thoughts? Anything I'm missing? —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 23:41, 27 June 2019 (UTC)

Some subpages (particularly /raw and /Edit notice) also deliberately lack {{tl|av}}, although those shouldn't be too hard to handle. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 00:35, 9 July 2019 (UTC)

:Redirect pages (and all other edge cases I've looked at) can be included in categories (like [[:Category:Current]]) to determine whether or not they should be copied into an archival version. But if the redirects are "properly qualified" then they can all be copied over blindly. Mainspace redirects pointing to versioned information should use a blank namespace (which will be automatically constrained to the archival namespace); mainspace redirects pointing to unversioned information should use an explicit "Main" (which will automatically link back to the unversioned page). Then, when [[[[Toady]]]] gets copied to [[[[v0.4x:Toady]]]] it will point back to [[[[Main:Toady One]]]]. Meanwhile, [[[[Beer]]]], copied to [[[[v0.4x:Beer]]]], will properly point to [[[[v0.4x:Alcohol]]]].--[[User:Loci|Loci]] ([[User talk:Loci|talk]]) 20:00, 14 July 2019 (UTC)

::I think qualifying redirects is the best solution here - categorizing redirects manually is another possible source of errors, since categories (or a lack thereof) would only be visible on the redirect page itself, and [[:Category:Current]] is a hidden category. Copying over mainspace redirects into versioned namespaces would also resolve some issues that have come up due to those not reliably existing currently. I should be able to set up a bot script to add "main:" to current mainspace redirects (and it shouldn't break anything, since those redirects go to other mainspace pages anyway). —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 21:57, 14 July 2019 (UTC)

(Note: I wrote all of this without noticing the previous discussion above.) I was wondering, when the wiki creates a new namespace for a major release again, if it is possible to ''not'' create a namespace for the next current version (e.g. "DF202x") and instead have the mainspace articles (which are currently redirects) become the new cv and move the content there. Therefore, [[cv:Cat]] would just be "[[Cat]]" (or [[Main:Cat]]).

Certain namespace-related templates like [[Template:Ns/0]] would need to be changed, though nothing significant as far as I know. For most cases, any "DF2014" would be replaced with "Main" or even blank. There's also multiple extensions handling the current namespace system and they may need to be modified too, though I'm not sure if or how much. I'm guessing based on the discussions above that it will change stuff up.

My reason is the current namespace is increasingly becoming more anachronistic. "DF2014" could be misinterpreted as "this page is about the 2014 version of the game" or "this page was last updated in 2014", which I've seen a few people in forums mention. Granted that [[Template:Av]] is on the top of very article, I still think the namespace is inconsistent with the recentness of the article. But how is this related to what I'm asking for? Let's say we continue the current system: if we happen to do a new namespace change this year and create DF2020, the next major release (after graphics/UI) will be mythgen, which is estimated to take several years to develop (the Big Wait), and so the anachronism will start over again. The proposed way will prevent this from occurring for the next major release and every release thereafter.

I think the confusion with having a namespace that becomes old-fashioned overtime supersedes the confusion with not marking current versioned articles with a namespace. Most users just search "Cat" on the search bar and naturally expect to get information about the latest release of DF. So if users go a page that's just titled "Cat", they won't expect outdated info about cats from a previous release. That's how the current system works anyways. We'll be skipping the two-step process that we have now. It'll make several wiki tasks much simpler as well. Editors can create new articles for current versions without remembering to add a namespace. It'll fix any existing issues with (double) redirects; instead of [[Main:Kitten]] redirecting to [[cv:Kitten]], which goes to [[DF2014:Kitten]], which then redirects to [[DF2014:Cat]], [[Main:Kitten]] would just redirect to [[Main:Cat]]. And the cv: alias will no longer be necessary since "cv:" = "Main:" and will be forever.

There's no need to differentiate the current version and previous versions with a namespace for the current version is what I'm saying. Articles of previous versions will retain their respective namespaces. Users will still type "40d:Cat" to go to the 40d version of the article, but if they want the current version, they'll just type "Cat" (like now). The mainspace containing the "live" version of an article is natural and would create no uncertainty when browsing the wiki. And it would simplify the wiki somewhat and future-proof this anachronism problem. As a bonus, this change will also prevent web search engines from showing previous version pages when typing "DF cat" or something. (This isn't happening right now as DF2014 has been the current namespace for ~6 years, but it'll happen again when everything moves to a new namespace.)

This is the gist of it, and I may have ignored most of the problems with this proposal. I have personally wished for the whole version namespacing be made less complicated and have been seeking for a solution, and I feel like this is the best way to go about in the future. – [[User:Doorkeeper|Doorkeeper]] 21:27, 14 August 2020 (UTC)

:<s>Whoops, looks like Loci already proposed this exact thing long ago. I definitely missed that discussion and should have checked first. My apologies. I'll move my text to that section and remove this one. – [[User:Doorkeeper|Doorkeeper]] 21:36, 14 August 2020 (UTC)</s> Done. – [[User:Doorkeeper|Doorkeeper]] 21:40, 14 August 2020 (UTC)

:The main issue I have with that is that putting pages about the current version in a namespace also differentiates between those pages and pages not about ''any'' version (for example, [[Toady One]] does not need a 40d or v0.34 page). Yes, we can use {{tl|av}} to mark versioned pages, but people often forget to add that to new pages. The current system also allows determining whether a page is versioned or not from its title, which makes migrations a lot faster. Relying on {{tl|av}} would require either reading the content of every page (which would slow scripts down significantly) or cross-checking with the list of all pages including the template (feasible, but a bit more complicated, and still susceptible to missing templates). I suppose that manually fixing and migrating pages missing {{tl|av}} later wouldn't be too much work, though.
:I am definitely in favor of changing "DF2014" (or a new namespace) to "Current", though. I was in favor of "DF2014" in 2014, but I don't think it makes sense anymore, and "Current" seemed to be a popular alternative in both the DF2012 and DF2014 discussions on the matter. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 04:02, 16 August 2020 (UTC)

== Weird redirect behaviour ==

[[Pump stack]] redirects to [[cv:Screw pump#Pump stack]]. If you look at the redirect itself it says it redirects to DF2014 namespace, which is correct. But if you actually follow the redirect, it goes to v0.34 namespace. [[User:Hairy Dude|Hairy Dude]] ([[User talk:Hairy Dude|talk]]) 16:10, 20 August 2018 (UTC)
:Yeah, that's part of the issue described in the above section (the wiki caching part, not on Google's end.) —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 15:00, 21 August 2018 (UTC)

== v50 organization ==

Some wiki admins have had a talk on Discord and decided that the most sustainable path forward is to put content for all future versions of DF in the main namespace. We will be working on a bot to do this in the next few days. Feel free to chime in with suggestions here. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 22:56, 14 December 2022 (UTC)

:Is it maybe possible to do backwards-namespacing? Like we have a "Main" namespace, which people are free to update, and whenever there's a new version of DF the "Main" namespace is copied into a namespace for the then old version, much like how you'd branch a stable branch from a development branch when working with a git-project? [[User:Therahedwig|Therahedwig]] ([[User talk:Therahedwig|talk]]) 23:13, 14 December 2022 (UTC)

::Yeah, we could do that if we decide to. We were talking about doing that for v50, actually, and might still do something similar to preserve edit history if it doesn't end up being too hard to automate. Our hope is that we will not introduce new namespaces for v50 -> v5x, unless there is a serious breaking change (and hopefully there isn't one). But if we change our mind, one advantage of the type of migration you mentioned is that it can be done retroactively - we can copy historical revisions that were current at the time of the release, and would only lose some typo fixes made after the release that apply to earlier versions as well. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 02:11, 15 December 2022 (UTC)

ETA is < 24 hours. Doing some final checks on a migration script. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 07:08, 19 December 2022 (UTC)

: We should really have a task list as there are many things that change and need updating. Including but not limited to:
:* Most templates that used the previous namespace convention broke, including nav templates.
:* Many game files changed locations and their pages need to be updated.
:* Raws need to be updated.
:* Various features added, changed, removed.
:* UI has been changed -- though I am more inclined to wait for classic release to avoid extra work --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 06:56, 20 December 2022 (UTC)

"''Raws need to be updated.''" Including applying text wraparound where necessary, I suppose - more than a few of them have proven to be that special kind of...''difficult'' to navigate otherwise, shall we say? [[User:Silverwing235|Silverwing235]] ([[User talk:Silverwing235|talk]]) 12:52, 20 December 2022 (UTC)

:There is already a task list in the [[#v50 migration|section below]] that includes templates and raws, with an explanation. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 16:25, 20 December 2022 (UTC)

== v50 migration ==

The initial migration script is done. New content is in the '''main''' namespace, e.g. [[Cat]]. Old content is still at [[DF2014:Cat]]. History was migrated to the ''new'' (main namespace) articles.

I know several things are broken still. Please reply if you find any others:
<div style="border-left: 2px solid red">
* <s>Versioned templates haven't been migrated yet (e.g. {{tl|vermin}} on [[Ant]])</s>
** Fixed. Most were migrated by a bot.
* Raws are missing on all pages that use them.
** This also affects sidebars, such as on [[Cat]] and [[Microcline]].
** Update: The DFRawFunctions extension has been upgraded to include v50 raws, using the "v50:" prefix for filenames instead of "DF2014:". I haven't finished a migration script to create the /raw pages themselves, but they can typically be created manually by copying the DF2014 /raw pages and changing "DF2014" to "v50" everywhere. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 20:20, 1 January 2023 (UTC)
* Some pages where the DF2014 page was a redirect to a main namespace page that contained content were migrated incorrectly.
** In this case, the main namespace page is usually a redirect to itself. This can be fixed by undoing LethosorBot's edit to the main namespace page, then copying the content to the DF2014 page.
** Update: most seem to have been fixed manually - thanks! —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 19:41, 21 December 2022 (UTC)
* <s>Some main-namespace talk pages redirect to DF2014 talk pages. Some of these redirects work, and some (usually older ones) do not.</s>
** Fixed with a bot. Some redirects from talk pages to other deleted talk pages are now broken, e.g. [[Talk:Above_ground]] (exists) -> [[Talk:Tile attributes]] (redlink). I am leaving them like that because they redirect to where the talk page should be created, but I'm also fine with people deleting them if they really want to. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 19:41, 21 December 2022 (UTC)
* {{tl|quality}} for new articles is disabled (see below)
* Some links from DF2014 to Main weren't working: e.g. the version selector [[DF2014:Mason's workshop]] was linking to [[DF2014:Main:Mason's workshop]] instead of [[Main:Mason's workshop]]. I'm not sure exactly why, but I fixed it with a change to the NamespaceLinks extension. Let me know if you spot similar broken links. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 23:19, 21 December 2022 (UTC)
</div>

—[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 04:54, 20 December 2022 (UTC)
:The quality levels of the 50.03 pages seem to be missing. I'm not sure if that's covered under that first point. [[User:Trainzack|Trainzack]] ([[User talk:Trainzack|talk]]) 06:47, 20 December 2022 (UTC)
::If the the [[Dwarf Fortress Wiki:Quality]] feature can be made to work with namespace scheme change, I suggest to automatically assign the lowest quality rating to all pages, alternately add the {{tl|old}} to all pages. Otherwise there will be a lot of pages that will fall through the cracks. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 09:12, 20 December 2022 (UTC)
:::I disabled {{tl|quality}} in the main namespace because it would require some rework to make the rating script and the template work properly there. Feel free to take a stab at the template. I will see what can be done on the extension side. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 21:14, 20 December 2022 (UTC)

It appears some pages are redirecting recursively and never resolving correctly, like the [[https://dwarffortresswiki.org/index.php?title=Character_table&redirect=no|character table]] and [[tileset repository]] 07:35, 20 December 2022 (UTC)
: Indeed, these can be caught here: [[Special:DoubleRedirects]] --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 07:51, 20 December 2022 (UTC)

It might be useful to change the notice title to "release information '''for editors'''" --[[Special:Contributions/142.59.195.176|142.59.195.176]] 10:26, 20 December 2022 (UTC)
:Can do. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 16:27, 20 December 2022 (UTC)

Main talkpages seem to redirect to DF2014 talk. Not sure if it is intentional but I like it, though we should pay attention when creating new discussion relating to v50 ending up there.--[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 14:18, 20 December 2022 (UTC)
:That's unintentional. I specifically wrote the migration script to not move talk pages, but that has the side-effect of leaving any previously-created "Talk -> DF2014 talk" redirects intact. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 16:27, 20 December 2022 (UTC)

Yo Lethosor, are we adding graphic sprites for the pages in some way? Or are we waiting for you to add some sort of new template or something? I'm sure you don't need me to tell you that the current templates don't allow that. Not sure if I'm allowed to change/create any templates either, as I don't want to break things for hundreds of pages. Edit: And IF the icons are allowed, should they be left alone, or 2×-3× sized like how the Minecraft wiki does it? --[[User:Zippy|Zippy]] ([[User talk:Zippy|talk]]) 14:29, 20 December 2022 (UTC)
:Depends on which templates you mean. There are copyright concerns with uploading a premium sprite sheet, for instance. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 16:27, 20 December 2022 (UTC)
::I'm not talking about uploading an entire sprite sheet. I'm just talking about individual icons for each respective page. One image for cows, one for horses, one for werebeasts, etc. --[[User:Zippy|Zippy]] ([[User talk:Zippy|talk]]) 16:50, 20 December 2022 (UTC)
:::If we do that for every creature in the sprite sheet, that's not much different (in terms of copyright) from uploading the entire sprite sheet. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 17:09, 20 December 2022 (UTC)
::::Is there someone we can talk to about that? We finally get this new game with graphics, and then we can't use the very graphics of the game? No matter what the rules are, I'd say that would be the stupidest thing ever. I know I'm infamous here when it comes to copyright and images and stuff, but about 80% of game wikis out there are completely unofficial, and use game file images like no one's business. I can't imagine anyone's door being knocked on if we used the game's sprites, but I won't add any here until we have a go-ahead. --[[User:Zippy|Zippy]] ([[User talk:Zippy|talk]]) 17:14, 20 December 2022 (UTC)

:::::...I've made noise in Mayday's direction on this matter, at least (prob an incorrect maneuver, ''but'').[[User:Silverwing235|Silverwing235]] ([[User talk:Silverwing235|talk]]) 17:55, 20 December 2022 (UTC)
:::::: I hope some sort of arrangement can be made so we can use the new sprites with permission/limits, just as we are using the raw files. Otherwise we are all (devs and editors alike) shooting ourselves in the foot here.--[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 21:07, 20 December 2022 (UTC)

:::::::I just thought of something. We're supposedly not allowed to upload entire sprite sheets, right? What if - for the time being - we just use a few of them for the purpose of testing out new infoboxes? --[[User:Zippy|Zippy]] ([[User talk:Zippy|talk]]) 21:46, 20 December 2022 (UTC)
::::::::I don't know. If someone could ask Kitfox and post the response here, that would be great. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 21:47, 20 December 2022 (UTC)

:::::::::I've reached out to Alexandra, but she hasn't answered yet. Until then I found these old approvals from the previous community manager, Feeona: ([http://www.bay12forums.com/smf/index.php?topic=173474.msg8243633#msg8243633 link1], [http://www.bay12forums.com/smf/index.php?topic=176640.msg8243642#msg8243642 link2]). Waiting for a newer response until we begin mass uploads is probably the politer option, but like Zippy said, it is also standard for wikis to use game sprites with less approval. I second their idea of trying it out with a few images to test the infoboxes. On the extreme off-chance (and I do think it is) Kitfox protests we can always remove these few. --[[User:Voliol|Voliol]] ([[User talk:Voliol|talk]]) 22:19, 20 December 2022 (UTC)
:::::::::And here is a third, more official statement: ([http://www.bay12forums.com/smf/index.php?topic=173474.msg8249718#msg8249718 link3]). Perhaps that address of info@kitfoxgames.com is the better channel to ask for a confirmation, rather than Discord DMs, but I will be going to bed, so it is best if someone else does that. --[[User:Voliol|Voliol]] ([[User talk:Voliol|talk]]) 22:29, 20 December 2022 (UTC)
::::::::::Thanks for tracking this down! Ok, sprites should be fine, but let's avoid uploading the entire premium tileset as a single image, for instance (as the forum thread says, "use common sense"). —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 00:21, 21 December 2022 (UTC)
::::::::::: Looks good, permission is always preferable over fairuse, I think it is a win win for all involved. I agree that we shouldn't upload entire sprite sheets (e.g. there is no reason to upload the windmill from every direction or whole construction phase for workshops) and that there are a lot of details that needs to be ironed out through testing. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 05:07, 21 December 2022 (UTC)
:::::::::We have a green light on uploading all and any sprites. Their response to me can be seen [https://i.imgur.com/BhmHjzC.png here]. I'm sure someone else confirmed it before me. --[[User:Zippy|Zippy]] ([[User talk:Zippy|talk]]) 19:00, 21 December 2022 (UTC)

Shifting temporarily to a new issue, is the documentation of [[Template:ArticleVersion]] outdated? It would seem so to me, since the current version no longer has its own namespace, with the templates needing updating being different ones. --[[User:Voliol|Voliol]] ([[User talk:Voliol|talk]]) 18:30, 20 December 2022 (UTC)
:I think it is still accurate enough. We left open the possibility of making another namespace in the future, albeit with a different migration strategy - see [[#v50 organization|above]]. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 21:52, 20 December 2022 (UTC)

Some Changes to infoboxes might be needed. Too bad [[User:Doorkeeper]] isn't around. He did a great work with navbox project--[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 20:52, 21 December 2022 (UTC)

I just realized that raw files aren't stored as regular wiki pages but loaded via the DFRawFunctions extension (hence the need to update). Good news it's going to be handled in bulk, consistently and relatively easy to updated. Even better it's Lethosor problem ;) Also I just realized that all the "raw files" (txt files in the new vanilla folder) are released into the public domain. Both are probably not news to the vets but I'll leave it here for those who less up to date like myself. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 07:35, 22 December 2022 (UTC)

: I noticed that some templates aren't working properly in the new namespace, e.g. [[Basalt]] entry had its raw updated manually but the infobox fail to show any details. Cursory look suggest {{t|layerlookup/0}} need a minor tweak. This should do the work
:: Replace: <nowiki>{{layerlookup/aux|{{{{FULLPAGENAME}}/raw}}|uses={{{uses|}}}|wiki={{{wiki|}}}}}</nowiki>
:: With___: <nowiki>{{layerlookup/aux|{{</nowiki>:<nowiki>{{FULLPAGENAME}}/raw}}|uses={{{uses|}}}|wiki={{{wiki|}}}}}</nowiki>
: Not sure what the plan and ETA with raws update so I didn't touch this high usage template for now. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 08:11, 24 December 2022 (UTC)

::Please do feel free to make this update. I am still working on a script to create the <code>/raw</code> pages themselves. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 03:12, 1 January 2023 (UTC)

== v50 specific issues ==
=== Graphics===
Follow up on the use of game sprites and the need to trying it out with a few images to test the infoboxes. First sprite [[:File:Beds v50.png]] was uploaded and used on [[Bed]] entry. Any thoughts? --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 18:06, 21 December 2022 (UTC)
:Seems like it should be rearranged to be horizontal. Also, has there been a serious discussion about copyright? Full screenshots are 100% fine, but you start going into a grey area when you upload pieces of a spritesheet. I'm of the opinion that it's all fine as long as it's inconvenient to reconstruct the full sheet from the individual images. Maybe a further restriction could be you shouldn't upload any of the art unless it's used in an infobox (maybe an exception for pieces of the UI). And one more restriction could be you shouldn't show everything, like in your bed example, maybe just the wooden bed is good enough, leave out the stone and metal, especially since those can only be made from strange moods. [[User:Brightgalrs|Brightgalrs]] ([[User talk:Brightgalrs|talk]]) 18:43, 21 December 2022 (UTC)
::Actually, your bed image is kinda bad for showing off what a bed looks like because it doesn't show the pillow/blankets. That might point to cropped screenshots being the best path, although less convenient for the uploader, as you don't get details left out. [[User:Brightgalrs|Brightgalrs]] ([[User talk:Brightgalrs|talk]]) 18:46, 21 December 2022 (UTC)
::I created a new license template [[Template:Copyright game]], based it on the way the RimWorld wiki does things. Call it a prototype, but it's probably how your bed image should be labelled. Indeed, I added it to it already. [[User:Brightgalrs|Brightgalrs]] ([[User talk:Brightgalrs|talk]])

::: I agree that the horizontal arrangement would suit better here and that we should strive to represent how things look in-game. Otherwise, I am not too concerned about people being able to reconstruct anything (lets just say that ''anyone'' interested in that can get the real thing from the game files), also it seem we have permission to use the sprits on top of fairuse. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 19:55, 21 December 2022 (UTC)

::: Modifying the existing template to allow the inclusion of the new sprites is easy (Something like [https://ibb.co/zFXCrjd this]?) The big question is the matter of consistency is there any exceptions that will break the format (size wise with variant bloat for example), the sprite naming format, etc --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 20:44, 21 December 2022 (UTC)
::: If we are going to show a variant for each material type, then maybe these should be added as separate images so we can add a tooltip for each image. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 20:49, 21 December 2022 (UTC)

:I've got another prototype going here and here: [[User:Brightgalrs/vector.css]] and [[User:Brightgalrs/Sandbox]]. (You'll need to add the css stuff to your own /vector.css). Basically it's a way to recolor images using css classes. No idea if there's a better way. Also, the real implementation would require a change to [[MediaWiki:Common.css]]. [[User:Brightgalrs|Brightgalrs]] ([[User talk:Brightgalrs|talk]]) 22:41, 21 December 2022 (UTC)
:Should mention, there ''is'' a different way, just upload each image 16 times, one for each coloring. But maybe that's not very elegant. [[User:Brightgalrs|Brightgalrs]] ([[User talk:Brightgalrs|talk]]) 22:45, 21 December 2022 (UTC)

: It should be noted that soon the classic edition will be released, hence one should plan to have both the Premium and classic alongside in that little space --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 03:14, 22 December 2022 (UTC)
::I'm looking into a tab extension to potentially support this in infoboxes. Perhaps [https://www.mediawiki.org/wiki/Extension:Tabs Extension:Tabs]? I tried [https://www.mediawiki.org/wiki/Extension:TabberNeue Extension:TabberNeue], but it displays a placeholder if JavaScript is disabled, which isn't great. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 04:22, 22 December 2022 (UTC)
::: The Neue Tabber seem to works pretty much like the old one (which fandom [https://coding-help.fandom.com/wiki/Tabber#Adding_images_into_tabbers still use]) defaulting to showing the first tab only. Quick look suggest that neue work the same, plus the notice that 'Tabber requires Javascript to function' warning? if so, and if it is a bother, then you should be able to edit out the tabberneue-noscript string in code. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 06:29, 22 December 2022 (UTC)
::: I much prefer your tabber solution, but if that fails we can also use the gallery slideshow mode. If so, beware it has no way to control image size so the images have to be maliciously uploaded using the exact same size. example:
<gallery mode="slideshow">
File:SteelSample.png
File:TinSample.png
File:ZincSample.png
File:GoldSample.png
</gallery> --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 10:19, 22 December 2022 (UTC)

==== adding premium set to Infobox ====
I am unclear where are we going with this? 
1) Will (A) tabs be implemented, (B) we be using mediawiki toggle [[Template_talk:V50_workshop|example]] for premium and classic/blocked, (c) put images side by side, or (d) something else? 
2) Also [[silver]] and [[Pig iron]] use very different image style for example. 
3) Anything else you want ? --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 12:32, 30 December 2022 (UTC)

: Personally, I would love tabs to be implemented, but I think that side by side might be best for most. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 12:32, 30 December 2022 (UTC)
: Here is rough layout we can use. It should fit most buildings given the default sprite size. There is also a different floor plan for both (inspired by reddit)

{|
|- valign=top
|
{| style="width:200px; background-color:#eaecf0; border-collapse: collapse; "
|+ 5x5
|- style="border-bottom:2px solid #3366cc; "
|<div class="mw-customtoggle-infoboxtab mw-ui-button mw-ui-progressive" style="border-top-right-radius: 10px; border-top-left-radius:10px;">toggle</div>
|{{Tooltip|Hotkey|adasdasdasd}}: {{Key|b|o|g}}
|- valign=top
|colspan=2|<div class="mw-collapsible" id="mw-customcollapsible-infoboxtab">
[[File:Siege workshop.png|center|160px]]</div>
<div class="mw-collapsible mw-collapsed" id="mw-customcollapsible-infoboxtab"">
{|
|rowspan=2 style="width:50%; font-size: 125%;"|<center>{{Template:Picture Siege workshop}}</center>
|style="line-height: 1em; font-size: 125%;"|
{| style="border-spacing:4px;"
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
|-
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#86878a; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#86878a; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#86878a; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
|-
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
|-
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#86878a; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#86878a; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#86878a; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
|-
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:12px; height:12px; background-color:#b7b9bd; border:1px solid #545557;"|
|}
|-
| style="text-align: center;" | Layout
|}
</div>
|}
|
{| style="width:200px; background-color:#eaecf0; border-collapse: collapse; "
|+ 3x3
|- style="border-bottom:2px solid #3366cc; "
|colspan=2 style="text-align: right;"|<div class="mw-customtoggle-infoboxtab mw-ui-button mw-ui-progressive" style="float:left; border-top-right-radius: 10px; border-top-left-radius:10px;">toggle</div>{{Tooltip|Hotkey|adasdasdasd}}: {{Key|b|o|g}}
|- valign=top
|rowspan=2 style="width:50%;"|
<div class="mw-collapsible" id="mw-customcollapsible-infoboxtab">[[File:Carpenter's workshop.png]]</div>
<div class="mw-collapsible mw-collapsed" id="mw-customcollapsible-infoboxtab""><center>
{| style="font-size: 175%; border-spacing: 0; background-color: black; border: 2px solid black"
|- 
| style="padding: 0; line-height: 1em"|
| style="padding: 0; line-height: 1em"| {{Raw Tile|"|7:0:0}}
| style="padding: 0; line-height: 1em"| {{Raw Tile|{{=}}|6:0:0}}
|-
| style="padding: 0; line-height: 1em"| {{Raw Tile|░|0:7:1}}
| style="padding: 0; line-height: 1em"|
| style="padding: 0; line-height: 1em"|
|-
| style="padding: 0; line-height: 1em"| {{Raw Tile|░|0:7:1}}
| style="padding: 0; line-height: 1em"| {{Raw Tile|]|0:0:1}}
| style="padding: 0; line-height: 1em"| {{Raw Tile|░|0:7:1}}
|}</center></div>
|
{| style="border-spacing:5px;"
| style="width:18px; height:18px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:18px; height:18px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:18px; height:18px; background-color:#b7b9bd; border:1px solid #545557;"|
|-
| style="width:18px; height:18px; background-color:#86878a; border:1px solid #545557;"|
| style="width:18px; height:18px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:18px; height:18px; background-color:#b7b9bd; border:1px solid #545557;"|
|-
| style="width:18px; height:18px; background-color:#86878a; border:1px solid #545557;"|
| style="width:18px; height:18px; background-color:#b7b9bd; border:1px solid #545557;"|
| style="width:18px; height:18px; background-color:#86878a; border:1px solid #545557;"|
|}
|-
| style="text-align: center;" | Layout
|}
</div>
|
{| style="width:200px; height:100px; padding:10px; background-color:#eaecf0; border-collapse: collapse;"
|+ 1x1
|- style="border-bottom:2px solid #3366cc;"
| colspan=3 style="text-align:center;"|{{Tooltip|Hotkey|adasdasdasd}}: {{Key|b|o|g}}
|-
| style="border-right: 1px dotted #545557;"|[[File:Screw_press.png|32px|center|link=]]
| style="font-size:125%;"|<center>{{Template:Picture Screw press}}</center>
| style="border-left: 1px dotted #545557;"|<center>{{Template:Floor Plan Screw press}}</center>
|}
|
{| style="width:200px; height:100px; padding:10px; background-color:#eaecf0; border-collapse: collapse;"
|+ 1x3
|- style="border-bottom:2px solid #3366cc;"
| colspan=3 style="text-align:center;"|{{Tooltip|Hotkey|adasdasdasd}}: {{Key|b|o|g}}
|-
| style="border-right: 1px dotted #545557;"|[[File:water_wheel.png|32px|center|link=]]
| style="font-size:125%;"|<center>{{Template:Picture Water wheel}}</center>
| style="border-left: 1px dotted #545557;line-height:normal;"|<center>{{Template:Floor Plan Water wheel}}</center>
|}
|}
:Any thoughts on the direction and or any and all of its elements? --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 10:16, 31 December 2022 (UTC)

::I kind of like side-by-side, if it fits. If anyone wants to implement a toggle button or tabs, I would ask that that be implemented in a template for now, so that e.g. we could change a toggle button to tabs in a single place if we decide to install an extension to support that. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 03:14, 1 January 2023 (UTC)

::: I noticed a comment saying that [[impassable tile]] are no longer used in v50, is that true for all constructions? If so, floor plans are no longer needed, making things much easier as we can fit everything in except the 5v5 constructions like trade depot (and even these can be placed one above the other if so desired). If not, any thought on the alternative floor plan design? --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 07:46, 1 January 2023 (UTC)

:::: None of the constructions have blocking tiles any more from my experience playing. I haven't tested siege weaponry with that stuff, but none of the workshops have it, nor does any furniture. (walls and fortifications will of course obstruct movement [[User:AndrielChaoti|AndrielChaoti]] ([[User talk:AndrielChaoti|talk]]) 18:47, 1 January 2023 (UTC)

==== Bizarre palette-swapping idea/prototype ====
No idea if this is a good idea, since it takes a bit of time to set up, and there might be some performance issues... and maybe display issues?

But take a look at this:
{{User:Brightgalrs/Sandbox/PaletteSwitch|templatename=User:Brightgalrs/Sandbox/Rock|palette-name=amber}}

It's way to swap palettes on an image, although the image itself is a table, with each cell representing a pixel. The template itself looks like this:
<code><nowiki>{{User:Brightgalrs/Sandbox/PaletteSwitch|templatename=User:Brightgalrs/Sandbox/Rock|palette-name=saffron}}</nowiki></code>
Input the pattern and desired palette name.

I've got a larger showcase here: [[User:Brightgalrs/Sandbox/PaletteSwapShowcase]]. Only did a rock pattern so far, but all palettes are implemented.
The major use for this would be on each stone, metal, wood, etc. type's page. The palette could be read directly from the raws. [[User:Brightgalrs|Brightgalrs]] ([[User talk:Brightgalrs|talk]]) 03:22, 24 December 2022 (UTC)

:From a technical perspective, my primary concern is indeed performance. Both on the server side and client side, a large number of tables that large (in terms of markup and cell count, that is) tend to be resource-intensive to generate and render. I saw your image-filtering experiments on [[User:Brightgalrs/vector.css]], and while that strikes me as a newer and less-backwards-compatible approach, it would probably be more resource-friendly.
:Is this color adjustment something the game is doing natively? i.e. does this accurately match what the game displays? I bet we could slap together an image-filtering extension (or find an existing one?) that can do this if needed. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 03:49, 24 December 2022 (UTC)
::Yeah that's what I suspected. The images the template creates are spot on, checked it against a screenshot I took of some mica rocks in-game. The css stuff is unfortunately totally incorrect, was cool to learn about it though, so not a complete waste of my time :p. The premium, in-game graphics are true sprites, basically patterns of indexed colors. Each of the in-game colors (which are significantly expanded over the 16 ascii colors, there's 116/117) there is a palette defined in "\Dwarf Fortress\data\vanilla\vanilla_descriptors_graphics\graphics\images\palettes.png". Each indexed color of the sprite is swapped for the corresponding color in the palette. Because of that, the css stuff doesn't work since it's doing the hue/saturation/brightness changes to the entire sprite.
::I've looked into an existing mediawiki extension, couldn't find anything. One thing I did't really look at is some type of lua script/module that would basically emulate what the game is doing. So some function that takes in the base image as well as the desired palette, and based on that finds and replaces each color. No idea what mediawiki's capabilities are on that front. [[User:Brightgalrs|Brightgalrs]] ([[User talk:Brightgalrs|talk]]) 05:31, 24 December 2022 (UTC)
:::We do have Scribunto installed now, so it's totally possible to do something in Lua too - forgot about that. I can add you to the group that grants access to edit the Module namespace if you want to give that a shot. If we use an extension, we'd probably need a custom one, similar to DFDiagram (or perhaps DFDiagram could be extended - it's in dire need of a rewrite anyway). —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 05:43, 24 December 2022 (UTC)
::::I asked around on the mediawiki irc, I think scribunto/lua is a deadend, at least for taking an uploaded image and doing stuff to it with a lua script. However I did come up with this even more bizarre solution, using block elements. [[User:Brightgalrs/Sandbox/PaletteSwapShowcase2]], maybe less resource intensive? Definitely displays a lot worse though, probably unusable.
::::{{User:Brightgalrs/Sandbox/PaletteSwitch|templatename=User:Brightgalrs/Sandbox/Rock2|palette-name=saffron}}
::::I dunno, maybe none of this is worth it and we should just write some external program to put all the images together offline, and then just mass upload. It wouldn't be ''that'' many... [[User:Brightgalrs|Brightgalrs]] ([[User talk:Brightgalrs|talk]]) 06:37, 24 December 2022 (UTC)

====Is there an easy way to just paste images from the clipboard?====

I use KDE spectacle to take screenshots straight to the clipboard (after cropping) -- is there an easy way to just paste (and auto-upload) an image into an article? It would make it a lot easier to contribute images. [[User:Kelvie|Kelvie]] ([[User talk:Kelvie|talk]]) 23:35, 1 January 2023 (UTC)

=== Hotkeys/Menu navigation ===
Most key bindings and menus have changed. Should the article reflect a) only the old version, b) only the GUI version or c) both? For example, [[Bridge|bridges]] used to be built via {{k|b}} -> {{k|g}}, but now it's in Place strucutures {{k|b}} -> Constructions {{k|n}} -> Bridge {{k|b}}. What should be written in the article? Currently, it's {{k|b}} -> {{k|g}}. I ''think'' it should be only b), but I am not sure if there will be differences regarding hotkeys or menus between the premium version and the free version and then, c) would be the most appropriate option. --[[User:Prometherus|Prometherus]] ([[User talk:Prometherus|talk]]) 10:16, 22 December 2022 (UTC)

: Not sure. I wish the classic release soon --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 16:45, 22 December 2022 (UTC)
:: Are you Toady's herald? Looks like it was just released! [[User:Brightgalrs|Brightgalrs]] ([[User talk:Brightgalrs|talk]]) 18:18, 22 December 2022 (UTC)
:: And our questions are answered, the old hotkeys seem to have been thrown out. Part of me is disappointed (useless muscle memory) but also relieved (unified UI for both versions is good in general and for the wiki). [[User:Brightgalrs|Brightgalrs]] ([[User talk:Brightgalrs|talk]]) 18:25, 22 December 2022 (UTC)
::: According to info, in a sort of 'demo version' at that. I'll wait a little while longer, for myself.[[User:Silverwing235|Silverwing235]] ([[User talk:Silverwing235|talk]]) 18:22, 22 December 2022 (UTC)
::::It's unlikely that keybindings in it will change significantly. My vote is that we should include information for both premium and classic, everywhere. Hopefully the keybindings are not different between versions. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 18:26, 22 December 2022 (UTC)
:::Shouldn't it be based on the 50 or what verion the article is written for? [[User:Dominick|Dominick]] [[User_talk:dominick|(TALK)]] 18:42, 22 December 2022 (UTC)
:::: The keybindings seem to be consistent between versions, (haven't checked exhausitvely, but since the menu layout is the same I think it is a good assumption). Should also keep in mind/consider that not all actions have keybindings. An option would be write 'Click on the <Example Text> icon or press {{k|E}}' [[User:Koos|Koos]] ([[User talk:Koos|talk]]) 23:14, 23 December 2022 (UTC)

=== Removed features & concepts ===

Since they're removed concepts, I've set [[Room]] to be a redirect for [[DF2014:Room]] and created [[Template:Activity zones]] for the nav bar bedrooms, etc, and made the necessary changes to [[Bedroom]] for it. Is this the correct approach, before I go on much further? (also a note, if it is, then [[Template:v50_rooms]] probably needs to be deleted) I also imagine that considering the number of changes in the interface, that things like [[Adventure mode]] and related pages might best be truncated to "not in 50.03" and when it does make it across, being more deliberately brought over in pieces? [[User:HawkOwl|HawkOwl]] ([[User talk:HawkOwl|talk]]) 06:23, 23 December 2022 (UTC)

:Usually it is marked with [[Template:Removed_feature]]. For example: [[Dipscript]] or [[Party]]. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 07:45, 23 December 2022 (UTC)

:: Ah, that's fair. Should that be mentioned in [[Dwarf_Fortress_Wiki:Versions#Redirects]]? [[User:HawkOwl|HawkOwl]] ([[User talk:HawkOwl|talk]]) 10:03, 23 December 2022 (UTC)

:::I think the redirect policy mostly had in mind things that were removed a ''long'' time ago, like [[Tax collector]] and [[Economy]] (and the latter actually has a stub page as well). I guess we could clarify. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 19:34, 23 December 2022 (UTC)

:::: The "current" redirects also cause the version box to incorrectly show that the current version has a page - e.g. [[23a:Cave_river]] shows a v50.04 version, but it's just a redirect back to that version. Similarly, what should happen to redirects like [[Clothes maker]], where a concept has evolved? It currently goes to [[23a:Clothes maker]] - that's correct if the user is trying to look up a very old concept, but if a new user is looking for "how to make clothes", they should be directed to [[Clothier]]. --[[User:Danny252|Danny252]] ([[User talk:Danny252|talk]]) 12:16, 26 December 2022 (UTC)

:::: One should be careful with cv redirects. Most that were recently adjusted were unused plural forms (that should probably be deleted) but few like [[Crown]] needed that for backward compatibility. Removing the [https://dwarffortresswiki.org/index.php?title=Crown&type=revision&diff=279966&oldid=219482 cv part] means the the link on [[v0.31:Tilesets]] is now broken. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 22:30, 26 December 2022 (UTC)

:::::If [[v0.31:Tilesets]] is about v0.31, it should not be using "main:" in its links - ''all'' of those links are going to pages about v50, not v0.31, regardless of whether the target is a redirect or not. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 23:37, 26 December 2022 (UTC)
:::::: You right, I removed it. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 17:55, 27 December 2022 (UTC)

Crown cv redir issue is now fixed, I believe. As goes with such cases where one can simply revert the troublesome edit, unless I've mistepped, myself? [[User:Silverwing235|Silverwing235]] ([[User talk:Silverwing235|talk]]) 23:52, 26 December 2022 (UTC)
:Both [https://dwarffortresswiki.org/index.php?title=Crown&diff=prev&oldid=280026] and [https://dwarffortresswiki.org/index.php?title=Crown&diff=prev&oldid=279966] should not have had any effect, because "cv" is an alias to the main namespace now, just like "main". Proof: [[Crown]], [[cv:Crown]], [[main:Crown]]. It's possible caching is coming into play here, although I purged the redirect cache after making that alias change earlier this month... —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 00:02, 27 December 2022 (UTC)

I think there have been some changes not captured, but as a newb, I'm afraid to edit the page(s). A good example is Strawberry. I'm playing the Steam version right now and Strawberry plants are "not relevant to brewing" in Labor > kitchen > veg / fruit / leaves. Unless I'm mistaken and need to process them? Another example is the trade caravan = it seems the 3 square pathing no longer happens; it's just yak(s). 12:31, 28 December 2022 (UTC) 12:29, 28 December 2022 (UTC)

As far as I can tell, none of the workshop buildings in v50 have blocking tiles any more. There's a comment to the like in data/vanilla/vanilla_buildings/objects/building_custom.txt that says this "[BLOCK:1:0:0:0] workbenches no longer block". Hesitant to update that template as I'm not sure if it's referenced for all of the old versions too. [[User:AndrielChaoti|AndrielChaoti]] ([[User talk:AndrielChaoti|talk]]) 05:54, 29 December 2022 (UTC)

=== creature infobox prototype (moved) ===

Check it out, I made a temporary template and added it to the [[cow]]s page. Now it shows the sprites (but not the zombified versions yet). I wanted to show everyone a prototype of what v50 creature infoboxes should look like. Or at least something similar to it. --[[User:Zippy|Zippy]] ([[User talk:Zippy|talk]]) 19:11, 27 December 2022 (UTC)
:Hi, I'm new to editing wikis but I have done a bit of work with sprite sheets and I've been going through the DF data files to find the different graphics hoping to help with the animal pages. I've thrown together a template with grass and a few nature sprites (plants, a tree, and a rock) for size reference but I'm unsure how large the 'display' tiles in the middle of the template should be to suit all animals. I can see in the sprite sheets that some land animals have an adult and child sprite, so two tiles. Others have a male, female, and child, but after seeing you include the zombie cows I'm unsure if I should make it twice the size to add them too. Alternatively, I could grab some tiles from the haunted biomes for the zombie animals and make a separate template for a side-by-side comparison. Either way, let me know if this helps. I'd like to help with other graphics too as we add the premium tilesets but the animals seemed the easiest to tackle with me being new to wiki editing. ~~[[User:UristTheSeventh|UristTheSeventh]]

=== When do we remove the migration note on specific pages? ===

At what point can we remove the "this page was auto migrated from v47" warning? There are a bunch of small pages that are more or less accurate, if I've reviewed them, can I go ahead and remove the warning? [[User:Kelvie|Kelvie]] ([[User talk:Kelvie|talk]]) 23:33, 1 January 2023 (UTC)

== Toggleable image ==

Any objections/comments to using this template for now for toggling between classic and premium images? I'd probably rename it to "Template:Premium-classic thumb image". I'm sure someone can come up with a better UI eventually, but should be easy to migrate at that point. I also think we should use the same customtoggle class for this and for the infobox. [[User:NiftyManiac|NiftyManiac]] ([[User talk:NiftyManiac|talk]]) 23:12, 1 January 2023 (UTC)

{{User:NiftyManiac/Sandbox/TemplateDualImage|
premium=File:Quickstart-finder.png|
classic=File:Quickstart-finder-partial.png
}}

{{User:NiftyManiac/Sandbox/TemplateDualImage|
premium=File:Quickstart-finder.png|
classic=File:Quickstart-finder-partial.png|
caption=My caption|
width=100px
}}