https://dwarffortresswiki.org/api.php?action=feedcontributions&feedformat=atom&user=DiscottDwarf Fortress Wiki - User contributions [en]2026-05-21T17:47:20ZUser contributionsMediaWiki 1.35.11https://dwarffortresswiki.org/index.php?title=Smelting&diff=220750Smelting2015-10-24T12:00:06Z<p>Discott: Updated quality rating timestamp ("Fine") using the rating script</p>
<hr />
<div>{{Quality|Fine|12:00, 24 October 2015 (UTC)}}<br />
{{av}}<br />
<br />
[[File:Agricola_Copper_smelting.png|thumb|A smelter smelting copper.]]<br />
'''Smelting''' is the act of refining raw stone ore(s) into useful bars of pure metal(s) or alloys. Smelting is similar but distinct from [[Melt_item|melting]], which reclaims existing metal objects back into (fractional) bars. Metal bars produced at a [[smelter]] are usable in a wide variety of goods, from weapons to goblets to furniture to buildings. <br />
<br />
Smelting also refines [[bituminous coal]] or [[lignite]] into [[coke]], a [[fuel]] which is equivalent to [[charcoal]], but first needs fuel to do this. Fuel is required to operate a smelter, metalsmith's forge, kiln, or glass furnace, but not their magma-powered equivalents.<br />
<br />
Smelting requires the [[ore]] (or coal) to be processed, a [[smelter]], either [[fuel]] or (for [[magma smelter]]s) [[magma]] at least 4/7 deep, and a dwarf with the [[furnace operator]] [[labor]] enabled. Smelting an ore gives 4 bars of metal, and refining coal gives 9 bars (from [[bituminous coal]]) or 5 bars (from [[lignite]]) of coke. Training in the skill is not necessarily required - since bars have no [[quality]] the only difference is the time the job takes. <br />
<br />
Since smelting coke requires [[fuel]] in a conventional (non-magma) smelter, usually one [[wood]] is burned in a [[wood furnace]] to create one charcoal to start the process. Alternatives are to bring one bar of charcoal or coke with the expedition at embark, [[trade]] for one from [[caravan]]s, or go straight to magma smelters.</div>Discotthttps://dwarffortresswiki.org/index.php?title=Wheelbarrow&diff=220717Wheelbarrow2015-10-19T18:09:06Z<p>Discott: /* Utility */added picture of wheelbarrow from De re metallica</p>
<hr />
<div>{{Quality|Superior|21:15, 16 May 2013 (UTC)}}<br />
{{av}}{{buggy}}<br />
<br />
A '''wheelbarrow''' is a [[tool]] used to increase the speed of [[hauling]]. Wheelbarrows can be made of [[metal]] or [[wood]] at a [[metalsmith's forge]] or [[carpenter's workshop]], and can carry the equivalent of a single [[stockpile]] tile, be it a single [[stone]], a bin or barrel (with its contents included), or a stray item. This is equivalent to one fifth of a [[minecart]]'s capacity.<br />
<br />
== Construction ==<br />
Wheelbarrows are constructed of either wood or metal:<br />
<br />
{| border="1" cellpadding="5" cellspacing="0" style="margin:1em 1em 1em 0; background:#F9F9F9; border:1px #AAA solid"<br />
|- style="background: #F9F9F9"<br />
! Material !! Worker !! Workshop<br />
|- style="background: #F2F2F2"<br />
| [[Wood]] (1 log) || [[Carpenter]] || [[Carpenter's workshop]]<br />
|- style="background: #F2F2F2"<br />
| [[Metal]] (2 bars) || [[Metal crafter]] || [[Metalsmith's forge]] or [[Magma forge]]<br />
|}<br />
<br />
== Utility ==<br />
[[File:De re metallica 1556-085.png|thumb|Dwarven wheelbarrows are sturdy and practical.]]<br />
Each [[stockpile]] may have up to 3 wheelbarrows assigned for [[hauling]] items to that stockpile. ([[DFHack]] allows assigning more than three wheelbarrows per stockpile with <code>tweak max-wheelbarrow</code>.) Stone stockpiles have 1 wheelbarrow automatically assigned upon designation, though any stockpile can have wheelbarrows assigned in the Set Building Tasks/Prefs ({{k|q}}) menu with the {{k|w}} hotkey. Wheelbarrows will be stored in their assigned stockpile when not in use, potentially sharing a tile with a stockpiled item. A stockpile's wheelbarrows are only used to carry items ''to'' that stockpile; they will not be used to carry items away ''from'' it. <br />
<br />
Dwarves carrying items in wheelbarrows ignore the weight of the contents, moving always at their top speed. This makes them particularly useful for hauling heavy items like stone, which slow haulers a lot. There's little benefit to carrying light items in a wheelbarrow, as dwarves won't load multiple items in it. They will, however, load a single bin ''full of items'' in a wheelbarrow.<br />
<br />
Wheelbarrows carry less stuff than [[minecart]]s, but do not require a track to be preconstructed, and can go up and down stairs.<br />
<br />
If wheelbarrows are assigned to a stockpile, dwarves will use them exclusively and cease hauling items to it with their bare hands, meaning that the number of assigned wheelbarrows is also the maximum number of active hauling jobs for said stockpile. This behaviour can save haulers for other more urgent jobs, but is sometimes inconvenient. Increasing the number of assigned wheelbarrows and adding linked stone stockpiles can allow you to pour more dwarfpower into hauling. If you set wheelbarrows at your stockpile to 0, all haulers may carry stones there, but will do it by hand, which is painfully slow work when long distances are involved.<br />
<br />
== Forging and Melting ==<br />
* Metal wheelbarrows cost '''two''' [[metal]] bars or '''six''' [[adamantine]] wafers to forge.<br />
* When a metal wheelbarrow is melted down, it will return '''1.8''' metal bars for an efficiency of '''90%''', or '''1.8''' wafers for an efficiency of '''30%'''.<br />
<br />
== Bugs == <br />
* If a stockpile is assigned both a wheelbarrow and [[container]], dwarves will only use the wheelbarrow to move the container to the stockpile, carrying the items to be stored in the container by hand. As a workaround, a "feeder" stockpile with wheelbarrows enabled can be designated to "give to" an adjacent "storage" stockpile with containers enabled.<br />
<br />
* If all of a stockpile's tiles are occupied by wheelbarrows, it will stop requesting new items even though the tiles under the wheelbarrows have no stockpiled item. Consequently, stockpiles need to have more tiles than wheelbarrows to work correctly.{{bug|8861}}<br />
<br />
* Dwarves carry wheelbarrows instead of pushing them when the wheelbarrows themselves are being hauled.{{bug|6008}}<br />
<br />
* Items can occasionally be left inside a wheelbarrow, causing the wheelbarrow to become unusable. This can cause a stockpile to stop collecting items if all of its wheelbarrows end up in this state{{bug|6074}} You can work around this by marking the contents of the wheelbarrow for dumping.<br />
<br />
{{Category|Items}}<br />
<br />
[[ru:Wheelbarrow]]</div>Discotthttps://dwarffortresswiki.org/index.php?title=Cobaltite&diff=220708Cobaltite2015-10-17T21:52:50Z<p>Discott: gallery</p>
<hr />
<div>{{quality|fine}}{{stonelookup/0}}{{av}}<br />
<br />
'''Cobaltite''' is a brilliant blue stone (notably, the '''only''' stone of its color) found as veins in numerous environments. Despite its appearance (showing up as {{Raw Tile|£|1:7:1}} unmined and {{Raw Tile|*|1:1}} mined), it is '''not''' a usable ore.<br />
<br />
Cobaltite is particularly [[density|dense]], making it useful for [[trap#Stone-fall_Trap|stone-fall traps]] and as [[catapult]] ammunition.<br />
<br />
== In real life ==<br />
Cobaltite is an ore of cobalt, a [[metal]] not modelled in Dwarf Fortress. Interestingly, the name derives from the word [[kobold]]. <br />
<gallery><br />
File:Cobaltite (Cobalt, Ontario, Canada) 1 (18599849584).jpg|A chunk of cobaltite rock.<br />
Cobaltite (Skutterud Mines, Modum, Norway) 2 (19226355671).jpg| A piece of Cobaltite <br />
</gallery><br />
{{gamedata}}<br />
{{stones}}</div>Discotthttps://dwarffortresswiki.org/index.php?title=Cobaltite&diff=220707Cobaltite2015-10-17T21:50:33Z<p>Discott: added picture</p>
<hr />
<div>{{quality|fine}}{{stonelookup/0}}{{av}}<br />
<br />
'''Cobaltite''' is a brilliant blue stone (notably, the '''only''' stone of its color) found as veins in numerous environments. Despite its appearance (showing up as {{Raw Tile|£|1:7:1}} unmined and {{Raw Tile|*|1:1}} mined), it is '''not''' a usable ore.<br />
<br />
Cobaltite is particularly [[density|dense]], making it useful for [[trap#Stone-fall_Trap|stone-fall traps]] and as [[catapult]] ammunition.<br />
<br />
== In real life ==<br />
[[File:Cobaltite (Cobalt, Ontario, Canada) 1 (18599849584).jpg|thumb|A chunk of cobaltite rock.]]<br />
Cobaltite is an ore of cobalt, a [[metal]] not modelled in Dwarf Fortress. Interestingly, the name derives from the word [[kobold]]. <br />
<br />
{{gamedata}}<br />
{{stones}}</div>Discotthttps://dwarffortresswiki.org/index.php?title=Millstone&diff=220706Millstone2015-10-17T21:08:31Z<p>Discott: </p>
<hr />
<div>{{Quality|Exceptional|21:54, 28 June 2010 (UTC)}}<br />
{{Workshop|name=Millstone|key=M|job=[[Miller|Milling]]<br />
|construction=<br />
* [[Furniture|Millstone]]<br />
* [[Mechanism]]<br />
|construction_job=<br />
* [[Mechanic]]<br />
|use=<br />
* [[Blade weed]]<br />
* [[Cave wheat]]<br />
* [[Dimple cup]]<br />
* [[Hide root]]<br />
* [[Longland grass]]<br />
* [[Quarry bush|Rock nut]]<br />
* [[Sliver barb]]<br />
* [[Sweet pod]]<br />
* [[Whip vine]]<br />
* An empty [[bag]]<br />
|production=<br />
* [[Emerald dye]]<br />
* [[Flour|Dwarven wheat flour]]<br />
* [[Dimple dye]]<br />
* [[Redroot dye]]<br />
* [[Flour|Longland flour]]<br />
* [[Quarry bush|Rock nut paste]]<br />
* [[Sliver dye]]<br />
* [[Dwarven sugar]]<br />
* [[Whip vine flour]]<br />
}}{{av}}<br />
<br />
A '''millstone''' is used to grind up certain [[plants]] to make [[sugar]], [[flour]] and [[dye]]. Each [[milling]] job requires an empty [[bag]]. To operate, it needs to be connected to a mechanical [[power]] source such as a [[water wheel]] or [[windmill]] that supplies it with 10 power units. If none is available, a [[quern]] can be used instead, although millstones process plants much faster than querns. Before they can be placed as a building, you must first construct the millstone at a [[Mason's workshop]].<br />
<br />
If the power to the millstone is interrupted, any jobs must be requeued when power is returned. Therefore it is best to have uninterrupted power or at least the ability to run it for a long period of time.<br />
<br />
A millstone can be placed in a hanging state, however, it will not actually be constructed as the builder needs to be able to stand on the square on which it is being built. Because of this, a millstone must be powered from above or from the side, not from below in order to be able to complete construction.<br />
<br />
Ensuring the exclusive milling of certain plants (to, say, produce only dye, not flour) is quite cumbersome. It requires a stockpile that only allows these plants and setting it to {{K|q}}-'{{K|g}}ive To A Pile/Workshop', as the millstone provides no menu to specify what to mill. If you don't set a custom stockpile, the miller will pick the closest random plant, with the usual, occasionally surprising, definition of closest. You also need something like a furniture stockpile that allows only bags, setting that to 'giving' to the millstone too. Deactivate wood, stone and metal as material to avoid it being cluttered with coffers. You still have to ensure somehow that the plants arrive at the right stockpile, for example by not allowing them on any other. Finally, allow the source stockpile or a third custom stockpile to take the resulting mill product or you will receive the misleading error "needs millable unrotten plants". Once you got this working repeat for every other plant you want to mill, either switching the 'give' orders every time or setting up a separate millstone for every plant/plant combination.<br />
<br />
For general details read [[Stockpile#Give_to_a_stockpile.2Fworkshop|Giving to a Stockpile/Workshop]].<br />
<br />
Alternatively, to preserve what little sanity a DF player has left, just forbid all millable plants you don't want milled (for example from the [[stocks]] menu) and (re-)claim them once the milling job is done.<br />
<br />
As another alternative, the utility [[Utility:DFHack|DFHack]] provides a "job item-material" command that allows you to specify a plant to mill (also available as "gui/workshop-job", bound to {{k-|Alt|A}} by default).<br />
[[File:De re metallica 1556-164.png| thumb| Silly humans using a mechanically powered millstone to grind stuff.]]<br />
<br />
==An Example Setup==<br />
As it is most efficient to set up workshops near their materials sources, usually by putting stockpiles next to them, it's common for millstones to be set up near farm plots. Putting a millstone just under the surface lets it be powered by a windmill on the surface, like so:<br />
<br />
::{|style="border: 1px solid #0b0; background: #dfd"<br />
|+'''Side view'''<br />
|- style="font-family: monospace; font-weight: bold; font-size: 135%"<br />
|style="color: #970; padding: 0; text-decoration: underline"|-<br />
|style="color: #970; padding: 0; text-decoration: underline"|=<br />
|style="color: #970; padding: 0; text-decoration: underline"|-<br />
|&nbsp;<br />
|style="color: #970; padding: 0"|-<br />
|style="color: #970; padding: 0"|=<br />
|style="color: #970; padding: 0"|-<br />
|&nbsp;<br />
|- style="font-family: monospace; font-weight: bold; font-size: 135%"<br />
|style="text-decoration: underline"|&nbsp;<br />
|style="text-decoration: underline"|*<br />
|style="text-decoration: underline"|&nbsp;<br />
| <br />
|style="text-decoration: underline"|&nbsp;<br />
|style="text-decoration: underline"|*<br />
|style="text-decoration: underline"|&nbsp;<br />
|- style="font-family: monospace; font-weight: bold; font-size: 135%"<br />
|<br />
|1<br />
| <br />
| <br />
| <br />
|2<br />
| <br />
|}<br />
Note that version 1 only works if the windmill is built first, and version 2 only works if the millstone is built first.<br />
<br />
''For a basic overview of how the different machine parts work and work together, see [[machinery]].''<br />
<br />
==Bugs==<br />
* Dwarves will occasionally combine two separate mill products in the same bag.{{bug|4371}}<br />
<br />
<br />
{{Workshops}}<br />
{{buildings}}</div>Discotthttps://dwarffortresswiki.org/index.php?title=Millstone&diff=220705Millstone2015-10-17T21:08:05Z<p>Discott: added picture</p>
<hr />
<div>{{Quality|Exceptional|21:54, 28 June 2010 (UTC)}}<br />
{{Workshop|name=Millstone|key=M|job=[[Miller|Milling]]<br />
|construction=<br />
* [[Furniture|Millstone]]<br />
* [[Mechanism]]<br />
|construction_job=<br />
* [[Mechanic]]<br />
|use=<br />
* [[Blade weed]]<br />
* [[Cave wheat]]<br />
* [[Dimple cup]]<br />
* [[Hide root]]<br />
* [[Longland grass]]<br />
* [[Quarry bush|Rock nut]]<br />
* [[Sliver barb]]<br />
* [[Sweet pod]]<br />
* [[Whip vine]]<br />
* An empty [[bag]]<br />
|production=<br />
* [[Emerald dye]]<br />
* [[Flour|Dwarven wheat flour]]<br />
* [[Dimple dye]]<br />
* [[Redroot dye]]<br />
* [[Flour|Longland flour]]<br />
* [[Quarry bush|Rock nut paste]]<br />
* [[Sliver dye]]<br />
* [[Dwarven sugar]]<br />
* [[Whip vine flour]]<br />
}}{{av}}<br />
<br />
A '''millstone''' is used to grind up certain [[plants]] to make [[sugar]], [[flour]] and [[dye]]. Each [[milling]] job requires an empty [[bag]]. To operate, it needs to be connected to a mechanical [[power]] source such as a [[water wheel]] or [[windmill]] that supplies it with 10 power units. If none is available, a [[quern]] can be used instead, although millstones process plants much faster than querns. Before they can be placed as a building, you must first construct the millstone at a [[Mason's workshop]].<br />
<br />
If the power to the millstone is interrupted, any jobs must be requeued when power is returned. Therefore it is best to have uninterrupted power or at least the ability to run it for a long period of time.<br />
<br />
A millstone can be placed in a hanging state, however, it will not actually be constructed as the builder needs to be able to stand on the square on which it is being built. Because of this, a millstone must be powered from above or from the side, not from below in order to be able to complete construction.<br />
<br />
Ensuring the exclusive milling of certain plants (to, say, produce only dye, not flour) is quite cumbersome. It requires a stockpile that only allows these plants and setting it to {{K|q}}-'{{K|g}}ive To A Pile/Workshop', as the millstone provides no menu to specify what to mill. If you don't set a custom stockpile, the miller will pick the closest random plant, with the usual, occasionally surprising, definition of closest. You also need something like a furniture stockpile that allows only bags, setting that to 'giving' to the millstone too. Deactivate wood, stone and metal as material to avoid it being cluttered with coffers. You still have to ensure somehow that the plants arrive at the right stockpile, for example by not allowing them on any other. Finally, allow the source stockpile or a third custom stockpile to take the resulting mill product or you will receive the misleading error "needs millable unrotten plants". Once you got this working repeat for every other plant you want to mill, either switching the 'give' orders every time or setting up a separate millstone for every plant/plant combination.<br />
<br />
For general details read [[Stockpile#Give_to_a_stockpile.2Fworkshop|Giving to a Stockpile/Workshop]].<br />
<br />
Alternatively, to preserve what little sanity a DF player has left, just forbid all millable plants you don't want milled (for example from the [[stocks]] menu) and (re-)claim them once the milling job is done.<br />
<br />
As another alternative, the utility [[Utility:DFHack|DFHack]] provides a "job item-material" command that allows you to specify a plant to mill (also available as "gui/workshop-job", bound to {{k-|Alt|A}} by default).<br />
[[File:De re metallica 1556-164.png| Silly humans using a mechanically powered millstone to grind stuff.]]<br />
<br />
==An Example Setup==<br />
As it is most efficient to set up workshops near their materials sources, usually by putting stockpiles next to them, it's common for millstones to be set up near farm plots. Putting a millstone just under the surface lets it be powered by a windmill on the surface, like so:<br />
<br />
::{|style="border: 1px solid #0b0; background: #dfd"<br />
|+'''Side view'''<br />
|- style="font-family: monospace; font-weight: bold; font-size: 135%"<br />
|style="color: #970; padding: 0; text-decoration: underline"|-<br />
|style="color: #970; padding: 0; text-decoration: underline"|=<br />
|style="color: #970; padding: 0; text-decoration: underline"|-<br />
|&nbsp;<br />
|style="color: #970; padding: 0"|-<br />
|style="color: #970; padding: 0"|=<br />
|style="color: #970; padding: 0"|-<br />
|&nbsp;<br />
|- style="font-family: monospace; font-weight: bold; font-size: 135%"<br />
|style="text-decoration: underline"|&nbsp;<br />
|style="text-decoration: underline"|*<br />
|style="text-decoration: underline"|&nbsp;<br />
| <br />
|style="text-decoration: underline"|&nbsp;<br />
|style="text-decoration: underline"|*<br />
|style="text-decoration: underline"|&nbsp;<br />
|- style="font-family: monospace; font-weight: bold; font-size: 135%"<br />
|<br />
|1<br />
| <br />
| <br />
| <br />
|2<br />
| <br />
|}<br />
Note that version 1 only works if the windmill is built first, and version 2 only works if the millstone is built first.<br />
<br />
''For a basic overview of how the different machine parts work and work together, see [[machinery]].''<br />
<br />
==Bugs==<br />
* Dwarves will occasionally combine two separate mill products in the same bag.{{bug|4371}}<br />
<br />
<br />
{{Workshops}}<br />
{{buildings}}</div>Discotthttps://dwarffortresswiki.org/index.php?title=Smelting&diff=220701Smelting2015-10-17T16:32:36Z<p>Discott: </p>
<hr />
<div>{{av}}<br />
{{Quality|Fine}}<br />
[[File:Agricola_Copper_smelting.png|thumb|A smelter smelting copper.]]<br />
'''Smelting''' is the act of refining raw stone ore(s) into useful bars of pure metal(s) or alloys. Smelting is similar but distinct from [[Melt_item|melting]], which reclaims existing metal objects back into (fractional) bars. Metal bars produced at a [[smelter]] are usable in a wide variety of goods, from weapons to goblets to furniture to buildings. <br />
<br />
Smelting also refines [[bituminous coal]] or [[lignite]] into [[coke]], a [[fuel]] which is equivalent to [[charcoal]], but first needs fuel to do this. Fuel is required to operate a smelter, metalsmith's forge, kiln, or glass furnace, but not their magma-powered equivalents.<br />
<br />
Smelting requires the [[ore]] (or coal) to be processed, a [[smelter]], either [[fuel]] or (for [[magma smelter]]s) [[magma]] at least 4/7 deep, and a dwarf with the [[furnace operator]] [[labor]] enabled. Smelting an ore gives 4 bars of metal, and refining coal gives 9 bars (from [[bituminous coal]]) or 5 bars (from [[lignite]]) of coke. Training in the skill is not necessarily required - since bars have no [[quality]] the only difference is the time the job takes. <br />
<br />
Since smelting coke requires [[fuel]] in a conventional (non-magma) smelter, usually one [[wood]] is burned in a [[wood furnace]] to create one charcoal to start the process. Alternatives are to bring one bar of charcoal or coke with the expedition at embark, [[trade]] for one from [[caravan]]s, or go straight to magma smelters.</div>Discotthttps://dwarffortresswiki.org/index.php?title=Smelting&diff=220700Smelting2015-10-17T16:32:16Z<p>Discott: added picture</p>
<hr />
<div>{{av}}<br />
{{Quality|Fine}}<br />
[[File:Agricola_Copper_smelting.png|A smelter smelting copper.]]<br />
'''Smelting''' is the act of refining raw stone ore(s) into useful bars of pure metal(s) or alloys. Smelting is similar but distinct from [[Melt_item|melting]], which reclaims existing metal objects back into (fractional) bars. Metal bars produced at a [[smelter]] are usable in a wide variety of goods, from weapons to goblets to furniture to buildings. <br />
<br />
Smelting also refines [[bituminous coal]] or [[lignite]] into [[coke]], a [[fuel]] which is equivalent to [[charcoal]], but first needs fuel to do this. Fuel is required to operate a smelter, metalsmith's forge, kiln, or glass furnace, but not their magma-powered equivalents.<br />
<br />
Smelting requires the [[ore]] (or coal) to be processed, a [[smelter]], either [[fuel]] or (for [[magma smelter]]s) [[magma]] at least 4/7 deep, and a dwarf with the [[furnace operator]] [[labor]] enabled. Smelting an ore gives 4 bars of metal, and refining coal gives 9 bars (from [[bituminous coal]]) or 5 bars (from [[lignite]]) of coke. Training in the skill is not necessarily required - since bars have no [[quality]] the only difference is the time the job takes. <br />
<br />
Since smelting coke requires [[fuel]] in a conventional (non-magma) smelter, usually one [[wood]] is burned in a [[wood furnace]] to create one charcoal to start the process. Alternatives are to bring one bar of charcoal or coke with the expedition at embark, [[trade]] for one from [[caravan]]s, or go straight to magma smelters.</div>Discotthttps://dwarffortresswiki.org/index.php?title=Bucket&diff=220699Bucket2015-10-17T15:45:53Z<p>Discott: added picture</p>
<hr />
<div>{{Quality|Exceptional|09:32, 17 May 2015 (UTC)}}<br />
{{av}}<br />
{{furniture|name=Bucket<br />
|tile=û|col=6:0:0<br />
|wood=y<br />
|metal=y<br />
|glass=N<br />
|rooms=<br />
* [[Well]]<br />
* [[Soap maker's workshop]]<br />
* [[Ashery]]<br />
* [[dyer's shop]]<br />
}}<br />
[[File:Gal_czerpaki.jpg|thumb|A rang of old buckets.]]<br />
'''Buckets''' are made of [[wood]] at a [[carpenter's workshop]] or [[metal]] at a [[metalsmith's forge]] or [[magma forge]]. They are used by dwarves to carry [[water]], when making [[lye]], milking [[animals]] and for cleaning wounded dwarves. Milk and lye can also be ''stored'' in buckets, but dwarves will prefer to empty the buckets into suitable [[barrel]]s. A bucket is also needed for the construction of a [[well]], a [[soap maker's workshop]], an [[ashery]] or a [[dyer's shop]]. To make a bucket, push {{k|q}} and highlight the carpenter's workshop. Then push {{k|a}} to add a new task, and push {{k|e}} to make a wooden bucket. A suitable dwarf will fulfill your request when he has time.<br />
<br />
They are stored on the furniture [[stockpile]]. <br />
<br />
[[Metal]] buckets are one of the few objects made with [[blacksmith]]ing that uses 1 [[bar]], with [[block]]s being the other. This makes them useful for training blacksmiths, as the buckets can be melted down for a single bar, and training can occur even when metals are scarce.<br />
<br />
{{buildings}}</div>Discotthttps://dwarffortresswiki.org/index.php?title=Glass_industry&diff=220696Glass industry2015-10-16T21:17:38Z<p>Discott: added picture</p>
<hr />
<div>{{Quality|Exceptional|11:26, 28 January 2015 (UTC)}}<br />
{{av}}<br />
[[File:Agricola-4.png|thumb|]]<br />
The '''Glass Industry''' is a versatile and, under the right circumstances, sustainable source of items. Everything from [[finished goods]] to [[furniture]] to low value [[glass]] [[gem]]s to [[block]]s to [[trap component]]s can be created in [[glass]], making [[Glassmaker]] a very useful profession. Since glass is [[magma-safe]] and capable of producing all necessary [[screw pump]] components, a glassmaking industry can prove quite valuable when working with [[magma]].<br />
<br />
==Producing glass==<br />
The limiting factors to [[glass]] production are [[sand]] and [[fuel]]; in order to produce glass in great quantities your map must have sand (any single tile has an infinite amount of sand) and either a good source of coal, magma or many trees. Small quantities of sand can regularly be acquired from [[caravan]]s, but rarely enough to run a large industry. Soil layers may or may not include sand; there is no way to tell if your map will provide it until you embark (other than [[cheating]]). If you want to ensure the possibility of a flourishing glass industry, embark on a [[sand desert]] or [[badlands]] biome. Keep in mind these biomes by themselves don't have [[tree]]s to [[fuel]] your furnaces early on.<br />
<br />
To make items from glass, sand must first be gathered in [[bag]]s using a task available at any [[glass furnace]], "Gather Sand". You must designate a [[activity zone|Sand Collection zone]] from the ({{k|i}})-menu that includes an accessible area of sand in order for this task to be performed. Only cut glass "gems" (and [[artifact]]s) can be made from raw glass purchased from [[caravan]]s. All other glass objects must be made from "sand bearing items", i.e. bags of sand.<br />
<br />
Once you have one bag of sand you can order glass to be created at a furnace. A standard [[glass furnace]] will consume one unit of [[fuel]] per job; a [[magma glass furnace]] uses no fuel.<br />
<br />
===Collecting sand===<br />
All sustainable types of glassmaking require a [[container|bag]] of [[sand]]. The "Collect [[Sand]]" order at the glass furnace requires the "[[hauling#Item_hauling|item hauling]]" labor, not glassmaking. The Collect Sand order does however still occupy the glass furnace, preventing glassmakers from performing any other jobs there until after the collection has been completed. Collecting sand is a time consuming task, and proficient glassmakers quickly become faster at making items than gathering materials, leading to job cancellations as collected sand becomes scarce.<br />
<br />
====Collecting sand efficiently====<br />
There are ways around this problem, each with its own benefits and drawbacks.<br />
<br />
=====Controlled=====<br />
Collect a specific amount of sand bags, then assign the correspondent orders of actual glass making. This ensures that enough bags remain for other tasks and no cancellations happen. It is also the best way to keep an overview of what has actually been produced, especially when using the manager. Time loss is negligible as the bulk of time is consumed by hauling sand.<br />
<br />
=====Brute force=====<br />
The fast, somewhat sloppy method is to build additional glass furnaces near your sand collection zone for the sole purpose of [[repeat]]ing the Collect Sand order while other furnaces are used for actual glassmaking. Keep in mind that ordering glass goods through the [[manager]] will schedule jobs in your sand collection glass furnaces, which can get irritating and interfere with your balance of sand supplies and glassmaking orders. To avoid this, queue ten sand collection jobs and set them all to repeat. This will prevent new jobs from being assigned to the [[furnace]].<br />
<br />
======Benefits======<br />
*This method will free up time for your glassmakers to focus on making glass items. <br />
<br />
*It is possible to turn off all of your craftsdwarves' hauling labors and let your pack of otherwise useless [[Potash maker|Potash Maker]]s do all the grunt work of filling [[container|bags]].<br />
<br />
======Drawbacks======<br />
*This method is hard to balance. Just when you think you have found an equilibrium between supply and demand, a legendary glassmaker goes to sleep and every bag is filled with sand during his absence, resulting in a cascade of canceled bag filling jobs. If you instead order more bags than can be used, hundreds of surplus sand bags will accumulate until you eventually run out of bags or tweak the balance again.<br />
<br />
=====Slow and easy=====<br />
The slightly slower but more controllable method of collecting sand efficiently. Assign each glass furnace to an individual glassmaker, and make sure that the dwarf's item hauling labor is turned on. Stagger work orders so the glassmaker hauls their own sand, then makes their item, then hauls their own sand. <br />
<br />
======Benefits======<br />
*Orders can be set to repeat endlessly in the background with no oversight, which is particularly excellent when mass-producing [[Gems#Glass|raw glass]] or [[block]]s.<br />
<br />
*Usage of bags is set to a minimum, which frees [[cloth]] and [[leather]] for other purposes.<br />
<br />
======Drawbacks======<br />
*Tandem job orders like this mean that only five orders can be placed at a time, meaning that orders are placed most effectively as [[repeat]]s. A way around this is to set five different types of tandem orders and [[suspend]] and unsuspend them as desired.<br />
<br />
*This method is slower than the brute force method, and doesn't give your horde of idle dwarves anything to do.<br />
<br />
*The manager can still be a burden with this system and ruin the balance of labors.<br />
<br />
==Varieties of glass==<br />
:*Producing '''green glass''' requires only a bag of sand. Green glass items are [[value|worth]] twice as much as objects made from most [[stone]], making it equivalent to cheap metals like [[copper]] and [[zinc]].<br />
<br />
:*Producing '''clear glass''' requires one bar of [[pearlash]] in addition to a bag of sand. Clear glass items are worth five times as much as items made from most stones, making it equivalent to metals like [[bronze]].<br />
<br />
:*Producing '''crystal glass''' requires no sand, but does require pearlash and rough [[rock crystal]]s, a [[gem]] which is not found on all maps. Cut rock crystals bought from [[trader]]s will not work for producing crystal glass. Crystal glass is worth ten times as much as objects made from most stones, making it equivalent in value to metals like [[silver]].<br />
<br />
See also "[[Glass]]" for a full discussion of the properties of glass items.<br />
<br />
==Glass Industry Flowchart==<br />
<br />
[[Image:Glass Industry 2012 Update.png|Flowchart of the glass industry and its interaction with surrounding industries.]]<br />
<br />
==Glassmaking vs. other professions==<br />
Functionally, the glass industry is like a cross between the Stone industry, and the Metal industry, incorporating elements from both. Functionally, it is similar to metalworking, using a furnace and fuel to produce its products, and its products can have material values similar to metals. Meanwhile, its actual product output is most similar to stoneworking, with only a few differences, and it can pretty much fully replace masonry except for those instances.<br />
<br />
===vs. Stoneworking===<br />
There is considerable overlap between items produced from [[stone]] at a [[Mason's workshop]], and items produced from glass at glass furnaces. [[Mason]]ry is easier to get running and will [[stone management|clear excess stone]] from your fortress. Glass produces items with a higher base [[value]] (unless you make your masons use flux or [[obsidian]]), and using a [[magma glass furnace]] allows you to make green glass objects without consuming anything but dwarven labor. Glass also provides a [[magma-safe]] alternative, to prepare for magma-based projects before it's discovered or avoid stockpile micromanagement for the correct building materials. Unique stone products which cannot be made of glass are querns/millstones, slabs, crafts, and stone short swords.<br />
<br />
===vs. Metalworking===<br />
There are many similarities in the processes between [[metalsmithing]] and glassmaking. Both require fuel, and both require supplementary materials for certain unique products. Additionally, crafts are made directly at the furnace, rather than at a craftsdwarf's workshop. Metalworking is generally more likely to be started first, as any site will eventually find metals and fuel, (if even only in the form of magma) and quality weapons are often needed to start a military, but how much you can make is limited by how much you can dig up or buy. Glassmaking has the potential to produce ''infinite'' products, if given sand, enough bags, and magma. Also, while metal ores are turned into an intermediary material, (bars) by another profession at a different workshop, which must then be forged into a product, glassmaking produces a product directly from the raw materials, and still leaves you with an empty bag. Finally, metalworking has a far more diverse range of products, including restraints, weapons, and armor.<br />
<br />
==Glassmaking and [[minecart]]s==<br />
In a typical fortress, [[magma]] is located deep below, while sand is a soil layer and thus without some creative management is just below ground. Without minecarts, each sand bag will be carried by a single dwarf, thus requiring a lot of dwarf labor and wide staircases. With minecarts one can not only transport a lot of sand bags to the magma furnace without much dwarftime wasted on hauling, but also transport all the glass products back up. If set up, the track can be also used to supply (and grab from) [[magma smelter]] which is likely to be located close to [[magma glass furnace]].<br />
If one is too lazy to set up a track, minecart system can be easily used simply to haul all the sand bags in a convenient container (requires a wooden minecart). If both endpoints are set to '''guide''', but are left disconnected, dwarves will just grab the minecart and haul it to destination. Since sand bags and wooden minecarts are both reasonably light, the dwarf won't slow down much.<br />
{{Category|Industry}}<br />
{{Industry}}</div>Discotthttps://dwarffortresswiki.org/index.php?title=Potter&diff=220695Potter2015-10-16T21:03:54Z<p>Discott: </p>
<hr />
<div>{{Quality|Exceptional|21:28 10 July 2012 (UTC)}}<br />
{{Skill<br />
| color = 1:1<br />
| skill = Potter<br />
| profession = [[Craftsdwarf]]<br />
| job name = [[Pottery]]<br />
| tasks =<br />
* Make clay jug<br />
* Make clay bricks<br />
* Make clay statue<br />
* Make large clay pot<br />
* Make clay crafts<br />
* Make clay hive<br />
| workshop = * [[Kiln]]<br />
* [[Magma kiln]]<br />
| attributes =<br />
* Creativity<br />
* Agility<br />
* Kinesthetic Sense<br />
* Spatial Sense<br />
}}<br />
{{av}}<br />
[[File:Agricola-3.png|thumb|Potter's using a kiln to fire or harden some clay pots.]]<br />
'''Potter''' is the skill associated with the pottery [[labor]]. Potters make [[ceramic]] [[brick]]s, [[jug]]s, [[statue]]s, [[container|pots]], and [[finished goods|craft items]] at the [[kiln]] or [[magma kiln]]. Note that using a kiln to Collect Clay requires the [[DF2014:Hauling|Item Hauling]] labor and not pottery.<br />
<br />
Potter [[skill|skill level]] is used to determine the [[quality]] of the created good. If a [[glaze]] is applied it adds to the value of the final product (but [[Glazing]] is a separate labor from pottery).<br />
<br />
Potters can produce a variety of goods for a fortress as part of the [[ceramic industry]].<br />
<br />
{{Skills}}</div>Discotthttps://dwarffortresswiki.org/index.php?title=Potter&diff=220694Potter2015-10-16T21:03:19Z<p>Discott: </p>
<hr />
<div>{{Quality|Exceptional|21:28 10 July 2012 (UTC)}}<br />
{{Skill<br />
| color = 1:1<br />
| skill = Potter<br />
| profession = [[Craftsdwarf]]<br />
| job name = [[Pottery]]<br />
| tasks =<br />
* Make clay jug<br />
* Make clay bricks<br />
* Make clay statue<br />
* Make large clay pot<br />
* Make clay crafts<br />
* Make clay hive<br />
| workshop = * [[Kiln]]<br />
* [[Magma kiln]]<br />
| attributes =<br />
* Creativity<br />
* Agility<br />
* Kinesthetic Sense<br />
* Spatial Sense<br />
}}<br />
{{av}}<br />
[[File:127.0.0.l~commonswiki|thumb|Potter's using a kiln to fire or harden some clay pots.]]<br />
'''Potter''' is the skill associated with the pottery [[labor]]. Potters make [[ceramic]] [[brick]]s, [[jug]]s, [[statue]]s, [[container|pots]], and [[finished goods|craft items]] at the [[kiln]] or [[magma kiln]]. Note that using a kiln to Collect Clay requires the [[DF2014:Hauling|Item Hauling]] labor and not pottery.<br />
<br />
Potter [[skill|skill level]] is used to determine the [[quality]] of the created good. If a [[glaze]] is applied it adds to the value of the final product (but [[Glazing]] is a separate labor from pottery).<br />
<br />
Potters can produce a variety of goods for a fortress as part of the [[ceramic industry]].<br />
<br />
{{Skills}}</div>Discotthttps://dwarffortresswiki.org/index.php?title=Potter&diff=220693Potter2015-10-16T21:02:50Z<p>Discott: </p>
<hr />
<div>{{Quality|Exceptional|21:28 10 July 2012 (UTC)}}<br />
{{Skill<br />
| color = 1:1<br />
| skill = Potter<br />
| profession = [[Craftsdwarf]]<br />
| job name = [[Pottery]]<br />
| tasks =<br />
* Make clay jug<br />
* Make clay bricks<br />
* Make clay statue<br />
* Make large clay pot<br />
* Make clay crafts<br />
* Make clay hive<br />
| workshop = * [[Kiln]]<br />
* [[Magma kiln]]<br />
| attributes =<br />
* Creativity<br />
* Agility<br />
* Kinesthetic Sense<br />
* Spatial Sense<br />
}}<br />
{{av}}<br />
[[File:Agricola-3|thumb|Potter's using a kiln to fire or harden some clay pots.]]<br />
'''Potter''' is the skill associated with the pottery [[labor]]. Potters make [[ceramic]] [[brick]]s, [[jug]]s, [[statue]]s, [[container|pots]], and [[finished goods|craft items]] at the [[kiln]] or [[magma kiln]]. Note that using a kiln to Collect Clay requires the [[DF2014:Hauling|Item Hauling]] labor and not pottery.<br />
<br />
Potter [[skill|skill level]] is used to determine the [[quality]] of the created good. If a [[glaze]] is applied it adds to the value of the final product (but [[Glazing]] is a separate labor from pottery).<br />
<br />
Potters can produce a variety of goods for a fortress as part of the [[ceramic industry]].<br />
<br />
{{Skills}}</div>Discotthttps://dwarffortresswiki.org/index.php?title=Potter&diff=220692Potter2015-10-16T21:01:53Z<p>Discott: added picture</p>
<hr />
<div>{{Quality|Exceptional|21:28 10 July 2012 (UTC)}}<br />
{{Skill<br />
| color = 1:1<br />
| skill = Potter<br />
| profession = [[Craftsdwarf]]<br />
| job name = [[Pottery]]<br />
| tasks =<br />
* Make clay jug<br />
* Make clay bricks<br />
* Make clay statue<br />
* Make large clay pot<br />
* Make clay crafts<br />
* Make clay hive<br />
| workshop = * [[Kiln]]<br />
* [[Magma kiln]]<br />
| attributes =<br />
* Creativity<br />
* Agility<br />
* Kinesthetic Sense<br />
* Spatial Sense<br />
}}<br />
{{av}}<br />
[[File:Agricola-3|thumb|Potter's using a kiln to fire/harden some clay pots.]]<br />
'''Potter''' is the skill associated with the pottery [[labor]]. Potters make [[ceramic]] [[brick]]s, [[jug]]s, [[statue]]s, [[container|pots]], and [[finished goods|craft items]] at the [[kiln]] or [[magma kiln]]. Note that using a kiln to Collect Clay requires the [[DF2014:Hauling|Item Hauling]] labor and not pottery.<br />
<br />
Potter [[skill|skill level]] is used to determine the [[quality]] of the created good. If a [[glaze]] is applied it adds to the value of the final product (but [[Glazing]] is a separate labor from pottery).<br />
<br />
Potters can produce a variety of goods for a fortress as part of the [[ceramic industry]].<br />
<br />
{{Skills}}</div>Discotthttps://dwarffortresswiki.org/index.php?title=Minecart&diff=220691Minecart2015-10-16T20:57:41Z<p>Discott: </p>
<hr />
<div>{{Quality|Masterwork|08:15, 19 May 2015 (UTC)}}<br />
{{av}}<br />
[[File:Leitnagel Hund.png|thumb|Minecarts]]<br />
A '''minecart''' is a [[tool]] intended for [[hauling]], introduced in version 0.34.08. It can be made of [[wood]] at a [[carpenter's workshop]] or [[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]].<br />
<br />
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 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.<br />
<br />
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.<br />
<br />
The invention of minecarts revolutionized the [[minecart logic|Science of Dwarfputing]] by enabling smaller, faster logic systems to be built.<br />
<br />
== Basic Minecart Usage ==<br />
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.<br />
<br />
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 be 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.<br />
<br />
To control which items to transport you can add conditions specifying: (1) which kind of items to be loaded, and unloaded, (2) stockpile links to define which stockpile(s) the items should be un/loaded to and from.<br />
<br />
===Capacity and weights ===<br />
Minecarts have five times the [[Weight|capacity]] of [[wheelbarrow]]s. <br />
<br />
'''Examples of the capacity of one cart'''<br />
{| class="wikitable"<br />
|-<br />
! Item<br />
! Amount<br />
|-<br />
| [[stone]]<br />
| 5<br />
|- <br />
| [[wood|log]]<br />
| 10<br />
|-<br />
| [[block]]/[[bar]]<br />
| 83<br />
|-<br />
| [[Kitchen|prepared meals]]<br />
| 500<br />
|-<br />
| [[Trap_component#Spiked_ball|spiked balls]]<br />
| 500<br />
|-<br />
| [[Weapon#Native_weapons|mace]]<br />
| 625<br />
|-<br />
| [[Weapon#Native_weapons|spears]]<br />
| 1250<br />
|-<br />
| [[cloth]]<br />
| 2500<br />
|}<br />
<br />
The weight of the loaded minecart does not affect the initial velocity received from pushing or launching from a roller. However, the load of a minecart ''does'' affect whether a [[pressure plate]] triggers or not, based on the pressure plate's setting.<br />
<br />
'''Weights of different carts'''<br />
<br />
{| class="wikitable"<br />
|-<br />
! Type of cart<br />
! Empty cart<br />
! Fully loaded (items)<br />
|-<br />
| oaken minecart <br />
| 28Γ<br />
| 378Γ (10 oak logs)<br />
|- <br />
| platinum minecart<br />
| 856Γ<br />
| 10482Γ (83 gold bars)<br />
|}<br />
<br />
<br />
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:<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Material !! Minecart weight !! Content weight required to trigger !! Banana roasts required to trigger (for scale)<br />
|-<br />
| [[Glumprong]] || 48 || 2 || 4<br />
|-<br />
| [[Electrum]] || 596 || 4 || 7<br />
|-<br />
| [[Nickel silver]] || 346 || 4 || 7<br />
|-<br />
| [[Brass]] || 342 || 8 || 14<br />
|-<br />
| [[Bismuth]] (moods only) || 391 || 9 || 15<br />
|-<br />
| [[Fine pewter]] || 291 || 9 || 15<br />
|-<br />
| [[Lay pewter]] || 291 || 9 || 15<br />
|-<br />
| [[Tin]] || 291 || 9 || 15<br />
|-<br />
| [[Trifle pewter]] || 291 || 9 || 15<br />
|}<br />
<br />
=== Creating tracks ===<br />
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.<br />
<br />
====Simple tracks====<br />
<br />
'''Carved'''<br />
<br />
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. <br />
<br />
'''Constructed'''<br />
<br />
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.<br />
<br />
====Ramps====<br />
<br />
'''Carved'''<br />
<br />
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.)<br />
<br />
'''Constructed'''<br />
<br />
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.<br />
<br />
'''Examples of ramps'''<br />
<br />
A simple ramp would look like this: <br />
{{diagram|spaces=yes|\<br />
z +0 z +1<br />
░░░░ ░░░░<br />
═▲o ░▼═<br />
░░░░ ░░░░<br />
o : wall<br />
}}<br />
<br />
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:<br />
{{diagram|spaces=yes|\<br />
z +0 z +1 <br />
░░░░░ ░░░░░ <br />
░░░░░ ══╗░░ <br />
=▲░░ ░░▼░░ <br />
░░░░░ ░░░░░ <br />
}}<br />
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.<br />
<br />
Moving to and from ramps (or between ramps "pointing" in different directions0 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}}<br />
<br />
{{anchor|Tracks}}<br />
<br />
=== Hauling route ===<br />
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.<br />
<br />
==== Route ====<br />
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.<br />
<br />
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.<br />
<br />
==== Stops ====<br />
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.<br />
<br />
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. Stops, which are the steps that make up a route, should not be confused with Track Stops, described below.<br />
<br />
===== Stockpile links =====<br />
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.<br />
<br />
===== Departure condition =====<br />
Departure conditions involve setting conditions in which the minecart will leave on the route. Each condition includes:<br />
# A departure mode (Guide, Ride or Push).<br />
# 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.<br />
# A timer, before which the departure condition cannot be met.<br />
# Conditions on the amount of items in the cart.<br />
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.<br />
<br />
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.<br />
<br />
=== Track Stops ===<br />
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.<br />
<br />
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.<br />
<br />
Counter-intuitive to their construction method, Track Stops are considered [[building]]s and must be removed by {{k|q}} {{k|x}}.<br />
* See [[#More_on_Track_stop |More on Track Stops]]<br />
<br />
=== Step-by-step tutorial ===<br />
<br />
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:<br />
<br />
[[File:minecart-example-1.png|Stockpiles designated.]]<br />
<br />
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.<br />
<br />
Next, carve the track:<br />
<br />
[[File:minecart-example-2.png|Track carving designation.]]<br />
<br />
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.)<br />
<br />
In addition, while we're waiting for that to happen, we'll build an iron minecart in the forge.<br />
<br />
[[File:minecart-example-3.png|Track carved.]]<br />
<br />
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:<br />
<br />
{|<br />
| [[File:minecart-example-4.png|Track stop designation.]]<br />
| [[File:minecart-example-5.png|Select dumping direction.]]<br />
|}<br />
<br />
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.<br />
<br />
[[File:minecart-example-6.png|Track stop constructed.]]<br />
<br />
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:<br />
<br />
{|<br />
| [[File:minecart-example-7.png|Stop 1 designation.]]<br />
| [[File:minecart-example-8.png|Route definition, in progress.]]<br />
|}<br />
<br />
Move the cursor again, to the output end of the track, and press {{k|s}} again to define the second stop:<br />
<br />
{|<br />
| [[File:minecart-example-9.png|Stop 2 designation.]]<br />
| [[File:minecart-example-10.png|Route definition, two stops.]]<br />
|-<br />
|<br />
| [[File:minecart-example-11.png|Stops are not defined yet.]]<br />
|}<br />
<br />
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|-}}.<br />
<br />
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:<br />
<br />
[[File:minecart-example-12.png|Default stop definition.]]<br />
<br />
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.<br />
<br />
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.<br />
<br />
When you've done all that, stop 1 should look like this:<br />
<br />
[[File:minecart-example-13.png|Stop 1, defined.]]<br />
<br />
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:<br />
<br />
[[File:minecart-example-14.png|Stop 2, defined.]]<br />
<br />
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}}.<br />
<br />
Now we've got everything set up:<br />
<br />
[[File:minecart-example-15.png|Route, fully defined.]]<br />
<br />
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.<br />
<br />
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!<br />
<br />
=== Troubleshooting ===<br />
<br />
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. <br />
<br />
'''Symptom:''' {{DFtext|! Set dir/connect track|6:1}} message appears to the right of one or more stops <br />
<br />
'''Possible Causes:'''<br />
* In basic terms, the game checks if there is a valid path for a cart along the rails to reach the next stop in the route, and whether a dwarf ''guiding'' a cart would be able to find a path to the destination without carrying the cart. This warning pops up if the cart can't find a valid path based upon guided carts.<br />
** 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. (But double-check to make sure it's fine...)<br />
* The departure direction of the stop might be invalid. Edit the stop using {{k|Enter}} and press{{k|d}} until it is pointing in a valid direction.<br />
* The track stop might not be built on top of a track. The track stop must be deconstructed to remedy this issue.<br />
* Your track might not be built correctly. Make sure all connected tracks between destinations are not one-way tracks.<br />
** This can be especially confusing with ramps. To carve a two-way track on a (natural) ramp, you must designate the ramp <b>and one square beyond</b> in the direction you want the track to go.<br />
** Ramps '''must''' have a solid block on the side opposite to the track, or they will neither work nor be marked as "unusable". The solid block can be natural or constructed.<br />
* The desired/kept items might not be configured correctly.<br />
<br />
'''Symptom:''' The status '''0% <span style="color:#00dd00;">V</span>''' always appears to the right of one stop. <br />
<br />
'''Possible Causes:''' <br />
* The stop may not be set to take from a stockpile. Edit the Stop using {{k|Enter}} and make sure you see a message like "Take from Stockpile #1".<br />
* The take conditions must correspond with the contents of the stockpile.<br />
* The track stop may be 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.)<br />
* Make sure the minecart itself has not been designated to be dumped (such as when using mass-dump).<br />
<br />
'''Symptom:''' Dwarves fill the minecart properly, but will not move it thereafter.<br />
<br />
'''Possible Causes:''' <br />
* The minecart may contain items which are not included in its current stop's desired items. Check inside the minecart using the {{key|k}} and {{key|z}} keys and ensure that all items in the cart are desired items.<br />
* The minecart may 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).<br />
<br />
'''Symptom:''' Dwarves repeatedly attempt to load the minecart, but no items are ever loaded into it.<br />
<br />
'''Possible Causes:''' <br />
* This can be caused by using a Track Stop with autodumping enabled at 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.<br />
<br />
'''Symptom:''' A dwarf picks up the minecart and carries it to its destination.<br />
* See [[#Quirks|Quirks]]<br />
<br />
=== Danger ===<br />
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.<br />
<br />
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).<br />
<br />
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."<br />
<br />
Of course, the danger of using minecarts means they can also be [[Trap_design#Minecarts|used as weapons]] by imaginative players.<br />
<br />
== Advanced usage and automation ==<br />
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}}. <br />
<br />
=== More on Track stop === <br />
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). <br />
<br />
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. <br />
<br />
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}}<br />
<br />
=== Automated propulsion ===<br />
==== Roller ====<br />
{{Main|Roller}}<br />
<br />
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.<br />
<br />
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.<br />
<br />
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}}<br />
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}}<br />
<br />
{{diagram|spaces=yes|\<br />
tracks: full:<br />
║ ║<br />
═╗═ ═╢═<br />
║ ║ <br />
<br />
╢ : roller pushing from W to E<br />
}}<br />
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.<br />
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.<br />
<br />
{{diagram|spaces=yes|\<br />
║ ║ <br />
═╗═ ═╟═<br />
║ ║<br />
<br />
╟ : Roller pushing from E to W<br />
}}<br />
Carts from the E or W: exit W.<br />
Carts from N: derailed diagonally, exit SW.<br />
Carts from S: derailed diagonally, exit NW.<br />
<br />
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.<br />
<br />
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}} &mdash; this allows a one-way track to be used in both directions. In addition, unpowered rollers do not affect minecarts.<br />
<br />
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.<br />
<br />
<br />
==== Impulse ramps ====<br />
Carts can be given momentum without rollers or changing z-level through a phenomenon called "impulse ramps". A track ramp which is connected both to a wall and to a floor will ''always'' accelerate a cart towards the connected floor tile, no matter where the cart enters the tile from. This means carts can be accelerated as though dropping z-levels, even if the cart doesn't actually change z-level at all. 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.<br />
<br />
Example of straight impulse acceleration:<br />
<br />
{{diagram|spaces=yes|\<br />
▒▒▒▒▒▒▒▒▒▒ ▒▒▒▒▒▒▒▒▒▒ <br />
═▲▲▲▲▲▲▲▲▲▲═ ═╚╚╚╚╚╚╚╚╚╚═ <br />
▒ : Wall<br />
═ : Normal track <br />
▲/╚ : N/E Track/Ramp<br />
}}<br />
<br />
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.<br />
<br />
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.<br />
<br />
Example of an impulse elevator:<br />
<br />
{{diagram|spaces=yes|\<br />
z +0 z +1 z +2 z +3<br />
░░░░░ ░░░░░ ░░░░░ ░░░░░<br />
░╔░░░ ░▼╚╗░ ░░▼▼░ ░░░░░<br />
░╝░░░ ░▼░░░ ░░░╔░ ░░░▼░<br />
░▼▼░░ ░░░░░ ░░░╝░ ░╚╗▼░<br />
░░░░░ ░░░░░ ░░░░░ ░░░░░<br />
<br />
░ : Wall<br />
╔,╚,╗,╝ : Track/Ramp<br />
▼ : Down Ramp (empty space)<br />
}}<br />
<br />
Note that this impulse elevator, 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.<br />
<br />
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.<br />
<br />
{{diagram|spaces=yes|\<br />
z +0 z +1 z +2 z +3<br />
░░░░░░ ░░░░░░ ░░░░░░ ░░░░░░<br />
░░░░░░ ░╔╔═░░ ░░▼▼╗░ ░░░░░░<br />
░║░░░░ ░▼░░░░ ░░░░╗░ ░░░░▼░<br />
░╚░░░░ ░▼░░░░ ░░░░║░ ░░░░▼░<br />
░╚▼▼░░ ░░░░░░ ░░░░░░ ░░═╝╝░<br />
░░░░░░ ░░░░░░ ░░░░░░ ░░░░░░<br />
<br />
░ : Wall<br />
║,═,╔,╚,╗,╝ : Track/Ramp<br />
▼ : Down Ramp (empty space)<br />
}}<br />
<br />
Also, if you want to have a cart following a below-derail speed, the following track works well:<br />
{{diagram|spaces=yes|\<br />
z +0 z +1 z +2 z +3<br />
░░░░░ ░░░░░ ░░░░░ ░░░░░<br />
░░░░░ ░══░░ ░▼▼║░ ░░░▼░<br />
░║░░░ ░▼░░░ ░░░║░ ░░░▼░<br />
░║▼▼░ ░▼░░░ ░░░░░ ░░══░<br />
░░░░░ ░░░░░ ░░░░░ ░░░░░<br />
<br />
░ : Wall<br />
║,═ : Track/Ramp<br />
▼ : Down Ramp (empty space)<br />
}}<br />
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. <br />
<br />
<br />
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.<br />
<br />
=== Controlling traffic ===<br />
<br />
==== Switching ====<br />
<!-- copying template ║ ═ ╔ ╗ ╚ ╝ ╠ ╣ ╦ ╩ ╬ ╞ ╡ ╥ ╨ --><br />
As constructions or tile features, [[door]]s and other furniture can be built on tracks. 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. <br />
{{diagram|spaces=yes|\<br />
-><br />
A ════┤≡════ B<br />
┤ : roller pushing to East<br />
≡ : door<br />
}}<br />
The roller pushes the cart east, but until the "departure condition" is fulfilled, the door remains closed and blocks the path. <br />
<br />
[[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.<br />
<br />
A powered track switch can be constructed by building an "inverted" corner as illustrated below.<br />
{{diagram|spaces=yes|\<br />
B B<br />
║ -> ║<br />
║ ║<br />
════╚═══ ════├════<br />
A C A C<br />
├ : roller pushing to West.<br />
}}<br />
<br />
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.<br />
<br />
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.<br />
{{diagram|spaces=yes|\<br />
B ╥<br />
║<br />
║<br />
╞════╝ ════╡<br />
A D C<br />
}}<br />
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).<br />
<br />
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.<br />
<br />
If carts are moving too slowly to derail at the corner, a retractable bridge may be used as a connector between A and C. <br />
{{diagram|spaces=yes|\<br />
B╥<br />
║<br />
║<br />
A╞════bbb════╡C<br />
}}<br />
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.<br />
<br />
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.<br />
<br />
==== Controlling Speed ====<br />
<!-- copying template ║ ═ ╔ ╗ ╚ ╝ ╠ ╣ ╦ ╩ ╬ ╞ ╡ ╥ ╨ --><br />
<br />
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:<br />
<br />
Will derail at > 0.5 t/st:<br />
<br />
{{diagram|spaces=yes|\<br />
in ══╗ -> derailing<br />
║<br />
out<br />
}}<br />
<br />
Will not derail at > 0.5 t/st:<br />
{{diagram|spaces=yes|\<br />
in ══╗O<br />
║<br />
out<br />
<br />
O : wall/column.<br />
}}<br />
<br />
This behavior can be used to build a "speed limiter", that will ensure that when a minecart exits it is traveling below derail speed:<br />
{{diagram|spaces=yes|\<br />
░░░░ ░░░░░ ░░░░░<br />
in ═╔═╗░ ░╔S╗░ ░╔S╗░<br />
out ═╬═╝░ out ═╗═╝░ out ═╗═╝░<br />
░╚S╝░ ░╚═╝═ in ░╚S╝░<br />
░░░░░ ░░░░ ║░░░<br />
in<br />
░ : wall<br />
S : Track Stop (High Friction or lower)<br />
}}<br />
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.<br />
<br />
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.<br />
<br />
=== Loading liquids ===<br />
[[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).<br />
The liquids can be dumped by a constructed track stop.<br />
<br />
== Quirks ==<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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}}<br />
<br />
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.<br />
<br />
== Physics ==<br />
<!-- copying template ║ ═ ╔ ╗ ╚ ╝ ╠ ╣ ╦ ╩ ╬ ╞ ╡ ╥ ╨ --><br />
<br />
Minecart physics depend greatly on the departure mode set in the route stop conditions.<br />
<br />
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.<br />
<br />
The difference between "Push" and "Ride" is whether the dwarf will go along with the cart or not.<br />
{{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.<br />
{{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.<br />
{{DFtext|Guide}}: minecarts seem to ignore all laws of physics. That is:<br />
*Ignore the weight of any and all items inside. Therefore:<br />
**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.<br />
*Ignore working rollers.<br />
*Will ''not'' collide with other guided carts even when a full frontal collision would be expected.<br />
*Will go up ramps like nobody's business.<br />
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.<br />
<br />
Some samples with behavior:<br />
{{diagram|spaces=yes|\<br />
A <-> B A <-> C A <-> B<br />
B B B <br />
║ ║ ║ <br />
A══╝ A══╩══C A══╬╗<br />
You can only go A->B ╚╝<br />
Works when the cart Works <br />
is in Guide mode. <br />
}}<br />
In the second example above, a cart "pushed" from B will go over the junction and roll off into the unknown south.<br />
<br />
=== Numbers behind the scene ===<br />
<br />
According to early research by '''expwnent'''{{cite forum|112831/3536975}}:<br />
<br />
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]].)<br />
<br />
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 either above 100,000 or below 0, (or several tiles if velocity is over 100,000,) and 100,000 is either added or subtracted to sub-tile position to restart the count to the next tile change. <br />
<br />
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 cover about four times the distance in a straight line, but only twice the distance along a winding track with very many corners.<br />
<br />
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 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. <br />
<br />
Friction of tiles:<br />
{| class="wikitable"<br />
|-<br />
! Tile<br />
! Friction<br />
! Comment<br />
|-<br />
| Tracks<br />
| 10<br />
|-<br />
| Ground/Floor<br />
| 200<br />
|-<br />
| Unusable ramp<br />
| 10<br />
|-<br />
| Upwards ramp<br />
| 4910 (10+4900)<br />
|-<br />
| Downwards ramp<br />
| -4890 (10-4900)<br />
|-<br />
| Roller<br />
| ±100000 (but capped by the set speed)<br />
|-<br />
| Corner track <br />
| 10<br />
| Speed reduced by 1000 upon leaving the corner tile<br />
|-<br />
| Track stop (highest)<br />
| 50000<br />
|-<br />
| Track stop (high)<br />
| 10000<br />
|-<br />
| Track stop (medium)<br />
| 500<br />
|-<br />
| Track stop (low)<br />
| 50<br />
|-<br />
| Track stop (lowest)<br />
| 10<br />
|-<br />
| Water 1-6<br />
| Additional (WaterLevel - 1) * 100<br />
| rowspan="2" | [[#Skipping|See Skipping]]<br />
|-<br />
| Magma 1-6<br />
| Additional (WaterLevel - 1) * 500<br />
|-<br />
| Empty space<br />
| 0<br />
|}<br />
<br />
Water of depth 7/7 provides a friction of about 10000 per step, as does maximum-depth magma. This higher friction may not apply to very slow-moving carts.<br />
<br />
Impulse sources:<br />
{| class="wikitable"<br />
|-<br />
! Feature<br />
! Speed<br />
|-<br />
| Push<br />
| 20000<br />
|-<br />
| Roller lowest<br />
| 10000<br />
|-<br />
| Roller low<br />
| 20000<br />
|-<br />
| Roller medium<br />
| 30000<br />
|-<br />
| Roller high<br />
| 40000<br />
|-<br />
| Roller Highest <br />
| 50000<br />
|-<br />
|}<br />
<br />
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 half-way point 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.<br />
<br />
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.)<br />
<br />
=== Sub-tile Positions and Velocity ===<br />
Carts store six values that are unique to them. Three sub-tile position values, and three velocity values. (X, Y, and Z.)<br />
<br />
Note that the Z position and velocity only matter when a cart is in flight. (See [[#Falling|Falling]] and [[#Cart Jumps|Cart Jumps]].)<br />
<br />
Each non-ramp tile is functionally composed of a value between 0 and 100,000, with a "centered" cart sitting at the 50,000 point in all three directions. 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. <br />
<br />
In essence, every sub-tile position unit is a decimal value of a tile, 0.000001 tiles, in a game that largely prefers integer values. <br />
<br />
When carts move beyond the maximum or minimum value 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 at 15,000 X sub-tile position and has an X velocity of -20,000 would move to -5000 X sub-tile position, which is out of bounds for that tile. As such, it will travel one tile West, and start the next tick at 95,000 X sub-tile position. 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.) <br />
<br />
Ramp tiles are longer, approximately 144,000 in the direction where it "slants downward", (to approximate a 45 degree slope, it is square root of two times longer,) and centered at 72,000. Because of this, a cart with no velocity dropped from a hatch will land at the center of a tile, at position 72,000, and 72,000, 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 0 or 144,000 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. <br />
<br />
Note that passing from one direction of ramp to another or to flat terrain causes unintuitive behavior, "teleporting" to the midpoint of another tile in what is called the "[[#Checkpoint Effect|checkpoint effect]]".<br />
<br />
Note, however, that 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:<br />
<br />
{{diagram|spaces=yes|\<br />
z0 z-1<br />
▒║▒ ▒▒▒<br />
═▼═ ▒╬▒<br />
▒ ▒ ▒║▒<br />
▒ : Wall<br />
═, ║ : Track <br />
╬ : Track and Ramp<br />
}}<br />
<br />
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 one tick in that tile, it will still have gained about -5k Y velocity, which will still apply motion Southward. If the tracks continue straight for another 11 tiles, it will have accumulated enough Southward motion to try to move a tile South, even if all tracks are facing East-West. <br />
<br />
'''Non-curving tracks do not correct this motion'''. <br />
<br />
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.) <br />
<br />
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, it will generate a diagonal track derailment that will send a cart flying until it strikes a wall, at which point it will not re-rail itself. In almost any circumstance, this is undesirable behavior. <br />
<br />
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. <br />
<br />
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. <br />
<br />
Curves are applied "halfway through" a tile. If a cart is moving East, and approaches a North-East track at 20k velocity, and friction is eliminated for the purposes of a cleaner demonstration, then when it enters the tile at sub-tile point 0 X, and 50k Y at the start of a tick, it will then move 20k East (+X) the next tick, and be at 20k X sub-tile position, and 50k Y sub-tile position. Next tick, it is at 40k X sub-tile position, and 50k Y sub-tile position. The next tick would take it to 60k X, but that's past the halfway point, so it stops at 50k, turns (and thus loses 1k velocity, but translates the rest from X-velocity to Y-velocity) and travels another 10k. It is now at 50k X sub-tile position, and 60k Y sub-tile position. Next tick, it travels at 19k velocity North, and so moves to 50k X sub-tile position, and 79k Y sub-tile position. Then in two more turns, it leaves to the North. <br />
<br />
In the case of diagonal motion due to having velocities in X and Y at the same time, it is critical that the direction the cart is heading in reaches that halfway point in a curve before the cart leaves the track off its sideways velocity direction. If it does so, 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 0 X sub-tile position with 20k X velocity, and 40k Y sub-tile position and -1k Y sub-tile position, it would take that "curve" (or rather, redirection of velocity) on the third turn, while it is at 38k Y sub-tile position to start with, and then move to 47k Y sub-tile position at the end of that tick. It would then move to 56k Y sub-tile position in the following turn, and take 3 turns, rather than just 2, to clear the tile.<br />
<br />
But, most importantly, it would be centered in the X sub-tile position, and with the negligible difference of an extra tick, all sideways velocity could be safely ignored.<br />
<br />
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. <br />
<br />
=== Track Direction Irrelevance ===<br />
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. <br />
<br />
This means, for example, that the following tracks, when a (non-guided) cart travels from West-to-East, are functionally identical in effect:<br />
<br />
{{diagram|spaces=yes|\<br />
A════════════B A╬║╚╔╣╩╦╠╥╨╞╡B<br />
}}<br />
<br />
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. <br />
<br />
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.<br />
<br />
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''. <br />
<br />
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''.<br />
<br />
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. <br />
<br />
If there is a curve the cart will respect, it checks for derailment. Carts derail at a speed whose exact number is currently unquantified, but is over 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 or impassible workshop tile, 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. <br />
<br />
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.<br />
<br />
=== Valid and Invalid Ramps ===<br />
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 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. <br />
<br />
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.) <br />
<br />
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. <br />
<br />
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.)<br />
<br />
=== Falling ===<br />
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.<br />
<br />
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. <br />
<br />
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, acceleration due to gravity in freefall seems curiously slightly ''slower'' than ramp acceleration.) 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.<br />
<br />
This means a cart falling (from a hatch, thus with no horizontal speed) 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}}<br />
<br />
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.<br />
<br />
=== Cart Jumps ===<br />
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. <br />
<br />
{{diagram|spaces=yes|\<br />
z0 z0 hiding ramps z+1 A z+1 B (hidden ramp)<br />
▒▒▒▒▒▒▒▒▒▒▒▒ ▒▒▒▒▒▒▒▒▒▒▒▒ ▒▒▒▒▒▒▒▒▒▒▒▒ ▒▒▒▒▒▒▒▒▒▒▒▒<br />
═▲▲▲▲▲══▲▒▲═ ═╚╚╚╚╚═══▒══ ▼▼▼▼▼ ▼═▼ ▼▼▼▼▼ ▼╚▼ <br />
▒ : Wall<br />
═ : track <br />
▲ : Ramp<br />
}}<br />
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.) <br />
<br />
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. <br />
<br />
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.<br />
<br />
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. The cart will also not fly off the ramp if there is a wall and ceiling preventing any motion but going down the ramp. <br />
<br />
=== Skipping ===<br />
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]].<br />
<br />
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.)<br />
<br />
=== Corner Ramp Derail ===<br />
<br />
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. <br />
<br />
This is caused by the fact that a cart, after turning the bend in the track halfway through the length of the tile, will still "accelerate down", which is now perpendicular to the movement of the cart, causing acceleration to occur in two directions. (Down corner ramps do not have this problem, as when they pass the halfway point, all perpendicular motion is added to forward motion, and after that curve, all downward acceleration is in the forward direction.) <br />
<br />
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.<br />
<br />
=== Checkpoint Effect ===<br />
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 into the next tile at the halfway point. <br />
<br />
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. <br />
<br />
This seems to be because ramps have a slightly longer length than regular tiles - 144,000, 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.<br />
<br />
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.<br />
<br />
Another useful thing to note about this exploit is that carts traveling at no less than 72,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. <br />
<br />
{{diagram|spaces=yes|\<br />
▒▒▒▒▒▒▒▒▒▒ ▒▒▒▒▒▒▒▒▒▒ <br />
═▲═▲═▲═▲═▲═ ═╚═╚═╚═╚═╚═ <br />
▒ : Wall<br />
═ : Normal track <br />
▲/╚ : N/E Track/Ramp<br />
}}<br />
<br />
If the cart enters from the West at less than 72,000 speed, some of those ramps will cause Eastward acceleration. <br />
<br />
This means that an impulse ramp not contiguous to other impulse ramps has a top speed of around 75k:<br />
<br />
{{diagram|spaces=yes|\<br />
▒▒▒▒▒ ▒▒▒▒▒<br />
▒╔═╗▒ ▒╔═╗▒<br />
▒╚▲╝▒ ▒╚╗╝▒<br />
▒▒▒▒▒ ▒▒▒▒▒<br />
}}<br />
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. <br />
<br />
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. <br />
{{diagram|spaces=yes|\<br />
▒▒▒▒▒▒ ▒▒▒▒▒▒<br />
▒╔══╗▒ ▒╔══╗▒<br />
▒╚▲▲╝▒ ▒╚╗╗╝▒<br />
▒▒▒▒▒▒ ▒▒▒▒▒▒<br />
}}<br />
This example results in a cart moving three times as fast as the previous cart.<br />
<br />
Three successive ramps results in the highest attainable speeds.<br />
<br />
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.<br />
<br />
=== Stacking ===<br />
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.<br />
<br />
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.<br />
<br />
<br />
=== Perfectly Elastic Collisions ===<br />
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. <br />
<br />
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].<br />
<br />
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.<br />
<br />
== Non-standard uses ==<br />
Minecarts include some interesting characteristics that have motivated uses beyond hauling. They can be useful for creating fully-automated [[exploit|quantum stockpiles]] and [[garbage disposal]]s. Storing perishable goods (meat, meals, etc.) inside a minecart appears to guard against rot and vermin.<br />
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]].<br />
Minecarts trigger [[pressure plate]]s, which means a trap can be designed to trigger when a thief attempts to steal a minecart.<br />
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}}<br />
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]].<br />
<br />
== Adventure mode ==<br />
In addition to being used for hauling, minecarts can also be ridden in [[adventure mode]]. (Adapted from forum thread {{cite forum|122903/4258212}})<br />
<br />
# If the minecart is in your inventory, drop it. If it is already on the ground, proceed to step 2.<br />
# Press {{k|u}} when you are 1 tile away from the minecart (or standing on the same tile as the minecart).<br />
# You will be presented with the following options:<br />
[[File:minecart adventure mode menu.png|left]]<br />
{{clear}}<br />
* 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. <br />
* 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]]. 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.<br />
<br />
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}})<br />
<br />
== Forging and Melting ==<br />
* Metal minecarts cost '''two''' [[metal]] bars to forge, or '''six''' [[adamantine]] wafers. <br />
* When a non-adamantine metal minecart is melted down, it will return '''1.8''' metal bars, for an '''efficiency of 90%'''.<br />
* When an adamantine minecart is melted down, it will produce '''1.8''' wafers, for an '''efficiency of 30%'''.<br />
<br />
== See also ==<br />
* [http://www.bay12forums.com/smf/index.php?topic=109460.0 The "How Does Minecart" Thread] by '''Girlinhat''' et al.<br />
* [http://www.bay12forums.com/smf/index.php?topic=112831.0 SCIENCE: Quantifying minecart physics] by '''Snaake''' et al.<br />
* [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'''.<br />
* [http://www.bay12forums.com/smf/index.php?topic=144328.0 My very own Minecart Education Thread. Ten Lessons, now complete.] by '''Larix'''.<br />
<br />
== Bugs ==<br />
*A dwarf will drop her [[child|baby]], if she has one, when boarding a minecart set to be ridden.<br />
*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.<br />
*Dwarves cannot guide a minecart through an unlocked door unless another dwarf opens the door.{{bug|6056}}<br />
*It is possible for a creature and minecart moving towards each other to pass without collision if they exchange tiles in the same tick.<br />
*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.<br />
*Minecarts falling onto a floor injure creatures in the tile below the floor.{{bug|6068}}<br />
*A minecart's initial velocity is not affected by weight, when pushed or launched from rollers.{{bug|6296}}<br />
*Removing a stop that has a vehicle waiting on it may cause the game to crash.{{bug|5980}}<br />
<br />
{{Category|Fortress mode}}<br />
{{Category|Interface}}<br />
<br />
[[ru:Minecart]]</div>Discotthttps://dwarffortresswiki.org/index.php?title=Minecart&diff=220690Minecart2015-10-16T20:57:15Z<p>Discott: added picture</p>
<hr />
<div>{{Quality|Masterwork|08:15, 19 May 2015 (UTC)}}<br />
{{av}}<br />
[[File:Leitnagel Hund.png|Minecarts]]<br />
A '''minecart''' is a [[tool]] intended for [[hauling]], introduced in version 0.34.08. It can be made of [[wood]] at a [[carpenter's workshop]] or [[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]].<br />
<br />
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 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.<br />
<br />
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.<br />
<br />
The invention of minecarts revolutionized the [[minecart logic|Science of Dwarfputing]] by enabling smaller, faster logic systems to be built.<br />
<br />
== Basic Minecart Usage ==<br />
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.<br />
<br />
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 be 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.<br />
<br />
To control which items to transport you can add conditions specifying: (1) which kind of items to be loaded, and unloaded, (2) stockpile links to define which stockpile(s) the items should be un/loaded to and from.<br />
<br />
===Capacity and weights ===<br />
Minecarts have five times the [[Weight|capacity]] of [[wheelbarrow]]s. <br />
<br />
'''Examples of the capacity of one cart'''<br />
{| class="wikitable"<br />
|-<br />
! Item<br />
! Amount<br />
|-<br />
| [[stone]]<br />
| 5<br />
|- <br />
| [[wood|log]]<br />
| 10<br />
|-<br />
| [[block]]/[[bar]]<br />
| 83<br />
|-<br />
| [[Kitchen|prepared meals]]<br />
| 500<br />
|-<br />
| [[Trap_component#Spiked_ball|spiked balls]]<br />
| 500<br />
|-<br />
| [[Weapon#Native_weapons|mace]]<br />
| 625<br />
|-<br />
| [[Weapon#Native_weapons|spears]]<br />
| 1250<br />
|-<br />
| [[cloth]]<br />
| 2500<br />
|}<br />
<br />
The weight of the loaded minecart does not affect the initial velocity received from pushing or launching from a roller. However, the load of a minecart ''does'' affect whether a [[pressure plate]] triggers or not, based on the pressure plate's setting.<br />
<br />
'''Weights of different carts'''<br />
<br />
{| class="wikitable"<br />
|-<br />
! Type of cart<br />
! Empty cart<br />
! Fully loaded (items)<br />
|-<br />
| oaken minecart <br />
| 28Γ<br />
| 378Γ (10 oak logs)<br />
|- <br />
| platinum minecart<br />
| 856Γ<br />
| 10482Γ (83 gold bars)<br />
|}<br />
<br />
<br />
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:<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Material !! Minecart weight !! Content weight required to trigger !! Banana roasts required to trigger (for scale)<br />
|-<br />
| [[Glumprong]] || 48 || 2 || 4<br />
|-<br />
| [[Electrum]] || 596 || 4 || 7<br />
|-<br />
| [[Nickel silver]] || 346 || 4 || 7<br />
|-<br />
| [[Brass]] || 342 || 8 || 14<br />
|-<br />
| [[Bismuth]] (moods only) || 391 || 9 || 15<br />
|-<br />
| [[Fine pewter]] || 291 || 9 || 15<br />
|-<br />
| [[Lay pewter]] || 291 || 9 || 15<br />
|-<br />
| [[Tin]] || 291 || 9 || 15<br />
|-<br />
| [[Trifle pewter]] || 291 || 9 || 15<br />
|}<br />
<br />
=== Creating tracks ===<br />
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.<br />
<br />
====Simple tracks====<br />
<br />
'''Carved'''<br />
<br />
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. <br />
<br />
'''Constructed'''<br />
<br />
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.<br />
<br />
====Ramps====<br />
<br />
'''Carved'''<br />
<br />
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.)<br />
<br />
'''Constructed'''<br />
<br />
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.<br />
<br />
'''Examples of ramps'''<br />
<br />
A simple ramp would look like this: <br />
{{diagram|spaces=yes|\<br />
z +0 z +1<br />
░░░░ ░░░░<br />
═▲o ░▼═<br />
░░░░ ░░░░<br />
o : wall<br />
}}<br />
<br />
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:<br />
{{diagram|spaces=yes|\<br />
z +0 z +1 <br />
░░░░░ ░░░░░ <br />
░░░░░ ══╗░░ <br />
=▲░░ ░░▼░░ <br />
░░░░░ ░░░░░ <br />
}}<br />
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.<br />
<br />
Moving to and from ramps (or between ramps "pointing" in different directions0 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}}<br />
<br />
{{anchor|Tracks}}<br />
<br />
=== Hauling route ===<br />
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.<br />
<br />
==== Route ====<br />
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.<br />
<br />
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.<br />
<br />
==== Stops ====<br />
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.<br />
<br />
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. Stops, which are the steps that make up a route, should not be confused with Track Stops, described below.<br />
<br />
===== Stockpile links =====<br />
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.<br />
<br />
===== Departure condition =====<br />
Departure conditions involve setting conditions in which the minecart will leave on the route. Each condition includes:<br />
# A departure mode (Guide, Ride or Push).<br />
# 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.<br />
# A timer, before which the departure condition cannot be met.<br />
# Conditions on the amount of items in the cart.<br />
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.<br />
<br />
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.<br />
<br />
=== Track Stops ===<br />
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.<br />
<br />
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.<br />
<br />
Counter-intuitive to their construction method, Track Stops are considered [[building]]s and must be removed by {{k|q}} {{k|x}}.<br />
* See [[#More_on_Track_stop |More on Track Stops]]<br />
<br />
=== Step-by-step tutorial ===<br />
<br />
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:<br />
<br />
[[File:minecart-example-1.png|Stockpiles designated.]]<br />
<br />
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.<br />
<br />
Next, carve the track:<br />
<br />
[[File:minecart-example-2.png|Track carving designation.]]<br />
<br />
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.)<br />
<br />
In addition, while we're waiting for that to happen, we'll build an iron minecart in the forge.<br />
<br />
[[File:minecart-example-3.png|Track carved.]]<br />
<br />
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:<br />
<br />
{|<br />
| [[File:minecart-example-4.png|Track stop designation.]]<br />
| [[File:minecart-example-5.png|Select dumping direction.]]<br />
|}<br />
<br />
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.<br />
<br />
[[File:minecart-example-6.png|Track stop constructed.]]<br />
<br />
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:<br />
<br />
{|<br />
| [[File:minecart-example-7.png|Stop 1 designation.]]<br />
| [[File:minecart-example-8.png|Route definition, in progress.]]<br />
|}<br />
<br />
Move the cursor again, to the output end of the track, and press {{k|s}} again to define the second stop:<br />
<br />
{|<br />
| [[File:minecart-example-9.png|Stop 2 designation.]]<br />
| [[File:minecart-example-10.png|Route definition, two stops.]]<br />
|-<br />
|<br />
| [[File:minecart-example-11.png|Stops are not defined yet.]]<br />
|}<br />
<br />
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|-}}.<br />
<br />
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:<br />
<br />
[[File:minecart-example-12.png|Default stop definition.]]<br />
<br />
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.<br />
<br />
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.<br />
<br />
When you've done all that, stop 1 should look like this:<br />
<br />
[[File:minecart-example-13.png|Stop 1, defined.]]<br />
<br />
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:<br />
<br />
[[File:minecart-example-14.png|Stop 2, defined.]]<br />
<br />
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}}.<br />
<br />
Now we've got everything set up:<br />
<br />
[[File:minecart-example-15.png|Route, fully defined.]]<br />
<br />
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.<br />
<br />
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!<br />
<br />
=== Troubleshooting ===<br />
<br />
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. <br />
<br />
'''Symptom:''' {{DFtext|! Set dir/connect track|6:1}} message appears to the right of one or more stops <br />
<br />
'''Possible Causes:'''<br />
* In basic terms, the game checks if there is a valid path for a cart along the rails to reach the next stop in the route, and whether a dwarf ''guiding'' a cart would be able to find a path to the destination without carrying the cart. This warning pops up if the cart can't find a valid path based upon guided carts.<br />
** 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. (But double-check to make sure it's fine...)<br />
* The departure direction of the stop might be invalid. Edit the stop using {{k|Enter}} and press{{k|d}} until it is pointing in a valid direction.<br />
* The track stop might not be built on top of a track. The track stop must be deconstructed to remedy this issue.<br />
* Your track might not be built correctly. Make sure all connected tracks between destinations are not one-way tracks.<br />
** This can be especially confusing with ramps. To carve a two-way track on a (natural) ramp, you must designate the ramp <b>and one square beyond</b> in the direction you want the track to go.<br />
** Ramps '''must''' have a solid block on the side opposite to the track, or they will neither work nor be marked as "unusable". The solid block can be natural or constructed.<br />
* The desired/kept items might not be configured correctly.<br />
<br />
'''Symptom:''' The status '''0% <span style="color:#00dd00;">V</span>''' always appears to the right of one stop. <br />
<br />
'''Possible Causes:''' <br />
* The stop may not be set to take from a stockpile. Edit the Stop using {{k|Enter}} and make sure you see a message like "Take from Stockpile #1".<br />
* The take conditions must correspond with the contents of the stockpile.<br />
* The track stop may be 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.)<br />
* Make sure the minecart itself has not been designated to be dumped (such as when using mass-dump).<br />
<br />
'''Symptom:''' Dwarves fill the minecart properly, but will not move it thereafter.<br />
<br />
'''Possible Causes:''' <br />
* The minecart may contain items which are not included in its current stop's desired items. Check inside the minecart using the {{key|k}} and {{key|z}} keys and ensure that all items in the cart are desired items.<br />
* The minecart may 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).<br />
<br />
'''Symptom:''' Dwarves repeatedly attempt to load the minecart, but no items are ever loaded into it.<br />
<br />
'''Possible Causes:''' <br />
* This can be caused by using a Track Stop with autodumping enabled at 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.<br />
<br />
'''Symptom:''' A dwarf picks up the minecart and carries it to its destination.<br />
* See [[#Quirks|Quirks]]<br />
<br />
=== Danger ===<br />
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.<br />
<br />
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).<br />
<br />
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."<br />
<br />
Of course, the danger of using minecarts means they can also be [[Trap_design#Minecarts|used as weapons]] by imaginative players.<br />
<br />
== Advanced usage and automation ==<br />
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}}. <br />
<br />
=== More on Track stop === <br />
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). <br />
<br />
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. <br />
<br />
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}}<br />
<br />
=== Automated propulsion ===<br />
==== Roller ====<br />
{{Main|Roller}}<br />
<br />
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.<br />
<br />
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.<br />
<br />
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}}<br />
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}}<br />
<br />
{{diagram|spaces=yes|\<br />
tracks: full:<br />
║ ║<br />
═╗═ ═╢═<br />
║ ║ <br />
<br />
╢ : roller pushing from W to E<br />
}}<br />
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.<br />
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.<br />
<br />
{{diagram|spaces=yes|\<br />
║ ║ <br />
═╗═ ═╟═<br />
║ ║<br />
<br />
╟ : Roller pushing from E to W<br />
}}<br />
Carts from the E or W: exit W.<br />
Carts from N: derailed diagonally, exit SW.<br />
Carts from S: derailed diagonally, exit NW.<br />
<br />
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.<br />
<br />
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}} &mdash; this allows a one-way track to be used in both directions. In addition, unpowered rollers do not affect minecarts.<br />
<br />
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.<br />
<br />
<br />
==== Impulse ramps ====<br />
Carts can be given momentum without rollers or changing z-level through a phenomenon called "impulse ramps". A track ramp which is connected both to a wall and to a floor will ''always'' accelerate a cart towards the connected floor tile, no matter where the cart enters the tile from. This means carts can be accelerated as though dropping z-levels, even if the cart doesn't actually change z-level at all. 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.<br />
<br />
Example of straight impulse acceleration:<br />
<br />
{{diagram|spaces=yes|\<br />
▒▒▒▒▒▒▒▒▒▒ ▒▒▒▒▒▒▒▒▒▒ <br />
═▲▲▲▲▲▲▲▲▲▲═ ═╚╚╚╚╚╚╚╚╚╚═ <br />
▒ : Wall<br />
═ : Normal track <br />
▲/╚ : N/E Track/Ramp<br />
}}<br />
<br />
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.<br />
<br />
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.<br />
<br />
Example of an impulse elevator:<br />
<br />
{{diagram|spaces=yes|\<br />
z +0 z +1 z +2 z +3<br />
░░░░░ ░░░░░ ░░░░░ ░░░░░<br />
░╔░░░ ░▼╚╗░ ░░▼▼░ ░░░░░<br />
░╝░░░ ░▼░░░ ░░░╔░ ░░░▼░<br />
░▼▼░░ ░░░░░ ░░░╝░ ░╚╗▼░<br />
░░░░░ ░░░░░ ░░░░░ ░░░░░<br />
<br />
░ : Wall<br />
╔,╚,╗,╝ : Track/Ramp<br />
▼ : Down Ramp (empty space)<br />
}}<br />
<br />
Note that this impulse elevator, 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.<br />
<br />
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.<br />
<br />
{{diagram|spaces=yes|\<br />
z +0 z +1 z +2 z +3<br />
░░░░░░ ░░░░░░ ░░░░░░ ░░░░░░<br />
░░░░░░ ░╔╔═░░ ░░▼▼╗░ ░░░░░░<br />
░║░░░░ ░▼░░░░ ░░░░╗░ ░░░░▼░<br />
░╚░░░░ ░▼░░░░ ░░░░║░ ░░░░▼░<br />
░╚▼▼░░ ░░░░░░ ░░░░░░ ░░═╝╝░<br />
░░░░░░ ░░░░░░ ░░░░░░ ░░░░░░<br />
<br />
░ : Wall<br />
║,═,╔,╚,╗,╝ : Track/Ramp<br />
▼ : Down Ramp (empty space)<br />
}}<br />
<br />
Also, if you want to have a cart following a below-derail speed, the following track works well:<br />
{{diagram|spaces=yes|\<br />
z +0 z +1 z +2 z +3<br />
░░░░░ ░░░░░ ░░░░░ ░░░░░<br />
░░░░░ ░══░░ ░▼▼║░ ░░░▼░<br />
░║░░░ ░▼░░░ ░░░║░ ░░░▼░<br />
░║▼▼░ ░▼░░░ ░░░░░ ░░══░<br />
░░░░░ ░░░░░ ░░░░░ ░░░░░<br />
<br />
░ : Wall<br />
║,═ : Track/Ramp<br />
▼ : Down Ramp (empty space)<br />
}}<br />
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. <br />
<br />
<br />
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.<br />
<br />
=== Controlling traffic ===<br />
<br />
==== Switching ====<br />
<!-- copying template ║ ═ ╔ ╗ ╚ ╝ ╠ ╣ ╦ ╩ ╬ ╞ ╡ ╥ ╨ --><br />
As constructions or tile features, [[door]]s and other furniture can be built on tracks. 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. <br />
{{diagram|spaces=yes|\<br />
-><br />
A ════┤≡════ B<br />
┤ : roller pushing to East<br />
≡ : door<br />
}}<br />
The roller pushes the cart east, but until the "departure condition" is fulfilled, the door remains closed and blocks the path. <br />
<br />
[[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.<br />
<br />
A powered track switch can be constructed by building an "inverted" corner as illustrated below.<br />
{{diagram|spaces=yes|\<br />
B B<br />
║ -> ║<br />
║ ║<br />
════╚═══ ════├════<br />
A C A C<br />
├ : roller pushing to West.<br />
}}<br />
<br />
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.<br />
<br />
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.<br />
{{diagram|spaces=yes|\<br />
B ╥<br />
║<br />
║<br />
╞════╝ ════╡<br />
A D C<br />
}}<br />
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).<br />
<br />
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.<br />
<br />
If carts are moving too slowly to derail at the corner, a retractable bridge may be used as a connector between A and C. <br />
{{diagram|spaces=yes|\<br />
B╥<br />
║<br />
║<br />
A╞════bbb════╡C<br />
}}<br />
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.<br />
<br />
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.<br />
<br />
==== Controlling Speed ====<br />
<!-- copying template ║ ═ ╔ ╗ ╚ ╝ ╠ ╣ ╦ ╩ ╬ ╞ ╡ ╥ ╨ --><br />
<br />
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:<br />
<br />
Will derail at > 0.5 t/st:<br />
<br />
{{diagram|spaces=yes|\<br />
in ══╗ -> derailing<br />
║<br />
out<br />
}}<br />
<br />
Will not derail at > 0.5 t/st:<br />
{{diagram|spaces=yes|\<br />
in ══╗O<br />
║<br />
out<br />
<br />
O : wall/column.<br />
}}<br />
<br />
This behavior can be used to build a "speed limiter", that will ensure that when a minecart exits it is traveling below derail speed:<br />
{{diagram|spaces=yes|\<br />
░░░░ ░░░░░ ░░░░░<br />
in ═╔═╗░ ░╔S╗░ ░╔S╗░<br />
out ═╬═╝░ out ═╗═╝░ out ═╗═╝░<br />
░╚S╝░ ░╚═╝═ in ░╚S╝░<br />
░░░░░ ░░░░ ║░░░<br />
in<br />
░ : wall<br />
S : Track Stop (High Friction or lower)<br />
}}<br />
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.<br />
<br />
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.<br />
<br />
=== Loading liquids ===<br />
[[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).<br />
The liquids can be dumped by a constructed track stop.<br />
<br />
== Quirks ==<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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}}<br />
<br />
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.<br />
<br />
== Physics ==<br />
<!-- copying template ║ ═ ╔ ╗ ╚ ╝ ╠ ╣ ╦ ╩ ╬ ╞ ╡ ╥ ╨ --><br />
<br />
Minecart physics depend greatly on the departure mode set in the route stop conditions.<br />
<br />
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.<br />
<br />
The difference between "Push" and "Ride" is whether the dwarf will go along with the cart or not.<br />
{{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.<br />
{{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.<br />
{{DFtext|Guide}}: minecarts seem to ignore all laws of physics. That is:<br />
*Ignore the weight of any and all items inside. Therefore:<br />
**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.<br />
*Ignore working rollers.<br />
*Will ''not'' collide with other guided carts even when a full frontal collision would be expected.<br />
*Will go up ramps like nobody's business.<br />
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.<br />
<br />
Some samples with behavior:<br />
{{diagram|spaces=yes|\<br />
A <-> B A <-> C A <-> B<br />
B B B <br />
║ ║ ║ <br />
A══╝ A══╩══C A══╬╗<br />
You can only go A->B ╚╝<br />
Works when the cart Works <br />
is in Guide mode. <br />
}}<br />
In the second example above, a cart "pushed" from B will go over the junction and roll off into the unknown south.<br />
<br />
=== Numbers behind the scene ===<br />
<br />
According to early research by '''expwnent'''{{cite forum|112831/3536975}}:<br />
<br />
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]].)<br />
<br />
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 either above 100,000 or below 0, (or several tiles if velocity is over 100,000,) and 100,000 is either added or subtracted to sub-tile position to restart the count to the next tile change. <br />
<br />
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 cover about four times the distance in a straight line, but only twice the distance along a winding track with very many corners.<br />
<br />
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 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. <br />
<br />
Friction of tiles:<br />
{| class="wikitable"<br />
|-<br />
! Tile<br />
! Friction<br />
! Comment<br />
|-<br />
| Tracks<br />
| 10<br />
|-<br />
| Ground/Floor<br />
| 200<br />
|-<br />
| Unusable ramp<br />
| 10<br />
|-<br />
| Upwards ramp<br />
| 4910 (10+4900)<br />
|-<br />
| Downwards ramp<br />
| -4890 (10-4900)<br />
|-<br />
| Roller<br />
| ±100000 (but capped by the set speed)<br />
|-<br />
| Corner track <br />
| 10<br />
| Speed reduced by 1000 upon leaving the corner tile<br />
|-<br />
| Track stop (highest)<br />
| 50000<br />
|-<br />
| Track stop (high)<br />
| 10000<br />
|-<br />
| Track stop (medium)<br />
| 500<br />
|-<br />
| Track stop (low)<br />
| 50<br />
|-<br />
| Track stop (lowest)<br />
| 10<br />
|-<br />
| Water 1-6<br />
| Additional (WaterLevel - 1) * 100<br />
| rowspan="2" | [[#Skipping|See Skipping]]<br />
|-<br />
| Magma 1-6<br />
| Additional (WaterLevel - 1) * 500<br />
|-<br />
| Empty space<br />
| 0<br />
|}<br />
<br />
Water of depth 7/7 provides a friction of about 10000 per step, as does maximum-depth magma. This higher friction may not apply to very slow-moving carts.<br />
<br />
Impulse sources:<br />
{| class="wikitable"<br />
|-<br />
! Feature<br />
! Speed<br />
|-<br />
| Push<br />
| 20000<br />
|-<br />
| Roller lowest<br />
| 10000<br />
|-<br />
| Roller low<br />
| 20000<br />
|-<br />
| Roller medium<br />
| 30000<br />
|-<br />
| Roller high<br />
| 40000<br />
|-<br />
| Roller Highest <br />
| 50000<br />
|-<br />
|}<br />
<br />
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 half-way point 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.<br />
<br />
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.)<br />
<br />
=== Sub-tile Positions and Velocity ===<br />
Carts store six values that are unique to them. Three sub-tile position values, and three velocity values. (X, Y, and Z.)<br />
<br />
Note that the Z position and velocity only matter when a cart is in flight. (See [[#Falling|Falling]] and [[#Cart Jumps|Cart Jumps]].)<br />
<br />
Each non-ramp tile is functionally composed of a value between 0 and 100,000, with a "centered" cart sitting at the 50,000 point in all three directions. 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. <br />
<br />
In essence, every sub-tile position unit is a decimal value of a tile, 0.000001 tiles, in a game that largely prefers integer values. <br />
<br />
When carts move beyond the maximum or minimum value 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 at 15,000 X sub-tile position and has an X velocity of -20,000 would move to -5000 X sub-tile position, which is out of bounds for that tile. As such, it will travel one tile West, and start the next tick at 95,000 X sub-tile position. 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.) <br />
<br />
Ramp tiles are longer, approximately 144,000 in the direction where it "slants downward", (to approximate a 45 degree slope, it is square root of two times longer,) and centered at 72,000. Because of this, a cart with no velocity dropped from a hatch will land at the center of a tile, at position 72,000, and 72,000, 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 0 or 144,000 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. <br />
<br />
Note that passing from one direction of ramp to another or to flat terrain causes unintuitive behavior, "teleporting" to the midpoint of another tile in what is called the "[[#Checkpoint Effect|checkpoint effect]]".<br />
<br />
Note, however, that 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:<br />
<br />
{{diagram|spaces=yes|\<br />
z0 z-1<br />
▒║▒ ▒▒▒<br />
═▼═ ▒╬▒<br />
▒ ▒ ▒║▒<br />
▒ : Wall<br />
═, ║ : Track <br />
╬ : Track and Ramp<br />
}}<br />
<br />
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 one tick in that tile, it will still have gained about -5k Y velocity, which will still apply motion Southward. If the tracks continue straight for another 11 tiles, it will have accumulated enough Southward motion to try to move a tile South, even if all tracks are facing East-West. <br />
<br />
'''Non-curving tracks do not correct this motion'''. <br />
<br />
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.) <br />
<br />
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, it will generate a diagonal track derailment that will send a cart flying until it strikes a wall, at which point it will not re-rail itself. In almost any circumstance, this is undesirable behavior. <br />
<br />
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. <br />
<br />
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. <br />
<br />
Curves are applied "halfway through" a tile. If a cart is moving East, and approaches a North-East track at 20k velocity, and friction is eliminated for the purposes of a cleaner demonstration, then when it enters the tile at sub-tile point 0 X, and 50k Y at the start of a tick, it will then move 20k East (+X) the next tick, and be at 20k X sub-tile position, and 50k Y sub-tile position. Next tick, it is at 40k X sub-tile position, and 50k Y sub-tile position. The next tick would take it to 60k X, but that's past the halfway point, so it stops at 50k, turns (and thus loses 1k velocity, but translates the rest from X-velocity to Y-velocity) and travels another 10k. It is now at 50k X sub-tile position, and 60k Y sub-tile position. Next tick, it travels at 19k velocity North, and so moves to 50k X sub-tile position, and 79k Y sub-tile position. Then in two more turns, it leaves to the North. <br />
<br />
In the case of diagonal motion due to having velocities in X and Y at the same time, it is critical that the direction the cart is heading in reaches that halfway point in a curve before the cart leaves the track off its sideways velocity direction. If it does so, 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 0 X sub-tile position with 20k X velocity, and 40k Y sub-tile position and -1k Y sub-tile position, it would take that "curve" (or rather, redirection of velocity) on the third turn, while it is at 38k Y sub-tile position to start with, and then move to 47k Y sub-tile position at the end of that tick. It would then move to 56k Y sub-tile position in the following turn, and take 3 turns, rather than just 2, to clear the tile.<br />
<br />
But, most importantly, it would be centered in the X sub-tile position, and with the negligible difference of an extra tick, all sideways velocity could be safely ignored.<br />
<br />
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. <br />
<br />
=== Track Direction Irrelevance ===<br />
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. <br />
<br />
This means, for example, that the following tracks, when a (non-guided) cart travels from West-to-East, are functionally identical in effect:<br />
<br />
{{diagram|spaces=yes|\<br />
A════════════B A╬║╚╔╣╩╦╠╥╨╞╡B<br />
}}<br />
<br />
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. <br />
<br />
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.<br />
<br />
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''. <br />
<br />
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''.<br />
<br />
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. <br />
<br />
If there is a curve the cart will respect, it checks for derailment. Carts derail at a speed whose exact number is currently unquantified, but is over 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 or impassible workshop tile, 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. <br />
<br />
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.<br />
<br />
=== Valid and Invalid Ramps ===<br />
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 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. <br />
<br />
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.) <br />
<br />
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. <br />
<br />
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.)<br />
<br />
=== Falling ===<br />
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.<br />
<br />
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. <br />
<br />
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, acceleration due to gravity in freefall seems curiously slightly ''slower'' than ramp acceleration.) 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.<br />
<br />
This means a cart falling (from a hatch, thus with no horizontal speed) 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}}<br />
<br />
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.<br />
<br />
=== Cart Jumps ===<br />
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. <br />
<br />
{{diagram|spaces=yes|\<br />
z0 z0 hiding ramps z+1 A z+1 B (hidden ramp)<br />
▒▒▒▒▒▒▒▒▒▒▒▒ ▒▒▒▒▒▒▒▒▒▒▒▒ ▒▒▒▒▒▒▒▒▒▒▒▒ ▒▒▒▒▒▒▒▒▒▒▒▒<br />
═▲▲▲▲▲══▲▒▲═ ═╚╚╚╚╚═══▒══ ▼▼▼▼▼ ▼═▼ ▼▼▼▼▼ ▼╚▼ <br />
▒ : Wall<br />
═ : track <br />
▲ : Ramp<br />
}}<br />
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.) <br />
<br />
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. <br />
<br />
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.<br />
<br />
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. The cart will also not fly off the ramp if there is a wall and ceiling preventing any motion but going down the ramp. <br />
<br />
=== Skipping ===<br />
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]].<br />
<br />
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.)<br />
<br />
=== Corner Ramp Derail ===<br />
<br />
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. <br />
<br />
This is caused by the fact that a cart, after turning the bend in the track halfway through the length of the tile, will still "accelerate down", which is now perpendicular to the movement of the cart, causing acceleration to occur in two directions. (Down corner ramps do not have this problem, as when they pass the halfway point, all perpendicular motion is added to forward motion, and after that curve, all downward acceleration is in the forward direction.) <br />
<br />
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.<br />
<br />
=== Checkpoint Effect ===<br />
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 into the next tile at the halfway point. <br />
<br />
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. <br />
<br />
This seems to be because ramps have a slightly longer length than regular tiles - 144,000, 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.<br />
<br />
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.<br />
<br />
Another useful thing to note about this exploit is that carts traveling at no less than 72,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. <br />
<br />
{{diagram|spaces=yes|\<br />
▒▒▒▒▒▒▒▒▒▒ ▒▒▒▒▒▒▒▒▒▒ <br />
═▲═▲═▲═▲═▲═ ═╚═╚═╚═╚═╚═ <br />
▒ : Wall<br />
═ : Normal track <br />
▲/╚ : N/E Track/Ramp<br />
}}<br />
<br />
If the cart enters from the West at less than 72,000 speed, some of those ramps will cause Eastward acceleration. <br />
<br />
This means that an impulse ramp not contiguous to other impulse ramps has a top speed of around 75k:<br />
<br />
{{diagram|spaces=yes|\<br />
▒▒▒▒▒ ▒▒▒▒▒<br />
▒╔═╗▒ ▒╔═╗▒<br />
▒╚▲╝▒ ▒╚╗╝▒<br />
▒▒▒▒▒ ▒▒▒▒▒<br />
}}<br />
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. <br />
<br />
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. <br />
{{diagram|spaces=yes|\<br />
▒▒▒▒▒▒ ▒▒▒▒▒▒<br />
▒╔══╗▒ ▒╔══╗▒<br />
▒╚▲▲╝▒ ▒╚╗╗╝▒<br />
▒▒▒▒▒▒ ▒▒▒▒▒▒<br />
}}<br />
This example results in a cart moving three times as fast as the previous cart.<br />
<br />
Three successive ramps results in the highest attainable speeds.<br />
<br />
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.<br />
<br />
=== Stacking ===<br />
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.<br />
<br />
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.<br />
<br />
<br />
=== Perfectly Elastic Collisions ===<br />
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. <br />
<br />
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].<br />
<br />
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.<br />
<br />
== Non-standard uses ==<br />
Minecarts include some interesting characteristics that have motivated uses beyond hauling. They can be useful for creating fully-automated [[exploit|quantum stockpiles]] and [[garbage disposal]]s. Storing perishable goods (meat, meals, etc.) inside a minecart appears to guard against rot and vermin.<br />
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]].<br />
Minecarts trigger [[pressure plate]]s, which means a trap can be designed to trigger when a thief attempts to steal a minecart.<br />
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}}<br />
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]].<br />
<br />
== Adventure mode ==<br />
In addition to being used for hauling, minecarts can also be ridden in [[adventure mode]]. (Adapted from forum thread {{cite forum|122903/4258212}})<br />
<br />
# If the minecart is in your inventory, drop it. If it is already on the ground, proceed to step 2.<br />
# Press {{k|u}} when you are 1 tile away from the minecart (or standing on the same tile as the minecart).<br />
# You will be presented with the following options:<br />
[[File:minecart adventure mode menu.png|left]]<br />
{{clear}}<br />
* 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. <br />
* 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]]. 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.<br />
<br />
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}})<br />
<br />
== Forging and Melting ==<br />
* Metal minecarts cost '''two''' [[metal]] bars to forge, or '''six''' [[adamantine]] wafers. <br />
* When a non-adamantine metal minecart is melted down, it will return '''1.8''' metal bars, for an '''efficiency of 90%'''.<br />
* When an adamantine minecart is melted down, it will produce '''1.8''' wafers, for an '''efficiency of 30%'''.<br />
<br />
== See also ==<br />
* [http://www.bay12forums.com/smf/index.php?topic=109460.0 The "How Does Minecart" Thread] by '''Girlinhat''' et al.<br />
* [http://www.bay12forums.com/smf/index.php?topic=112831.0 SCIENCE: Quantifying minecart physics] by '''Snaake''' et al.<br />
* [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'''.<br />
* [http://www.bay12forums.com/smf/index.php?topic=144328.0 My very own Minecart Education Thread. Ten Lessons, now complete.] by '''Larix'''.<br />
<br />
== Bugs ==<br />
*A dwarf will drop her [[child|baby]], if she has one, when boarding a minecart set to be ridden.<br />
*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.<br />
*Dwarves cannot guide a minecart through an unlocked door unless another dwarf opens the door.{{bug|6056}}<br />
*It is possible for a creature and minecart moving towards each other to pass without collision if they exchange tiles in the same tick.<br />
*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.<br />
*Minecarts falling onto a floor injure creatures in the tile below the floor.{{bug|6068}}<br />
*A minecart's initial velocity is not affected by weight, when pushed or launched from rollers.{{bug|6296}}<br />
*Removing a stop that has a vehicle waiting on it may cause the game to crash.{{bug|5980}}<br />
<br />
{{Category|Fortress mode}}<br />
{{Category|Interface}}<br />
<br />
[[ru:Minecart]]</div>Discotthttps://dwarffortresswiki.org/index.php?title=Bin&diff=220687Bin2015-10-16T19:17:18Z<p>Discott: added picture</p>
<hr />
<div>{{Quality|Exceptional|21:47, 17 May 2015 (UTC)}}<br />
{{av}}<br />
<br />
{{furniture|name=Bin<br />
|tile=X|col=0:6:0<br />
|wood=y<br />
|metal=y<br />
|glass=N<br />
}}<br />
A '''bin''' is a specially made basket for certain [[stockpile]]s. A bin can be made from one [[wood|wooden log]] at a [[carpenter's workshop]] or forged from 3 [[metal]] [[bar]]s at a [[forge]]. Bins make it possible to store lots of objects into one tile of a stockpile. A stockpile without a bin will likely fill up fast, leaving any remaining items where they are to get in the way.<br />
<br />
Bins are therefore incredibly useful to a maturing fortress. The best material for bins is generally [[wood]], because wooden bins are the lightest bins and will therefore save your haulers' time. Of course, if you intend to use bins next to a volcano or something equally [[fire|hot]], you may want to use metal bins. <br />
<br />
If your fort suffers from a lack of wood but charcoal is also your only [[fuel]] source, producing metal instead of wooden bins will actually '''increase''' your wood consumption. Forging each bin will cost one unit of fuel and smelting the metal bars will also require fuel. Charcoal is produced at a rate of one bar per log. You can only reduce wood consumption by making metal bins if you use coke or [[magma]] to heat your smelters and forges.<br />
<br />
Stockpiles that use bins are [[ammunition|ammo]], [[armor]], [[bar]]s/[[block]]s, [[cloth]], [[Currency|coins]], [[finished goods]], [[gems]], [[leather]] and [[weapon]]s. [[Food]] stockpiles use [[barrel]]s and [[large pot]]s instead of bins. Other stockpiles do not use anything at all.<br />
<br />
Bins are a fast way to transport trade goods to a [[trade depot]]. Instead of carrying the individual item, the dwarf will haul the whole container for trade. Though if the contents inside are heavy, it will still take a long time.<br />
<br />
For information on managing bins in stockpiles, see [[using bins and barrels]].<br />
<br />
== Bugs ==<br />
<br />
* Hauling jobs block access to all the items in the destination containers until the hauling is complete. This often results in cancellation spam and work delays.{{bug|9004}} One workaround is creating a "feeder stockpile" with containers disabled.<br />
<br />
* [[Ammunition]] stored in bins may not appear available to marksdwarves, eventually causing them to head to battle without bolts. Disabling bins in ammo [[stockpile]]s is recommended.{{bug|2706}}<br />
* Items in bins are sometimes not found for tasks.{{bug|8755}}<br />
<br />
== See also ==<br />
* [[Container]]<br />
<br />
<gallery><br />
File:Wood (2942371043).jpg|A large number of wooden bins stacked upon each other.<br />
</gallery><br />
{{Translation<br />
| dwarven = osed<br />
| elvish = masa<br />
| goblin = sputo<br />
| human = itlud<br />
}}</div>Discotthttps://dwarffortresswiki.org/index.php?title=Lignite&diff=220685Lignite2015-10-16T17:39:14Z<p>Discott: added picture</p>
<hr />
<div>{{stonelookup/0|uses=* Create 5 [[coke]] at [[smelter]]}}{{av}}{{Quality|Exceptional|22:05, 8 June 2010 (UTC)}}<br />
<br />
One of the two mineral sources of [[fuel]], '''Lignite''' is found in [[vein]]s in [[sedimentary layer]]s. When processed at a [[smelter]] or [[magma smelter]], one unit of lignite produces 5 units of [[Fuel#The_two_sub-types_of_fuel|coke]]. If done at a regular [[smelter]], this processing requires one pre-existing unit of fuel (either [[Fuel#The_two_sub-types_of_fuel|charcoal]] or coke), leaving a ''net'' production of 4 fuel.<br />
<br />
Lignite is flammable - if exposed to [[fire]] or [[magma]], an item made of lignite will burn for the better part of a year before [[wear]]ing away. Exposure to [[water]] (including rain) will extinguish it, unless it happens to be stored in a [[bin]].<br />
<br />
==See also==<br />
* [[Bituminous coal]]<br />
<br />
<gallery><br />
File:DBM Deutsches Bergbau-Museum Bochum, Lignit Westerwald.JPG|A block of lignite.<br />
</gallery><br />
<br />
{{gamedata}}<br />
{{stones}}<br />
{{Category|Economic Stone}}</div>Discotthttps://dwarffortresswiki.org/index.php?title=Bituminous_coal&diff=220684Bituminous coal2015-10-16T17:37:12Z<p>Discott: </p>
<hr />
<div>{{Quality|Superior|09:13, 18 May 2015 (UTC)}}<br />
{{stonelookup/0|uses=<br />
* Create 9 [[fuel#Coke, from bituminous coal or lignite|coke]] at [[smelter]]}}{{av}}<br />
<br />
'''Bituminous coal''' is found in [[vein]]s in [[sedimentary layer]]s and is one of the two mineral sources of [[fuel]]. When processed at a [[smelter]] or [[magma smelter]], one unit of bituminous coal produces 9 units of [[fuel#Coke, from bituminous coal or lignite|coke]]. If done at a regular [[smelter]], this processing requires one pre-existing unit of fuel (either charcoal or coke), leaving a ''net'' production of 8 fuel.<br />
<br />
Bituminous coal is flammable, and obviously is ''not'' a [[fire-safe]] material - if exposed to [[fire]] or [[magma]], an item made of bituminous coal will burn for the better part of a year before [[wear]]ing away. Exposure to [[water]] (including rain) will extinguish it, unless it happens to be stored in a [[bin]].<br />
<br />
Bituminous coal is '''not''' the same as [[fuel|"refined coal" or "coal"]], though it is directly related.<br />
<br />
==See also==<br />
* [[Lignite]]<br />
* [[Fuel]]<br />
<br />
{{d for dwarf}}<br />
Of all the fallacies of the humans probably the most laughable is "Old Eartherism". Some humans have estimated the world's age from the ludicrous 6000, to the unimaginable 4.5 billion years. As "proof" they point to the bones of giant lizards buried beneath the soil, and coal, which they claim is the byproduct of the lizard's decay. Dwarven history extends back to 1 year after the creation of earth, and coal is amply documented even then. Dwarves are also well aware of how those monstrous lizards' bones ended up underground, as well as *exactly* what they decay into. They don't bother to correct the humans because they think they're cute when they're wrong.<br />
<br />
<gallery><br />
File:Coal bituminous.jpg| A piece of bituminous coal.<br />
</gallery><br />
{{gamedata}}<br />
{{stones}}<br />
{{Category|Economic Stone}}</div>Discotthttps://dwarffortresswiki.org/index.php?title=Bituminous_coal&diff=220683Bituminous coal2015-10-16T17:33:41Z<p>Discott: added picture</p>
<hr />
<div>{{Quality|Superior|09:13, 18 May 2015 (UTC)}}<br />
{{stonelookup/0|uses=<br />
* Create 9 [[fuel#Coke, from bituminous coal or lignite|coke]] at [[smelter]]}}{{av}}<br />
<br />
'''Bituminous coal''' is found in [[vein]]s in [[sedimentary layer]]s and is one of the two mineral sources of [[fuel]]. When processed at a [[smelter]] or [[magma smelter]], one unit of bituminous coal produces 9 units of [[fuel#Coke, from bituminous coal or lignite|coke]]. If done at a regular [[smelter]], this processing requires one pre-existing unit of fuel (either charcoal or coke), leaving a ''net'' production of 8 fuel.<br />
<br />
Bituminous coal is flammable, and obviously is ''not'' a [[fire-safe]] material - if exposed to [[fire]] or [[magma]], an item made of bituminous coal will burn for the better part of a year before [[wear]]ing away. Exposure to [[water]] (including rain) will extinguish it, unless it happens to be stored in a [[bin]].<br />
<br />
Bituminous coal is '''not''' the same as [[fuel|"refined coal" or "coal"]], though it is directly related.<br />
<br />
==See also==<br />
* [[Lignite]]<br />
* [[Fuel]]<br />
<br />
{{d for dwarf}}<br />
Of all the fallacies of the humans probably the most laughable is "Old Eartherism". Some humans have estimated the world's age from the ludicrous 6000, to the unimaginable 4.5 billion years. As "proof" they point to the bones of giant lizards buried beneath the soil, and coal, which they claim is the byproduct of the lizard's decay. Dwarven history extends back to 1 year after the creation of earth, and coal is amply documented even then. Dwarves are also well aware of how those monstrous lizards' bones ended up underground, as well as *exactly* what they decay into. They don't bother to correct the humans because they think they're cute when they're wrong.<br />
<br />
<gallery><br />
File:Coal bituminous.jpg| A piece of bituminous coal.<br />
<gallery /><br />
{{gamedata}}<br />
{{stones}}<br />
{{Category|Economic Stone}}</div>Discotthttps://dwarffortresswiki.org/index.php?title=Limestone&diff=220682Limestone2015-10-16T17:30:32Z<p>Discott: added picture</p>
<hr />
<div>{{Quality|Superior|11:05, 18 May 2015 (UTC)}}<br />
{{stonelookup/0}}{{av}}<br />
<br />
Like [[dolomite]] and [[chalk]], '''limestone''' is a [[flux]] stone which forms entire [[sedimentary layer]]s. In addition, limestone layers are the only sedimentary layers to contain [[galena]] or [[malachite]].<br />
<br />
In general, limestone layers tend to yield more ores and [[gem]]s per volume mined than those of other stones, which makes them a prime candidate for exploratory [[mining]]. Any overburden thus generated will also be doubly valuable compared to regular stone for [[craft]]ing as a result of limestone's flux property.<br />
<br />
"Limestone" is also the name of the seventh month of the dwarven [[calendar]], covering early Autumn.<br />
<br />
==In real life==<br />
Limestone is a sedimentary rock composed largely of minerals like [[calcite]]. It can also contain silica in the form of [[chert]], and varying amounts of [[clay]], [[silt]] and [[sand]] carried in by [[river]]s.<br />
<br />
<br />
<gallery><br />
File:Limestone.jpg|Limestone<br />
File:An elbow column.jpg| An elbow column made from limestone.<br />
</gallery><br />
<br />
{{gamedata}}<br />
{{stones}}<br />
{{Category|Economic Stone}}</div>Discotthttps://dwarffortresswiki.org/index.php?title=Native_platinum&diff=220681Native platinum2015-10-16T17:23:55Z<p>Discott: </p>
<hr />
<div>{{#rreplace:<br />
{{stonelookup/0}}<br />
|\[\[olivine\]\] as veins<br />
|[[olivine]] as small clusters{{bug|1429}}<br />
}} <!-- This fixes stonelookup/0 to reflect the bug explained below (see v0.34 talk page). --><br />
<br />
{{av}}{{Quality|Exceptional|22:51, 8 June 2010 (UTC)}}<br />
<br />
'''Native platinum''' is the only [[ore]] of [[platinum]], one of the most valuable [[metal]]s available (equal in value to [[aluminum]]). Its high material value makes both the ore and the smelted metal a convenient material for high value furniture for [[noble]]s. If the deposits are not mined out, smoothed and [[engraver|engraved]] platinum walls can add a lot of value to rooms, too.<br />
<br />
Native platinum can occur in [[vein|veins]] inside bodies of [[magnetite]] and as small [[cluster]] within [[chromite]]. The veins from magnetite specifically can extend far outside the magnetite they originate from and the vein may even be interrupted at the magnetite cluster border.<br />
<br />
When mined, chunks of native platinum are called ''platinum nuggets''.<br />
<br />
Although the raw entries for native platinum indicate that it appears as veins within olivine, a bug causes it to only appear in small clusters (even in the absence of chromite). {{bug|1429}}<br />
<br />
=== In Real Life ===<br />
Native platinum is technically not an ore; it's simply chunks of mostly pure metallic platinum. As platinum is an extremely unreactive metal, even less reactive than gold, this is by far the most common form in which platinum is found in nature.<br />
[[File:Platinum-nugget.jpg|thumb|left|A 112g (3.6 oz) platinum nugget.]]<br />
<br />
{{gamedata}}<br />
{{stones}}<br />
{{Category|Ore}}<br />
{{Category|Economic Stone}}</div>Discotthttps://dwarffortresswiki.org/index.php?title=Native_platinum&diff=220680Native platinum2015-10-16T17:23:32Z<p>Discott: </p>
<hr />
<div>{{#rreplace:<br />
{{stonelookup/0}}<br />
|\[\[olivine\]\] as veins<br />
|[[olivine]] as small clusters{{bug|1429}}<br />
}} <!-- This fixes stonelookup/0 to reflect the bug explained below (see v0.34 talk page). --><br />
<br />
{{av}}{{Quality|Exceptional|22:51, 8 June 2010 (UTC)}}<br />
<br />
'''Native platinum''' is the only [[ore]] of [[platinum]], one of the most valuable [[metal]]s available (equal in value to [[aluminum]]). Its high material value makes both the ore and the smelted metal a convenient material for high value furniture for [[noble]]s. If the deposits are not mined out, smoothed and [[engraver|engraved]] platinum walls can add a lot of value to rooms, too.<br />
<br />
Native platinum can occur in [[vein|veins]] inside bodies of [[magnetite]] and as small [[cluster]] within [[chromite]]. The veins from magnetite specifically can extend far outside the magnetite they originate from and the vein may even be interrupted at the magnetite cluster border.<br />
<br />
When mined, chunks of native platinum are called ''platinum nuggets''.<br />
<br />
Although the raw entries for native platinum indicate that it appears as veins within olivine, a bug causes it to only appear in small clusters (even in the absence of chromite). {{bug|1429}}<br />
<br />
=== In Real Life ===<br />
Native platinum is technically not an ore; it's simply chunks of mostly pure metallic platinum. As platinum is an extremely unreactive metal, even less reactive than gold, this is by far the most common form in which platinum is found in nature.<br />
[[File:Platinum-nugget.jpg|thumb|right|A 112g (3.6 oz) platinum nugget.]]<br />
<br />
{{gamedata}}<br />
{{stones}}<br />
{{Category|Ore}}<br />
{{Category|Economic Stone}}</div>Discotthttps://dwarffortresswiki.org/index.php?title=Native_platinum&diff=220679Native platinum2015-10-16T17:23:01Z<p>Discott: added picture</p>
<hr />
<div>{{#rreplace:<br />
{{stonelookup/0}}<br />
|\[\[olivine\]\] as veins<br />
|[[olivine]] as small clusters{{bug|1429}}<br />
}} <!-- This fixes stonelookup/0 to reflect the bug explained below (see v0.34 talk page). --><br />
<br />
{{av}}{{Quality|Exceptional|22:51, 8 June 2010 (UTC)}}<br />
<br />
'''Native platinum''' is the only [[ore]] of [[platinum]], one of the most valuable [[metal]]s available (equal in value to [[aluminum]]). Its high material value makes both the ore and the smelted metal a convenient material for high value furniture for [[noble]]s. If the deposits are not mined out, smoothed and [[engraver|engraved]] platinum walls can add a lot of value to rooms, too.<br />
<br />
Native platinum can occur in [[vein|veins]] inside bodies of [[magnetite]] and as small [[cluster]] within [[chromite]]. The veins from magnetite specifically can extend far outside the magnetite they originate from and the vein may even be interrupted at the magnetite cluster border.<br />
<br />
When mined, chunks of native platinum are called ''platinum nuggets''.<br />
<br />
Although the raw entries for native platinum indicate that it appears as veins within olivine, a bug causes it to only appear in small clusters (even in the absence of chromite). {{bug|1429}}<br />
<br />
=== In Real Life ===<br />
[[File:Platinum-nugget.jpg|thumb|A 112g (3.6 oz) platinum nugget.]]<br />
Native platinum is technically not an ore; it's simply chunks of mostly pure metallic platinum. As platinum is an extremely unreactive metal, even less reactive than gold, this is by far the most common form in which platinum is found in nature.<br />
<br />
{{gamedata}}<br />
{{stones}}<br />
{{Category|Ore}}<br />
{{Category|Economic Stone}}</div>Discotthttps://dwarffortresswiki.org/index.php?title=Native_silver&diff=220678Native silver2015-10-16T17:20:31Z<p>Discott: </p>
<hr />
<div>{{stonelookup/0}}{{av}}{{Quality|Exceptional}}<br />
'''Native silver''' is an ore of [[silver]], a mid-value metal. Native silver may also be [[Smelter|smelted]] with other ores to create [[electrum]] and [[billon]]. Native silver can be found as veins in [[gneiss]] and [[granite]]. When mined, hunks of native silver are called ''silver nuggets''.<br />
<br />
[[Horn silver]] is mostly identical to native silver, other than its name and physical properties. [[Tetrahedrite]] and [[galena]] are related ores which, once smelted, '''may''' produce a bar of silver.<br />
<br />
== In Real Life ==<br />
[[File:Acanthite-Silver-tuc8-107a.jpg|thumb|left| A piece of acanthite ore with heavily included by patches of very visible silver wires.]]<br />
Native silver is not technically an ore; it's just chunks of mostly pure metallic silver, naturally formed. As silver is not very reactive, as metals go, this is not an extremely uncommon form to find silver in.<br />
<br />
{{gamedata}}<br />
{{stones}}<br />
{{Category|Ore}}<br />
{{Category|Economic Stone}}</div>Discotthttps://dwarffortresswiki.org/index.php?title=Native_silver&diff=220677Native silver2015-10-16T15:03:56Z<p>Discott: added picture</p>
<hr />
<div>{{stonelookup/0}}{{av}}{{Quality|Exceptional}}<br />
'''Native silver''' is an ore of [[silver]], a mid-value metal. Native silver may also be [[Smelter|smelted]] with other ores to create [[electrum]] and [[billon]]. Native silver can be found as veins in [[gneiss]] and [[granite]]. When mined, hunks of native silver are called ''silver nuggets''.<br />
<br />
[[Horn silver]] is mostly identical to native silver, other than its name and physical properties. [[Tetrahedrite]] and [[galena]] are related ores which, once smelted, '''may''' produce a bar of silver.<br />
<br />
== In Real Life ==<br />
[[File:Acanthite-Silver-tuc8-107a.jpg|thumb|left| Heavily included by patches of very visible, silver wires on a mass of acanthite ore.]]<br />
Native silver is not technically an ore; it's just chunks of mostly pure metallic silver, naturally formed. As silver is not very reactive, as metals go, this is not an extremely uncommon form to find silver in.<br />
<br />
{{gamedata}}<br />
{{stones}}<br />
{{Category|Ore}}<br />
{{Category|Economic Stone}}</div>Discotthttps://dwarffortresswiki.org/index.php?title=Sphalerite&diff=220676Sphalerite2015-10-16T14:50:56Z<p>Discott: added picture</p>
<hr />
<div>{{stonelookup/0}}{{av}}{{Quality|Exceptional}}<br />
[[File:Baryte-Fluorite-Sphalerite-232885.jpg|thumb|Crystallized, lustrous, black sphalerite crystals with red highlights, are the host for two discrete rosettes of light tan baryte, to 3.25 cm across along with a single, glassy and gemmy, lavender colored fluorite crystal.]]<br />
'''Sphalerite''' is the only [[ore]] of [[zinc]], and can also be used as an ingredient in the [[smelter|smelting]] of [[brass]]. In the game, sphalerite is found as veins in [[metamorphic layer]]s. Interestingly, dwarves can smelt sphalerite into zinc while the stone itself does not melt, but ''sublimates'' (going from solid to gas without melting).<br />
<br />
== Smelting ==<br />
Sphalerite is needed to make two types of [[metal]] [[bar]]s at a smelter:<br />
* [[Zinc]] bars<br />
* [[Brass]] bars - with [[native copper]], [[malachite]], or [[tetrahedrite]]<br />
<br />
[[Image:Sphalerite4.jpg|Sphalerite|thumb]]<br />
[[Image:Sphalerite-JR.jpg|A 6 mm sphalerite crystal|thumb]]<br />
<br />
{{gamedata}}<br />
{{stones}}<br />
{{Category|Ore}}<br />
{{Category|Economic Stone}}</div>Discotthttps://dwarffortresswiki.org/index.php?title=Tetrahedrite&diff=220669Tetrahedrite2015-10-14T21:46:45Z<p>Discott: added picture</p>
<hr />
<div>{{stonelookup/0}}{{av}}{{Quality|Exceptional}}<br />
<br />
[[File:Tetrahedrite-Chalcopyrite-Sphalerite-251531.jpg|thumb|left|Tetrahedrite crystals with chalcopyrite and sphalerite crystals (size: 8.2 x 6.4 x 4.7 cm)]]<br />
'''Tetrahedrite''' is an incredibly common [[ore]] of both [[copper]] and [[silver]]. [[Smelter|Smelting]] tetrahedrite will produce 4 copper [[bar]]s and 0-4 silver [[bar]]s (with a 20% chance of each silver bar being produced). On average, each nugget of tetrahedrite will produce less than one bar of silver when smelted.<br />
<br />
Tetrahedrite can also be used in [[alloy]] reactions requiring either a copper-bearing ore or a silver-bearing ore, but will only be used as a ''silver'' ore if no other silver ores are available. Two tetrahedrite nuggets can be smelted together as a copper-bearing ore and a silver-bearing ore to make eight [[billon]] bars for a roughly 70% increase in value compared to smelting the nuggets independently.<br />
<br />
When using Tetrahedrite as a copper-bearing ore, it's often best to smelt it into bars first and then create the alloy using copper bars. This allows you to produce a few [[silver]] bars in addition to the bars of alloy, but does require additional [[fuel]], dwarf effort, and time. Note, however, that when producing [[billon]] from two tetrahedrite nuggets, the benefits of using tetrahedrite as a silver-bearing ore outweigh the drawbacks of using tetrahedrite as a copper-bearing ore.<br />
<br />
==Understanding the value chain==<br />
A single tetrahedrite boulder (seen in game as simply "tetrahedrite", laying on floor as a subproduct of digging) has a [[Item value|value]] of 9 (3 for being a stone boulder, times 3 for it being tetrahedrite).<br />
<br />
This boulder can be smelted into 4 bars of copper, each having a value of 10 (5 for being bars, times 2 for them being made of copper), for a total of 40, and a random amount of 0 to 4 bars of silver (mean being 0.8), each having a value of 50 (5 for being bars, times 10 for them being made of silver). So each single tetrahedrite boulder gives you a (mean) value of 80 in copper and silver bars.<br />
<br />
Each bar can be then [[Forge|forged]] into items, like a [[battle axe]]. A copper battle axe will have a value of 68 (34 for being a battle axe, times 2 for being made of copper), thus the original tetrahedrite boulder will yield a total value of 544 (272 from the 4 copper battle axes, plus 272 as a mean of the possible silver battle axes, each worth 340). And this can be multiplied up to 12x since battle axes have [[quality]] levels.<br />
<br />
{{gamedata}}<br />
{{stones}}<br />
{{Category|Ore}}<br />
{{Category|Economic Stone}}</div>Discotthttps://dwarffortresswiki.org/index.php?title=Dwarf_Fortress_Wiki_talk:Centralized_Discussion&diff=220668Dwarf Fortress Wiki talk:Centralized Discussion2015-10-14T20:22:58Z<p>Discott: /* Adding pictures from commons */</p>
<hr />
<div>== C++ Symbols ==<br />
Hi, Im try using "windows debugging tools" to get some useful information about some crashs since windows 7 doesnt have the so called "dr watson" anymore (which creates a dump useful for toady).<br />
For the debug info to be more useful, there is an option to use symbols file (*.pdb)<br />
I found some c++ symbols in the wiki but is it possible to make a real pdb file out of that?<br />
copypasta into a new txt file and renaming the extension doesnt seem to work.<br />
<br />
== Clarification on "Verification" of content ==<br />
The policy is that all content from 40d must be verified before making it to the 2010 namespace. Whould confirming with the changelog that something hasn't changed be good enough to meet this requirement? If not, does this means that each feature must be tested in game? [[User:bongotastic|bongotastic]] #11:05, 27 May 2010 (UTC)<br />
:In general the changelog is not sufficient. For example, the changelog doesn't say that the [[DF2010:Archery Target]] is now broken, but if you tried it out personally before moving it then you would know that simply copy-pasting this is a bad idea. Not a small task I know, but long-term this is far more valuable. Any article in particular you were thinking about? [[User:Mason11987|Mason]] <sup>([[User talk:Mason11987|T]]-[[Special:Contributions/Mason11987|C]])</sup> 12:45, 30 May 2010 (UTC)<br />
<br />
== Thoughts? ==<br />
Any thoughts on this page? Any potentially useful organizing ideas? [[User:Mason11987|Mason]] <sup>([[User talk:Mason11987|T]]-[[Special:Contributions/Mason11987|C]])</sup> 16:58, 23 April 2010 (UTC)<br />
:I think this is a great idea. --[[User:Briess|Briess]] 17:03, 23 April 2010 (UTC)<br />
<br />
== Missing discussions? ==<br />
Are there any important discussions I've missed, or anything you'd like to discussion that you'd like a location to discuss? [[User:Mason11987|Mason]] <sup>([[User talk:Mason11987|T]]-[[Special:Contributions/Mason11987|C]])</sup> 16:58, 23 April 2010 (UTC)<br />
:Will any articles be pruned away or merged? In the jump from 40D to v31 a lot of articles that used to be served well by tables seem to have become their own articles, which really clutters the place up and scatters information all over unfindably. Stones, ores, and gems are the most obvious, they really only need three tables instead of hundreds of articles. --[[User:Corona688|Corona688]] 19:53, 23 April 2010 (UTC)<br />
::Might I suggest responses go to the just created [[Dwarf Fortress Wiki talk:Article Consolidation|Dwarf Fortress Wiki:Article Consolidation talk page]]. I think this is a big issue worth discussing, and so it deserves to be discussed there. [[User:Mason11987|Mason]] <sup>([[User talk:Mason11987|T]]-[[Special:Contributions/Mason11987|C]])</sup> 21:34, 23 April 2010 (UTC)<br />
:I wonder, is there a place here for a Future Versions Ideas page? I have many ideas for things that could be used in future versions of Dwarf Fort, but there's no way to get the word to Toady that I'm aware of, aside from straight e-mailing him...--[[User:Aescula|Aescula]] 20:55, 25 April 2010 (UTC)<br />
::I'm not really sure if the wiki is the right place for something like that. I mostly say that because I don't think that he will look at what we set up for the wiki either. There is a [http://www.bay12forums.com/smf/index.php?board=5.0 Suggestions Forum] that seems to be the best place for that kind of thing. I imagine if he looks anywhere he looks there. [[User:Mason11987|Mason]] <sup>([[User talk:Mason11987|T]]-[[Special:Contributions/Mason11987|C]])</sup> 19:53, 3 May 2010 (UTC)<br />
<br />
== Template madness ==<br />
Okay I was looking at [[DF2010:Native platinum]] and wanted to make the changes but the arrangement of templates make editing the sidebar incredibly complicated even for the fairly good amount of knowledge I have of the wiki.<br />
<br />
This really doesn't need to be this complicated. Could someone explain how it works and more importantly why it needs to be so complicated. [[User:Mason11987|Mason]] <sup>([[User talk:Mason11987|T]]-[[Special:Contributions/Mason11987|C]])</sup> 21:12, 24 April 2010 (UTC)<br />
:I agree, we need a short tutorial on templates. This is shutting out IPs (and probably the majority of editors) through the backdoor. --[[User:Birthright|Birthright]] 00:32, 7 May 2010 (UTC)<br />
::[http://www.mediawiki.org/wiki/Help:Template Here] [http://www.mediawiki.org/wiki/Help:Parser_functions you] [http://www.mediawiki.org/wiki/Help:Parser_functions_in_templates go.] [[User:VengefulDonut|VengefulDonut]] 14:20, 7 May 2010 (UTC)<br />
:::Right. You make it obvious that excessive use of templates will make the wiki unusable for all but a small aristocracy. Plus we would still need a central place frequently visited by editors that links to those pages. Maybe link to the -still missing- ''short'' tutorial next to every template in the articles? --[[User:Birthright|Birthright]] 20:57, 7 May 2010 (UTC)<br />
::You seem confident that you will get what you want. [[User:VengefulDonut|VengefulDonut]] 23:52, 7 May 2010 (UTC)<br />
<br />
== Magmawiki skin feedback ==<br />
I just decided to try out the new skin. I am using it for ten minutes and I already can't imagine using anything different, it's great!--[[User:SanDiego|SanDiego]] 13:54, 25 April 2010 (UTC)<br />
<br />
== If not consolidation, then what? ==<br />
<br />
I don't seem to have a lot of support for article consolidation, and have abruptly been relieved of the time I had to try and help. Fine. I still insist the clutter of pages remains troublesome. Whenever your search is slightly off, instead of returning few to no results, it returns hundreds of irrelevant results. When I search for BODY_SIZE I don't want creature_standard.txt, grimeling size, mud man size, olmman size, fire man size, insert-material-here-man size or anything else's tags, I'm looking for info on the tags themselves. Same when I search "raws", I don't mean those of beetles, whales, walruses, sturgeon, stingray, etc, etc, etc. Redirects won't fix this until we redirect every possible thing that needs to be redirected, at all, ever, but that seems an even more exhaustive task than tables.<br />
<br />
Is it possible to prevent the search from indexing these stub articles, or at least giving them less priority? The 'whale' page is going to be irrelevant to anyone not searching for whales... --[[User:Corona688|Corona688]] 17:02, 1 May 2010 (UTC)<br />
:I agree with you that there isn't the support for consolidation. I do understand what you're saying. It seems like there are two possible solutions to your problem.<br />
:*Better organization: This is entirely possible, but very complicated. I've been trying to improve this but it is very difficult. If you don't have the time to work on this and improve it you'll have to rely on my inconsistent free time to make some improvements. If you have some good ideas besides "make it better" I'm all ears.<br />
:*Better search: This is much more difficult, and probably not exactly possible given the extreme constraints that is the mediawiki software. You'd be pleased to know that we ([[User:Briess]] and [[User:Emi]]) are working on developing a new wiki software specifically for DF. Details can be found [[Dwarf_Fortress_Wiki:Magmawiki|here]] and [http://www.bay12forums.com/smf/index.php?topic=55613.60 here]. I can only assume that they will make sure to provide improved searching as one of their goals, but if you want to post in the forum thread your wishes that would probably be useful.<br />
:[[User:Mason11987|Mason]] <sup>([[User talk:Mason11987|T]]-[[Special:Contributions/Mason11987|C]])</sup> 20:10, 3 May 2010 (UTC)<br />
<br />
::Yeah, it's not the wiki that sucks, the search function is limited. You are simply asking too much. --[[User:Birthright|Birthright]] 00:29, 7 May 2010 (UTC)<br />
<br />
== Gamelog Template? ==<br />
We should add a "gamelog" template, so that bored players (like me) can easily locate other player's gamelogs about the fun adventures they are getting up to. I'd do it myself, but I have no idea how to. -[[User:Romeofalling|Romeofalling]] 21:25, 18 August 2010 (UTC)<br />
<br />
I don't know about a template, but I have been wanting a way to find other users who are "logging" their games on the wiki for weeks. Can we have a page listing such things, and feature a link to that page on the Main page? -- [[User:Maunder|Maunder]] 21:49, 18 November 2010 (UTC) (now heading to look at Romeofalling's page)<br />
<br />
Okay I added a [[Stories#Game_Diaries|new section]] to [[Stories]]. Anyone who is chronicling their fortress on the wiki, please add a link to your story [[Stories#Game_Diaries|here]]! -- [[User:Maunder|Maunder]] 22:27, 18 November 2010 (UTC)<br />
<br />
== Bloodline ==<br />
Currently there is a [[bloodline|bloodline page]], a [http://df.magmawiki.com/index.php/Bloodline_games bloodline category] and a [http://df.magmawiki.com/index.php?title=Special:PrefixIndex&from=&namespace=100 bloodline namespace]. I understand that community stuff is currently lower priority than getting the other content ready for players, but this should all be consolidated and made easily accessible. I'd be willing to do it, but should we go with the category or namespace? [[User:Calite|Calite]] 00:36, 9 October 2010 (UTC)<br />
<br />
== Community Portal ==<br />
<br />
Why was the [[Dwarf Fortress Wiki:Community Portal|Community Portal]] link dropped from the sidebar? We kind of need to have a '''reachable''' list of editing guidelines, especially given the "dwarfs/dwarves" conflict that's going on (where said page states that the proper term would be "dwarves" due to being used in-game). --[[User:Quietust|Quietust]] 17:16, 13 June 2011 (UTC)<br />
<br />
== crayon art rewards-donation drive to illustrate the wiki ==<br />
<br />
I found [http://www.bay12forums.com/smf/index.php?topic=77360.0 this topic on forums] and as experiment added image to [[DF2010:Gorlak]]. Is it a great/good/acceptable idea? Is it possible that there is certain licence problem? Maybe it should go to infobox? I prefer to ask before uploading 30+ images. [[User:Kogut|Kogut]] 17:14, 15 December 2011 (UTC)<br />
<br />
==Adding pictures from commons==<br />
Hello, I am trying to add a picture of a [[DF2014:Kiwi man|Kiwiman]] I draw and [https://commons.wikimedia.org/wiki/File:DF-Kiwiman.jpg put on Wikimedia Commons] but I dont seem to be having any luck in being able to put that image on the Kiwiman article page using Wikimedia syntax. How can I add this picture from Wikimedia Commons? I am not authorised to create new articles on this Wiki so uploading the image directly here is not an option for me right now. --[[User:Discott|Discott]] ([[User talk:Discott|talk]]) 12:12, 12 October 2015 (UTC)<br />
<br />
:It shows up for me below the column on the right. (You should be able to create new pages now, since Briess changed the requirement to 3 edits, but it doesn't matter in this case since this wiki can pull images from Commons.) &mdash;[[User:Lethosor|<span style="color:#074">Lethosor</span>]] ([[User talk:Lethosor|<span style="color:#092">talk</span>]]) 02:00, 13 October 2015 (UTC)<br />
<br />
::It is showing up for me as well now, I suspect I just needed to refresh my browser or it was due to some sort of lag between the DFwiki server and Commons... or some thing like that. --[[User:Discott|Discott]] ([[User talk:Discott|talk]]) 20:22, 14 October 2015 (UTC)</div>Discotthttps://dwarffortresswiki.org/index.php?title=User:Discott&diff=220649User:Discott2015-10-12T16:53:24Z<p>Discott: Created page with "In additional to very occasionally editing DF Wiki I also [https://en.wikipedia.org/wiki/User:Discott edit Wikipedia]."</p>
<hr />
<div>In additional to very occasionally editing DF Wiki I also [https://en.wikipedia.org/wiki/User:Discott edit Wikipedia].</div>Discotthttps://dwarffortresswiki.org/index.php?title=Dwarf_Fortress_Wiki_talk:Centralized_Discussion&diff=220648Dwarf Fortress Wiki talk:Centralized Discussion2015-10-12T12:12:17Z<p>Discott: Kiwiman picture</p>
<hr />
<div>==Adding pictures from commons==<br />
Hello, I am trying to add a picture of a [[DF2014:Kiwi man|Kiwiman]] I draw and [https://commons.wikimedia.org/wiki/File:DF-Kiwiman.jpg put on Wikimedia Commons] but I dont seem to be having any luck in being able to put that image on the Kiwiman article page using Wikimedia syntax. How can I add this picture from Wikimedia Commons? I am not authorised to create new articles on this Wiki so uploading the image directly here is not an option for me right now. --[[User:Discott|Discott]] ([[User talk:Discott|talk]]) 12:12, 12 October 2015 (UTC) <br />
<br />
== C++ Symbols ==<br />
Hi, Im try using "windows debugging tools" to get some useful information about some crashs since windows 7 doesnt have the so called "dr watson" anymore (which creates a dump useful for toady).<br />
For the debug info to be more useful, there is an option to use symbols file (*.pdb)<br />
I found some c++ symbols in the wiki but is it possible to make a real pdb file out of that?<br />
copypasta into a new txt file and renaming the extension doesnt seem to work.<br />
<br />
== Clarification on "Verification" of content ==<br />
The policy is that all content from 40d must be verified before making it to the 2010 namespace. Whould confirming with the changelog that something hasn't changed be good enough to meet this requirement? If not, does this means that each feature must be tested in game? [[User:bongotastic|bongotastic]] #11:05, 27 May 2010 (UTC)<br />
:In general the changelog is not sufficient. For example, the changelog doesn't say that the [[DF2010:Archery Target]] is now broken, but if you tried it out personally before moving it then you would know that simply copy-pasting this is a bad idea. Not a small task I know, but long-term this is far more valuable. Any article in particular you were thinking about? [[User:Mason11987|Mason]] <sup>([[User talk:Mason11987|T]]-[[Special:Contributions/Mason11987|C]])</sup> 12:45, 30 May 2010 (UTC)<br />
<br />
== Thoughts? ==<br />
Any thoughts on this page? Any potentially useful organizing ideas? [[User:Mason11987|Mason]] <sup>([[User talk:Mason11987|T]]-[[Special:Contributions/Mason11987|C]])</sup> 16:58, 23 April 2010 (UTC)<br />
:I think this is a great idea. --[[User:Briess|Briess]] 17:03, 23 April 2010 (UTC)<br />
<br />
== Missing discussions? ==<br />
Are there any important discussions I've missed, or anything you'd like to discussion that you'd like a location to discuss? [[User:Mason11987|Mason]] <sup>([[User talk:Mason11987|T]]-[[Special:Contributions/Mason11987|C]])</sup> 16:58, 23 April 2010 (UTC)<br />
:Will any articles be pruned away or merged? In the jump from 40D to v31 a lot of articles that used to be served well by tables seem to have become their own articles, which really clutters the place up and scatters information all over unfindably. Stones, ores, and gems are the most obvious, they really only need three tables instead of hundreds of articles. --[[User:Corona688|Corona688]] 19:53, 23 April 2010 (UTC)<br />
::Might I suggest responses go to the just created [[Dwarf Fortress Wiki talk:Article Consolidation|Dwarf Fortress Wiki:Article Consolidation talk page]]. I think this is a big issue worth discussing, and so it deserves to be discussed there. [[User:Mason11987|Mason]] <sup>([[User talk:Mason11987|T]]-[[Special:Contributions/Mason11987|C]])</sup> 21:34, 23 April 2010 (UTC)<br />
:I wonder, is there a place here for a Future Versions Ideas page? I have many ideas for things that could be used in future versions of Dwarf Fort, but there's no way to get the word to Toady that I'm aware of, aside from straight e-mailing him...--[[User:Aescula|Aescula]] 20:55, 25 April 2010 (UTC)<br />
::I'm not really sure if the wiki is the right place for something like that. I mostly say that because I don't think that he will look at what we set up for the wiki either. There is a [http://www.bay12forums.com/smf/index.php?board=5.0 Suggestions Forum] that seems to be the best place for that kind of thing. I imagine if he looks anywhere he looks there. [[User:Mason11987|Mason]] <sup>([[User talk:Mason11987|T]]-[[Special:Contributions/Mason11987|C]])</sup> 19:53, 3 May 2010 (UTC)<br />
<br />
== Template madness ==<br />
Okay I was looking at [[DF2010:Native platinum]] and wanted to make the changes but the arrangement of templates make editing the sidebar incredibly complicated even for the fairly good amount of knowledge I have of the wiki.<br />
<br />
This really doesn't need to be this complicated. Could someone explain how it works and more importantly why it needs to be so complicated. [[User:Mason11987|Mason]] <sup>([[User talk:Mason11987|T]]-[[Special:Contributions/Mason11987|C]])</sup> 21:12, 24 April 2010 (UTC)<br />
:I agree, we need a short tutorial on templates. This is shutting out IPs (and probably the majority of editors) through the backdoor. --[[User:Birthright|Birthright]] 00:32, 7 May 2010 (UTC)<br />
::[http://www.mediawiki.org/wiki/Help:Template Here] [http://www.mediawiki.org/wiki/Help:Parser_functions you] [http://www.mediawiki.org/wiki/Help:Parser_functions_in_templates go.] [[User:VengefulDonut|VengefulDonut]] 14:20, 7 May 2010 (UTC)<br />
:::Right. You make it obvious that excessive use of templates will make the wiki unusable for all but a small aristocracy. Plus we would still need a central place frequently visited by editors that links to those pages. Maybe link to the -still missing- ''short'' tutorial next to every template in the articles? --[[User:Birthright|Birthright]] 20:57, 7 May 2010 (UTC)<br />
::You seem confident that you will get what you want. [[User:VengefulDonut|VengefulDonut]] 23:52, 7 May 2010 (UTC)<br />
<br />
== Magmawiki skin feedback ==<br />
I just decided to try out the new skin. I am using it for ten minutes and I already can't imagine using anything different, it's great!--[[User:SanDiego|SanDiego]] 13:54, 25 April 2010 (UTC)<br />
<br />
== If not consolidation, then what? ==<br />
<br />
I don't seem to have a lot of support for article consolidation, and have abruptly been relieved of the time I had to try and help. Fine. I still insist the clutter of pages remains troublesome. Whenever your search is slightly off, instead of returning few to no results, it returns hundreds of irrelevant results. When I search for BODY_SIZE I don't want creature_standard.txt, grimeling size, mud man size, olmman size, fire man size, insert-material-here-man size or anything else's tags, I'm looking for info on the tags themselves. Same when I search "raws", I don't mean those of beetles, whales, walruses, sturgeon, stingray, etc, etc, etc. Redirects won't fix this until we redirect every possible thing that needs to be redirected, at all, ever, but that seems an even more exhaustive task than tables.<br />
<br />
Is it possible to prevent the search from indexing these stub articles, or at least giving them less priority? The 'whale' page is going to be irrelevant to anyone not searching for whales... --[[User:Corona688|Corona688]] 17:02, 1 May 2010 (UTC)<br />
:I agree with you that there isn't the support for consolidation. I do understand what you're saying. It seems like there are two possible solutions to your problem.<br />
:*Better organization: This is entirely possible, but very complicated. I've been trying to improve this but it is very difficult. If you don't have the time to work on this and improve it you'll have to rely on my inconsistent free time to make some improvements. If you have some good ideas besides "make it better" I'm all ears.<br />
:*Better search: This is much more difficult, and probably not exactly possible given the extreme constraints that is the mediawiki software. You'd be pleased to know that we ([[User:Briess]] and [[User:Emi]]) are working on developing a new wiki software specifically for DF. Details can be found [[Dwarf_Fortress_Wiki:Magmawiki|here]] and [http://www.bay12forums.com/smf/index.php?topic=55613.60 here]. I can only assume that they will make sure to provide improved searching as one of their goals, but if you want to post in the forum thread your wishes that would probably be useful.<br />
:[[User:Mason11987|Mason]] <sup>([[User talk:Mason11987|T]]-[[Special:Contributions/Mason11987|C]])</sup> 20:10, 3 May 2010 (UTC)<br />
<br />
::Yeah, it's not the wiki that sucks, the search function is limited. You are simply asking too much. --[[User:Birthright|Birthright]] 00:29, 7 May 2010 (UTC)<br />
<br />
== Gamelog Template? ==<br />
We should add a "gamelog" template, so that bored players (like me) can easily locate other player's gamelogs about the fun adventures they are getting up to. I'd do it myself, but I have no idea how to. -[[User:Romeofalling|Romeofalling]] 21:25, 18 August 2010 (UTC)<br />
<br />
I don't know about a template, but I have been wanting a way to find other users who are "logging" their games on the wiki for weeks. Can we have a page listing such things, and feature a link to that page on the Main page? -- [[User:Maunder|Maunder]] 21:49, 18 November 2010 (UTC) (now heading to look at Romeofalling's page)<br />
<br />
Okay I added a [[Stories#Game_Diaries|new section]] to [[Stories]]. Anyone who is chronicling their fortress on the wiki, please add a link to your story [[Stories#Game_Diaries|here]]! -- [[User:Maunder|Maunder]] 22:27, 18 November 2010 (UTC)<br />
<br />
== Bloodline ==<br />
Currently there is a [[bloodline|bloodline page]], a [http://df.magmawiki.com/index.php/Bloodline_games bloodline category] and a [http://df.magmawiki.com/index.php?title=Special:PrefixIndex&from=&namespace=100 bloodline namespace]. I understand that community stuff is currently lower priority than getting the other content ready for players, but this should all be consolidated and made easily accessible. I'd be willing to do it, but should we go with the category or namespace? [[User:Calite|Calite]] 00:36, 9 October 2010 (UTC)<br />
<br />
== Community Portal ==<br />
<br />
Why was the [[Dwarf Fortress Wiki:Community Portal|Community Portal]] link dropped from the sidebar? We kind of need to have a '''reachable''' list of editing guidelines, especially given the "dwarfs/dwarves" conflict that's going on (where said page states that the proper term would be "dwarves" due to being used in-game). --[[User:Quietust|Quietust]] 17:16, 13 June 2011 (UTC)<br />
<br />
== crayon art rewards-donation drive to illustrate the wiki ==<br />
<br />
I found [http://www.bay12forums.com/smf/index.php?topic=77360.0 this topic on forums] and as experiment added image to [[DF2010:Gorlak]]. Is it a great/good/acceptable idea? Is it possible that there is certain licence problem? Maybe it should go to infobox? I prefer to ask before uploading 30+ images. [[User:Kogut|Kogut]] 17:14, 15 December 2011 (UTC)</div>Discotthttps://dwarffortresswiki.org/index.php?title=Kiwi_man&diff=220647Kiwi man2015-10-12T12:05:33Z<p>Discott: trying to add image of Kiwiman from Wikimedia Commons (https://commons.wikimedia.org/wiki/File:DF-Kiwiman.jpg), doesn't seem to be working though :-(</p>
<hr />
<div>{{Quality|Superior|06:09, 17 May 2015 (UTC)}}<br />
{{Creaturelookup/0}}<br />
{{av}}<br />
{{creaturedesc}}<br />
[[File:DF-Kiwiman.jpg|thumb|A pencil drawing of a Kiwiman armed with a stone axe.]]<br />
{{gamedata}}<br />
{{Creatures}}</div>Discotthttps://dwarffortresswiki.org/index.php?title=User_talk:Briess&diff=181281User talk:Briess2013-02-18T13:18:40Z<p>Discott: /* Image upload */ replied to Lethosor</p>
<hr />
<div>{{archive|*[[User_talk:Briess/archive1|archive 1]]<br />
*[[User_talk:Briess/archive2|archive 2]]<br />
*[[User_talk:Briess/archive3|archive 3]]}}<br />
<br />
== Stockpile settings info ==<br />
I'd like to read your oppinion on my planned long-term editing concerning [[User_talk:Emi#Stockpile_setting_info|Stockpile settings information]]. --[[User:Nagidal|Nagidal]] 07:16, 10 August 2012 (UTC)<br />
<br />
== User unban ==<br />
I'd like to point you to a discussion on [[User_talk:Quietust#Potential_contributor_banned|Quietust's page]] where I ask to unban a guy who would like to contribute but cannot create an account here. Can you unban him? --[[User:Nagidal|Nagidal]] 21:20, 18 June 2012 (UTC)<br />
<br />
<br />
== Proxy Problem ==<br />
When accessing the wiki through a proxy, it generates this error:<br />
<br />
MediaWiki internal error.<br />
Exception caught inside exception handler.<br />
Set $wgShowExceptionDetails = true; at the bottom of LocalSettings.php to show detailed debugging information.<br />
<br />
I saw on your user page that you're doing something with X-Forwarded-For headers. Could be related? All my access goes through a proxy, bypassing it is possible but difficult. This is the only mediawiki-based site that I see this problem.<br />
<br />
--[[Special:Contributions/72.64.155.9|72.64.155.9]] 16:04, 5 March 2012 (UTC)<br />
<br />
== Account problem ==<br />
<br />
Created April 17-24 2011, IP: 80.92.249.130. I don't remember password. Little help? tapem@yandex.ru<br />
<br />
== Help I Can't Remember Password ==<br />
<br />
Help me Briess. I can't remember my password. ;-; [[user:Emi|<span style="color:#8a4e4e">Emi</span>]] [[user_talk:Emi|<span style="color:#6a3e4e">[T]</span>]] 23:13, 19 January 2012 (UTC)<br />
<br />
== Image upload ==<br />
I've noticed that this wiki is going through many changes, and I'm starting to like it more than ever before. I'll wait it out. --[[User:Nagidal|Nagidal]] 17:00, 19 February 2012 (UTC)<br />
<br />
: Thanks for telling me that the upload works again. I'll try to upload my tileset soon. --[[User:Nagidal|Nagidal]] 18:31, 24 February 2012 (UTC)<br />
<br />
Hello Briess, I have a picture of a Kiwiman that I drew that I would like to upload onto the Wiki. I see that non-Administrators can not upload files. Would it be possible for you to upload it for me and if I do make more pictures in the future how can I go about getting them onto the Wiki? Thanks. [[User:Discott|Discott]] 16:33, 16 February 2013 (UTC)<br />
:Are you a new user? I'm pretty sure you have to make around 10 edits before you're allowed to upload images. --[[User:Lethosor|Lethosor]] ([[User_talk:Lethosor|talk]]) 01:00, 17 February 2013 (UTC)<br />
::I am a new user. Thanks for the information, I just thought that only a select group of users could upload images. [[User:Discott|Discott]] 13:18, 18 February 2013 (UTC)<br />
<br />
== Campfirethanks ==<br />
Thanks for moving '''Campfires''' to the 2012 version. I didn't realize that should be done.<br />
<br />
== Site Dump? ==<br />
<br />
Heyo, is there a compressed archive of the wiki as it is now? Because I'd love to be able to have an offline copy that I can update occasionally. You should try to find some program that can work with a compressed version of the archive, but still update it when new pages are added and such. Anyways, thank you for your time. Let me know if you have a compressed version sitting about!<br />
<br />
<br />
A 1+ for this from me. I am frequently without net access and having the wiki with me would be a great help. [http://www.wikitaxi.org/delphi/doku.php/products/wikitaxi/index WikiTaxi] looks promising as an offline viewer, I just need something to fill it with. --[[User:Plastefuchs|Plastefuchs]] 10:46, 29 April 2012 (UTC)<br />
<br />
I believe there was once a wiki dump available from the site announcement box at the top. It looks like Breiss took it down, but it wasn't really a fully-functional version anyway (more of a backup). I agree that some sort of offline wiki would be useful (although it could be huge if it includes ''every'' page on this wiki) --[[User:Lethosor|Lethosor]] ([[User_talk:Lethosor|talk]]) 01:07, 17 February 2013 (UTC)<br />
<br />
== Community Portal ==<br />
<br />
Back in June last year, I added a "Community Portal" link to the navigation bar, only for you to remove it in November. Is there a particular reason why you removed the only visible link to the wiki's editing rules and conventions? --[[User:Quietust|Quietust]] 15:24, 3 April 2012 (UTC)<br />
<br />
== Account deletion? ==<br />
<br />
Is there any way that you could delete my account? - Nomen<br />
<br />
== How do you think about a German wiki? ==<br />
<br />
That's Probably all ;D <br />
<br />
maybe I can help you (if you like to have a German wiki)<br />
(if want to have a closer look ,sign me at: "kempe@live.de")- MAKE<br />
<br />
<br />
9. April 2012<br />
13:55 MESZ (11:55 UTC)<br />
<br />
== Something's wrong with the Advance world generation page. (The current version page) ==<br />
<br />
As we all know, there is ''almost'' always a page for topics regarding how the item being discussed in them work for the current version. Well, for some strange reason, the DF2012:Advanced world generation page seems to have some sort of strange issue, that prevents it from being made or edited. Since I'm a little too new with how this wiki works beyond the bare surface of editing, I simply didn't know who else to ask about fixing this.<br />
<br />
I sincerely hope that you will get this message, and fix the article as soon as possible. This is the page. [[DF2012:Advanced_world_generation]] There are pages for the previous versions, but not for the current version. Also, a link to a page about how to fix things like these would be nice. --[[User:Learner4|Learner4]] 19:36, 19 May 2012 (UTC)<br />
<br />
==Registration Spam==<br />
Got this comment on my talk page, figured it might be more useful to you: --[[User:Quietust|Quietust]] 03:31, 4 June 2012 (UTC)<br />
:Q, methinks the method shown under "Comment Spam defeated at last" on Steve Hanov's Blog stevehanov.ca would save you a lot of work. <small>&ndash; [[template:unsigned|unsigned]] comment by [[User:2.215.60.207|2.215.60.207]]</small><br />
<br />
==Aquifers Tutorial==<br />
I have published it by now. It's [[DF2012:Double-slit_method]]<br />
<br />
== Just letting you know ==<br />
<br />
Just in case you didn't see my post on the forum, I was able to sign up for the forum just fine now that you fixed the DNSBL. Just wanted to say thanks again!<br />
<br />
== Why the revert? ==<br />
<br />
I'm a bit confused about why you reverted [http://dwarffortresswiki.org/index.php?title=v0.31:Flow&curid=13142&diff=174793&oldid=174785 these changes] on the v0.31 [[Flow]] page. The 2nd link was redundant, and the first pointed to a section of another article that doesn't exist. Why revert it back to its redundant broken state? -- [[User:HiEv|<span style="color:#E05858;font-weight:bold;">Hi</span>]][[User talk:HiEv|<span style="color:#C06060;font-weight:bold;">Ev</span>]] 23:30, 4 July 2012 (UTC)<br />
<br />
== Interested in taking part in a small research project? ==<br />
<br />
Hi Briess,<br />
<br />
I hope this the best way of contacting you! I'm a PhD researcher at the University of Glasgow and I'm just about to start a small research project on gaming wikis and collaborative learning (some background is available here: [http://www.smke.org/blog-post-2/]). I'm hoping to interview a few key players in the gaming wiki world (probably via web chat or Skype, or perhaps within some game environment) and wondered if you might be interested. If so, drop me a line at [email rmv'd] or reply to me here (again, I hope I'm not hijacking your User page here!).<br />
<br />
Cheers,<br />
<br />
Matt<br />
<br />
== Regenerating category contents ==<br />
<br />
Hello, and I hope you are the right person to handle an bit of administrative work. [http://dwarffortresswiki.org/index.php?title=Template:Attrib_proc&diff=prev&oldid=179609 This edit] added category links for common creature attributes to a template that is transcluded to (almost) all the creature pages. While the creature pages now correctly include a link to the relevant categories, the categories themselves do not include all the creature pages (ex. [[:Category:DF2012:Flying]] should include [[Giant eagle]]s, and many other bird variations). It appears that any (trivial) edit to a creature page "updates" the category pages appropriately, but that means every creature page that should be in a category will have to be manually edited before the category lists are correctly completed. My question is whether there is an administrative way to regenerate these category lists directly, saving hundreds of manual edits to the creature pages. Thank you! --[[User:Loci|Loci]] 22:59, 5 January 2013 (UTC)<br />
<br />
:It appears that the pages still aren't being categorized--the jobs are likely stuck in the [http://www.mediawiki.org/wiki/Manual:Job_queue Job Queue] (currently [http://dwarffortresswiki.org/api.php?action=query&meta=siteinfo&siprop=statistics 770 jobs] waiting). [http://www.mediawiki.org/wiki/Manual:RunJobs.php Manually running the queue] will hopefully put everything in the proper categories. --[[User:Loci|Loci]] 21:14, 10 January 2013 (UTC)</div>Discotthttps://dwarffortresswiki.org/index.php?title=User_talk:Briess&diff=181244User talk:Briess2013-02-16T16:33:24Z<p>Discott: /* Image upload */ on uploading Kiwiman</p>
<hr />
<div>{{archive|*[[User_talk:Briess/archive1|archive 1]]<br />
*[[User_talk:Briess/archive2|archive 2]]<br />
*[[User_talk:Briess/archive3|archive 3]]}}<br />
<br />
== Stockpile settings info ==<br />
I'd like to read your oppinion on my planned long-term editing concerning [[User_talk:Emi#Stockpile_setting_info|Stockpile settings information]]. --[[User:Nagidal|Nagidal]] 07:16, 10 August 2012 (UTC)<br />
<br />
== User unban ==<br />
I'd like to point you to a discussion on [[User_talk:Quietust#Potential_contributor_banned|Quietust's page]] where I ask to unban a guy who would like to contribute but cannot create an account here. Can you unban him? --[[User:Nagidal|Nagidal]] 21:20, 18 June 2012 (UTC)<br />
<br />
<br />
== Proxy Problem ==<br />
When accessing the wiki through a proxy, it generates this error:<br />
<br />
MediaWiki internal error.<br />
Exception caught inside exception handler.<br />
Set $wgShowExceptionDetails = true; at the bottom of LocalSettings.php to show detailed debugging information.<br />
<br />
I saw on your user page that you're doing something with X-Forwarded-For headers. Could be related? All my access goes through a proxy, bypassing it is possible but difficult. This is the only mediawiki-based site that I see this problem.<br />
<br />
--[[Special:Contributions/72.64.155.9|72.64.155.9]] 16:04, 5 March 2012 (UTC)<br />
<br />
== Account problem ==<br />
<br />
Created April 17-24 2011, IP: 80.92.249.130. I don't remember password. Little help? tapem@yandex.ru<br />
<br />
== Help I Can't Remember Password ==<br />
<br />
Help me Briess. I can't remember my password. ;-; [[user:Emi|<span style="color:#8a4e4e">Emi</span>]] [[user_talk:Emi|<span style="color:#6a3e4e">[T]</span>]] 23:13, 19 January 2012 (UTC)<br />
<br />
== Image upload ==<br />
I've noticed that this wiki is going through many changes, and I'm starting to like it more than ever before. I'll wait it out. --[[User:Nagidal|Nagidal]] 17:00, 19 February 2012 (UTC)<br />
<br />
: Thanks for telling me that the upload works again. I'll try to upload my tileset soon. --[[User:Nagidal|Nagidal]] 18:31, 24 February 2012 (UTC)<br />
<br />
Hello Briess, I have a picture of a Kiwiman that I drew that I would like to upload onto the Wiki. I see that non-Administrators can not upload files. Would it be possible for you to upload it for me and if I do make more pictures in the future how can I go about getting them onto the Wiki? Thanks. [[User:Discott|Discott]] 16:33, 16 February 2013 (UTC)<br />
<br />
== Campfirethanks ==<br />
Thanks for moving '''Campfires''' to the 2012 version. I didn't realize that should be done.<br />
<br />
== Site Dump? ==<br />
<br />
Heyo, is there a compressed archive of the wiki as it is now? Because I'd love to be able to have an offline copy that I can update occasionally. You should try to find some program that can work with a compressed version of the archive, but still update it when new pages are added and such. Anyways, thank you for your time. Let me know if you have a compressed version sitting about!<br />
<br />
<br />
A 1+ for this from me. I am frequently without net access and having the wiki with me would be a great help. [http://www.wikitaxi.org/delphi/doku.php/products/wikitaxi/index WikiTaxi] looks promising as an offline viewer, I just need something to fill it with. --[[User:Plastefuchs|Plastefuchs]] 10:46, 29 April 2012 (UTC)<br />
<br />
== Community Portal ==<br />
<br />
Back in June last year, I added a "Community Portal" link to the navigation bar, only for you to remove it in November. Is there a particular reason why you removed the only visible link to the wiki's editing rules and conventions? --[[User:Quietust|Quietust]] 15:24, 3 April 2012 (UTC)<br />
<br />
== Account deletion? ==<br />
<br />
Is there any way that you could delete my account? - Nomen<br />
<br />
== How do you think about a German wiki? ==<br />
<br />
That's Probably all ;D <br />
<br />
maybe I can help you (if you like to have a German wiki)<br />
(if want to have a closer look ,sign me at: "kempe@live.de")- MAKE<br />
<br />
<br />
9. April 2012<br />
13:55 MESZ (11:55 UTC)<br />
<br />
== Something's wrong with the Advance world generation page. (The current version page) ==<br />
<br />
As we all know, there is ''almost'' always a page for topics regarding how the item being discussed in them work for the current version. Well, for some strange reason, the DF2012:Advanced world generation page seems to have some sort of strange issue, that prevents it from being made or edited. Since I'm a little too new with how this wiki works beyond the bare surface of editing, I simply didn't know who else to ask about fixing this.<br />
<br />
I sincerely hope that you will get this message, and fix the article as soon as possible. This is the page. [[DF2012:Advanced_world_generation]] There are pages for the previous versions, but not for the current version. Also, a link to a page about how to fix things like these would be nice. --[[User:Learner4|Learner4]] 19:36, 19 May 2012 (UTC)<br />
<br />
==Registration Spam==<br />
Got this comment on my talk page, figured it might be more useful to you: --[[User:Quietust|Quietust]] 03:31, 4 June 2012 (UTC)<br />
:Q, methinks the method shown under "Comment Spam defeated at last" on Steve Hanov's Blog stevehanov.ca would save you a lot of work. <small>&ndash; [[template:unsigned|unsigned]] comment by [[User:2.215.60.207|2.215.60.207]]</small><br />
<br />
==Aquifers Tutorial==<br />
I have published it by now. It's [[DF2012:Double-slit_method]]<br />
<br />
== Just letting you know ==<br />
<br />
Just in case you didn't see my post on the forum, I was able to sign up for the forum just fine now that you fixed the DNSBL. Just wanted to say thanks again!<br />
<br />
== Why the revert? ==<br />
<br />
I'm a bit confused about why you reverted [http://dwarffortresswiki.org/index.php?title=v0.31:Flow&curid=13142&diff=174793&oldid=174785 these changes] on the v0.31 [[Flow]] page. The 2nd link was redundant, and the first pointed to a section of another article that doesn't exist. Why revert it back to its redundant broken state? -- [[User:HiEv|<span style="color:#E05858;font-weight:bold;">Hi</span>]][[User talk:HiEv|<span style="color:#C06060;font-weight:bold;">Ev</span>]] 23:30, 4 July 2012 (UTC)<br />
<br />
== Interested in taking part in a small research project? ==<br />
<br />
Hi Briess,<br />
<br />
I hope this the best way of contacting you! I'm a PhD researcher at the University of Glasgow and I'm just about to start a small research project on gaming wikis and collaborative learning (some background is available here: [http://www.smke.org/blog-post-2/]). I'm hoping to interview a few key players in the gaming wiki world (probably via web chat or Skype, or perhaps within some game environment) and wondered if you might be interested. If so, drop me a line at [email rmv'd] or reply to me here (again, I hope I'm not hijacking your User page here!).<br />
<br />
Cheers,<br />
<br />
Matt<br />
<br />
== Regenerating category contents ==<br />
<br />
Hello, and I hope you are the right person to handle an bit of administrative work. [http://dwarffortresswiki.org/index.php?title=Template:Attrib_proc&diff=prev&oldid=179609 This edit] added category links for common creature attributes to a template that is transcluded to (almost) all the creature pages. While the creature pages now correctly include a link to the relevant categories, the categories themselves do not include all the creature pages (ex. [[:Category:DF2012:Flying]] should include [[Giant eagle]]s, and many other bird variations). It appears that any (trivial) edit to a creature page "updates" the category pages appropriately, but that means every creature page that should be in a category will have to be manually edited before the category lists are correctly completed. My question is whether there is an administrative way to regenerate these category lists directly, saving hundreds of manual edits to the creature pages. Thank you! --[[User:Loci|Loci]] 22:59, 5 January 2013 (UTC)<br />
<br />
:It appears that the pages still aren't being categorized--the jobs are likely stuck in the [http://www.mediawiki.org/wiki/Manual:Job_queue Job Queue] (currently [http://dwarffortresswiki.org/api.php?action=query&meta=siteinfo&siprop=statistics 770 jobs] waiting). [http://www.mediawiki.org/wiki/Manual:RunJobs.php Manually running the queue] will hopefully put everything in the proper categories. --[[User:Loci|Loci]] 21:14, 10 January 2013 (UTC)</div>Discott