Dwarf Fortress Wiki - User contributions [en]

User:Quatch

2021-04-02T22:13:28Z

Quatch:

Longtime player, occasionally active on the forum, active on the subreddit, active on twitch DF streams, decided to start contributing to the wiki instead of just answering questions in the gameplay forum. Please excuse my wiki syntax, not really up to speed on it.

Find me on /r/dwarffortress (message, no chat), [https://www.twitch.tv/qvatch/about twitch], or the bay12forum (slow response), discord Qvatch#0476 if you happen to share a server.

==Current DFhack stuff I work on==
quicksave before you use these, but they don't crash the game for me. GUI commands must be launched from the dfhack console, not from the ingame command prompt!

* [https://www.reddit.com/r/keupo/comments/jb15sv/stamper_v4_with_constructions/ Stamper]: Copy paste for designations and constructions!
* [https://github.com/Datacup/dfhackscripts Digshape]: Designate all sorts of geometric stuff! [https://github.com/Datacup/dfhackscripts/tree/digshape-gui-dev Now with a GUI! (warning: in really active dev, 90% functional 60% of the time)]
* [https://github.com/qvatch/scripts/blob/master/faith.lua Faith]: Prints out a summary of the gods, temples, and worshippers in your fort (in dev, mostly functional), no longer make a new temple just to see the list!
* [https://github.com/qvatch/scripts/blob/master/migrationcap.lua Migrationcap]: Set a maximum size for migration waves (not the 2 first hardcoded ones) that is mostly respected! Grow your fort slowly, and get to know your dwarves! (in active dev, usually works)

==Links I might refer you here to find==
* [https://dffd.bay12games.com/file.php?id=7622 Windows LNP]: for playing DF with a snazzy interface to give you tilesets and dfhack.
* Disable soundsense things
** [https://www.reddit.com/r/dwarffortress/comments/4lobqh/soundsense_sparring_sounds_off/ sparring sounds]
** [ end the eternally forsaken native flute job cancellation nightmare]

==Fun DF things==
===Minecarts===
* [https://www.youtube.com/watch?v=qUF5R7hQppk Minecart shotgun]
* [https://www.youtube.com/watch?v=fTox69FiEiI Goblin frogger minecart defense]
* [https://df-walkthrough.readthedocs.io/en/latest/masterclass/minecart-education.html Minecarts explained]
* [https://imgur.com/gallery/eMhYznJ The 'clinodev' magma minecart 'easiest' retrieval]
* [http://www.bay12forums.com/smf/index.php?topic=137557.0 Supersonic minecarts (past max speed)]

===Notable bugs===
* [ ]
* [ ]
* [ ]

===IRL DF things===
* [https://en.wikipedia.org/wiki/File:Persepolis_Apadana_Eastern_Stairway_Triangle.jpg Example of engraved placed stone blocks] [https://en.wikipedia.org/wiki/Ishtar_Gate no really, it was a thing]
* [https://www.gamasutra.com/view/feature/131954/interview_the_making_of_dwarf_.php?page=10 2008 DF interview]

===Saved wiki pages===
* [http://dwarffortresswiki.org/index.php/DF2014:Werebeast#Transformation_dates Werebeast dates]
* [https://dwarffortresswiki.org/index.php/DF2014:Tilesets Character code -> DF usage]
* [https://dwarffortresswiki.org/index.php/DF2014:Color DF color overview]
** [https://dwarffortresswiki.org/index.php/DF2014:Color_scheme user color schemes]

===Misc===
* [https://df-walkthrough.readthedocs.io/en/latest/tutorials/dwarven-martial-arts.html Kisat Dur, dwarven martial art]
* [https://github.com/numinit/armokweb armokweb, yet-another-df-multiplayer]
* [https://old.reddit.com/r/dwarffortress/comments/i9rthn/the_public_release_of_df_storyteller/ DF storyteller, legends mode interface]
* [http://www.bay12forums.com/smf/index.php?topic=161328.0 curses vector font]
* [ My complete DF delta, might be current, might not be. See the above direct links to current scripts.]
* [ Dwarven artisan class]: for player named honoured dwarves. Give them the rich life they've earned.
* [https://www.dropbox.com/s/y6e085raqbfa1ci/NichoTiles.bmp?dl=0 ASCII tileset with NichoLive's diagonal walls]

===DFhack dev===
* [https://github.com/DFHack/scripts DFhack github (official)]
* [https://dfhack.org/builds/ DFhack nightly builds]
* [https://docs.dfhack.org/en/stable/index.html DFhack manual]
* [https://buildmedia.readthedocs.org/media/pdf/dfhack/stable/dfhack.pdf DFhack manual (PDF)]

User:Quatch

2021-04-01T18:17:36Z

Quatch:

User:Quatch

2021-04-01T18:07:24Z

Quatch: Revised personal page to be not 2010ish

Pick

2021-01-14T18:06:30Z

Quatch: noting which labour is used in crafting, blacksmithing might be the more logical first guess to the new player.

{{Quality|Exceptional|19:13, 1 March 2017 (UTC)}}
{{av}}
[[Image:pickaxe_transparent.png|190px|right|≡Iron pickaxe≡]]
A '''pick''' is a [[equipment|digging implement]] / [[weapon]] that can be [[Metalsmith's forge|forged]] (using the [[Weaponsmithing]] labour) from most weapon-grade [[metal]]s, such as [[copper]], [[iron]], [[bronze]], [[bismuth bronze]], [[steel]], and [[adamantine]], but not [[silver]], (although other [[weapon]]s can be forged from silver). Picks are essential for a properly-functioning fortress: [[miner]]s require picks to strike the earth, dig tunnels, carve staircases and everything else related to the removal of rock and soil tiles. You will need to purchase or create picks on embark, as miners won't bring their own. Without picks, your dwarves will be stranded on the surface, forced to live like [[elf|elves]]. The [[quality]] and [[material]] of a pick have no effect on its speed when digging through rock; that depends solely on the user's [[Mining]] skill level.

Picks can also be used as weapons. They inflict [[attack types|EDGE type]] damage, tend to impale or dismember enemies, and gain damage bonuses dependent on the user's Mining skill level. Picks are brutally effective, combining slashing and impaling and generally far better than anything that isn't a [[whip]] or [[scourge]]. Unlike when digging through rock, [[quality]] and [[material]] are both important when using a pick as a weapon. Since a [[steel]] pick can penetrate most armor, picks are effective weapons against any foe, armored, [[Forgotten beast|forgotten]], [[Bronze colossus|bronze]], or otherwise. Almost all dwarves can equip picks; [[Weapon#Size|some must use two hands]].

Note that military dwarves will never select a pick as a weapon if allowed "individual choice". They must be specifically assigned picks as part of their uniform or on their equip screen.

== Forging and Melting ==
* Metal picks cost '''one''' [[metal]] bar to [[forge]], or '''four''' [[adamantine]] wafers.
* When a non-adamantine metal pick is [[melt|melted down]], it will return '''1.2''' metal bars, for an '''efficiency of 120%'''.
* When an adamantine pick is melted down, it will produce '''1.2''' wafers, for an '''efficiency of 30%'''.

{{Translation
| dwarven = tekkud
| elvish = mubara
| goblin = otez
| human = tekud
}}

{{gamedata}}
{{Weapons}}
{{Category|Weapons}}

Sky support

2020-11-16T23:44:40Z

Quatch: Feature in linked article and forum post removed in v0.40, linked article has been removed, but this one survived.

Minecart

2020-10-24T01:43:54Z

Quatch: /* See also */ Uploaded WanderingKid's post to imgur with pictures recovered from wayback machine. Seemed a nicer option than replying to a bay12 thread silent for 7 years.

{{Quality|Masterwork|08:15, 19 May 2015 (UTC)}}
{{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; which, as mentioned before, gives them 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
|-
| [[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
|}

=== 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}}

{{anchor|Tracks}}

=== 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.png|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.png|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.png|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 next to the output stockpile:

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

You must press {{k|d}} three times to 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.png|Track stop constructed.]]

Now we'll define the actual ''route''. This is done in the {{k|h}}auling menu. Press {{k|r}} to begin defining a route. Next, move the cursor to the input end of the track, and then press {{k|s}} to define the first stop:

{|
| [[File:minecart-example-7.png|Stop 1 designation.]]
| [[File:minecart-example-8.png|Route definition, in progress.]]
|}

Move the cursor again, to the output end of the track, and press {{k|s}} again to define the second stop:

{|
| [[File:minecart-example-9.png|Stop 2 designation.]]
| [[File:minecart-example-10.png|Route definition, two stops.]]
|-
|
| [[File:minecart-example-11.png|Stops are not defined yet.]]
|}

There are several user interface features to note at this point. The stops have been positioned, but they haven't been ''defined'' yet, so there is a warning {{DFtext|!|#ff0}} symbol by each of them. In the lower right corner, we see what the {{DFtext|!|#ff0}} means. Also, note that the second stop is labeled in white, while the other two lines are grey. The white text is a selection indicator, and can be moved up and down by pressing {{k|+}}/{{k|-}}.

Next we need to define what our stops do. We want the minecart to be filled with blocks at the first stop, then travel to the second stop where it will dump its cargo, and then return. Press {{k|-}} to move the selection up to stop 1, and {{k|Enter}} to open it up. By default, the stop has three conditions:

[[File:minecart-example-12.png|Default stop definition.]]

We don't want any of these, so press {{k|x}} three times to delete them. This leaves us with a blank stop. Now we can add the conditions we actually want. Press {{k|n}} to begin adding the first condition, then {{k|d}} twice to change the direction from north to east. Then press {{k|c}} to change the condition from empty to full. This will instruct the minecart to be guided east when full of desired items.

To set the desired items, we create a stockpile link. Press {{k|s}}, then move the cursor to the input stockpile, then press {{k|p}} to select that stockpile. Now press {{k|Enter}}; this opens up a selection screen that resembles the stockpile customization screen. Move down to Blocks, {{k|e}}nable them, then (if you wish) restrict it to stone blocks.

When you've done all that, stop 1 should look like this:

[[File:minecart-example-13.png|Stop 1, defined.]]

Stop 2 is much simpler. All we need to do is have the minecart return to the input stop. So, make a condition and change the direction:

[[File:minecart-example-14.png|Stop 2, defined.]]

Finally, we just have to assign our minecart. Go back to the route definition screen, and press {{k|v}}. Select the minecart, and press {{k|Enter}}.

Now we've got everything set up:

[[File:minecart-example-15.png|Route, fully defined.]]

The V is red because the minecart hasn't been moved onto the track yet. Some dwarf will have to haul it from the forge to the first stop, by hand; this will take a while, especially if the forge is far away.

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!

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

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 trackstops are built on top of existing track to operate on moving minecarts, but they can also be used without tracks to create [[Exploit#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:
{{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 [[exploit|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]].

== 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}}

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

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

[[ru:Minecart]]

Adamantine

2020-07-11T04:13:41Z

Quatch: /* Processing */ noted that wafer production consumes dyed thread just fine, but the wafer is not dyed.

{{Quality|Masterwork|23:22, 27 April 2013 (UTC)}}
{{Metal|name=Adamantine|color=3:3:1
|ore=
* [[Raw adamantine]]
|properties=
* [[Material value]] 300
{{firemagmasafe|yes|yes}}
* [[Melting point]] {{ct|25000}}
* [[Boiling point]] {{ct|50000}}
* [[Ignition point]] none
* [[Solid density]] 200
* Liquid [[density]] 2600
* [[Specific heat]] 7500
|uses=
* [[Weapon|Melee Weapons]]
* [[Crossbow]]s
* [[Bolt]]s
* [[Pick]]s
* [[Armor]]
* [[Anvil]]s
* [[Metalsmith's forge|Metal crafting]]
* [[Clothing]]
|wiki=Adamant}}
{{av}}{{Minorspoiler}}

'''Adamantine''' is a rare, high-value [[metal]] which is impossibly lightweight, strong, and sharp. Adamantine is refined from [[raw adamantine]], and can be woven into [[cloth]] or [[smelter|smelted]] into wafers, useful for making almost any item in the game. [[Armor]] and edged [[weapon]]s made from adamantine are absurdly valuable and wonderfully effective.

== Processing ==
[[File:adamantine_axe.jpg|thumb|280px|right|A dwarf with an adamantine axe. ''Art by Kobb'']]
Unlike what a player would expect, one does not simply make adamantine wafers directly from raw adamantine. You must first extract adamantine strands from the raw adamantine, and those are then processed into wafers or cloth.

Adamantine strands are extracted from [[raw adamantine]] at a [[craftsdwarf's workshop]] by a [[strand extractor]]. Strand extraction is an extremely long process for an unskilled laborer, making it potentially worthwhile to focus extraction experience on one or two individual dwarves. Extracted strands are considered a special metallic form of [[thread]], and after extraction can either be woven into adamantine cloth at a [[loom]] or smelted into adamantine [[bar|wafer]]s at a [[smelter]] (removing any dye); thankfully these tasks are performed just as quickly as other weaving and smelting jobs.

Given this extra step of extraction before the smelting phase, most players will want to build additional craftsdwarves' workshops and stockpiles near the smelters and forges. Note that the strands of adamantine are stored in cloth/thread stockpiles. When processing adamantine, it is a good idea to smelt the strands into wafers as fast as possible, as your medical dwarves may use the valuable adamantine strands for [[suturing]] wounds, since, to them, it's just another type of thread.

Adamantine cloth is used to make ultra high-value clothing, but it is no more resistant to [[wear]] than less exotic materials. Adamantine wafers are functionally identical to metal bars and can be used to forge the full range of metal goods, but are far smaller in size, requiring about three times as many units of material per unit as regular metal bars:
* [[weapon token|Weapons]], [[armor token|armor/clothing]], and [[trap component token|trap components]] require the item's MATERIAL_SIZE in wafers/units of cloth
* Most types of furniture ([[door]], [[floodgate]], [[throne]], [[coffin]], [[table]], [[chest]], [[bin]], [[armor stand]], [[weapon rack]], [[cabinet]], [[statue]], [[anvil]], [[barrel]], [[pipe section]], [[hatch cover]], [[grate]], [[quern]], [[millstone]], and [[slab]]) require 9 wafers.
* [[Cage]]s, [[minecart]]s and [[wheelbarrow]]s require 6 wafers.
* [[Block]]s, [[chain]]s, and [[Siege engine|ballista]] arrowheads require 4 wafers.
* [[Animal trap]]s, [[bucket]]s, [[mechanism]]s, and [[crutch]]es require 3 wafers.
* [[Backpack]]s and [[quiver]]s require 2 units of cloth, and [[splint]]s require 2 wafers.
* All other items require 1 wafer.
* [[Strange mood]]s require 1 wafer, regardless of the end product.

Raw adamantine, along with adamantine-made objects, cannot be spawned in the [[object testing arena]] nor during [[embark|embarking]], presumably for balance reasons.

== Application ==
{{Translation
| dwarven = ebsas
| elvish = lire
| goblin = kumo
| human = medi
}}
Adamantine has extreme [[material science|material properties]]: it is nigh-weightless (weighing about as much as [[wikipedia:Cork (material)|cork]]), extremely strong, and razor-sharp. These properties make it ideal for edged [[weapon]]s and [[armor]], but unfortunately, likewise, make it near-useless for blunt weapons, which will simply bounce off of foes: considering the lethality of [[hammerer]] and [[fortress guard]] beatings, this may be the point. [[Armor]] made of adamantine provides unmatched protection against slashing and piercing attacks, but blunt attacks and ranged weapons have high armor penetration capacity, so a full kit of adamantine armor is nonetheless not a recipe for combat invulnerability.

Because the metal's material properties are irrelevant in other applications and because it's so rare and hard to produce, using adamantine for other things is generally a waste. Adamantine statues are ten times as valuable as [[gold]] ones, but are prohibitively expensive to produce, requiring nine wafers per statue. Some of the highest values per wafer for a normal adamantine product can be realised by forging adamantine [[flask]]s or [[trap component|large serrated discs]]. However, by the time you have adamantine available, you're likely not to be in serious need of such valuable export products. By far the most [[wealth]] can be generated simply by adding adamantine to [[artifact]]s – a single stone, wafer, block or bolt of cloth can add hundreds of thousands of dwarfbucks in value, making your fortress the envy of all the [[forgotten beast|neighbors]].

{{gamedata}}
{{metals}}

{{spoiler}}

<s>Un</s>fortunately, breaching any of the tubular veins leads to the [[Underworld|HFS]], for lots of [[Losing|Fun]].

==Origins of Adamantine and Slade==
{{D for Dwarf}}
Back in the mists of time, the Gods decided to create the World. To do so they had to find a way to heat it in the cold voids of space. Demonkind had already forged their own world out of the vile substance [[Slade]], a stone anathema to all creation and only able to be worked through the vile rituals they had created, for slade was truly "dead" stone, with no life in it at all.

Deciding both to imprison their greatest enemies and to create a home for their creations, the Gods poured into the skies of the Demons' world "living" stone (known to mortals as [[semi-molten rock]] - rock burning hot with the fresh life of Creation). The Gods knew that if it were not constantly heated, this living rock would cool, and yet the Demons, fools that they were, constantly attacked the living rock, not realizing that their attacks simply heated the rock again and again, keeping it alive. Unfortunately, as the Gods began to pour more and more of the rock onto their creation, they found it quickly lost its life when removed too far from the Demons. It would only remelt once it touched the living rock, creating vast seas of magma that heated the tunnels above. Worse, the living rock itself had been disturbed by this process, creating gaping holes through which the Demons escaped, killing and maiming the first creations of the Gods, warping those they could find into the terrible Forgotten Beasts, leaving the [[Titan]]s safe on the surface.

Knowing this state of affairs could not last if their weaker creations, the first mortals, were to survive, the Gods created a new substance, imbued with their power: Adamantine. The beautiful aqua-colored ore was poured into the holes, sealing the entrances that the living rock could no longer seal, preventing the Demons from escaping, for its power totally repelled Demonkind.

Unfortunately, as time passed and the first mortals began to carve their civilization from both the surface and the underworld, they discovered the vast shafts of this amazing substance and began to mine it, instantly realizing its divine potency. In doing so, they removed the great barriers the gods had placed in order to keep the Demons sealed. The Demons rose up, slaughtering thousands and escaping into the World, often rising to lead mortal civilizations, such as that of the Goblins. Upon these sites they raised towers carved from the vile Slade that only they could work. Brave adventurers and champions of the Gods forged special swords made from the divine Adamantine and ventured into these dark places to seal the Demons within hell once more. Leaving their swords buried in these places, those who survived swore to defend them for all eternity, binding themselves with oaths of such might that they surpassed death itself. They remain, even today, as zombies and skeletons, driven by their undying thought "none must take the sword!" and nothing more. These undead are totally obsessed with their duty to defend the ancient demonic structures from all interlopers and have been the death of many an unwary explorer.

In retrospect, all this could probably have been avoided if the Gods had bothered to make their all-powerful metal capable of withstanding the swing of a copper pick.

==The Great Adamantine Space Elevator==
{{D for Dwarf}}
[http://www.bay12forums.com/smf/index.php?topic=61507.0 Source]

In a great fluke, a new world was created in the midst of Armok shaving. No one quite understands why this happened, but the whisker of the holy one landed vertically. The material can only be described as a super adamantine. It is over 2000 z-levels high. And the map continues on.

Year after year, the dwarves of [SUBJECT CIVILIZATION HERE] send an expedition out into the world in order to ascertain the fate of last year's expedition. It has long-since been forgotten exactly when this series of fruitless expeditions started, but the dwarves are a sort that demand an answer.

It happens year after year, when they head northeast to the ominous shrubland that has been known only in name: "The Hill of Spit." The hill lies beyond a ruined elven settlement, a stone's throw away from a brook that has come to be known as "Troublemysteries." By the time they arrive, it is already too late.

They embark year after year, and there they stand, awe-struck with their implements of dwarven duty left undisturbed at their feet. All about them are the decrepit wagons and bleached bones of those who heralded their grim arrival -- barrels filled with rot and worm, picks covered in rust and dust. There they stand with their eyes open wide and jaws agape, and they stare upward into the dome of the heavens. What they see is beyond the ken of mortal beard. It reaches from the ground higher than any bird has flown; higher than any cloud has drifted; higher than any man, dwarf, beast or monster has ever or will ever ascend, twisting and writhing upward in ways that can only transfix the gaze of unwary observers in their fundamentally impossible geometries -- a spiraling needle of pure adamantine, ascending beyond the vanishing-point into the sky.

They stand there, motionless and breathless, and wait only for time to wear them down into the dust of the earth from whence they came, leaving that siren spire standing amidst a graveyard of wagons and barrels to call more of their bearded kind to an emaciated doom.

Another year, another expedition unheard of, another question unanswered, another expedition prepared.

Lever

2020-06-28T03:30:51Z

Quatch: /* Linking */ doors cannot be locked or task will suspend

{{Quality|Exceptional|18:31, 23 August 2014 (UTC)}}
{{av}}

A '''lever''' is a building constructed from one [[mechanism]] on an empty tile. It can be built with {{k|b}},{{k|T}},{{k|l}}. Once in place, it can be linked to one or more devices such as [[door]]s, [[bridge]]s or [[support]]s, permitting you to control these other devices remotely. Order the lever to be pulled through its {{k|q}} menu. A dwarf with the [[lever operation]] labor will get assigned the job of pulling the lever. This dwarf might be a long way away, and the delay in pulling the lever can result in [[Fun]]. Levers also make good furniture choices when constructed with high-quality mechanisms.

[[Pressure plate]]s are like levers, but are triggered by creatures or fluids directly rather than by giving an order to a dwarf. If levers are too much [[fun]], a pressure plate may be a better choice. There is more information on trap design [[trap design|here]].

==Activation of the devices==
When a lever is pulled, the connected device(s) activate. What happens during activation depends on the linked device:

* [[Door]]s and [[hatch]]es open and close.
* [[Support]]s collapse, potentially causing a cave-in (pulling the lever again won't re-assemble the support, cave-in or not).
* [[Bridge]]s raise and lower, or retract and extend, depending on the type of bridge.
* [[Floodgate]]s open and close.
* [[Gear assembly|Gear assemblies]] toggle between engaged and disengaged (disengaged assemblies can't support other machinery).
* [[Restraint]]s release the creature assigned to them (leaving the restraint attached to the creature and, at present, unrecoverable).
* [[Cage]]s are deconstructed, releasing their occupants (needless to say, this is irreversible!)
* [[Spike]]s raise and lower.

Different objects take different amounts of time to respond to activation; generally this is only a brief pause, but it can be enough for a charging [[goblin]] to cover more than a few tiles.

==Linking==
One [[mechanism]] is required to construct a lever, and then two more are required to '''link''' the lever with a device. You need a dwarf with the [[Mechanic]] labor enabled to link a lever to a device. The link is made by selecting the lever with {{k|q}}, choosing the type of object you want to link the lever to, and then using {{k|-}} and {{k|+}} to choose the particular object. The list is chronological by order of construction, most recently designated last, and the map will recenter on each object as you scroll through the list.

In addition, you can choose the building to link to with the cursor, moving via arrow keys and up/down. The interface will offer and highlight the nearest applicable building. This choice by cursor was introduced in DF 0.40 and is only available when linking to levers, not pressure plates.

The linkage interface will not give you the option to link buildings already linked to the trigger in question, or tasked to be linked. Buildings that are currently forbidden aren't offered, either. This allows limiting the choices offered to you by deliberately forbidding buildings you don't wish to link.

Once a building is picked, you can choose what specific mechanisms you want to use to connect the device to the lever. The quality of a mechanism affects the accuracy of traps, but not the speed of activation. The first mechanism you choose is for the device end, the second for the lever end. This is important when working with [[magma]].

A lever cannot be successfully linked to a locked door, the dwarves must stand on the door to complete the link. The task will be suspended with a message that they cannot find a path.

A lever can be linked to any number of objects, and each object can have any number of levers controlling it.

There is no way to de-link an object without disassembling either object or lever. When using a lever for a single-use purpose (cages or supports), the mechanism in the lever will remain in the lever, but the object and its mechanism will deconstruct. In this manner, a single lever might accumulate many mechanisms. Deconstructing the lever will free all these mechanisms and allow their reuse - keep your permanent and one-time linkages to separate levers.

In contrast with [[pressure plate]]s, build order does not affect the timing of levers whatsoever. In any given tick, any levers will send their signals before any furniture receives those signals, so it as if levers are always considered to be built after the furniture they link to. In rare cases, it is possible for the order of arrival of the dwarf pulling the lever to affect the precise timing of lever-linked devices, as when using a hatch to drop a dwarf-- if the falling dwarf arrived later than the lever pulling dwarf, the dropping dwarf will take an extra tick to fall.

==On/Off vs Open/Close==
Levers normally have an "on" and an "off" state, seen as whether the small tag at the top of the lever is to the left ("off" state) or the right ("on" state). Upon being pulled, the state of the lever changes, and everything they're connected to updates to the ''corresponding'' state of that lever, and does not just ''change'' states ("toggle"). This becomes important if you have several levers attached to the same device, or one trigger attached to several systems.
:Example: 2 levers (both in "off" position) are connected to a drawbridge. After pulling the first lever, the bridge will lift. Pulling the second lever tells the bridge to "open", which it already has done - no visible effect. When it is pulled a second time it will let the bridge down. This in turn requires the ''first'' lever (still in "open/lift" position) to be pulled twice to trigger a change (lift again), and so on.

"On" and "off" state is fixed and dependent on the lever, not the object that lever is linked to:

* "dash to the right" ( '''ó''' ) is '''on'''
* "dash to the left" ( '''ò''' ) is '''off'''

Note, however, that gear assemblies are ''the sole exception'' to this: Instead of On/Off triggers, they indeed '''do''' toggle.

Several devices, such as [[floodgate]]s and [[bridge]]s, have a delayed response to all incoming signals, and will not respond to subsequent signals until the first has taken effect. For instance, if you pull a lever attached to a floodgate on then off in rapid succession, the floodgate will only respond to the first signal, independent of the position the lever rests in eventually.

In the unusual case that a device receives both an on and an off trigger in exactly the same tick, the device will change states-- an open device will close, and a closed device will open.

==On/Off states==
Objects that can be controlled by levers include:

===== Multiple Uses =====

A "step" is not a step that a dwarf makes, and not based on [[Frames per second|FPS]]. It's one "step" that the game advances. When paused (via {{k|spacebar}} ), you can manually advance the game "1 step" by hitting the period ( {{k|.}} ) key.

* [[Bridge]] – Activates 100 steps after being triggered (see [[#Bugs|bug]] below)
** '''On:''' Turns the bridge into either a raised drawbridge, or a retracted bridge, depending on which option was chosen when the bridge was constructed.
** '''Off:''' Returns the bridge to normal.

* [[Door]] – Activates instantly. Note that once you connect a door, it is either completely open or sealed shut. There is no "''closed, but can be opened by a dwarf''" state anymore.
** '''On:''' Opens the door.
** '''Off:''' Closes the door.

* [[Floodgate]] – Activates 100 steps after being triggered.
** '''On:''' Opens the floodgate.
** '''Off:''' Closes the floodgate.

* [[Floor hatch]] – Activates instantly. Note that, like doors, once you connect a hatch, it is either completely open or sealed shut.
** '''On:''' Opens the hatch.
** '''Off:''' Closes the hatch.

* [[Grate]] – Activates 100 steps after being triggered. When it is open, it just disappears. Liquids go through it just the same, but it will no longer function as a floor/wall (depending on its orientation).
** '''On:''' Opens the grate.
** '''Off:''' Closes the grate.

* [[Bars]] – Activates 100 steps after being triggered. When it is open, it just disappears. Liquids go through it just the same, but it will no longer function as a floor/wall (depending on its orientation).
** '''On:''' Opens the bars.
** '''Off:''' Closes the bars.

* [[Trap|Upright Spear/Spikes]] – Activates 40 steps after being triggered.
** '''On:''' Retracts spears/spikes.
** '''Off:''' Extends spears/spikes.

* [[Gear assembly]] – Activates instantly. When it is disengaged, no power goes through it and anything that is being kept up by its presence (like a [[windmill]] right on top of it) falls down.
** '''On:''' Toggles gear state.
** '''Off:''' Toggles gear state.

* [[Minecart|Track stop]] – Activates 40 steps after being triggered. When disabled, trackstops behave like the track (or floor) underneath them, and minecarts occupying the tile will not auto-dump or experience friction.
** '''On:''' Disables the track stop.
** '''Off:''' Enables the track stop.

===== One-Shot =====

These items, when activated, deconstruct, and/or cannot be triggered again until re-linked.

* [[Cage]] – Activates instantly. Deconstructs the cage and releases all of its contents. The cage and its attached mechanism will be left on the floor nearby; you recover the [[mechanism]] used on the cage but you do not recover the mechanism used in the lever until you deconstruct the lever itself.
* [[Restraint]] – Deconstructs the [[Restraint|chain/rope]] and releases whatever creature it held. The restraint's mechanism will be left on the floor nearby, and the restraint itself will remain attached to the creature's neck; again, you recover the [[mechanism]] used on the restraint but you do not recover the mechanism used in the lever until deconstructing the lever itself.
* [[Support]] – Deconstructs the support, ideally without a dwarf next to it. Most commonly used to cause controlled [[cave-in]]s. The support's building material and its attached mechanism can both be recovered (unless they happen to get destroyed in said cave-in).

==Labeling==
There is no built-in indication of what a lever does, and pulling them to see what will happen can be immensely [[fun]]. Naming the levers using {{k|Ctrl}}-{{k|n}} is the most foolproof way of labeling levers; color-coding of levers can give some indication too. If you really don't want to name your levers, using the [[note]] function can fulfill the same purpose.

However, it is possible to ascertain whether or not a building has been linked to a lever by finding the building under {{k|R}} "View Rooms/Buildings" and then selecting {{k|t}} "Zoom to building items". A device that is actuated by a lever not only lists the components of the building but will also include a mechanism item. Viewing the lever itself this way will display one mechanism for each building the lever is linked to (plus one mechanism from the construction of the lever itself).

There is way to ascertain which lever is linked to what, but it becomes very hard when you have many linkable items. Find the lever, use "q" and then select "add new task". Try for every linkable thing in your fortress, to link the lever to it. If an object isn't available for linking, that's because it is already linked. Though this method isn't very usable to find the single linked item in all of them, it is useful when you forgot whether the left or the right lever was linked to the support.

Finally, the utility [[Utility:DFHack|DFHack]] provides a new GUI command "gui/mechanisms" (bound to {{k|ctrl}}-{{k|m}} by default) which allows you to list and navigate mechanical connections from inside the game itself. This is by far the easiest and least tedious method to review your levers.

==Toggling Passages==

Since all activatable devices apart from gear assemblies have predefined "on" and "off" states, you cannot directly link a lever to two doors in such a way that a single lever flip opens one and closes the other. You can, however, make use of the differences between different linkable devices:

* while doors and floodgates prevent passage when "off" and allow passage when "on", a bridge prevents passage by raising or retracting upon receiving an "on" signal and returns to its passable state when "off".
* hatches, floor bars and floor grates can be placed over a channelled-out tile creating a gap in a passage. When closed (switched "off"), those structures now provide a path across the gap, but block passage when switched "on" and opening. Hatches, like doors, react immediately to signals, which makes them particularly useful for this purpose.

So, to "switch" between paths with a single lever, you could connect functionally different devices to it, e.g. a floodgate in one passage and a raising bridge in another. Whenever the lever is switched now, it will send the necessary signals to open one path and at the same time close the other.

If you want to "toggle" two buildings which follow the same switching rules, you will probably need to build a [[Computing|Logic device]] to do the job.

==Bugs==

* Linked devices that were prevented from operating on a previous trigger may engage immediately on the next trigger.

{{buildings}}

Kobold language

2020-06-12T00:14:06Z

Quatch: Inspiration for kobold language

{{distinguish|l1 = COBOL|wikipedia: COBOL}}

The '''Kobold language''' is one of the [[language]]s the player will come across. This language is used in-game for the names, groups, and civilizations of [[kobold]]s.

Kobold is governed by different rules than the four main languages. Kobolds have the [[DF2014:Creature_token#UTTERANCES|UTTERANCES]] creature token, which means their language has no pre-defined vocabulary. Instead, the language consists entirely of proper names built by hard-coded rules, which are detailed below.

Kobold-language words do not actually have a proper English translation; however, Kobold-language objects and individual kobolds will maintain the same name over time.

==Alphabet and Graphemics==
The letters of the Kobold alphabet are:
<center>
{|class="wikitable" style="border-collapse:collapse;"
|-
|width=2% align="center"|1||width=2% align="center"|2
|width=2% align="center"|3||width=2% align="center"|4
|width=2% align="center"|5||width=2% align="center"|6
|width=2% align="center"|7||width=2% align="center"|8
|width=2% align="center"|9||width=2% align="center"|10
|width=2% align="center"|11||width=2% align="center"|12
|width=2% align="center"|13||width=2% align="center"|14
|width=2% align="center"|15||width=2% align="center"|16
|width=2% align="center"|17||width=2% align="center"|18
|width=2% align="center"|19||width=2% align="center"|20
|width=2% align="center"|21
|-
|bgcolor="#EFEFEF" align="center" colspan="34" | '''Majuscule forms''' (also called '''uppercase''' or '''capital letters''')
|-
|width=2% align="center"|A||width=2% align="center"|B||width=2% align="center"|C||width=2% align="center"|D||width=2% align="center"|E||width=2% align="center"|F||width=2% align="center"|G||width=2% align="center"|H||width=2% align="center"|I||width=2% align="center"|J||width=2% align="center"|K||width=2% align="center"|L||width=2% align="center"|M||width=2% align="center"|N||width=2% align="center"|O||width=2% align="center"|P||width=2% align="center"|R||width=2% align="center"|S||width=2% align="center"|T||width=2% align="center"|U||width=2% align="center"|Y
|-
|bgcolor="#EFEFEF" align="center" colspan="34" | '''Minuscule forms''' (also called '''lowercase''' or '''small letters''')
|-
|align="center"|a||align="center"|b||align="center"|c||align="center"|d||align="center"|e||align="center"|f||align="center"|g||align="center"|h||align="center"|i||align="center"|j||align="center"|k||align="center"|l||align="center"|m||align="center"|n||align="center"|o||align="center"|p||align="center"|r||align="center"|s||align="center"|t||align="center"|u||align="center"|y
|}
</center>

Of these 21 letters, six (A, E, I, O, U, and Y) represent vowels, while the other fifteen represent consonants.

Peculiarities:
*The letter ''h'' only appears in the digraphs ''ch'' and ''sh.''
*The letter ''n'' only appears in the digraphs ''ng, nk,'' and ''sn.''
*The letter ''y'' only appears in the digraph ''ay.''

The letters Q, V, W, X, and Z of the [[wikipedia:ISO basic Latin alphabet|ISO basic Latin alphabet]] do not occur in the Kobold alphabet.

===Letter Frequency===
Based on a sample of 120 kobold names, the approximate letter frequencies can be established:

{| class="wikitable"
! style="text-align: center; font-weight: bold;" | Letter
! Frequency
|-
| style="text-align: center; font-weight: bold;" | a
| 7.8%
|-
| style="text-align: center; font-weight: bold;" | b
| 4.7%
|-
| style="text-align: center; font-weight: bold;" | c
| 0.9%
|-
| style="text-align: center; font-weight: bold;" | d
| 3.6%
|-
| style="text-align: center; font-weight: bold;" | e
| 4.2%
|-
| style="text-align: center; font-weight: bold;" | f
| 2.4%
|-
| style="text-align: center; font-weight: bold;" | g
| 4.3%
|-
| style="text-align: center; font-weight: bold;" | h
| 3.6%
|-
| style="text-align: center; font-weight: bold;" | i
| 8.6%
|-
| style="text-align: center; font-weight: bold;" | j
| 1.5%
|-
| style="text-align: center; font-weight: bold;" | k
| 2.9%
|-
| style="text-align: center; font-weight: bold;" | l
| 10.8%
|-
| style="text-align: center; font-weight: bold;" | m
| 1.9%
|-
| style="text-align: center; font-weight: bold;" | n
| 2.7%
|-
| style="text-align: center; font-weight: bold;" | o
| 4.9%
|-
| style="text-align: center; font-weight: bold;" | p
| 1.3%
|-
| style="text-align: center; font-weight: bold;" | r
| 8.1%
|-
| style="text-align: center; font-weight: bold;" | s
| 11.4%
|-
| style="text-align: center; font-weight: bold;" | t
| 3.6%
|-
| style="text-align: center; font-weight: bold;" | u
| 9%
|-
| style="text-align: center; font-weight: bold;" | y
| 1.9%
|}

==Phonotactics==

The Kobold language has 16 distinguishable consonant phonemes, forming the phonological consonant inventory:
<center>
{| class="wikitable"
! style="text-align: center;" |
! style="text-align: center; font-weight: bold;" | Labial
! style="text-align: center; font-weight: bold;" | Dental
! style="text-align: center; font-weight: bold;" | Alveolar
! style="text-align: center; font-weight: bold;" | Post-alveolar
! style="text-align: center; font-weight: bold;" | Velar
|-
| style="text-align: center; font-weight: bold;" | Nasal
| style="text-align: center;" | ''m'' [m]
| style="text-align: center;" |
| style="text-align: center;" | ''n'' [n*]
| style="text-align: center;" |
| style="text-align: center;" |
|-
| style="text-align: center; font-weight: bold;" | Plosive
| style="text-align: center;" | ''p'' [p], ''b'' [b]
| style="text-align: center;" |
| style="text-align: center;" | ''t'' [t], ''d'' [d]
| style="text-align: center;" |
| style="text-align: center;" | ''k'' [k], ''g'' [g]
|-
| style="text-align: center; font-weight: bold;" | Affricate
| style="text-align: center;" |
| style="text-align: center;" |
| style="text-align: center;" |
| style="text-align: center;" | ''ch'' [t͡ʃ], ''j'' [d͡ʒ]
| style="text-align: center;" |
|-
| style="text-align: center; font-weight: bold;" | Fricative
| style="text-align: center;" | ''f'' [f]
| style="text-align: center;" | ''th'' [θ]
| style="text-align: center;" | ''s'' [s]
| style="text-align: center;" | ''sh'' [ʃ]
| style="text-align: center;" |
|-
| style="text-align: center; font-weight: bold;" | Approximant
| style="text-align: center;" |
| style="text-align: center;" |
| style="text-align: center;" | ''r'' [r]
| style="text-align: center;" |
| style="text-align: center;" |
|-
| style="text-align: center; font-weight: bold;" | Lateral
| style="text-align: center;" |
| style="text-align: center;" |
| style="text-align: center;" | ''l'' [l]
| style="text-align: center;" |
| style="text-align: center;" |
|}
</center>

<nowiki>*</nowiki>The phoneme represented by ''n'' likely has the [[wikipedia: Allophone|allophone]] [ŋ] before ''g'' and ''k.''

===Syllables===

Kobold has three kinds of syllables, ''primary,'' ''secondary,'' and ''final.'' Every word is composed of one or two primary syllables, zero to three secondary syllables, and one final syllable. Words must begin with a primary syllable, end with a final syllable, the penultimate syllable must be a primary syllable, and all others must be secondary syllables. Therefore, the following structures are allowed:
<center>
{| class="wikitable"
! No. of syllables
! Structure
|-
| 2 syllables
| 1-F
|-
| 3 syllables
| 1-1-F
|-
| 4 syllables
| 1-2-1-F
|-
| 5 syllables
| 1-2-2-1-F
|-
| 6 syllables
| 1-2-2-2-1-F
|}
</center>

====Primary Syllables====
Every primary syllable is of the [[wikipedia: Syllable#Components|syllable structure]] C1(C2)V. C1 is mandatory, and can be one of many consonants; C2 is an optional [[wikipedia: Approximant consonant|approximant]], which can be either ''r'' or ''l;'' and V is a vowel.
*The allowed consonants for C1 are: ''b, ch, d, f, g, j, k, l, p, s, sh, st, t,'' and ''th.''
*The allowed consonants for C2 are: ''r,'' ''l,'' or nothing.
**'''Exception:''' The consonant cluster ''ll'' is forbidden.
*The allowed vowels for V are: ''a, ay, ee, i, o,'' and ''u.''
**'''Exception:''' The digraph vowels ''ay'' and ''ee'' can only be present in the penultimate syllable of a word (if this is also the initial syllable, it is still allowed).

====Secondary Syllables====
Every secondary syllable is of the simple form CV. C is one of a handful of consonants, and V is a vowel.
*The allowed consonants for C are: ''b, d, f, g, k,'' and ''l.''
*The allowed vowels for V are: ''a, i, o,'' and ''u.''

====Final Syllables====
Every final syllable is of the structure (C1)C2R. C1 is optional, and can be ''r, l, n,'' or ''m,'' though their allowed usage is limited; C2 is mandatory, and can be one of several consonants; R is a [[wikipedia: Syllable#Rime|rime]] that is limited to one of the four endings ''-er, -in, -is,'' or ''-us.''
*The allowed consonants for C1 are: ''r, l, m,'' and ''n.''
**''r'' is only allowed before ''b'' and ''sn.''
**''l'' is only allowed before ''b, d, g,'' and ''m.''
**''n'' is only allowed before ''g'' and ''k.''
**''m'' is only allowed before ''b.''
*The allowed consonants for C2 are: ''b, d, g, k, m, l, r,'' and ''sn.''
*The allowed rimes for R are: ''er, in, is,'' and ''us.''

Note that the consonant C1 is likely not meant to actually begin the final syllable, but rather to be appended to the penultimate syllable. For example, the kobold name ''Krudulugrilgus'' would be enunciated as ''Kru-du-lu-'''gril'''-gus'', not ''Kru-du-lu-gri-'''lgus.'''''

==Vocabulary==
As mentioned above, Kobold has no set vocabulary, being formed entirely of procedurally generated proper names. The shortest possible words would be 5 letters and 2 syllables, like ''jomus.'' While nothing known about the rules of the language limits the length of a word, the longest observed word so far is the personal name ''thrushrutlichokuldus'' at 20 letters and 6 syllables.

==Inspiration==
{{D for Dwarf}}
Toady has said in an interview that the kobold language was created in imitation of his and Threetoe's childhood language developed to speak to cats. (BlindIRL interview, 2020/06/11, youtube link to follow)

{{Language}}

{{Category|Language}}
[[ru:Kobold language]]

Dungeon master

2020-05-02T02:19:14Z

Quatch: corrected history

{{Quality|Superior|00:11, 17 February 2020 (UTC)}}
{{Noble
| noble=Dungeon Master
| office=Office
| quarters=Quarters
| dining=Dining Room
| chests=1
| cabinets=1
| racks=1
| stands=1
| arrival=
* Appointed by player
* Requires [[mayor]]
| function=
* Unknown
}}{{av}}
{{New in|0.47.01}}

The '''dungeon master''' is a dwarven [[noble]] who can be appointed once your fortress has a [[mayor]]. Their function is, at the time, unknown. They have mild [[room]] requirements and favor citizens with the [[Schemer]] [[skill]].

Their raws note they hold espionage and managing animals as responsibilities. In previous versions of the game, dungeon masters were responsible for taming exotic creatures, a function which in the current version is done by any dwarf with the [[animal training]] labor enabled, regardless of the fortress having a dungeon master or not. The espionage responsibility is presumably used in the [[intrigue]] system, but has no functional use in [[fortress mode]].

==History==

v44.x: [[animal trainer|Animal training]] is done through the [[Status#Animal Status Screen|Animals]] menu, and does not require a specific [[noble]].

v31 through 0.34.06, the dungeon master appeared in the [[raw file|raw files]], but would never appear.

v28 and older, dungeon master present and functional as an exotic animal trainer and cloak wearer.

{{Translation| dwarven = edir kôn | elvish = nuwetha ithera | goblin = bosa âs | human = thudel siñur}}

{{gamedata}}
{{Nobles}}
{{Category|Appointed Nobles}}

DF2014 Talk:Dungeon master

2020-01-29T15:41:46Z

Quatch: v47, dungeon master returns, how to handle difference with v44?

== v47.01 ==

Dungeon master is back. I'm not really sure how to differentiate DF2014's v44 lack of dungeon master and v47's presence, as far as the version tag at the top. I suspect this won't be the only article where in-game behaviour is fundamentally different between the versions. Sorry if I'm jumping the gun and a new DF2020 tag will be added. I'll keep an eye out to go back and revert this article to v44's text and move it to v47's new home if so. Also, I haven't edited a wiki in forever, so apologies for the multiple edits and lack of skill. -- [[User:Quatch|Quatch]] ([[User talk:Quatch|talk]]) 15:41, 29 January 2020 (UTC)

Dungeon master

2020-01-29T15:37:46Z

Quatch: Added a bit of description text

{{Quality|Tattered|15:04, 29 January 2020 (UTC)}}
{{Noble
| noble=Dungeon Master
| office=Office
| quarters=Quarters
| dining=Dining Room
| tomb=Burial Chamber
| chests=1
| cabinets=1
| racks=1
| stands=1
| demands=1
| arrival=
* 50 population
* Discover at least 1 map feature
| function=
* Unknown..., responsibilities: Espionage, Manage animals
}}{{av}}

The '''Dungeon master''' once again appears in 47.01.

Things noted from the Raws:
* Precidence has moved down a bit
* Now appointed by Mayor rather than Baron(etc).
* No longer [PUNISHMENT_EXEMPT]
* [RESPONSIBILITY:ESPIONAGE]
* [RESPONSIBILITY:MANAGE_ANIMALS] does this mean [[animal trainer|Animal training]] has changed?

v44.x: [[animal trainer|Animal training]] is done through the [[Animals]] menu, and does not require a specific [[noble]].

Prior to 0.34.06, the Dungeon master appeared in the [[raw file|raw files]], but would never appear.

{{Translation| dwarven = edir kôn | elvish = nuwetha ithera | goblin = bosa âs | human = thudel siñur}}

{{gamedata| [POSITION:DUNGEON_MASTER]
[NAME:dungeon master:dungeon masters]
[SITE]
[REQUIRES_MARKET]
[NUMBER:1]
[RESPONSIBILITY:ESPIONAGE]
[RESPONSIBILITY:MANAGE_ANIMALS]
[APPOINTED_BY:MAYOR]
[REQUIRES_POPULATION:50]
[PRECEDENCE:108]
[DO_NOT_CULL]
[COLOR:0:0:1]
[ACCOUNT_EXEMPT]
[DUTY_BOUND]
[REQUIRED_BOXES:1]
[REQUIRED_CABINETS:1]
[REQUIRED_RACKS:1]
[REQUIRED_STANDS:1]
[REQUIRED_OFFICE:250]
[REQUIRED_BEDROOM:250]
[REQUIRED_DINING:250]}}

{{Nobles}}
{{Category|Appointed Nobles}}

Dungeon master

2020-01-29T15:33:29Z

Quatch: Fixing formatting of raws. (sorry about this, haven't edited a wiki in forever)

{{Quality|Tattered|15:04, 29 January 2020 (UTC)}}
{{Noble
| noble=Dungeon Master
| office=Office
| quarters=Quarters
| dining=Dining Room
| tomb=Burial Chamber
| chests=1
| cabinets=1
| racks=1
| stands=1
| demands=1
| arrival=
* 50 population
* Discover at least 1 map feature
| function=
* Unknown..., responsibilities: Espionage, Manage animals
}}{{av}}

The '''Dungeon master''' once again appears in 47.01.

[[animal trainer|Animal training]] is done through the [[Animals]] menu, and does not require a specific [[noble]].

Prior to 0.34.06, the Dungeon master appeared in the [[raw file|raw files]], but would never appear.

{{Translation| dwarven = edir kôn | elvish = nuwetha ithera | goblin = bosa âs | human = thudel siñur}}

{{gamedata| [POSITION:DUNGEON_MASTER]
[NAME:dungeon master:dungeon masters]
[SITE]
[REQUIRES_MARKET]
[NUMBER:1]
[RESPONSIBILITY:ESPIONAGE]
[RESPONSIBILITY:MANAGE_ANIMALS]
[APPOINTED_BY:MAYOR]
[REQUIRES_POPULATION:50]
[PRECEDENCE:108]
[DO_NOT_CULL]
[COLOR:0:0:1]
[ACCOUNT_EXEMPT]
[DUTY_BOUND]
[REQUIRED_BOXES:1]
[REQUIRED_CABINETS:1]
[REQUIRED_RACKS:1]
[REQUIRED_STANDS:1]
[REQUIRED_OFFICE:250]
[REQUIRED_BEDROOM:250]
[REQUIRED_DINING:250]}}

{{Nobles}}
{{Category|Appointed Nobles}}

Dungeon master

2020-01-29T15:28:20Z

Quatch: added to 'appointed nobles'

DF2014:Dungeon master/raw

2020-01-29T15:10:00Z

Quatch: Part fixed layout, but I don't really know what I'm doing..

[POSITION:DUNGEON_MASTER] 
[NAME:dungeon master:dungeon masters] 
[SITE] 
[REQUIRES_MARKET] 
[NUMBER:1] 
[RESPONSIBILITY:ESPIONAGE] 
[RESPONSIBILITY:MANAGE_ANIMALS] 
[APPOINTED_BY:MAYOR] 
[REQUIRES_POPULATION:50] 
[PRECEDENCE:108] 
[DO_NOT_CULL] 
[COLOR:0:0:1] 
[ACCOUNT_EXEMPT] 
[DUTY_BOUND] 
[REQUIRED_BOXES:1] 
[REQUIRED_CABINETS:1] 
[REQUIRED_RACKS:1] 
[REQUIRED_STANDS:1] 
[REQUIRED_OFFICE:250] 
[REQUIRED_BEDROOM:250] 
[REQUIRED_DINING:250]

DF2014:Dungeon master/raw

2020-01-29T15:06:13Z

Quatch: Added raws, 47.01.

[POSITION:DUNGEON_MASTER]
[NAME:dungeon master:dungeon masters]
[SITE]
[REQUIRES_MARKET]
[NUMBER:1]
[RESPONSIBILITY:ESPIONAGE]
[RESPONSIBILITY:MANAGE_ANIMALS]
[APPOINTED_BY:MAYOR]
[REQUIRES_POPULATION:50]
[PRECEDENCE:108]
[DO_NOT_CULL]
[COLOR:0:0:1]
[ACCOUNT_EXEMPT]
[DUTY_BOUND]
[REQUIRED_BOXES:1]
[REQUIRED_CABINETS:1]
[REQUIRED_RACKS:1]
[REQUIRED_STANDS:1]
[REQUIRED_OFFICE:250]
[REQUIRED_BEDROOM:250]
[REQUIRED_DINING:250]

Dungeon master

2020-01-29T15:05:48Z

Quatch: Dungeon master is back in the raws as of 47.01, personally waiting on worldgen for science..

Gait

2018-09-10T14:48:38Z

Quatch: /* Gaits and Modding */ added file name to reference, added syntax explanation line

{{quality|Fine}}{{av}}

A '''gait''' is a mode of movement which a creature can use. In real life, the word only applies to movement on land; but in Dwarf Fortress, the term describes any mode of movement by a creature, including swimming, flying, and climbing.

== Gait Types ==

There are 5 different types of gaits: walking, crawling, climbing, swimming, and flying.

* Walking gaits are land-based gaits which require the creature to be standing up, and have more than half of their [STANCE] body parts, e.g. legs, intact and working. They can be used to move across flat ground, and go up and down ramps and stairs.

* Crawling gaits are like walking gaits, except that they require neither standing up nor [STANCE] body parts. They are much slower than walking gaits. Please note that an uninjured, slithering snake is considered to be using a walking gait, not a crawling gait: its body is its [STANCE] body part. If a snake is injured in the body, it will revert to a crawling gait.

* Climbing gaits are used for moving up and down vertical surfaces, such as trees or walls, as well as for moving horizontally while supporting oneself against a vertical surface. In order to climb, a creature needs intact body parts to climb with: [GRASP] body parts by default, or [STANCE] body parts if the creature has the [STANCE_CLIMBER] token. Stance climbers include cats and giant cave spiders.

* Swimming gaits are used for moving in the water. In order to swim, a creature needs either the [SWIMS_INNATE] tag, or [SWIMS_LEARNED], [CAN_LEARN] and skill in swimming.

* Flying gaits are used for moving in the air. In order to fly, a creature needs the [FLIER] tag, and for enough of its body parts tagged [FLIER] (e.g. wings) to be intact, if applicable. Flying does not require a minimum speed to stay airborne, and turning while flying is no more difficult than turning while walking.

== Speed ==

Gait speeds are expressed in ticks/100 tiles. This means that "larger" speeds are '''slower''' than "smaller" speeds. Currently, the maximum allowed speed is 100 ticks/100 tiles, or 1 tick per tile.

The speeds of each gait are only a baseline for how fast a creature of that species will move. In practice, speed can also be affected by factors such as what a creature is wearing or carrying, as well as its [[skills]], [[attributes]], and even its [[personality]]{{verify}}.

Here are some speeds for reference.

{| class="wikitable sortable"
|-
! Gait Speed !! kph !! mph !! Example
|-
| 8775 || 1 || 0.6 || average giant earthworm's top speed
|-
| 100 || 87 || 54 || maximum allowed gait speed
|-
| 900 || 9.6 || 6 || normal walking speed
|-
| 293 || 30 || 19 || average dwarf's top speed
|-
| 5951 || 1.5 || 0.9 || normal dwarven climbing speed
|-
| 225 || 39 || 24 || average human's/goblin's top speed
|-
| 6561 || 1.3 || 0.8 || normal human/goblin climbing speed
|-
| 214 || 41 || 25 || average elf's top speed
|-
| 2206 || 4 || 2.5 || normal elven climbing speed
|-
| 251 || 35 || 22 || average kobold's top speed
|-
| 3512 || 2.5 || 1.5 || normal kobold climbing speed
|-
| 439 || 20 || 12 || average troll's top speed
|-
| 1422 || 6.2 || 3.9 || normal ogre walking speed
|-
| 488 || 18 || 11 || average ogre's top speed
|-
| 125 || 70 || 43 || average horse's top speed
|-
| 351 || 25 || 16 || average dragon's top speed
|-
| 219 || 40 || 25 || average bronze colossus's top speed
|-
| 390 || 45 || 28 || average beak dog's top speed
|-
| 176 || 50 || 31 || average roc's top speed
|-
| 149 || 59 || 37 || average dog's top speed
|-
| 183 || 48 || 30 || average cat's top speed
|-
| 293 || 30 || 19 || average giant cave spider's top running '''and climbing''' speed
|-
| 109 || 80 || 50 || average gazelle's top speed
|-
| 157 || 56 || 35 || average gibbon's top climbing speed
|}

== Standard Gaits ==

The grand majority of standard DF creatures use predefined gait patterns. While their gaits vary in speed from type to type and from creature to creature, the gaits' relations to each other are mostly uniform.

{| class="wikitable"
|-
! Relative Gait !! Gait Names !! Gait Types !! Build-up !! Turning !! Speed Affected by Physique !! Slowed by Stealth !! Energy Drain
|-
| Fastest
||
Sprint

Gallop

Fastest Walk

Scramble

Maximum Swim Speed

Scramble

Maximum Flight Speed

Scramble
||
WALK (biped)

WALK (quadruped)

WALK (general)

CLIMB

SWIM

CRAWL

FLY

WALK (no legs)
|| 10, from a start speed of Fast || No || Yes || 50 || 50
|-
| Faster ||
Run

Canter

Faster Walk

Faster Climb

Faster Swim

Faster Crawl

Faster Flight

Faster Crawl
||
WALK (biped)

WALK (quadruped)

WALK (general)

CLIMB

SWIM

CRAWL

FLY

WALK (no legs)
|| 5, from a start speed of Fast || No || Yes || 20 || 10
|-
| Fast ||
Jog

Trot

Fast Walk

Fast Climb

Fast Swim

Fast Crawl

Fast Flight

Fast Crawl
||
WALK (biped)

WALK (quadruped)

WALK (general)

CLIMB

SWIM

CRAWL

FLY

WALK (no legs)
|| No || Yes || Yes || 10 || 5
|-
| Normal
||
Walk

Walk

Walk

Climb

Swim

Crawl

Fly

Crawl
||
WALK (biped)

WALK (quadruped)

WALK (general)

CLIMB

SWIM

CRAWL

FLY

WALK (no legs)
|| No || Yes || No || No || 0
|-
| Slow
||
Stroll

Stroll

Slow Walk

Slow Climb

Slow Swim

Slow Crawl

Slow Fly

Slow Crawl
||
WALK (biped)

WALK (quadruped)

WALK (general)

CLIMB

SWIM

CRAWL

FLY

WALK (no legs)
|| No || Yes || No || No || 0
|-
| Slowest
||
Creep

Creep

Slowest Walk

Creep

Creeping Swim

Creep

Hover

Creep
||
WALK (biped)

WALK (quadruped)

WALK (general)

CLIMB

SWIM

CRAWL

FLY

WALK (no legs)
|| No || Yes || No || No || 0
|}

== Gaits and Modding ==

In the raw files, gaits are specified in c_variation_default. A better understanding of how creature gaits work can be found under [CREATURE_VARIATION:STANDARD_BIPED_GAITS] (in c_variation_default.txt), where brief information pertaining to their syntax is found.

To specify one of these predefined gaits,the tag [APPLY_CREATURE_VARIATION] should be used.

Example, taken from the dwarf:

[APPLY_CREATURE_VARIATION:STANDARD_BIPED_GAITS:900:711:521:293:1900:2900] 30 kph

where the speeds are: "GAIT:type:name:full speed:build up time:turning max:start speed:energy use"

Talk:ThreeToe

2010-11-16T02:37:49Z

Quatch: Content suggestion

=Article Content=
As to what to put into this page, maybe some summaries of the stories, or details of what story factoids made it into the game? [[User:Quatch|Quatch]] 02:37, 16 November 2010 (UTC)

Talk:Main Page/archive2

2010-10-13T16:26:53Z

Quatch: /* DF2010 Title needs changing */ Toady's input

{{Archive|
# [[Talk:Main Page/archive1|Archive 1]]
}}

== Two DF2010 main pages ==
Why are there two DF2010 main pages? When I check the wiki, I see the one with the missing hydra heads image, and the http://df.magmawiki.com/index.php/Main_Page address, but when I check the 40d version and go back to DF2010 main page, I get Belal's tileset image and the http://df.magmawiki.com/index.php/DF2010:Main_Page address. Then, when I check the discussion page and return to the main page, it's http://df.magmawiki.com/index.php/Main_Page again. Is redirecting messed up or what? --[[Special:Contributions/109.93.118.60|109.93.118.60]] 09:37, 4 June 2010 (UTC)
:There is only one main page for DF2010 - the image shown on it is '''randomly selected'''. The page [[DF2010:Main Page]] is just a redirect to [[Main Page]]. --[[User:Quietust|Quietust]] 12:36, 4 June 2010 (UTC)
Except that one shows "'''28.3 out of 100 quality rating for DF2010 namespace (approximate)'''" and the other shows: "'''29.8 out of 100 quality rating for DF2010 namespace (approximate)'''". Not to mention that the page that contains "''(Redirected from DF2010:Main Page)''" in the top left corner is ''http://df.magmawiki.com/index.php/DF2010:Main_Page'' It redirects to itself. Also, I get one image on the DF2010:Main_Page, and a different one one at Main_Page. When I check DF2010:Main_Page, it's the first picture again. I made sure that it isn't the same page already. Repeat the steps I mentioned in my first comment and see for yourself. It's not a redirect, those are two different pages. --[[Special:Contributions/109.93.118.60|109.93.118.60]] 17:05, 4 June 2010 (UTC)
::[http://df.magmawiki.com/index.php?title=DF2010:Main_Page&redirect=no DF2010:Main Page - Redirect page - Main Page]. It is a redirect. When you load a redirect page, it does not actually forward you to the destination page but simply displays it immediately, so the redirect's URL is still in the address bar. Either your web browser or the server itself is caching different versions of the page depending on whether or not you viewed it through the redirect. --[[User:Quietust|Quietust]] 17:31, 4 June 2010 (UTC)
Well, it stopped happening after the new-version change of the main page, whatever the cause was. Thanks anyway. --[[Special:Contributions/79.101.254.106|79.101.254.106]] 19:30, 4 June 2010 (UTC)

== HFS creatures ==
We don't seem to have any pages for them, shouldn't they have pages like normal creatures? --[[Special:Contributions/78.151.176.4|78.151.176.4]] 13:09, 11 April 2010 (UTC)
:Aren't they randomly generated during worldgen?--[[User:SanDiego|SanDiego]] 13:29, 11 April 2010 (UTC)
Oh right, didn't realise that. Thought that they were just lacking raws. --[[Special:Contributions/92.29.248.178|92.29.248.178]] 14:42, 11 April 2010 (UTC)

Well, you're both right :P. They're randomly generated, and they lack raws! --[[User:612DwarfAvenue|612DwarfAvenue]] 06:20, 18 April 2010 (UTC)

== Random page function ==

I'm not familiar with how the Special:Random function works, but would it be possible to restrict it to random pages from particular namespaces? Getting 23a, 40d and DF2010 pages returned isn't very helpful. [[User:Oddtwang of Dork|Oddtwang of Dork]] 16:27, 8 April 2010 (UTC)
:That would require (iirc) some fairly heavy editing to the mediawiki code. We're trying to avoid modding the code because that creates problems with updating the mediawiki software to new versions. [[user:Emi|Emi]] [[user_talk:Emi|[T]]] 18:51, 8 April 2010 (UTC)
::Just a little correction, you an get to just DF2010 pages by appending "/DF2010" to the end of special random.
:: For example. [[Special:Random/DF2010]], [[Special:Random/Utility]], ect.
:: Perhaps this link might be useful as a more available link? [[User:Mason11987|Mason]] ([[User talk:Mason11987|T]]-[[Special:Contributions/Mason11987|C]]) 00:19, 15 April 2010 (UTC)

== DF2010 Title needs changing ==

The new version is now df_31_01 and each article beginning with "DF2010" seems tacky. Any others agree it should be changed to df31 or something around like that? [[User:Richards|Richards]] 19:59, 1 April 2010 (UTC)
:The problem is that we version the wiki for each game-save compatibility change. Simply changing it to 31.01 would fix it now, but when 31.02 - 39.07 come out, and then finally 40.01 comes out that breaks save compatibility, we have much more work to do. Until we know the final version number in the series, it's not easy for us to just say "oh, this is it." --[[User:Briess|Briess]] 20:02, 1 April 2010 (UTC)
::And wtf is the precedent? In all the versions of the wiki I've seen, versions are always specified as the actual number. How is it more clear to use DF2010 instead of v0.31.01? --Peewee 09:57, 2 April 2010 (UTC)

:If you aren't planning to make more special version namespaces for a while, let's use the main namespace. Also, you guys really need to talk things out more before implementing giant sweeping changes. The more I see you describe your respective visions for the wiki, the more different they seem from each other. [[User:VengefulDonut|VengefulDonut]] 11:29, 2 April 2010 (UTC)

::Well. A solution would be to make every article title for the current version just say the article name, ex/ instead of "DF2010:Armor", make it "Armor", like last time. If a new version is released that is different, then archive it as whatever version it last applied to, like "40d:Armor, or 31.01:Armor". Is there any problem with this idea? [[User:Richards|Richards]] 14:28, 2 April 2010 (UTC)

Yes, there is. (Namely, the amount of labor you're talking about if pages are not set-up for that.)

Here's "The Plan", which was set up a couple months ago (and which has been discussed elsewhere, but we'll do it one more time)...
:* Old versions are clearly labeled and consistently linked internally. All 40d links bounce around only to 40d articles, so if a player is researching that version, it's all one package. ''(Same w/ 23a, the "2-D" version previous to that, but an ongoing and lower-priority project.)''
:* "New" versions are, likewise, consistent within themselves. Versionless search terms (like "[[stone]]" automatically default to "current version".
:* Future versions get their own version names, "current" becomes one-older, and the pattern continues.
The current PROBLEM is three-fold - the first is the changeover itself, when first time Editors start firing away at articles without the correct names or understanding The Plan. That is understandable, but compounded by the fact that we don't currently ''know'' the "proper" version number to use - is it 0.31.01, or 0.31, or 31.01 - when the first bugfix comes out, what will be changed and what kept? What part of that number constitutes/defines this as a "version"? There is no equiv of 23.a or 40.d - it's a new code, and we weren't given the codebook. (We're waiting on Three-toe/Toady for a response on that.) The 3rd problem is "DF2010" - which is wrong, but while popular and everyone is using it, it won't be very friendly later down the road.

So... we've got something that works now but won't in the future, and needs to be changed to be consistent so we don't bequeath future Admin and users the big bone. A diff between more work now and the sort of complete cluster that has gone on behind the scenes for the last 2 months preparing for this change - which is going SO MUCH SMOOTHER NOW (believe it or not!) because of that (thankless, ahem) preparation.

Once we know the correct version, all current articles will appear as that. Search terms will default to current version. Older articles will be consistent within their own namespace. AND we'll be setup for future version changes without quite so much trauma (which is ''why'' some of the more obscure of these changes are being implemented). Clear as mud?--[[User:Albedo|Albedo]] 19:06, 2 April 2010 (UTC)

:Are you basically trying to say that DF2010 is a convenient placeholder string that can be used to identify and move articles by bot when we get a stable version number from Toady? --[[User:Squirrelloid|Squirrelloid]] 19:20, 2 April 2010 (UTC)

::Dammit, if I could express myself in anything less than 500 words at a time, I would have! (Yes, that's basically what I'm saying.)--[[User:Albedo|Albedo]] 19:31, 2 April 2010 (UTC)

:::I'm not sure who wins the eloquence award here. Anyways, we're still waiting on information from ToadyOne before we rename DF2010 to something else more appropriate. --[[User:Briess|Briess]] 19:37, 2 April 2010 (UTC)

:::: Toady has already said that he plans to aim for possibly as often as a weekly bugfix release while the early issues of this release get ironed out. Trying to keep up with release number changes weekly would be an absolute nightmare. Until things calm down a bit I don't blame anyone here in the least for using DF2010 as a more general version name. [[User:Doctorzuber|Doctorzuber]] 15:54, 5 April 2010 (UTC)

:::::It ''is'' understood that Toady intends (ideally) for this to be both the last save-compat breaking version and the last major long-delay version... correct? Putting the entire Wiki in a namespace forever seems to me like a fairly terrible idea in any case, but it is intended for future versions to change much less of existing stuff as things go on (that is why this version took so long, in part, to get all the sweeping structural changes out of the way.) It is unlikely that there will ever be another version that would require reversioning the entire wiki, if, indeed, you think that even this one reached that level. While I'm not sure I'd agree that it was necessary to reversion the wiki for this version, the DF development plan is certainly intended to be such that revisioning the Wiki like this will never be necessary again. --[[User:Aquillion|Aquillion]] 03:47, 7 April 2010 (UTC)
:::::: All I'm saying is that for the immediate near future a large number of incremental bug fix releases are to be expected. To avoid driving people completely nuts trying to keep up with frequent version changes it makes sense to use the DF2010 title in the short term. After we see things settle down a bit I agree we should probably go ahead and return to an actual version number. [[User:Doctorzuber|Doctorzuber]] 17:27, 7 April 2010 (UTC)
:::::::With the new version numbering system being so much simpler, could we simply refer to the version as 31a? Then changing letters to account for bugfixes. I'm using 0.31 enough myself but the decimal point is awful. --[[User:Retro|Retro]] 17:40, 7 April 2010 (UTC)
::::::::Not really. We're mainly talking about the namespace's name. Changing a namespaces's name is a BIG headache (though it is the reason we're using the <nowiki>{{l|link}}</nowiki> stuff) because we did know that we'd be doing at least one change, and that gets rid of a decent portion of the headache. [[user:Emi|Emi]] [[user_talk:Emi|[T]]] 18:49, 7 April 2010 (UTC)
:::::::::I'm still waiting on ToadyOne to provide an official tagname for this series of releases. If we receive one, we will use it in the wiki. --[[User:Briess|Briess]] 19:02, 7 April 2010 (UTC)
::::::::::Toady's response to what to call this version. http://www.bay12forums.com/smf/index.php?topic=60554.msg1636714#msg1636714 (7th reply) probably not as satisfactory/definitive as hoped :) --[[User:Quatch|Quatch]] 16:26, 13 October 2010 (UTC)

== World Painter Page ==
The wiki has needed a page on the [[World Painter]] for a while, so I've started one. The information in there is decent, but I'm relatively new to wiki editing, so the formatting probably isn't. If someone wouldn't mind cleaning it up a bit for me I'd really appreciate it. --[[User:Timmeh|Timmeh]] 01:15, 3 April 2009 (UTC)

:Well I don't know if someone helped you already, but it looks fine to me. --[[User:frandude|frandude]]
:I changed the name into World Painter so it looked better (no more petty redirects!) [[User:Inawarminister|Inawarminister]] 12:01, 7 December 2009 (UTC)

== French language wiki ==

Can we have interlanguage links with the [http://www.dwarffortress.fr/wiki/ French wiki]? -[[User:Alan Trick|Alan Trick]] 17:48, 14 April 2009 (UTC)

== Add a CptnDuck page? ==

Captain Duck is a DF video tutorial maker, which an impressive collection of 40 videos on youtube (and a few extra videos of sieges and arenas and whatnot), and explains how to do most everything, from magma forges to Dwarven justice. He adds humor to it and he's the reason a lot of people understand the game...I think we should give him a page. – [[template:unsigned|unsigned]] comment by [[User:Blackdoggie998|Blackdoggie998]]

:As it is insanely easy for anyone to sign up for editing priviledges on this site (I managed to, after all), I see no need to make one for him when he could make one for himself. However, if you wish to add user:CptnDuck, or invite him to make one himself, feel free. He can link to all of his tutorials from his user page. They even be searchable through that lovely little box to the(my) left. (Who knows where it is on your skin.) -- [[User:Teres_Draconis|jaz]] ... on this day, at this time.

:P.S. Does it seem odd to you to have it say "unsigned comment by [username]"? Or is that just me? -- [[User:Teres_Draconis|jaz]] ... on this day, just a little after the previous one.
:: Clicking 'unsigned' gave me all the explanation I need, might want to do the same [[User:Kinzarr|Kinzarr]] 23:27, 25 November 2009 (UTC)

:We don't need a userpage for him, but a page with the assembled listing of all his (and others of equal quality) video tutorials wouldn't be a bad idea at all. -[[User:N9103|Edward]] 16:47, 23 June 2009 (UTC)

== Articles on Olivine and other generic stones ==

There is a current discussion as to whether or not [[Olivine]] (and perhaps some few other stones) are duly covered on the current [[stone]] page, or are truly worth having their own article/page. This relates to a larger question of how this wiki is organized, and "What deserves a page" in a general sense. Any interested are encouraged to chime in, if only with a "me too" post pro or con. See [[Talk:Olivine]] for an idea of the issue. I'd like to have the debate move from the specific Olivine page to here since this is a more general issue that affects many potential pages. --[[User:Senso|Senso]] 21:29, 19 May 2009 (UTC)

:I'm not really sure which way to go on this one. A lot of otherwise useless stones would need their own articles if the guidelines were expanded... and yet, there's a good amount of useful information that's not on the main pages, that would further clutter them if it were added; And permitting more individual pages would solve both those problems. I guess this ends up being a vote both ways, with provisions on each. -[[User:N9103|Edward]] 23:54, 19 May 2009 (UTC)

:My vote is, if someone can make it amusing, then sure. If someone is of the bent to enjoy making such a page, then again, sure... otherwise, leave it at the bottom of the pile of "things that someday we might get around to if we feel like it" and don't stress. The relevant data is covered (or will be when someone notices it's not), and everything else is gravy. Beside, what would you rather do, play the game, or figure out how to make a whole page of jokes about how gneiss nice is.... (or did I get that backwards?)... ? --[[User:Teres_Draconis|jaz]] ... on this day, at this time.

::All relevant information is covered, yes. But not necessarily on a relevant page. Before the Olivine page was made you couldn't learn that olivine may contain native platinum from any page related to olivine or stone in general.
::Another example is kaolinite. You can look it up in the table of Other Stone to see it can be found in sedimentary rock. But in order to see that it may itself contain alunite and marcasite you have to go through the entire table (or use the browser search function). Now, in order to see if it may contain anything else, you have to notice the note at the top of the page (just above the table of contents) that points to Metal Ore and Gem, whith another two tables you have to search through. (Kaolinite may contain turquoise). --[[User:Nahno|Nahno]] 21:44, 20 May 2009 (UTC)

:It's not just about "which stones" - it's a larger question of how the wiki is organized and presented. Should each separate and distinct item get its own page, like the current one- or two-line articles on [[vial]]s, [[instrument]]s or [[Restraint|chain]]s, (just as random parallel examples of some [[finished goods]] that have their very own, very short, very dull, and predictably repetitive articles.) Surely the [[Masons guild]] and [[miners guild]] don't deserve or need separate articles. Do we need a separate and largely redundant article for every trap weapon? What about the cookie-cutter articles on ''every'' individual animal? The GCS deserves its own, and many others, but one on each separate type of shark and hunting cat? There is no actual article there, only a template.

:Quivers and bolts are sub-sections of the [[crossbow]] article, and I think that's a ''great'' call. Olivine, talc and kaolinite are merely similar examples, distinct enough to warrant special treatment, but on the borderline of being so small to each only represent a stub. Ultimately, I don't think a functional formal definition would be easily achieved - rather guidelines and a fuzzy target, combining related info into groups with optimal size limitations (both lower end and upper end). Perhaps a template should not be forced on every lesser example, but they could be grouped into a table on their own article, "other stones of note" or "sharks" or "finished goods" or whatever.

:In many ways, our only current guidelines are "what has been done so far" - and that varies widely and wildly. Too often, pages are cobbled onto related ones, or split off just because its a new topic, if a brutally short one. Myself, I'd like to see most related articles of less than 4 lines or so get grouped into larger, more universally informative articles, and anything larger than maybe 5 full sub-sections be considered for splitting up. If an item stands out from the rest, it should stand out somewhere, in an article - but that doesn't mean it has to have its very own, or invite every similar item to do so as well.--[[User:Albedo|Albedo]] 03:30, 21 May 2009 (UTC)

:: Please check out the (no longer) current [[Chalk]] page and tell me what you think. ... which is to say, it doesn't /have/ to be a stub, does it? It can be rich and detailed and sadly unamusing. It would please me to continue to do all stones in this manner, or another manner of your choosing.... Thus negating fussing over "this one was done this way, that one was done that way" arguments. I'll get to them all, in the order they appear on the [[Stones]] page. ... assuming you guys are ok with that. --[[User:Teres Draconis]] 08:28, 21 May 2009 (UTC)
:: P.S. Who's the outpost manager of this place, anyways? I'd like to know to whom I should be pandering. --jaz

::: I think 1) you should take time to read, if not learn the wiki format guidelines, 2) you should sign with your REAL user name, and stop using a pseudonym, and 3) you should not break someone else's post with yours in between their paragraphs. As to the chalk page, I think it's over-enthusiastic and pays no attention to previous article style or formatting precedent - which may be a good thing or a bad thing, depending. --[[User:Albedo|Albedo]] 09:33, 21 May 2009 (UTC)

:::: 1) You're right, I'm sorry.
::::2) We've discussed user names on [[User_Talk:Teres_Draconis#Naming Conventions|my talks page]]. (Also, <nowiki>~~~</nowiki> still puts "jaz"... why bother with the link when it's just a P.S.?)
::::3) I'm sorry. I was (apparently) trained wrong, and that was a /long/ time ago. I was taught (20 years ago) that when responding, to do so in-line, so that people can tell what the response is actually relating to. (Like an actual conversation, except with a time warp. You say something, I respond, someone else adds, we all move on to the next topic.) It supposedly adds clarity. The style and curtesy rules of such things has changed. I can see I'll need to update myself. Thank you for pointing that out. =)
::::4) I was hasty. I had to have meatspace people explain to me why, as wiki-''writers'', you would not want so much detail on a page. Especially when, with every new game release, any given page on the wiki might need an over haul. I was only looking at it from the end-user perspective of "If I'm looking for information, I don't want a page that just tells me to go look at the three pages I've already looked at. I want a page that reduces the noise of the irrelevant, and distills to just that specific (sub-)topic." I /don't/ see the point of six pages that are identacle except for title, and all only three lines long. If it's got it's own page, it should have it's own page. If it just links back to the three pages that linked to it, and they all link to each other already, what's the point? If the only thing Chalk has going for it is that it's flux, why not just make a note on the [[Stone]] page reading, "These three rocks can be used as flux" and link to the flux page from there? Why should chalk have it's own page, if it's not going to be richly detailed and, you know, informative? - [[User:Teres Draconis|jaz]] 18:59, 22 May 2009 (UTC)

::::The templates are there because they are pretty, detailed, and condensed ways to display some key information. Rather than expanding existing information so that it takes up more space, it's more productive to add things that you think are lacking. [[User:VengefulDonut|VengefulDonut]] 12:15, 21 May 2009 (UTC)

::: I changed the other [[Stones]] table to allow for interesting minerals that are in other[[Stones]] to be posted.--[[User:Mrdudeguy|Mrdudeguy]] 22:17, 21 May 2009 (UTC)
:What would actually be helpful is a [[Geology]] primer, indicating how layers and inclusions are placed, where, and what the implications of "You have struck XXX" are. I know, now, that if it's olivine, I have a chance of finding veins of native platinum. One good page explaining what all of the geological processes mean would be a lot more useful then all of the various descriptions of exploratory mining. [[User:Decius|Decius]] 22:35, 21 May 2009 (UTC)
::That sounds like a great idea.--[[User:Mrdudeguy|Mrdudeguy]] 22:46, 21 May 2009 (UTC)

:::I agree! But I have no idea how to write it. Most of what I know about geology I learned from looking at the raws. Everything else is "OMG, is that a ''rock''?! I've heard of those!" - [[User:Teres Draconis|jaz]] 18:59, 22 May 2009 (UTC)

::"More useful" to some, but I agree it would be a great addition. Also, the more I think about it, the more I like what MrDG did with the table in Other Stone - tables could condense any and all small, individual articles into single pages w/ (sortable?) tables where all these various similar objects could be compared/contrasted at a glance. Templates are perfect when there is a lot of various info, but if the different topics (semi-generic stones, animals, finished goods) all differ only in one or two details, and there is just not that many variables to begin with, a Table would be (imo) preferable. ''(And imo that table now covers such stones as Olivine well, to get back to the original example that sparked this discussion.)''

::As an additional example of how current stub-articles could be combined into a simple table, I've made this page - [[Example - some fish]] - which could be a model for such. (A page/table with all the "Sea-creatures" would be more likely approp, but this was faster for now.) It would replace every stub-article on related "generic" items, but any truly noteworthy items would still have their own full articles for expanded information and commentary (here, "carp"). It still has 100% of the prev information, but also allows immediate comparison and contrast, and, if sortable, allows a User to more easily compare relations between similar aspects (like "biome", in this example.)--[[User:Albedo|Albedo]] 00:13, 22 May 2009 (UTC)

::: Is it possible to put the expandable version of the raw ("game object data (show)" seen at the bottom of the [[carp]] page) inside the table, instead of the whole thing? Or does the one preclude the other? - [[User:Teres Draconis|jaz]] 18:59, 22 May 2009 (UTC)

:::Actually, if someone finds it easy to extract that information from the .RAWs, I would find that an improvement on what [[Creatures]] currently has. [[User:Decius|Decius]] 17:52, 22 May 2009 (UTC)

::::If someone here knows PHP they may be able to write a new wiki hook that pulls information from raw entries. That would make many things much easier. [[User:VengefulDonut|VengefulDonut]] 22:22, 22 May 2009 (UTC)

:::Which information do you want extracted? I can probably do it for you, but you may have heard, I'm in the doghouse for not paying attention to style and formating rules. =/ Show me what there is, and one example of what you want, and I can probably do it for you with a minimum of stupid questions. ... ''Probably.'' - [[User:Teres Draconis|jaz]] 18:59, 22 May 2009 (UTC)

::::@ jaz, Dec - Did either of you look at this sample table? [[Example - some fish]] Does that cover what you were envisioning? It's just a rough idea - but it could work the same way that the table on the [[stone]] page currently does, to cover all the generic, almost-identical objects. Same w/ finished goods, weapon traps, probably many other sim categories of like items.--[[User:Albedo|Albedo]] 22:52, 22 May 2009 (UTC)
I've read this sort of. My view is, wikis add value to the game far more for noobs than they do to legends who have been around since when the z-axis was just an idea. With this in mind, I reckon if everything with a name in the game had an article that would be *A Good Thing* (tm). Just my own opinion, feel free to disagree. Ideally, articles for things like stones should contain a template constructed from the raws, with prose/dialogue manually added.
Even things like [[screw pump]] could have a template driven section, advising what the components are / who makes it etc. Maybe <nowiki>{{building|Building Name|Component 1:Component 1 name|Component X| component X name|Constructed by|trade}}</nowiki> or similar.[[User:GarrieIrons|GarrieIrons]] 08:45, 30 May 2009 (UTC)

:I agree, probably, although that sounds like a lot of work. I think the stone templates and articles could do with a bit of a cleanup and more in-game information. I mostly use the articles to see if there's anything notable about a particular stone and then check out the wikipedia page. Some of the wikipedia links are broken or indirect now because disambiguity pages have been added since. Also, the wikipedia links are right at the bottom of very long boxes listing ores and gems and the like - I suggest adding drop down boxes to the templates that contain all that information but which are minimized by default. Or changing the template so that the wikipedia link wraps around the stone name at the top. --[[User:Harmonica|Harmonica]] 01:36, 2 July 2009 (UTC)

Way late to this party, apologies. Tables are no good (to me) if they aren't sortable. The World Ends With You (a Nintendo DS game) Wikia portal/wiki thing has an ''awesome'' method for adding sortable tables. Some gadget called [http://en.wikipedia.org/wiki/Semantic_MediaWiki Semantic MediaWiki] that hooks into the Wiki to automatically pull data out as you request it, then display it in easy-to-read and use sortable tables. The TWEWY Wikia has [http://twewy.wikia.com/wiki/The_World_Ends_With_You:Semantic_MediaWiki a page on it] for their editors, giving a few examples of how powerful it is. Their use of the tool is to easily pull information from a table of 304 items, each containing 30 attributes, to generate lists comparing and compiling various items. Hugely powerful, extremely flexible.

This type of tool would work wonderfully with a PHP RAW parser, or even simple dumps of the RAWs to the Wiki. Think of how easy it would be to update the entire Wiki across the board when new versions come out. New critters? Changes to existing critters? Update the information in one spot and it trickles down through the entire Wiki! That's in addition, of course, to being able to, say, generate tables listing how many bones each creature drops when killed, then sort to see which one drops the most. Pretty sweet stuff.

With some sort of system in place for wading through all the data on the wiki, one wouldn't have to worry about having too much information, right? -- [[User:Blank|Blank]] 04:44, 3 July 2009 (UTC)

Particularly for stone, I think that it would be a good idea to describe each individual stone relative to other, similar stones. Let's use [[sandstone]] as an example. Suppose that I read (either in its own article, or in a table) something along the lines of "Sandstone is a [[sedimentary]] layer. Unlike most sedimentary layers, it may contain [[aquifers]] or veins of [[native copper]]." If I already know what a sedimentary layer is (and how it differs from other types of layers), this information will be much easier to process and much more useful than a full list of everything that appears in sandstone. If I have no idea what a sedimentary layer is, this will tell me that there are several sedimentary layers and that they all have many things in common, which is again more useful than a list of everything that appears in sandstone. --[[User:LaVacaMorada|LaVacaMorada]] 08:56, 2 October 2009 (UTC)
:That's not the way this (any?) wiki is set up. The idea is that a lesser concept (here, "sandstone") need not include redundant info from a larger, parent concept (here, "sedimentary layer"). If you don't know what a sed'y layer is (or an aquifer or a vein or whatever) you click that link. If, then, you don't know what a "layer" is, you click that link. Sounds good at first, but if every lesser article included an explanation, even a quick synopsis, of the info for all relevant articles on broader, umbrella concepts, the articles, and this wiki as a whole, would explode beyond usefulness. --[[User:Albedo|Albedo]] 23:43, 2 October 2009 (UTC)
::Thanks for making my point for me. If you look at the current sandstone article, it lists everything contained in sandstone. Looking at just the ores and non-generic stones, we have: Native copper, Hematite, Limonite, Magnetite, Native platinum, Tetrahedrite, Bituminous coal, Lignite, Bauxite. All of these except for native copper appear in every sedimentary layer. That's not even counting all of the generic stone (especially gypsum with its five other types of generic stone contained in it) and (mostly low-value) gems. 95% of the text in this article is redundant, and could easily be summarized by "This layer is exactly like every other sedimentary layer except for these two differences". --[[User:LaVacaMorada|LaVacaMorada]] 09:06, 6 October 2009 (UTC)
:::Ah - ''that's'' your point. (When you said "describe", I thought you were advocating a narrative commentary on and verbal expansion of the info included in the sidebar.) When I was talking about not having redundant info, I was talking text - which is quite terse in this case, exactly because of the point you make. Those sidebars were designed to encapsulate the key info, an "at a glance" sort of thing, to avoid exactly what you're talking about in narrative form. Are the sidebars redundant? Often, yes. But they are the style this wiki has adopted for ''all'' stone. So you're talking not just about changing sed'y layers, but the style approach to all stone, since they would not then be consistent across the board. (Not how I would have personally designed the layout, but it's there and it works, and well. Any stone, same layout, same info in the same place, bam got it.) And when discussing presentation and usability issues, any article has to be taken both individually and in the context of others "like" it - here, any "stone" article is the same layout, the same info at a glance, which (for now) trumps whatever redundancies exist. Perhaps a quick line such as you're stating would go well, since there is, indeed, very little unique to say about any one sub-type of sedimentary layer, and that is info in and of itself. (Take a look at any [[igneous extrusive]] except obsidian for something similar.)--[[User:Albedo|Albedo]] 16:46, 6 October 2009 (UTC)

A lot of people have been talking a lot of things about reorganizing the information on the stones pages. After browsing around on them for a while, I've found the information to be mostly scattered and difficult to draw conclusions from. For example, I wasn't aware that each geographic stone type had a base list of stones that can appear, while only some of them have a couple of unique stones that may appear along with that list. It wasn't until I began gathering all of that data together for myself, that I found the patterns. I had to work to tie it all together. So, I have a partially completed table of pulldown menus on my user page right now. If anyone's interested they could take a look and tell me what they think? (Yes, I know a lot of it is redundant. I have an idea on how to fix this, but I haven't completely decided yet) --Kydo 13:55, 25 October 2009 (UTC)

Lumping all the generic stones into one page is pretty much a labor saving device. There are a lot of different stones in DF most of which have no real differences other than color. So in one respect, I do see reasoning for saving some effort and dumping them in one place. On the other hand, it would be useful to me to see slightly more detailed information about each of the colored stones, for example, I know alunite looks a certain way before it is mined out, it's general color is bright white, when used to build trap components it is bright white in both the on and off position (many stones go to dark in the off position). In the same vein, when used to build tables and chairs, both will be bright white (many stones go to dark for chairs). If you're looking for a "certain look" and want to know a tiny bit more about the stone colors at present, that information simply isn't here as things are now. [[User:Doctorzuber|Doctorzuber]] 16:21, 5 April 2010 (UTC)

== Not a Roguelike ==

Dwarf Fortress only resembles a Roguelike in the sense that everything kills you. ASCII graphics haven't connoted Rogue-resemblance since Diablo came out with modern 3D graphics and was still considered a Roguelike.
[[User:LogicalDash|LogicalDash]] 22:08, 5 August 2009 (UTC)

I agree with you for Fortress mode, but adventurer mode is rogue like.--[[User:Mjo625|Mjo625]] 22:54, 5 August 2009 (UTC)

:DF is rogue-like like.[[User:GarrieIrons|Gar]][[User Talk:GarrieIrons|rie]] 08:59, 2 September 2009 (UTC)

LogicalDash, Diablo is in 2D, not 3D. --[[User:612DwarfAvenue|612DwarfAvenue]] 05:10, 27 November 2009 (UTC)

What makes a rogue-like? too classic a question to pass up . ahem IMHO there three major elements, A dungeon crawl/ fantasy setting, ASCII and random as hell. That makes dwarf fortress three outta three hits for me. Close enough, i'd say, if it's not a rogue-like what other category could it go in? sure its not a great fit but a unique game has to go somewhere. Diablo is a dungeon crawl like rogue sure, but it lacks the depth and randomness of any of the other recognised roguelikes, ADOM, moria etc. So one outta three? The depth, randomness and spontaneity really make it, ever had a character eaten by a bear on the way to the village in ADOM? classic. --[[User:Pedantictype|Pedantictype]] 05:46, 20 March 2010 (UTC)
:I'm afraid I have to disagree with you, Pedantictype. A Rogue-like is defined by the original: Rogue. Rogue was, first and foremost, a dungeon-crawl with control of a single character, yes? I would postulate that that is one of the elements that is required to be defined as a rogue-like, which qualifies Adventure mode but not Fortress mode. --[[User:Eagle0600|Eagle0600]] 05:04, 5 April 2010 (UTC)
::Eagle's right. A roguelike game plays somewhat like Rogue and has ascii graphics. Fortress mode DF is a tactical/strategic/sandbox ascii game, not a roguelike. And isn't there general intent for it to have graphics one day, once it's out of the design stages? --Kydo 01:58, 8 April 2010 (UTC)

== Link to Add Quotes ==

To get help on how to add quotes to the main page, consult [[Talk:Main Page/Quote|this]] link.

== Incoming New Version ==

Guys. We might as well prepare for the new version that will be coming by the end of the year (maybe). What will need to change? Weapons and armor, the underground stuff... I don't know all of it. But it's extensive. Get ready.--[[User:Zchris13|Zchris13]] 17:02, 7 October 2009 (UTC)
:Well, we don't know all the details, and names of jobs/items can change before actual release. [[User:Kurokikaze|Kurokikaze]] 16:14, 8 October 2009 (UTC)
:I don't see what this has to do with anything, i guess it's nice of you to tell us. But what do you mean "get ready?"
: Gird your loins, gentlemen. Or something.
::It'll be hard to cover every page - if you edit, try to follow up on links, etc. Might also have to check the "oldest pages" listing to see that they've all been updated (except it's broken atm). The worst currently is that we ''still'' have legacy crap from earlier versions in obscure corners and comments that's not relevant to current version. Bonus.--[[User:Albedo|Albedo]] 06:11, 19 October 2009 (UTC)
:This might be useful: http://docs.google.com/Doc?docid=0AT8EQVUjrv96ZGc5cnBwOHZfMjgyY3FzZHFtanA&hl=en
:Are we just changing this wiki? (as opposed to forking with the new version, in case some people keep playing 40d?) [[Special:Contributions/206.45.111.58|206.45.111.58]] 22:39, 9 December 2009 (UTC)
::Forking sounds good to me. But I have no idea how well wikis handle forking. --[[User:Nahno|Nahno]] 14:11, 17 December 2009 (UTC)
:::In any case I think it would be a good idea to updated articles as is, and not wipe them out like in the wiki's switch to 3d which simply wiped out a lot of good information along with outdated text. Forking is a good route to take if people don't want to lose 40d inforamtion. [[User:Richards|Richards]] 19:40, 26 January 2010 (UTC)

== Interwiki ==

Correct link to Russian DF wiki, please.
Right link = www.dfwk.ru instead current www.dfwiki.ru --[[Special:Contributions/91.192.82.106|91.192.82.106]] 11:43, 4 December 2009 (UTC)
:It's done, so should we delete this conservation? (not that great at wiki myself) [[User:Inawarminister|Inawarminister]] 09:46, 7 December 2009 (UTC)
::They get archived at some point, so no need. [[User:Mason11987|Mason]] ([[User talk:Mason11987|T]]-[[Special:Contributions/Mason11987|C]]) 00:33, 15 April 2010 (UTC)

== Random page ==

Why is "Random page" only bringing me to "Count Consort"? :\ --[[Special:Contributions/99.33.67.9|99.33.67.9]] 22:33, 15 January 2010 (UTC)
:It seems "Random page" is only random daily... Is this intentional? --[[Special:Contributions/99.33.67.9|99.33.67.9]] 20:31, 2 February 2010 (UTC)
::There's probably something wrong with your browser cache settings - it works fine for me. --[[User:Quietust|Quietust]] 20:37, 2 February 2010 (UTC)

== Random images ==

Where are the images on the main page coming from? It's easy to find the quotes, but where are the images? [[User:MC Dirty|MC Dirty]] 15:14, 17 January 2010 (UTC)

:I have an image I'd like added... I'll put it on my userpage if anyone wants to take a look at it and see if it's acceptable for uploading. --[[User:Waladil|Waladil]] 06:40, 21 February 2010 (UTC)

== New Category Idea - Well Known Dwarves ==

After reading some stories on many of the most awesome dwarfs to show up in this game. (Namely Captain Ironblood, Morul, Tholtig) That a category, perhaps a sub one to Humor and Stories just for Dwarves that are very very clearly above the normal for the already outrageous(ly awesome) game of Dwarf Fortress. However do to the fact this is less on the game mechanics and such, the idea is first here so other's can figure if it's worth having a category. One thing that comes to mind is there really should be some sort of limit to what makes a Dwarf and Epic/Well Known Dwarf so as to prevent people from putting everyone they liked up there rather then the few '''everyone''' likes. Mostly asking as there is a handful of such dwarfs and that number is only going to (slowly) grow. Each said Dwarf I think deserves some sort of noting on a page for my two cents on the topic.
:I definitely thing that this is a great idea in the true spirit of DF.
::These should of course go under D for Dwarf.

== Images ==

So, what does everyone think? Would it be a good idea to have real-world images (or possibly sketches for fantasy, if applicable) of the following:
* Trees
* Fish
* Land animals
* Weapons and armor
* Stones
* Ores
* Land features (desert, savannah, etc.)
* Gems
* Metals
* Plants
We already have two pages with example images for a [[Pike_(weapon)#Pike|weapon]] and a [[Sandstone|stone]] for example. I find this very nice for visualizing my fortress and what's going on, since I'm not very familiar with many of the distinctions DF makes. I mean, I know what a fish looks like but I haven't got a clue what the difference between a pike and a char is, or a birch and alder, or even bronze and pewter to be honest.--[[User:Ar-Pharazon|Ar-Pharazon]] 22:42, 6 February 2010 (UTC)
:The normal issues with this kind of thing is REAL-WORLD publishers being annoying with copyright. I guess if we can find it from the real-world wiki then there is a good chance it is a public domain image.
:There is no way in the world it would hurt an article to have one of these. Although, for fantasy objects, materials, and creatures, there may well be some discussion about if the "Dragon" should be a European, Oriental, or some other dragon (and so on for the rest).
:[[User:GarrieIrons|Gar]][[User Talk:GarrieIrons|rie]] 11:52, 7 February 2010 (UTC)
::Well, I've added pictures to some of the layer stones and vermin, as well as all the ores. If anyone is interested, you can link to files on wikimedia commons as if they were internal files now.--[[User:Ar-Pharazon|Ar-Pharazon]] 04:52, 8 February 2010 (UTC)
:::What if those of us with artistic skills were to produce original content for such pages? For example, I could easily do a few drawings depicting certain fantasy creatures as well as actual creatures. --Kydo 22:56, 24 February 2010 (UTC)
::::I don't see how that could even remotely hurt at all.--[[User:Ar-Pharazon|Ar-Pharazon]] 15:21, 12 March 2010 (UTC)
::Who says that the 'Dragon' as a creature isn't a generalization of any species? To be honest, with the graphics as they are, I think that most of Dwarf Fortress comes down to the way the user imagines it, rather than how it appears on screen. Rather like the old text based adventure games of old.--[[Special:Contributions/85.12.64.150|85.12.64.150]] 10:18, 4 March 2010 (UTC)
:::Whoever you are, that is why i don't use a tileset.[[User:GarrieIrons|Gar]][[User Talk:GarrieIrons|rie]] 06:15, 6 March 2010 (UTC)
:As a rule of thumb, "graphics" are good things - eye candy, if nothing else. Purty. Use common sense and discretion when choosing (or creating) the image - avoid genre-specific images or anything that is copyrighted (like from an identifiable RPG, for instance), and perhaps add "artist's interpretation" under it, or a selection of (smaller) different images for something like a dragon (tho' I, personally, don't see dwarves with oriental dragons - ymmv.) --[[User:Albedo|Albedo]] 08:49, 6 March 2010 (UTC)
::Seeing as how this is a wiki and what not, why not simple add a western dragon, and if anyone objects to the bias they can add an oriental dragon, so we have two pictures and not only both sides are happy but everyone gets more pictures to look at?--[[User:Ar-Pharazon|Ar-Pharazon]] 15:21, 12 March 2010 (UTC)
:(Also, if you're interested enough to post in the Main Page Discussion, you might want to get an account. Meh.)--[[User:Albedo|Albedo]] 08:49, 6 March 2010 (UTC)

== No link to World Generation? ==

Home page needs a link to World Generation. I thought of adding it, but didn't want to upset the delicate symmetry happing in the menus. Thoughts as to where it could go? [[Special:Contributions/118.208.7.232|118.208.7.232]] 04:25, 19 February 2010 (UTC)

== Namespaces ==

As the subject has been mentioned on the forum:
some articles have been moved to a new 40d namespace. This is intended to make way for the "main" namespace to be reserved for the "current version", which ''real soon now'' will be DF2010.
For the full discussion see [[Dwarf Fortress Wiki:Versions]] and the talk page.
[[User:GarrieIrons|Gar]][[User Talk:GarrieIrons|rie]] 10:32, 8 March 2010 (UTC)

Then bloody well move them. These blank 40d pages are making finding information that is supposed to be there very hard to find.

:Agreed..Plus I dont understand the site announcements so i pretty much can't contribute to the wiki right now. Hope you got a stable team to help and are done with it soon. Oh, and a better explanation would be great of course. --[[Special:Contributions/92.202.120.234|92.202.120.234]] 00:10, 4 April 2010 (UTC)
::When is the moving of things to the main namespace going to be complete? Having everything in DF2010 namespace is horribly annoying, and the 40d namespace screws up searches and makes it harder to find stuff via google searches and such. How long is it going to take to get the wiki fixed to the current version, delete all the old d40 stuff, and get rid of the namespaces? --[[User:Aquillion|Aquillion]] 03:40, 7 April 2010 (UTC)

== Tutorials clutter ==

Currently we have in the first box:
*About Dwarf Fortress
*'''Tutorials and guides'''
*'''Quickstart guide (recent)'''
*'''Frequently Asked Questions'''
*'''Your first fortress'''
*'''Video tutorials'''
*'''Important advice'''
*'''Indecisive's Illustrated Tutorial'''
*'''Get help from online chat'''
*Game development
*'''Non-Dwarf's Guide to Rock'''
*'''Starting builds'''

Bolded are the ones I think are redundant. Basically, we have the following categories of stuff:
*Tutorials for newbies: Step by step instructions where you follow what the guide says, without necessarily understanding why right away.
*Guides for newbies: General explanations of game concepts, such as z-level, how to set labors, how to farm, how to work the interface and install a graphical tileset, what the aim of the game is, etc.
*Guides for advanced players: These assume you know how to play the game, and are concerned with optimizing/pushing strategy. Embark build discussions which go beyond explaining the bare minimums you should take (such as "don't embark without a pick!", intended for newbies who may not know what they are doing), megaprojects, combat mechanics, computing, farming strategies, defense strategies, design strategies, macros, world generation parameter discussion and the like.
*FAQ, bugs and troubleshooting: The index of known problems and what to do about them, for when you have a clear question you want to figure out. This includes the FAQ, IRC channels and bugs to watch out for.
That makes 4 categories. Currently, we have 10 categories dealing with the same things. Moreover, the current break down makes no sense, and is obviously not maintained (I think that quickstart guide has been "recent" since early last summer). It's becoming confusing for the clueless first time player who was just linked to Bay12 and the wiki on a forum, and left to fend for itself. In fact, ideally, the tutorials and newbie guides should also be sorted from short to long, with datestamps.

I would rearrange the box myself, but I thought I'd ask what everyone else is thinking first. By the way, are there any tutorials for DF2010, or plans to write any? --[[User:Ar-Pharazon|Ar-Pharazon]] 02:07, 4 April 2010 (UTC)
::By the way, my proposal is to have the box look like this:
::'''Help with Dwarf Fortress'''
::*About Dwarf Fortress
::*How to set up and play Dwarf Fortress (Tutorials)
::*General game information (explanation of basics)
::*Advanced strategies (for experienced players)
::*Troubleshooting: FAQ, where to ask for help, known bugs and issues
::*Game development
::--[[User:Ar-Pharazon|Ar-Pharazon]] 02:14, 4 April 2010 (UTC)

::If [[40d:Quickstart guide]] is obsolete, you should definitely remove the links to it from the front page (both "Your first fortress" and "Quickstart guide" end up there). As a new player pointed at this wiki by the game, I wasted twenty minutes trying to load in the save game (was I being unlucky, or does it simply not work with the new version?) and gave up on trying to play Dwarf Fortress, as a result. --[[User:Gritspeck|Gritspeck]] 16:45, 12 April 2010 (UTC)

:I'm all for this, this is a terrible organization. I like your plan. Given further agreement (or at least no opposition) I say go for it. [[User:Mason11987|Mason]] ([[User talk:Mason11987|T]]-[[Special:Contributions/Mason11987|C]]) 00:38, 15 April 2010 (UTC)

Well, I went ahead and did my best.--[[User:Ar-Pharazon|Ar-Pharazon]] 22:13, 28 May 2010 (UTC)

:I think the frontpage would benefit from highlighting a couple well-written and important pages as well. A "featured article," perhaps. --[[User:Falldog|Falldog]] 01:16, 6 June 2010 (UTC)

::I think it does highlight important pages. See the blue boxes. A 'featured article' would (further) clutter the front page while not being of any value to viewers of the front page or users of this wiki in general. --[[User:Nahno|Nahno]] 17:33, 6 June 2010 (UTC)

::: Let me rephrase. The main page would benefit from the inclusion of links to the most often used reference pages (like the stone summary and the metal summary) than the section on "Playing Dwarf Fortress." It is redundant as there is already a Newbie section and an Advanced tutorials section. I think we agree about that. --[[User:Falldog|Falldog]] 21:22, 7 June 2010 (UTC)

== New modding guide ==
I'm not really sure what the process is for new guides and tutorials. I figured it would be of general community interest, so I'm posting this here; [[User:Tfaal/The Complete Dorf's Guide to Bodies]] --[[User:Tfaal|Tfaal]] 16:43, 5 April 2010 (UTC)

==Bug listings on the Wiki==
Given that the version number is expected to be changing quite rapidly in the near future as bugs are caught and killed, I think it's a good idea to always keep a version number associated with any bug reports we migrate into the wiki pages. This will hopefully minimize confusion as updates gradually remove these. If we could get one of those mini-version tags to use for this purpose or if someone can explain to me how to use that half-sized font for this purpose that would be helpful. Thanks. [[User:Doctorzuber|Doctorzuber]] 16:23, 6 April 2010 (UTC)
:There is already a template for this: [[Template:Version]]. You use it as follows.
:<nowiki>Example.{{version|0.23.130.23a}}</nowiki>
:results in:
:Example.{{version|0.23.130.23a}} --[[User:Soy|Soy]] 16:44, 6 April 2010 (UTC)
:: Thank you, that is all I needed. [[User:Doctorzuber|Doctorzuber]] 17:54, 6 April 2010 (UTC)

== What happened to the link to the dev changelog? ==

There used to be a link to the changelog and a link to the 31_01 release information, but now there's just a link to the release information labeled "changelog." Also the main page appears to use a funny template or something so the link's messed up throughout all of the mainpage history.
:-That's a link I used almost daily. While I realize I'm an idiot for not just bookmarking it, it is a little disconcerting for it to :be gone. Either way, I've always thought it was one of the most relevant links on the main page—it let's you know where the game :project is at ''right now''.
:Wow, forgot sig and indent. I'm amazing. :P ----[[User:Njero|Njero]] 01:03, 8 April 2010 (UTC)
Found the template in question, figured there was no reason for the changelog link not to be there so I put it back; it seemed like it was removed by mistake anyway. Also renamed the link to the release information so there wouldn't be two links entitled "changelog." --[[User:Untelligent|Untelligent]] 02:22, 8 April 2010 (UTC)

==Announcements Hider==
The announcement-hiding script on Briess's page no longer works--it's checking the contents of an id that no longer exists. Replacing the conditional with collapseTable(0) works, but sidesteps the original intent of the conditional, which I presume is to display the options if they've changed since last visit. Does that functionality still apply? While we're at it, is it possible to assign a named value to the collapsible table, so that it can be collapsed without referring to its position relative to other collapsible tables (which breaks the hider script on certain skins)? -[[User:Slitherrr|Slitherrr]]

==How will merging/splitting topics work for backward compatibility linking==
I got thinking about this when helping work on the military pages, we're branching this out into squads/military/schedule/etc. because of how much more complex things have suddenly got with the military system. It was a natural direction to take things. What's the correct way to handle backward compatibility links in this situation? And now that I'm thinking about it, how about page merging? If we decide to merge anything how will that be handled? [[User:Doctorzuber|Doctorzuber]] 03:59, 9 April 2010 (UTC)

== Game object date boxes ==

These boxes on the creature pages need some kind of text formatting to stop them expanding to far. Just an example try the [[dog|dog]] page. --[[User:AKAfreaky|AKAfreaky]] 12:54, 11 April 2010 (UTC)

== Carrying over saved games? ==

Hi, is it possible to carry over savegames from one version to the next, and if so, how do I do this? Thanks [[User:EddyP|EddyP]] 10:27, 13 April 2010 (UTC)
:It is possible - go to the /data folder and just copy the file called "save" to the /data folder in the new DF. You'll then have to edit the raws in each region folder (inside the save folder) to match the new raws in the main /raw folder (or just copy them over). --[[User:AKAfreaky|AKAfreaky]] 20:22, 13 April 2010 (UTC)
::As long as the "different versions" are within the same "generation" of Dwarf Fortress (i.e. 0.21 thru 0.23, 0.27 thru 0.28, or 0.31), this'll work. If you actually try to copy a saved game from 0.28.101.40d to 0.31.xx, expect it to fail in a very spectacular way. --[[User:Quietust|Quietust]] 20:51, 13 April 2010 (UTC)

==Quote wrong on main page==
The quote on the main page comes up with something to the effect that you cannot milk creatures. This was true for 40d, but not for the most recent edition.--[[User:Kwieland|Kwieland]] 12:23, 21 April 2010 (UTC)
: ''"The alert statuses (i.e., "Stay Indoors") have been entirely redone. You may set several custom alerts with user defined scheduling."''
: Is this really intended to be a main page quote? I thought the main pages quotes were usually . . . funny. [[User:Doctorzuber|Doctorzuber]] 02:38, 27 April 2010 (UTC)

== "Your ad here, free!" ==

What's up with another ad space on the bottom of every page? We're getting to a point where more ads just cause more annoyance, not more profit. {{unsigned|213.157.252.41}}
:There are ads? Where? *turns off adblock* OH HOLY CRAP *quickly turns adblock back on* Yeah, if there are more ads than page it kinda defeats the point doesn't it? [[User:Volatar|Volatar]] 14:00, 5 May 2010 (UTC)
::The ad stuff is trying to get a baseline for different types of ads. We're hoping the button ads perform well enough that we can get rid of the larger banner ads. In 5 or so days the number of ads will decrease depending on what we find. [[user:Emi|Emi]] [[user_talk:Emi|[T]]] 20:31, 5 May 2010 (UTC)
::Also, the "free" part is that ads with no bids can be obtained freely, but that'll disappear in the next few days as the ads establish a page view trend. (Which is why in 5 or so days we'll be getting rid of some ads.) [[user:Emi|Emi]] [[user_talk:Emi|[T]]] 20:33, 5 May 2010 (UTC)
:::Good enough. Thanks for the explanation! {{unsigned|213.157.252.41}}

::There are ads?? *switches to IE* oh, yeah, ads.. *switches back to opera* --[[Special:Contributions/92.202.79.42|92.202.79.42]] 11:48, 9 June 2010 (UTC)

== "The wiki currently has 3 articles. " ==

I'm assuming this has something to do with the recent namespace thing? --[[Special:Contributions/217.132.92.69|217.132.92.69]] 10:27, 6 May 2010 (UTC)
:Haha, yes, I'll get right on that. [[user:Emi|Emi]] [[user_talk:Emi|[T]]] 18:04, 6 May 2010 (UTC)
::Looks like someone beat me too it. :( [[user:Emi|Emi]] [[user_talk:Emi|[T]]] 18:05, 6 May 2010 (UTC)

== Quality ==
I really like how the bar is counting down to zero. Keep templating, rawing and tableing all you want, eventually you will have to face the truth: to make a helpful wiki you need to ''play'' the game and add ''content''. --[[Special:Contributions/68.161.167.37|68.161.167.37]] 02:09, 9 May 2010 (UTC)
:What are you objecting to? Someone said it would be a good idea to know "how close to 'complete' the wiki is", we did that. If you don't like it then you don't have to look at it. I'd also like to ask why you think you have such a right to critisize others work after your... 3 edits? [[User:Mason11987|Mason]] ([[User talk:Mason11987|T]]-[[Special:Contributions/Mason11987|C]]) 17:26, 10 May 2010 (UTC)
::I think the big problem is that the vast majority of 40d pages are still completely accurate or near-completely accurate to the new version, but little to no effort has been made to port them over. Now that the latest version has been out for a while, I think it's reasonable to say that it's obvious that 'nuking' the 40d version by forcing it into a separate namespace instead of just trying to update it normally was a terrible mistake -- as was setting up this wretched namespace system, given that this is intended to be the ''last'' such gap between releases. The change from 40d to 2010 wasn't nearly as sweeping in terms of underlying mechanics as some people on the Wiki thought it would be -- but now, because of the way the changeover was mishandled here, we're left basically rewriting or copy-pasting a bunch of pages for stuff that hasn't changed, and nobody actually wants to waste time doing that when perfectly good and accurate articles exist in 40d namespace. Look at [[Animal Trap]], say -- the 40d version is detailed and near-perfectly accurate to DF2010, while the DF2010 version is barely more than a stubby paragraph. This happens all over the place, because people were eager to rewrite (or create) the articles related to stuff that changed, but nobody wanted to waste time rewriting all the relatively accurate articles that were mindlessly pushed into a separate namespace in the botched shift. --[[User:Aquillion|Aquillion]] 16:51, 9 July 2010 (UTC)

== Legacy? SDL? ==
Could someone explain the difference between the legacy and SDL releases? Seems that information ought to be around here somewhere. Can't seem to find it if it is. --[[User:Doctorzuber|Doctorzuber]] 00:12, 21 June 2010 (UTC)
:From my guess, Legacy is the old version (without SDL), and the SDL... well you get it. --[[User:Hugna|Hugna]] 03:55, 21 June 2010 (UTC)
== New website==
I've got a new website up and running with drupal. It is about dwarf fortress and you can find it [http://darkcloudterrace.dyndns.info/drupal6/ Here darkcloudterrace] it has a forum for dwarf fortress

== Download Mirrors Working or Broken ==

I can't seem to download df_31_13 from any of the three mirrors on the front page. Is anyone else having a problem with them?
--[[Special:Contributions/208.81.12.34|208.81.12.34]] 12:55, 16 September 2010 (UTC)

== Unworthy Self-link ==

Would it be improper to add a link to [[Bentgirder]] on the home page?

== Dwarf Forttress Wiki Portable ==
Hello all.
I'm building a portable, well somewhat portable, version of the Dwarf Fortress Wiki site. It is being made with Personal Brain (www.thebrain.com) and I will be importing everything I can find.
Admittedly I will need some help with this project. Any volunteers?--[[User:SpyMaster356|SpyMaster356]] 20:58, 4 October 2010 (UTC)

And another note: The finished "Brain" can be used as a navigator for this wiki too.--[[User:SpyMaster356|SpyMaster356]] 21:00, 4 October 2010 (UTC)

v0.31 Talk:Ramp

2010-05-06T03:07:27Z

Quatch: Suggestion for further content.

Looks like someone just copied over the 40d stuff. Most of it is OK, but the section on Channeling vs ramps is not right.--[[User:Kwieland|Kwieland]] 13:42, 22 April 2010 (UTC)

:I'm on this. --[[User:Zombiejustice|Zombiejustice]] 14:22, 22 April 2010 (UTC)

When channeling over empty space miners may stand in the tile being channeled, falling to their doom. Perhaps a (bug) caution is warranted? Details: http://www.bay12games.com/dwarves/mantisbt/view.php?id=826 I lost 6 miners to this before I figured out why...

User:Quatch/monobook.js

2010-04-17T03:43:58Z

Quatch: Created page with 'importScript('User:Briess/hideAnnouncements.js');'

importScript('User:Briess/hideAnnouncements.js');

v0.31:Shell

2010-04-05T00:59:39Z

Quatch:

Shell no longer comes from cooking and eating prepared shell-bearing food (as in 40d), but from preparing the fish/turtle at the fishery.

(as far as I've seen it doesn't come via caravan because of this.)

v0.31:Shell

2010-04-05T00:59:00Z

Quatch: Created page with 'Shell no longer comes from cooking and eating prepared shell-bearing food (as in 40d), but from preparing the fish/turtle at the fishery.'

Shell no longer comes from cooking and eating prepared shell-bearing food (as in 40d), but from preparing the fish/turtle at the fishery.

User:Quatch

2009-08-13T19:55:43Z

Quatch: Created page

Longtime player, active on the forum, decided to start contributing to the wiki instead of just answering questions in the gameplay forum. Please excuse my wiki syntax, not really up to speed on it.

==Current Fortress==
Playing on the dwarf heaven site, DFd11, mac version with Mayday tileset.

Manged to loose all liasons, both GCS, and the king. Otherwise everyone is happy.

==Mods in play==
(links to come eventually)
Orcs!
Accurate melting points (yay Alunite!)
Tempered glass (with most of it cut out)
Roughen blocks/gems

40d Talk:Crossbowman

2009-08-12T03:23:34Z

Quatch: /* Starting stock */

Added a bit on training issues, as it gets asked about on the forums twice a week or so. The link to crossTraining isn't quite right, can anyone find the article on weapon-skill multi training?-- [[User:Quatch|Quatch]]

Why do you think this info can't just be kept on the [[crossbow]] page? --[[User:Juckto|juckto]] 00:55, 14 December 2008 (EST)

:It's not consistent. All of the other weapon skills have individual pages. Presumably, they could all be merged into [[weapon]] or their respective weapon articles, but that seems like a worse solution. The weapon skill and the weapon itself are different things. Also, [[crossbow]] seems a bit cluttered with non-crossbow info. Related topics are usually handled with links. [[User:VengefulDonut|VengefulDonut]] 01:11, 14 December 2008 (EST)

::IMO there are several areas in this wiki where the information is spread over too many "related pages" - in fact that's why I wrote [[clothing industry]], because I was frustrated trying to search everywhere for what to do next. But you have a point with [[crossbow]], so I removed everything except bolts and quivers. --[[User:Juckto|Juckto]] 18:18, 14 December 2008 (EST)

:::What is a category of stuff that you think has too much page splitting? We can have it both ways, actually. Both individual item articles and larger compilations. Like the way the stones are set up. [[User:VengefulDonut|VengefulDonut]] 22:04, 14 December 2008 (EST)

==Starting stock==
Inaccurate; I don't believe embarking marksdwarves start out with a bolt/crossbow stock. That'd be ambushers. – [[template:unsigned|unsigned]] comment by [[User:LucienSadi|LucienSadi]]

:I tested this recently; having weapon skills did not give embarking dwarves weapons, but ambusher did give them a crossbow, bolts, and some armor. However, I can't remember if I tested marksdwarf. Nonetheless, I believe LucienSadi is correct here. I'll remove the line from the article for now and double-check it later.--[[User:Maximus|Maximus]] 10:57, 15 December 2008 (EST)

As I recall, you get equipment if the weapon skill is your highest starting skill? --[[User:Quatch|Quatch]]

=="and embarking"?==
Embark means to leave - are dwarves leaving the fort now? I'll admit I've never played a single fort for a long period. --[[User:Juckto|Juckto]] 18:27, 14 December 2008 (EST)

:I think it refers to those you embark with. [[User:VengefulDonut|VengefulDonut]] 22:00, 14 December 2008 (EST)

== Armor ==

Will wearing plate armor reduce the accuracy/damage of Marksdwarves? If so, does the Armor User skill reduce this penalty? --[[User:Aethios|Aethios]] 21:40, 23 March 2009 (UTC)

:It won't reduce the accuracy or damage per shot. However, encumbrance might slow down rate of fire, and armor user would alleviate that encumbrance. --[[User:LegacyCWAL|LegacyCWAL]] 15:28, 24 March 2009 (UTC)

40d Talk:Crossbowman

2009-08-12T03:21:59Z

Quatch:

Added a bit on training issues, as it gets asked about on the forums twice a week or so. The link to crossTraining isn't quite right, can anyone find the article on weapon-skill multi training?-- [[User:Quatch|Quatch]]

Why do you think this info can't just be kept on the [[crossbow]] page? --[[User:Juckto|juckto]] 00:55, 14 December 2008 (EST)

:It's not consistent. All of the other weapon skills have individual pages. Presumably, they could all be merged into [[weapon]] or their respective weapon articles, but that seems like a worse solution. The weapon skill and the weapon itself are different things. Also, [[crossbow]] seems a bit cluttered with non-crossbow info. Related topics are usually handled with links. [[User:VengefulDonut|VengefulDonut]] 01:11, 14 December 2008 (EST)

::IMO there are several areas in this wiki where the information is spread over too many "related pages" - in fact that's why I wrote [[clothing industry]], because I was frustrated trying to search everywhere for what to do next. But you have a point with [[crossbow]], so I removed everything except bolts and quivers. --[[User:Juckto|Juckto]] 18:18, 14 December 2008 (EST)

:::What is a category of stuff that you think has too much page splitting? We can have it both ways, actually. Both individual item articles and larger compilations. Like the way the stones are set up. [[User:VengefulDonut|VengefulDonut]] 22:04, 14 December 2008 (EST)

==Starting stock==
Inaccurate; I don't believe embarking marksdwarves start out with a bolt/crossbow stock. That'd be ambushers. – [[template:unsigned|unsigned]] comment by [[User:LucienSadi|LucienSadi]]

:I tested this recently; having weapon skills did not give embarking dwarves weapons, but ambusher did give them a crossbow, bolts, and some armor. However, I can't remember if I tested marksdwarf. Nonetheless, I believe LucienSadi is correct here. I'll remove the line from the article for now and double-check it later.--[[User:Maximus|Maximus]] 10:57, 15 December 2008 (EST)

=="and embarking"?==
Embark means to leave - are dwarves leaving the fort now? I'll admit I've never played a single fort for a long period. --[[User:Juckto|Juckto]] 18:27, 14 December 2008 (EST)

:I think it refers to those you embark with. [[User:VengefulDonut|VengefulDonut]] 22:00, 14 December 2008 (EST)

== Armor ==

Will wearing plate armor reduce the accuracy/damage of Marksdwarves? If so, does the Armor User skill reduce this penalty? --[[User:Aethios|Aethios]] 21:40, 23 March 2009 (UTC)

:It won't reduce the accuracy or damage per shot. However, encumbrance might slow down rate of fire, and armor user would alleviate that encumbrance. --[[User:LegacyCWAL|LegacyCWAL]] 15:28, 24 March 2009 (UTC)

40d Talk:Crossbowman

2009-08-12T03:19:14Z

Quatch:

Added a bit on training issues, as it gets asked about on the forums twice a week or so.-- [[User:Quatch|Quatch]]

Why do you think this info can't just be kept on the [[crossbow]] page? --[[User:Juckto|juckto]] 00:55, 14 December 2008 (EST)

:It's not consistent. All of the other weapon skills have individual pages. Presumably, they could all be merged into [[weapon]] or their respective weapon articles, but that seems like a worse solution. The weapon skill and the weapon itself are different things. Also, [[crossbow]] seems a bit cluttered with non-crossbow info. Related topics are usually handled with links. [[User:VengefulDonut|VengefulDonut]] 01:11, 14 December 2008 (EST)

::IMO there are several areas in this wiki where the information is spread over too many "related pages" - in fact that's why I wrote [[clothing industry]], because I was frustrated trying to search everywhere for what to do next. But you have a point with [[crossbow]], so I removed everything except bolts and quivers. --[[User:Juckto|Juckto]] 18:18, 14 December 2008 (EST)

:::What is a category of stuff that you think has too much page splitting? We can have it both ways, actually. Both individual item articles and larger compilations. Like the way the stones are set up. [[User:VengefulDonut|VengefulDonut]] 22:04, 14 December 2008 (EST)

==Starting stock==
Inaccurate; I don't believe embarking marksdwarves start out with a bolt/crossbow stock. That'd be ambushers. – [[template:unsigned|unsigned]] comment by [[User:LucienSadi|LucienSadi]]

:I tested this recently; having weapon skills did not give embarking dwarves weapons, but ambusher did give them a crossbow, bolts, and some armor. However, I can't remember if I tested marksdwarf. Nonetheless, I believe LucienSadi is correct here. I'll remove the line from the article for now and double-check it later.--[[User:Maximus|Maximus]] 10:57, 15 December 2008 (EST)

=="and embarking"?==
Embark means to leave - are dwarves leaving the fort now? I'll admit I've never played a single fort for a long period. --[[User:Juckto|Juckto]] 18:27, 14 December 2008 (EST)

:I think it refers to those you embark with. [[User:VengefulDonut|VengefulDonut]] 22:00, 14 December 2008 (EST)

== Armor ==

Will wearing plate armor reduce the accuracy/damage of Marksdwarves? If so, does the Armor User skill reduce this penalty? --[[User:Aethios|Aethios]] 21:40, 23 March 2009 (UTC)

:It won't reduce the accuracy or damage per shot. However, encumbrance might slow down rate of fire, and armor user would alleviate that encumbrance. --[[User:LegacyCWAL|LegacyCWAL]] 15:28, 24 March 2009 (UTC)

40d:Crossbowman

2009-08-12T03:17:29Z

Quatch: /* Training */ added link to cross-training.

Dwarfs or other creatures armed with [[crossbow]]s deal "[[Weapon#Damage calculation|pierce]]" damage from a long distance. A marks'''dwarf''' will usually open fire at a distance of 20 tiles or so from their target, but a bolt may carry 30 or more*. While also doing decent general [[Weapon#Weapon statistics|damage]], a [[bolt]] does a fine job at piercing the internal organs of a [[creature]], which can possibly cause organ failure and instant death, [[unconscious]]ness or crippling of any size target. This is of limited use against creatures without internal organs, such as [[Magma man|magma men]]. Occasionally a bolt will get stuck in a target; the only known use for this is that a [[wrestling]] dwarf may grab the bolt and twist it in the [[wound]].

: ''(* Note that increase in height (z-levels) ''hurts'' range, rather than helps it.)''

Increasing Marksman skill requires a successful hit upon a target, with "live targets" granting more experience than an [[archery target]]{{verify}}. Higher skill grants better accuracy and higher rate of fire. An archery range is only used by [[military]] dwarves that are off duty, and they will only use [[wood]] or [[bone]] bolts during practice.

A '''marksdwarf''' who is forced into melee will use the [[hammerdwarf]] skill to bash enemies with their crossbow.

[[Immigrant|Immigrating]] marksdwarves bring their own crossbows and 30-40 bolts. Immigrating [[ranger]]s often arrive with Novice Marksdwarf skill, though will only bring a crossbow and bolts if they also have [[ambusher]] skill. (See [[Ambusher]] for more details.)

===Training===
Training marksdwaves leads to a number of obscure problems. Marksdwarves will not equip bolts and practice (or fight) with bolts if they are carrying items in hand. Items get in hand if the marksdwarf has been wrestling, a frequent [[CrossTraining|cross-training]] exercise. The solution is to temporarily set the marksdwarf to use no weapon/armour/shield and set to off duty. This will cause the marksdwarf to drop carried items.

{{Skills}}
[[Category:Skills]][[Category:Military]][[Category:Combat Skills]]
[[Category:Jobs]]

40d:Crossbowman

2009-08-12T03:13:52Z

Quatch: Added the most common forum question about marksdwarf

Dwarfs or other creatures armed with [[crossbow]]s deal "[[Weapon#Damage calculation|pierce]]" damage from a long distance. A marks'''dwarf''' will usually open fire at a distance of 20 tiles or so from their target, but a bolt may carry 30 or more*. While also doing decent general [[Weapon#Weapon statistics|damage]], a [[bolt]] does a fine job at piercing the internal organs of a [[creature]], which can possibly cause organ failure and instant death, [[unconscious]]ness or crippling of any size target. This is of limited use against creatures without internal organs, such as [[Magma man|magma men]]. Occasionally a bolt will get stuck in a target; the only known use for this is that a [[wrestling]] dwarf may grab the bolt and twist it in the [[wound]].

: ''(* Note that increase in height (z-levels) ''hurts'' range, rather than helps it.)''

Increasing Marksman skill requires a successful hit upon a target, with "live targets" granting more experience than an [[archery target]]{{verify}}. Higher skill grants better accuracy and higher rate of fire. An archery range is only used by [[military]] dwarves that are off duty, and they will only use [[wood]] or [[bone]] bolts during practice.

A '''marksdwarf''' who is forced into melee will use the [[hammerdwarf]] skill to bash enemies with their crossbow.

[[Immigrant|Immigrating]] marksdwarves bring their own crossbows and 30-40 bolts. Immigrating [[ranger]]s often arrive with Novice Marksdwarf skill, though will only bring a crossbow and bolts if they also have [[ambusher]] skill. (See [[Ambusher]] for more details.)

===Training===
Training marksdwaves leads to a number of obscure problems. Marksdwarves will not equip bolts and practice (or fight) with bolts if they are carrying items in hand. Items get in hand if the marksdwarf has been wrestling, a frequent cross-training exercise. The solution is to temporarily set the marksdwarf to use no weapon/armour/shield and set to off duty. This will cause the marksdwarf to drop carried items.

{{Skills}}
[[Category:Skills]][[Category:Military]][[Category:Combat Skills]]
[[Category:Jobs]]

40d:Repeater

2009-08-05T15:49:41Z

Quatch: /* Repeater */

A [[Computing#Fluid Logic|fluid logic]] device which creates a neverending cyclic on/off signal. Described on the [http://www.bay12games.com/forum/index.php?topic=33563.msg495183#msg495183 forum] by [http://www.bay12games.com/forum/index.php?action=profile;u=16168 AncientEnemy]

<blockquote>
... River/brook 
WwW Walls, wall to be channeled out after construction 
WBW Raising Bridge (1 tile, direction doesn't matter) linked to plate 
WPD Pressure plate set to 7-7, Door for access 
WFW Floodgate linked to plate 
WWW 
</blockquote>

Useful features:
*Toggles slowly (once every 200 steps or so), which enables things it is linked to to trigger and activate before a new signal is sent.
*Can fill a resivour reliably to 3-4 water, if the bottom wall is removed and dug to a cistern.

40d:Repeater

2009-08-05T15:49:33Z

Quatch: Article created by copying from forum. Excuse my very basic wiki understanding.

==Repeater==
A [[Computing#Fluid Logic|fluid logic]] device which creates a neverending cyclic on/off signal. Described on the [http://www.bay12games.com/forum/index.php?topic=33563.msg495183#msg495183 forum] by [http://www.bay12games.com/forum/index.php?action=profile;u=16168 AncientEnemy]

<blockquote>
... River/brook 
WwW Walls, wall to be channeled out after construction 
WBW Raising Bridge (1 tile, direction doesn't matter) linked to plate 
WPD Pressure plate set to 7-7, Door for access 
WFW Floodgate linked to plate 
WWW 
</blockquote>

Useful features:
*Toggles slowly (once every 200 steps or so), which enables things it is linked to to trigger and activate before a new signal is sent.
*Can fill a resivour reliably to 3-4 water, if the bottom wall is removed and dug to a cistern.