Dwarf Fortress Wiki - User contributions [en]

Sheriff

2020-07-12T14:37:44Z

Larix: Just confirmed for the nth time that sheriffs don't auto-upgrade. Failure to meet demands are pretty unusual under a sheriff, and 50 adam. hammers are impossible anyway.

{{av}}
{{Quality|Fine}}
{{Noble
| noble=Sheriff
| quarters=Modest Quarters
| dining=Modest Dining Room
| office=Modest Office
| stands=1
| racks=1
| chests=1
| cabinets=1
| function=
* Law enforcement
}}

The '''sheriff''' is the [[noble]] responsible for crude [[Justice|law enforcement]] until your fortress grows large enough to require a [[captain of the guard]], designated through the [[Nobles screen|{{k|n}}obles screen]]. They will punish lawbreaking dwarves through beatings or imprisonment. Without a [[jail]], jail sentences will be "commuted" to beatings as well.

(''When appointing a sheriff, note that having a weak dwarf take the position is sometimes a good thing. A sheriff with good strength or training could heavily injure or kill a criminal who might have done nothing worse than push over a [[quern|handmill]] in anger.'')

When your fortress first elects a [[mayor]] (after reaching 50 dwarves), the sheriff's position will disappear and the sheriff will revert to their normal profession title. A [[captain of the guard]] must be nominated to enforce the law in larger settlements.

{{gamedata| [POSITION:SHERIFF]
[NAME:sheriff:sheriffs]
[SITE]
[NUMBER:1]
[RESPONSIBILITY:LAW_ENFORCEMENT]
[APPOINTED_BY:EXPEDITION_LEADER]
[APPOINTED_BY:MAYOR]
[REPLACED_BY:CAPTAIN_OF_THE_GUARD]
[PRECEDENCE:130]
[DO_NOT_CULL]
[COLOR:1:0:1]
[ACCOUNT_EXEMPT]
[DUTY_BOUND]
[REQUIRED_BOXES:1]
[REQUIRED_CABINETS:1]
[REQUIRED_RACKS:1]
[REQUIRED_STANDS:1]
[REQUIRED_OFFICE:100]
[REQUIRED_BEDROOM:100]
[REQUIRED_DINING:100]}}
{{Nobles}}
{{Category|Military Ranks}}
{{Category|Justice}}

Soap

2017-12-03T21:29:53Z

Larix: Removed "trade value" section for extreme obsolescence - soap was last a sensible trade good in .28 it seems.

{{Quality|Superior|02:43, 19 August 2014 (UTC)}}
{{av}}

'''Soap''' is a particularly useful type of [[bar]] used for [[clean self|personal cleaning]], which increases happiness ("recently took a soapy bath") and lowers the chances of an [[Health care|infection]] in case they are [[wound]]ed, and for cleaning [[wound]]s in [[hospital]]s, preventing infections from developing. It is thus a vital commodity in dwarven [[health care]], and one not traded in [[caravan]]s: you're going to have to make some soap yourself. Since soap is considered to be a bar it can be used to make [[constructions]] and [[workshop]]s.

== Manufacture ==

Soap is made of two components, [[lye]] and fat (either [[tallow]] or [[oil]]), and requires a dedicated workshop, the [[soap maker's workshop]]. It has a somewhat complicated production process; lye must be produced at an [[ashery]] from [[ash]], which in turn must be created at a [[wood furnace]] from [[wood]] logs that must first be [[woodcutting|cut down]]. [[Tallow]] is rendered from [[fat]] from butchered [[creature|animal]]s at a [[kitchen]], requiring either [[Meat industry|livestock]] or [[hunting]] activities, while oil must be [[pressing|pressed]] from seeds or rock nuts at a [[screw press]], which first requires [[plant gathering|gathering]] up or [[farming|growing]] [[crop]] and then processing them at the [[farmer's workshop]]. One unit of tallow or oil plus one of lye creates a single bar of finished soap.

{{/flowchart}}

== Hygiene ==

Dwarves do not require soap to clean [[contaminant]]s such as mud and blood from themselves - if necessary, they will use murky pools, artificial pools of water, brooks, or a [[well]]. However, using soap will often generate the happy [[thought]] "recently took a soapy bath". It is possible to construct bath-houses (rooms containing pools of water, a soap stockpile, and perhaps a few nice statues) so dwarves living deep underground need not venture to dangerous cave pools or surface brooks to clean off a little mud or bloodstain. For cleaning wounds and preventing infection after [[surgery]], however, [[hospital]]s should be kept stocked with a small amount of soap. Soap will get used up as dwarves wash themselves; the current rate seems to be 1/10 a bar per washing, so each bar lasts quite a while.

Dwarves have an internal "dirtiness" level, which gets lowered when they have a bath, lowered further when they have a soapy bath and slowly builds up over time. This "dirtiness" value is connected to the chance of getting an infection if the dwarf is injured, making soap useful as a preventative as well as treatment.

Soap is stored in bar/block stockpiles with the "soap" option enabled.

A convenient way to keep an emergency stockpile of soap is to use it as a building material for workshops or constructions such as walls. When/if you need more soap, you can deconstruct and get the soap bars back. Since soap in a hospital is reserved for hospital use, this is especially useful in case you start to produce soap before setting up a hospital.

{{Translation
| dwarven = uben
| elvish = dathe
| goblin = snubez
| human = kamven
}}

{{gamedata}}
{{Industry}}
{{Category|Healthcare}}
{{Category|Materials}}

Creepy crawler

2017-10-08T13:47:14Z

Larix: I have creepy crawler products in a .43.05 fort, they're evidently still butcherable.

{{Quality|Exceptional|00:29, 10 June 2010 (UTC)}}
{{verminlookup/0|wiki=no}}
{{av}}
{{creaturedesc}}

'''Creepy crawlers''' are a type of [[evil]] subterranean [[vermin]]. They are found in deep [[caverns]], and may [[miasma|rot]] [[food]] [[stockpile]]s if they are nearby. They can be captured by [[trapper]]s and turned into low-value [[pet]]s. When the cavern layer they inhabit is breached, they'll begin appearing in the surface, typically wandering on top of [[food]] or [[refuse]] stockpiles.

Unlike most other vermin, creepy crawlers can be butchered for a small amount of [[meat]] and organs. Live creepy crawlers, captured by [[trapper]]s in [[animal trap]]s, are automatically lined up for slaughter at a butchery, but only if they have not been tamed yet. If killed, e.g. by a [[cat]], only unusable [[remains]] will be left over.

Some [[dwarves]] [[Preferences|like]] creepy crawlers for their ''freakish wriggling''.

{{gamedata}}
{{vermin}}

Vermin

2017-10-08T13:37:55Z

Larix: Corrected miscorrection: creepy crawlers are still butcherable.

{{av}}{{Quality|Exceptional|22:00, 9 June 2010 (UTC)}}
{{catbox}}

'''Vermin''' are small [[creature]]s such as [[rat]]s, [[bat]]s, and [[lizard]]s which are difficult to see, and also the type of [[fish]] which are caught by [[fisherdwarf|fisherdwarves]]. They are below 2 kg (4 lb) in size, much smaller than [[cat]]s. The presence of vermin can be noted if you are particularly observant, as they will occasionally blink into and out of view on the screen. The main distinctions between vermin and creatures are that vermin:
# Do not attack and cannot be engaged in [[combat]] or trigger [[trap]]s, save those specifically made to trap them;
# Do not usually provide [[meat]] or [[bone]]s. Only [[creepy crawler]]s can be butchered;
# Do not breed, but "spawn", spontaneously appearing in their natural environment or [[biome]];
# Are sometimes "[[hateable]]", meaning dwarves can have an anti-[[preference]] which gives them a negative [[thought]] when they see the hated vermin.

Vermin can be problematic as many types feed on [[stockpile]]s, thus making it more difficult to keep enough [[food]] and [[alcohol|drink]] to survive. Some species can even cause food to rot faster when left outside of a [[barrel]] or [[large pot]]. Vermin can be hunted by [[cat]]s and [[peregrine falcon]]s to reduce this problem, though the [[remains]] will still need to be [[Activity zone#Garbage Dump|removed]]. Cats and falcons can be [[pasture]]d at the relevant stockpiles to further reduce the problem.

Vermin can, however, be captured in [[animal trap]]s, and can be trained as [[pet]]s. A few captured vermin can be used to produce [[extract]]s using a glass [[vial]] and the [[animal dissector]] labor. Captured [[purring maggot]]s can also be [[milk]]ed at a farmer's workshop.

Dwarves will eat vermin if no [[food]] source is available, resulting in an unhappy [[thought]].

==Reading the Table==
{{CreatureCurrent table head}}
|}
The above columns indicate, in order:

*'''Symbol:''' The symbol assigned to the vermin, how you will see it without a graphic set.
*'''Name:''' The name of the vermin as it shows up in-game.
*'''Playable:''' Whether the vermin is playable in any of the game modes. As of now, no vermin are playable.
*'''Hostile:''' Whether the vermin is hostile to the player. As of now, no vermin are hostile to dwarves.
*'''Food Source:''' If "Yes" then the vermin can be turned into food when processed in a [[fishery]].
*'''Adult Body Size:''' The average size of the vermin when an adult. This can be anywhere from 1 for a [[fly]] to 2,000 for a [[fox squirrel]]. More or less equals the creature's weight in grams.
*'''Pet Value:''' This is the value the vermin can be bought and sold for as a [[pet]] during [[trading]].
*'''Biome:''' Where the vermin can be found.
*'''Features:''' Any special features the vermin possesses, these can include alignment and special properties.

==Vermin==
{{CreatureCurrent table head}}
{{CreatureCurrent table row|name=[[Acorn fly]]|symbol=·|color=6:0:1|food=No|playable=No|hostile=N/A|size=20|value=N/A|biome=Any pool|note=Savage}}
{{CreatureCurrent table row|name=[[Anchovy]]|symbol=α|color=7:0:1|food=Yes|playable=No|hostile=N/A|size=200|value=N/A|biome=Temperate oceans|note=}}
{{CreatureCurrent table row|name=[[Anole]]|symbol=∙|color=2:0:1|food=No|playable=No|hostile=N/A|size=90|value=10|biome=Any tropical forest|note=}}
{{CreatureCurrent table row|name=[[Ant]]|symbol=∙|color=7:0:0|food=No|playable=No|hostile=N/A|size=1|value=N/A|biome=Not freezing|note=}}
{{CreatureCurrent table row|name=[[Axolotl]]|symbol=∙|color=5:0:0|food=No|playable=No|hostile=N/A|size=200|value=10|biome=Tropical saltwater, brackish and freshwater lakes|note=}}
{{CreatureCurrent table row|name=[[Banded knifefish]]|symbol=α|color=6:0:0|food=Yes|playable=No|hostile=N/A|size=200|value=N/A|biome=Tropical freshwater lakes and rivers|note=}}
{{CreatureCurrent table row|name=[[Bark scorpion]]|symbol=∙|color=6:0:1|food=No|playable=No|hostile=N/A|size=3|value=N/A|biome=Tropical grasslands, savannas, shrublands, coniferous forests and any desert|note=Hateable}}
{{CreatureCurrent table row|name=[[Bat]]|symbol=∙|color=0:0:1|food=No|playable=No|hostile=N/A|size=100|value=10|biome=Not freezing, subterranean chasms|note=Hateable}}
{{CreatureCurrent table row|name=[[Bat ray]]|symbol=ò|color=7:0:0|food=Yes|playable=No|hostile=N/A|size=200|value=N/A|biome=Temperate and tropical oceans|note=}}
{{CreatureCurrent table row|name=[[Beetle]]|symbol=·|color=4:0:0|food=No|playable=No|hostile=N/A|size=1|value=N/A|biome=Not freezing|note=}}
{{CreatureCurrent table row|name=[[Black bullhead]]|symbol=α|color=6:0:0|food=Yes|playable=No|hostile=N/A|size=200|value=N/A|biome=Tropical brackish and freshwater lakes|note=}}
{{CreatureCurrent table row|name=[[Blood gnat]]|symbol=·|color=4:0:1|food=No|playable=No|hostile=N/A|size=1|value=N/A|biome=Any pool|note=Hateable, evil, rots food}}
{{CreatureCurrent table row|name=[[Blue jay]]|symbol=∙|color=1:0:1|food=No|playable=No|hostile=N/A|size=100|value=30|biome=Temperate grasslands, savannas, shrublands, broadleaf and coniferous forests|note=}}
{{CreatureCurrent table row|name=[[Brook lamprey]]|symbol=~|color=3:0:0|food=Yes|playable=No|hostile=N/A|size=200|value=N/A|biome=Tropical saltwater, brackish and freshwater lakes, tropical oceans|note=}}
{{CreatureCurrent table row|name=[[Brown bullhead]]|symbol=α|color=6:0:0|food=Yes|playable=No|hostile=N/A|size=200|value=N/A|biome=Temperate brackish and freshwater lakes|note=}}
{{CreatureCurrent table row|name=[[Brown recluse spider]]|symbol=∙|color=6:0:0|food=No|playable=No|hostile=N/A|size=1|value=N/A|biome=Temperate broadleaf forests|note=Hateable, produces [[web]]}}
{{CreatureCurrent table row|name=[[Bumblebee]]|symbol=·|color=6:0:1|food=No|playable=No|hostile=N/A|size=1|value=N/A|biome=Not freezing|note=}}
{{CreatureCurrent table row|name=[[Bushtit]]|symbol=∙|color=6:0:0|food=No|playable=No|hostile=N/A|size=5|value=30|biome=Any temperate forest|note=}}
{{CreatureCurrent table row|name=[[Cap hopper]]|symbol=∙|color=2:0:0|food=No|playable=No|hostile=N/A|size=200|value=10|biome=Subterranean water|note=}}
{{CreatureCurrent table row|name=[[Cardinal]]|symbol=∙|color=4:0:1|food=No|playable=No|hostile=N/A|size=50|value=30|biome=Temperate grasslands, savannas, shrublands, broadleaf and coniferous forests|note=}}
{{CreatureCurrent table row|name=[[Cave fish]]|symbol=α|color=7:0:1|food=Yes|playable=No|hostile=N/A|size=1000|value=N/A|biome=Subterranean water|note=}}
{{CreatureCurrent table row|name=[[Cave lobster]]|symbol=¥|color=7:0:1|food=Yes|playable=No|hostile=N/A|size=600|value=N/A|biome=Subterranean water|note=}}
{{CreatureCurrent table row|name=[[Cave spider]]|symbol=∙|color=7:0:0|food=No|playable=No|hostile=N/A|size=50|value=N/A|biome=Subterranean water and chasm|note=Hateable, produces web}}
{{CreatureCurrent table row|name=[[Cave swallow]]|symbol=∙|color=0:0:1|food=No|playable=No|hostile=N/A|size=100|value=30|biome=Subterranean chasm|note=}}
{{CreatureCurrent table row|name=[[Chameleon]]|symbol=∙|color=2:0:1|food=No|playable=No|hostile=N/A|size=150|value=10|biome=Any tropical forest, tropical shrublands and savannas, any desert|note=}}
{{CreatureCurrent table row|name=[[Char]]|symbol=α|color=0:0:1|food=Yes|playable=No|hostile=N/A|size=200|value=N/A|biome=Temperate brackish and freshwater lakes|note=}}
{{CreatureCurrent table row|name=[[Chipmunk]]|symbol=∙|color=6:0:0|food=No|playable=No|hostile=N/A|size=300|value=10|biome=Any temperate forest|note=}}
{{CreatureCurrent table row|name=[[Clown loach]]|symbol=α|color=6:0:1|food=Yes|playable=No|hostile=N/A|size=200|value=N/A|biome=Tropical brackish and freshwater lakes|note=}}
{{CreatureCurrent table row|name=[[Clownfish]]|symbol=α|color=4:0:1|food=Yes|playable=No|hostile=N/A|size=200|value=N/A|biome=Tropical oceans|note=}}
{{CreatureCurrent table row|name=[[Cockatiel]]|symbol=∙|color=7:0:1|food=No|playable=No|hostile=N/A|size=90|value=30|biome=Any desert, temperate grasslands|note=}}
{{CreatureCurrent table row|name=[[Creepy crawler]]|symbol=*|color=6:0:0|food=Yes|playable=No|hostile=N/A|size=1000|value=20|biome=Underground chasm|note=Evil, rots food}}
{{CreatureCurrent table row|name=[[Crow]]|symbol=∙|color=0:0:1|food=No|playable=No|hostile=N/A|size=500|value=10|biome=Temperate forests, grasslands, savannas, shrublands and wetlands, taiga|note=}}
{{CreatureCurrent table row|name=[[Cuttlefish]]|symbol=♂|color=6:0:0|food=Yes|playable=No|hostile=N/A|size=1000|value=10|biome=Any ocean|note=}}
{{CreatureCurrent table row|name=[[Damselfly]]|symbol=∙|color=3:0:1|food=No|playable=No|hostile=N/A|size=1|value=N/A|biome=Any pool|note=}}
{{CreatureCurrent table row|name=[[Demon rat]]|symbol=∙|color=4:0:0|food=No|playable=No|hostile=N/A|size=300|value=20|biome=Not freezing|note=Evil}}
{{CreatureCurrent table row|name=[[Dragonfly]]|symbol=∙|color=3:0:1|food=No|playable=No|hostile=N/A|size=1|value=N/A|biome=Any pool|note=}}
{{CreatureCurrent table row|name=[[Fairy]]|symbol=∙|color=6:0:1|food=No|playable=No|hostile=N/A|size=100|value=10|biome=All except pools, rivers, and underground|note=Good, [[fanciful]]}}
{{CreatureCurrent table row|name=[[Fire snake]]|symbol=∙|color=6:0:1|food=No|playable=No|hostile=N/A|size=1000|value=10|biome=Subterranean lava|note=Hateable}}
{{CreatureCurrent table row|name=[[Firefly]]|symbol=∙|color=2:0:1|food=No|playable=No|hostile=N/A|size=1|value=N/A|biome=Not freezing|note=}}
{{CreatureCurrent table row|name=[[Flounder]]|symbol=α|color=6:0:0|food=Yes|playable=No|hostile=N/A|size=200|value=N/A|biome=Temperate oceans|note=}}
{{CreatureCurrent table row|name=[[Fluffy wambler]]|symbol=∙|color=7:0:1|food=No|playable=No|hostile=N/A|size=2000|value=20|biome=Any land|note=Good}}
{{CreatureCurrent table row|name=[[Fly]]|symbol=·|color=0:0:1|food=No|playable=No|hostile=N/A|size=1|value=N/A|biome=Not freezing, any pool|note=Hateable}}
{{CreatureCurrent table row|name=[[Flying squirrel]]|symbol=∙|color=6:0:0|food=No|playable=No|hostile=N/A|size=200|value=10|biome=Any temperate forest|note=}}
{{CreatureCurrent table row|name=[[Fox squirrel]]|symbol=∙|color=6:0:0|food=No|playable=No|hostile=N/A|size=2000|value=100|biome=Any temperate forest|note=Savage}}
{{CreatureCurrent table row|name=[[Glasseye]]|symbol=α|color=4:0:1|food=Yes|playable=No|hostile=N/A|size=200|value=N/A|biome=Tropical oceans|note=}}
{{CreatureCurrent table row|name=[[Grackle]]|symbol=∙|color=0:0:1|food=No|playable=No|hostile=N/A|size=120|value=30|biome=Temperate grasslands and savannas|note=}}
{{CreatureCurrent table row|name=[[Grasshopper]]|symbol=·|color=2:0:1|food=No|playable=No|hostile=N/A|size=1|value=N/A|biome=Not freezing|note=}}
{{CreatureCurrent table row|name=[[Gray squirrel]]|symbol=∙|color=7:0:0|food=No|playable=No|hostile=N/A|size=300|value=10|biome=Any temperate forest|note=}}
{{CreatureCurrent table row|name=[[Green tree frog]]|symbol=∙|color=2:0:1|food=No|playable=No|hostile=N/A|size=100|value=10|biome=Temperate freshwater lakes, pools, swamps and marshes|note=}}
{{CreatureCurrent table row|name=[[Guppy]]|symbol=α|color=1:0:1|food=Yes|playable=No|hostile=N/A|size=200|value=N/A|biome=Tropical brackish, saltwater and freshwater lakes and rivers|note=}}
{{CreatureCurrent table row|name=[[Hagfish]]|symbol=~|color=6:0:0|food=Yes|playable=No|hostile=N/A|size=200|value=N/A|biome=Arctic and temperate oceans|note=}}
{{CreatureCurrent table row|name=[[Hake]]|symbol=α|color=7:0:1|food=Yes|playable=No|hostile=N/A|size=200|value=N/A|biome=Arctic and temperate oceans|note=}}
{{CreatureCurrent table row|name=[[Hamster]]|symbol=∙|color=7:0:0|food=No|playable=No|hostile=N/A|size=150|value=10|biome=Not freezing|note=Hateable}}
{{CreatureCurrent table row|name=[[Hedgehog]]|symbol=∙|color=6:0:0|food=No|playable=No|hostile=N/A|size=800|value=10|biome=Temperate shrublands and savannas|note=}}
{{CreatureCurrent table row|name=[[Herring]]|symbol=α|color=3:0:1|food=Yes|playable=No|hostile=N/A|size=200|value=N/A|biome=Arctic and temperate oceans|note=}}
{{CreatureCurrent table row|name=[[Honey bee]]|symbol=·|color=6:0:1|food=No|playable=No|hostile=N/A|size=1|value=1|biome=Not freezing|note=Usable for [[beekeeping industry]]}}
{{CreatureCurrent table row|name=[[Jumping spider]]|symbol=·|color=0:0:1|food=No|playable=No|hostile=N/A|size=1|value=N/A|biome=Not freezing|note=Hateable}}
{{CreatureCurrent table row|name=[[Knuckle worm]]|symbol=~|color=0:0:1|food=No|playable=No|hostile=N/A|size=1000|value=100|biome=Not freezing|note=}}
{{CreatureCurrent table row|name=[[Large roach]]|symbol=∙|color=6:0:0|food=No|playable=No|hostile=N/A|size=1|value=5|biome=Not freezing|note=Hateable}}
{{CreatureCurrent table row|name=[[Leech]]|symbol=~|color=0:0:1|food=No|playable=No|hostile=N/A|size=100|value=10|biome=Any lake and pool|note=Hateable}}
{{CreatureCurrent table row|name=[[Leopard gecko]]|symbol=∙|color=6:0:1|food=No|playable=No|hostile=N/A|size=50|value=10|biome=Any desert|note=}}
{{CreatureCurrent table row|name=[[Lion tamarin]]|symbol=∙|color=6:0:1|food=No|playable=No|hostile=N/A|size=620|value=10|biome=Tropical moist broadleaf forests|note=}}
{{CreatureCurrent table row|name=[[Lizard]]|symbol=∙|color=6:0:0|food=No|playable=No|hostile=N/A|size=200|value=10|biome=Not freezing|note=Hateable}}
{{CreatureCurrent table row|name=[[Lorikeet]]|symbol=∙|color=4:0:1|food=No|playable=No|hostile=N/A|size=200|value=30|biome=Tropical moist broadleaf forests, mangrove swamps|note=}}
{{CreatureCurrent table row|name=[[Louse]]|symbol=·|color=6:0:0|food=No|playable=No|hostile=N/A|size=1|value=N/A|biome=Not freezing|note=}}
{{CreatureCurrent table row|name=[[Lungfish]]|symbol=α|color=6:0:0|food=Yes|playable=No|hostile=N/A|size=200|value=N/A|biome=Tropical brackish, saltwater and freshwater lakes, rivers and pools|note=}}
{{CreatureCurrent table row|name=[[Mackerel]]|symbol=α|color=7:0:0|food=Yes|playable=No|hostile=N/A|size=200|value=N/A|biome=Arctic and temperate oceans|note=}}
{{CreatureCurrent table row|name=[[Magpie]]|symbol=∙|color=0:0:1|food=No|playable=No|hostile=N/A|size=200|value=30|biome=Temperate grasslands, savannas and shrublands|note=}}
{{CreatureCurrent table row|name=[[Mantis]]|symbol=·|color=2:0:1|food=No|playable=No|hostile=N/A|size=1|value=N/A|biome=Not freezing|note=}}
{{CreatureCurrent table row|name=[[Masked lovebird]]|symbol=∙|color=2:0:1|food=No|playable=No|hostile=N/A|size=90|value=30|biome=Any tropical forest|note=}}
{{CreatureCurrent table row|name=[[Moghopper]]|symbol=∙|color=6:0:0|food=No|playable=No|hostile=N/A|size=300|value=20|biome=Any pool|note=Savage, only usable creature for [[fish dissector]]s}}
{{CreatureCurrent table row|name=[[Monarch butterfly]]|symbol=∙|color=4:0:1|food=No|playable=No|hostile=N/A|size=1|value=N/A|biome=Not freezing|note=}}
{{CreatureCurrent table row|name=[[Moon snail]]|symbol=∙|color=4:0:1|food=No|playable=No|hostile=N/A|size=200|value=10|biome=Temperate oceans|note=Hateable}}
{{CreatureCurrent table row|name=[[Mosquito]]|symbol=·|color=0:0:1|food=No|playable=No|hostile=N/A|size=1|value=N/A|biome=Not freezing, any pool|note=Hateable}}
{{CreatureCurrent table row|name=[[Moth]]|symbol=∙|color=6:0:0|food=No|playable=No|hostile=N/A|size=1|value=N/A|biome=Not freezing|note=}}
{{CreatureCurrent table row|name=[[Mussel]]|symbol=m|color=7:0:1|food=Yes|playable=No|hostile=N/A|size=200|value=10|biome=Any ocean, lake and river|note=Hateable}}
{{CreatureCurrent table row|name=[[Nautilus]]|symbol=♂|color=4:0:1|food=Yes|playable=No|hostile=N/A|size=500|value=10|biome=Any ocean|note=}}
{{CreatureCurrent table row|name=[[Olm]]|symbol=∙|color=7:0:1|food=No|playable=No|hostile=N/A|size=200|value=10|biome=Subterranean water|note=}}
{{CreatureCurrent table row|name=[[Oriole]]|symbol=∙|color=6:0:1|food=No|playable=No|hostile=N/A|size=40|value=30|biome=Temperate broadleaf forests|note=}}
{{CreatureCurrent table row|name=[[Oyster]]|symbol=o|color=7:0:1|food=Yes|playable=No|hostile=N/A|size=200|value=10|biome=Any ocean|note=Hateable}}
{{CreatureCurrent table row|name=[[Parakeet]]|symbol=∙|color=2:0:1|food=No|playable=No|hostile=N/A|size=120|value=30|biome=Tropical grasslands, savannas, shrublands and forests|note=}}
{{CreatureCurrent table row|name=[[Peach-faced lovebird]]|symbol=∙|color=2:0:1|food=No|playable=No|hostile=N/A|size=60|value=30|biome=Temperate grasslands, savannas, shrublands and broadleaf forests|note=}}
{{CreatureCurrent table row|name=[[Perch]]|symbol=α|color=7:0:1|food=Yes|playable=No|hostile=N/A|size=200|value=N/A|biome=Temperate freshwater rivers and lakes|note=}}
{{CreatureCurrent table row|name=[[Phantom spider]]|symbol=∙|color=7:0:1|food=No|playable=No|hostile=N/A|size=500|value=N/A|biome=Temperate and tropical forests|note=Evil, produces web}}
{{CreatureCurrent table row|name=[[Pixie]]|symbol=·|color=3:0:1|food=No|playable=No|hostile=N/A|size=1|value=10|biome=All except pools, rivers, and underground|note=Good, fanciful}}
{{CreatureCurrent table row|name=[[Pond turtle]]|symbol=☼|color=2:0:0|food=Yes|playable=No|hostile=N/A|size=500|value=10|biome=Any pool|note=}}
{{CreatureCurrent table row|name=[[Purring maggot]]|symbol={|color=7:0:1|food=No|playable=No|hostile=N/A|size=1000|value=10|biome=Underground chasm|note=Hateable, produces [[milk]]}}
{{CreatureCurrent table row|name=[[Rainbow trout]]|symbol=α|color=2:0:1|food=Yes|playable=No|hostile=N/A|size=200|value=N/A|biome=Temperate freshwater rivers and lakes|note=}}
{{CreatureCurrent table row|name=[[Rat]]|symbol=∙|color=0:0:1|food=No|playable=No|hostile=N/A|size=300|value=10|biome=Not freezing|note=Hateable}}
{{CreatureCurrent table row|name=[[Red squirrel]]|symbol=∙|color=6:0:0|food=No|playable=No|hostile=N/A|size=300|value=10|biome=Any temperate forest|note=}}
{{CreatureCurrent table row|name=[[Red-winged blackbird]]|symbol=∙|color=0:0:1|food=No|playable=No|hostile=N/A|size=50|value=30|biome=Temperate salwater and freshwater marshes|note=}}
{{CreatureCurrent table row|name=[[Sailfin molly]]|symbol=α|color=2:0:0|food=Yes|playable=No|hostile=N/A|size=200|value=N/A|biome=Temperate brackish, saltwater and freshwater lakes, rivers and pools|note=}}
{{CreatureCurrent table row|name=[[Salmon]]|symbol=α|color=4:0:1|food=Yes|playable=No|hostile=N/A|size=200|value=N/A|biome=Temperate brackish, saltwater and freshwater lakes, temperate oceans|note=}}
{{CreatureCurrent table row|name=[[Sea nettle jellyfish]]|symbol=Ω|color=6:0:0|food=Yes|playable=No|hostile=N/A|size=200|value=10|biome=Temperate oceans|note=}}
{{CreatureCurrent table row|name=[[Seahorse]]|symbol=α|color=2:0:0|food=Yes|playable=No|hostile=N/A|size=200|value=N/A|biome=Temperate and tropical oceans|note=}}
{{CreatureCurrent table row|name=[[Shad]]|symbol=α|color=3:0:1|food=Yes|playable=No|hostile=N/A|size=200|value=N/A|biome=Temperate brackish, saltwater and freshwater lakes, temperate and arctic oceans|note=}}
{{CreatureCurrent table row|name=[[Skink]]|symbol=∙|color=7:0:0|food=No|playable=No|hostile=N/A|size=500|value=10|biome=Any desert, temperate and tropical|note=}}
{{CreatureCurrent table row|name=[[Slug]]|symbol=~|color=6:0:0|food=No|playable=No|hostile=N/A|size=1|value=10|biome=Not freezing|note=Hateable}}
{{CreatureCurrent table row|name=[[Snail]]|symbol=∙|color=7:0:0|food=No|playable=No|hostile=N/A|size=1|value=10|biome=Not freezing|note=Hateable}}
{{CreatureCurrent table row|name=[[Sole]]|symbol=α|color=6:0:0|food=Yes|playable=No|hostile=N/A|size=200|value=N/A|biome=Temperate and arctic oceans|note=}}
{{CreatureCurrent table row|name=[[Sparrow]]|symbol=∙|color=6:0:0|food=No|playable=No|hostile=N/A|size=30|value=30|biome=Any grassland, savanna, shrubland, temperate and tropical forest, desert and wetland|note=}}
{{CreatureCurrent table row|name=[[Spotted ratfish]]|symbol=α|color=6:0:0|food=Yes|playable=No|hostile=N/A|size=200|value=N/A|biome=Temperate oceans|note=}}
{{CreatureCurrent table row|name=[[Squid]]|symbol=♂|color=7:0:1|food=Yes|playable=No|hostile=N/A|size=200|value=10|biome=Any ocean|note=}}
{{CreatureCurrent table row|name=[[Steelhead trout]]|symbol=α|color=3:0:1|food=Yes|playable=No|hostile=N/A|size=200|value=N/A|biome=Temperate brackish, saltwater and freshwater lakes, temperate and arctic oceans|note=}}
{{CreatureCurrent table row|name=[[Termite]]|symbol=·|color=7:0:1|food=No|playable=No|hostile=N/A|size=1|value=N/A|biome=Not freezing|note=}}
{{CreatureCurrent table row|name=[[Thornback ray]]|symbol=ò|color=6:0:0|food=Yes|playable=No|hostile=N/A|size=200|value=N/A|biome=Temperate and tropical oceans|note=}}
{{CreatureCurrent table row|name=[[Thrips]]|symbol=·|color=7:0:1|food=No|playable=No|hostile=N/A|size=1|value=N/A|biome=Not freezing|note=}}
{{CreatureCurrent table row|name=[[Tick]]|symbol=·|color=0:0:1|food=No|playable=No|hostile=N/A|size=1|value=N/A|biome=Not freezing|note=}}
{{CreatureCurrent table row|name=[[Toad]]|symbol=∙|color=2:0:0|food=No|playable=No|hostile=N/A|size=200|value=10|biome=Any pool|note=Hateable}}
{{CreatureCurrent table row|name=[[Two-legged rhino lizard]]|symbol=∙|color=7:0:0|food=No|playable=No|hostile=N/A|size=1000|value=20|biome=Any land|note=Savage}}
{{CreatureCurrent table row|name=[[White-spotted puffer]]|symbol=α|color=7:0:0|food=Yes|playable=No|hostile=N/A|size=200|value=N/A|biome=Tropical oceans|note=}}
{{CreatureCurrent table row|name=[[Worm]]|symbol=~|color=7:0:0|food=No|playable=No|hostile=N/A|size=100|value=10|biome=Any temperate, any tropical, taiga|note=Hateable}}
{{CreatureCurrent table row|name=[[Wren]]|symbol=∙|color=6:0:0|food=No|playable=No|hostile=N/A|size=40|value=30|biome=Any grassland, savanna, shrubland, forest, desert and wetland|note=}}
{{CreatureCurrent table row|name=[[Yellow bullhead]]|symbol=α|color=6:0:0|food=Yes|playable=No|hostile=N/A|size=200|value=N/A|biome=Temperate brackish and freshwater lakes|note=}}
|}

{{Translation
| dwarven = bomik
| elvish = nirica
| goblin = otod
| human = strilu
}}

{{Category|Vermin| }}

[[ru:DF2012:Vermin]]
{{Vermin}}

DF2014 Talk:Minecart

2017-09-12T22:25:56Z

Larix: /* Landing Cradle */

===Track stops===

Since this has needed scrubbing three times already:

In the game as is, track stops can only be edited at build time. Once the order has been placed, the player can no longer directly see or change the parameters. To change the settings of a track stop, you have to deconstruct it and re-build it with the desired settings. I've verified this as behaviour of unmodded DF 40.24.

There's apparently a DFHack command that allows editing existing track stops. This is ''not'' standard functionality and should be mentioned as DFHack-specific, if at all.--[[User:Larix|Larix]] ([[User talk:Larix|talk]]) 13:48, 28 February 2015 (UTC)

== Physics, "numbers behind the scenes" ==

Since dwarven pushes ''demonstrably'' 'port carts to the middle of the next tile, and the checkpoint effect to the very end of them, i'm reasonably certain that the various "middle of the previous/current/next tile" effects mentioned are simple misinterpretations of the game's data dumps:

I suspect that in the data dumps cited in the thread about the minecart speed spreadsheet, an exact-number tile location of, say "120" is not the "start" but the ''middle'' of a tile, and the sub-locations that are actually part of the tile are those which "round" to 120, i.e. those from 119,50001 to 120,5. I find this much more intuitive than talking about how ramps/holes/rollers affect carts from the "middle of the previous tile", when a closer inspection would show that the carts are actually ''displayed'' in the relevant feature's tile at that point. Since this is really a question of interpretation of programme-internal data which are invisible in the game proper, i've taken the liberty to only mention the observable effects.--[[User:Larix|Larix]] ([[User talk:Larix|talk]]) 20:15, 9 October 2015 (UTC)

== Pragmatic calculations ==

Classic high school physics effectively analyzes a lot of minecart problems. This is already casually alluded to in the article, but IMO could be spelled out more blatantly for those who might not find the connections obvious. DF minecart physics approximate ds/dt = v and dv/dt = a from which follows energy conservation dE/dt = 0 where E = ∫ a ds - v2/2. --[[User:Crcr|Crcr]] ([[User talk:Crcr|talk]]) 13:24, 30 October 2016 (UTC)

== Movement of large items like furniture? ==

I'm planning my next fortress and wanted to make a sort of 'service elevator' that moves items up and down floors en-masse.

I was wondering how this would work with furniture. How many beds, for example, will fit in a minecart? What about mechanisms etc? I wouldn't want to bottleneck the whole system with large furniture items.

I could work it out myself if I had the volume value for each item, but I can't find them. I've had a really good dig through the raws.

I can't test it right now because I'm at work, daydreaming and doodling about the next chance I'll get to play...

== Landing Cradle ==

I've figured out a way to negate falling damage, but this needs independent verification and a clearer explanation of the physics behind it before it can be organized into the article. I have a cart with a forward velocity of 180k falling from 23 tiles landing on a valid down ramp followed immediately by a valid up ramp. Friction is added only from the up ramp, z vel becomes positive, and the next tile becomes checkpointed. Placing a floor over the checkpoint tile will level out z vel, and the cart will continue horizontally at derailing speed. [[User:Uzu Bash|Uzu Bash]] ([[User talk:Uzu Bash|talk]]) 21:44, 9 September 2017 (UTC)

: I can confirm - that landing on a ramp (a functional one that actually provides acceleration) keeps a rider safe. I simply set up a plain old impulse ramp with adjacent wall in the landing spot and got dwarfs to land without combat report after flights of 15z and 7z apex height. Two dwarfs were hurt verifying that such a landing is very much not safe otherwise. Adding some more ramps with the same acceleration direction also allows a safe landing, so it appears that it's the touching down onto a ramp (and not e.g. checkpoint weirdness) what prevents the collision with the cart.--[[User:Larix|Larix]] ([[User talk:Larix|talk]]) 22:25, 12 September 2017 (UTC)

Weapon

2017-08-17T16:48:17Z

Larix: rainbow trout haven't produced craftable bones for years.

{{Quality|Masterwork|16:52, 10 June 2015 (UTC)}}
{{av}}
:''This page deals entirely with manufactured weapons. For natural weapons, see [[Natural weapon]].''

A '''weapon''' in the sense described on this page is any object specifically designed to be wielded in the pursuit of bodily harm to others. In [[fortress mode]], weapons can be made at a [[metalsmith's forge]] (all metal weapons) using a single bar of metal, despite the fact that most weapons in the game (with the exception of swords and maces) would have wooden handles in real life, a [[bowyer's workshop]] (wooden and bone crossbows), or a [[craftsdwarf's workshop]] ([[obsidian]] short swords).

== Basics ==

=== Native vs. foreign ===
Weapons can be split in two categories: those that you can produce, and those that you can't. [[Weaponsmith]]s can produce seven types of native weapons at a [[metalsmith's forge]], but there are also fourteen foreign weapons that can be found in the hands of enemy combatants, or bought from trading caravans (note, however, that due to bugs, several foreign weapons currently are effectively unusable by dwarves). These may use skills your dwarves are unfamiliar with. It is impossible to buy them in bulk, and they are of variable quality and material. Like all weapons they tend to be expensive as trade goods. They may be worth using if you can secure a high-quality specimen (see [[#Quality and strange moods|Quality]] below). Since they are common for other nations, it is important to understand their properties when you have to fight enemies wielding them.

=== Types of weapons ===
{{main|Attack types}}
From another point of view there are four categories: slashing, piercing, crushing, and ranged.

Slashing weapons, like [[short sword]]s and [[battle axe]]s, work by concentrating their force along a sharp edge, allowing them to cut gashes in or to completely sever body parts. Severing is most likely when the body part's thickness is smaller than the weapon's contact edge. They make the quickest work of unarmored opponents who are not tremendously large. They are far less effective against armored targets, however, as armor may prevent the cutting, converting strikes into weaker blunt damage.

Piercing weapons, like [[spear]]s and [[pick]]s, work by concentrating their force at a point, allowing them to punch through armor and damage internal organs. They often get stuck in the opponent, giving their wielder further leverage on the target.

Crushing weapons, like [[war hammer]]s and [[mace]]s, work by concentrating their force behind a large, blunt mass, putting dents in armor and breaking bones beneath their blows. These weapons are slow to kill their targets - dwarves have a habit of breaking every bone in their opponent's body before finally landing a fatal head strike and moving on to the next target - but are the most effective weapons against large and heavily armored foes, and possibly against the [[undead]] as well.

Ranged weapons - [[crossbow]]s, [[bow]]s, and [[blowgun]]s - are effectively piercing weapons which work at a distance. When used in melee combat as a bludgeon, crossbows produce blunt weapon damage instead. Bows used in melee are treated like extremely weak swords.

There exists one more kind of weapon: the so-called training weapon. Training weapons are all wooden, and are all made at the [[carpenter's workshop]]. Training axes, spears, and short swords can be constructed in fortress mode. They do little blunt impact damage, due to the poor [[material science|material properties]] of wood. Their primary purpose in fortress mode is to allow your dwarves to train before you have a working metal industry. They can also be used during live combat exercises (beating upon a disarmed goblin, etc.) to extend the training session's length. Finally, they may be issued to the guards to reduce the lethality of a [[justice|criminal beating]].

=== Types of targets ===
One can divide the types of foes you will meet into three categories. The first is organic and unarmored (or poorly armored) enemies, like [[thief|thieves]], non-sentient [[creature]]s (be it local wildlife or siege mounts), [[semi-megabeast]]s and [[megabeast]]s besides the [[bronze colossus]]. Weapons that deal slashing damage work best and quickest against these types of enemies, severing whole body parts and leaving them severely incapacitated.

The second is organic and armored enemies, like [[ambush]]ers and [[siege]]rs. The way [[armor]] works, slashing blows that are countered by a piece of armor are converted into generally less effective blunt damage; the best damage against these kinds of enemies are piercing weapons, which punch through armor and damage their internal organs, incapacitating them and allowing the wielder to finish them off. Crushing weapons work as well, although they are slower.

The third and most dangerous types of enemies are inorganic enemies (or ones that [[Giant cave spider|don't feel pain]]), which are [[titan]]s, [[forgotten beast]]s, [[bronze colossus]]es, and [[HFS|hidden fun stuff]]. These enemies ''have'' no internal organs, and depending on the material they are made of, may be very difficult to slash at (although a forgotten beast made of, for instance, mud is laughably easy to kill). Against these enemies, crushing weapons are the best, because they can chip at their foes until they collapse from cumulative damage.

=== Weapon skill ===
{{main|Combat skill#Weapon skill}}
Every type of weapon has its own associated [[military]] [[skill]]. The higher a dwarf is in his skill with a weapon, the better he will be able to use it in combat, connecting hammer blows to more advantageous sweet spots and sending spears right through enemy hearts and lungs with greater accuracy. The higher the weapon skill, the better at fighting the dwarf will be.

Once a dwarf has reached "Great" skill in a certain weapon, they become weapon lords for that specific weapon. They are listed as such on the [[status]] screen, will love fighting, and will no longer complain about long patrol duties. Weapon skill is trained in fighting enemies in combat, demonstrations, and combat drills, but if you leave your dwarves shield-less, a [[danger room]] will train their skill very, very quickly. Note that this does not quite work for marksdwarves - danger rooming ranged weapons increases their melee skill, increasing their hammerdwarf skill, although [[Cross-training|this may be the point]].

=== Attachment ===
A dwarf that has used a particular weapon for a long time will grow attached to it, equipping it whenever their uniform allows them to. This is fine if they are wielding a ☼Steel Mace☼, but a major problem if they are wielding what is meant to be a training weapon (be it a wooden axe or a copper spear). You can avoid this pitfall by not using training weapons and not forging weapons until you have real weaponsmithing underway. These events generate [[announcement]]s. If a dwarf does become attached you can easily force him to relinquish the weapon by assigning a 'specific weapon' instead in his equipment view.

In addition, dwarves that reach a certain number or level of kills or train long enough with a weapon will name it. This prompts a major announcement. The weapon in question may have no kills associated with it, legendary dwarves occasionally name their weapons while training with them. Once named, the weapon will appear in the artifact list, albeit in blue. It is unknown if named weapons perform better than unnamed weapons.

Dwarves may also become attached to shields and name them in the same way.

=== Quality and strange moods ===
The [[quality]] of a weapon has a significant (and currently poorly understood) impact on its combat performance, as well as its [[value]].

{{DF2014:Item quality/Table}}

Weaponsmithing is a [[moodable]] profession, which means that you can get [[artifact]] weapons. This is a bit of a mixed bag: while a legendary [[armorsmith]] might be more useful, it's certainly better than a legendary [[tanner]]. Artifact weapons have a 3x combat bonus and can be made out of a wide range of materials; ordinarily a [[hippo]] [[bone]] spear is impossible, but a moody dwarf can create one with a stack of hippo bone. Artifact weapons made of totally inappropriate materials are inferior to regular ones made of weapons-grade metal, although the exact balance is still under discussion.

=== Weapons as tools ===
[[Hunter]]s use crossbows, [[Wood cutter]]s use [[battle axe]]s (wooden training axes worked prior to version 0.43.01), and [[miner]]s use [[pick]]s. They must be in possession of these items to do their jobs, and it's as simple as that.

Hunters gain [[marksdwarf]] skill from hunting, but wood cutters do not gain [[axedwarf]] weapon skill from cutting trees. Miners gain [[mining]] skill, which is not considered a military skill, but is used as a weapon skill when fighting with a pick. A dwarf using a weapon as a tool will not use the same tool as a military weapon, instead dropping their tool to pick up another for military use.{{bug|1451}} Dwarves may carry only one weapon as a tool at a time; for example, woodcutters/hunters will drop their axes then go and pick up crossbows every time they begin hunting.

=== Ammunition ===
:''Main article: [[Ammunition]]''

[[Crossbow]]s and other ranged weapons require [[ammunition]] (in the case of the crossbow, [[bolt]]s). This ammunition is carried in a [[quiver]] in packs of about 25, and when they run out they will switch to using their ranged weapons as crude hammers. It's often a good idea to try to get them to retreat once they run out of ammo — crossbows are meant for shooting, not bashing.

=== Secondary weapons ===
Although it sounds like a cool idea, equipping a marksdwarf with a backup short sword just in case doesn't often work, as dwarves are just as quick to run up their foes and start bashing them with a crossbow as they are to draw their swords and do it properly.

== Weapons ==
=== Native weapons ===
{| class="wikitable" border="border"
! Type
! Size
! Attack
! [[Attack type]]
! Contact Area
! Penetration
! Velocity
! Skill Used
! Hands Used
! [[Weaponsmith|Metal]]
! [[Bowyer|Wood]]
! [[Bowyer|Bone]]
! [[Stone crafter|Obsidian]]
|- valign="top"
|rowspan="3"| [[battle axe|Battle Axe]]
|rowspan="3"| 800
| Hack || Edge || 40000 || 6000 || 1.25x
|rowspan="3"| Axe
|rowspan="3"| Singlegrasp
|rowspan="3"| Yes
|rowspan="3"| No
|rowspan="3"| No
|rowspan="3"| No
|-
| Flat slap || Blunt || 40000 || (6000) || 1.25x
|-
| Pommel strike || Blunt || 100 || (1000) || 1.0x
|-
| [[Crossbow]] (Melee)
| 400
| Bash || Blunt || 10000 || (4000) || 1.25x
| Hammer
| Singlegrasp?
| Yes
| Yes
| Yes
| No
|-
| [[Mace]]
| 800
| Bash || Blunt || 20 || (200) || 2.0x
| Mace
| Singlegrasp
| Yes
| No
| No
| No
|-
| [[Pick]] (foreign)
| 500
| Strike || Edge || 100 || 4000 || 2.0x
| Mining
| Singlegrasp
| Yes
| No
| No
| No
|- valign="top"
|rowspan="4"| [[short sword|Short Sword]]
|rowspan="4"| 300
| Slash || Edge || 20000 || 4000 || 1.25x
|rowspan="4"| [[Sword]]
|rowspan="4"| Singlegrasp
|rowspan="4"| Yes
|rowspan="4"| No
|rowspan="4"| No
|rowspan="4"| Yes
|-
| Stab || Edge || 50 || 2000 || 1.0x
|-
| Flat slap || Blunt || 20000 || (4000) || 1.25x
|-
| Pommel strike || Blunt || 100 || (1000) || 1.0x
|- valign="top"
|rowspan="2"| [[Spear]]
|rowspan="2"| 400
| Stab || Edge || 20 || 10000 || 1.0x
|rowspan="2"| Spear
|rowspan="2"| Singlegrasp
|rowspan="2"| Yes
|rowspan="2"| No
|rowspan="2"| No
|rowspan="2"| No
|-
| Shaft bash || Blunt || 10000 || (6000) || 1.25x
|-
| [[war hammer|War Hammer]]
| 400
| Bash || Blunt || 10 || (200) || 2.0x
| Hammer
| Singlegrasp
| Yes
| No
| No
| No
|}

Note that although the [[pick]] is a foreign weapon, it can be produced by dwarves and is therefore considered native.

=== Details ===
*If you find your dwarves wearing more than one weapon -- or any unwanted [[armor]], for that matter -- one way to get rid of them is to dump the weapon from their {{k|v}}-{{k|i}} inventory screen. This does not always work, as they might re-equip the item. Another option is to remove any weapons and/or shields listed on their military equip screen. This too does not always work. At least "left-handedness" seems to not pose a problem. If you cancel the work by {{k|v}}-{{k|p}} and selecting a job that needs a tool they will sometimes put it back in the pile. Example: Miners use picks, cancel their mining job and they will put the pick away AFTER you ordered it to be dumped.
* Using weapons is much more effective than unarmed combat -- an untrained swordsdwarf with an [[iron]] weapon can defeat a grand master [[wrestler]], provided neither is wearing armor.
** Larger weapons with more heft tend to do more damage. How damage is calculated is currently not fully understood, and this is an area requiring more research.
* The size for a weapon is its volume in cm3.
* Attacks of type EDGE will either slice or pierce their target, depending on the contact area and penetration depth, while BLUNT attacks tend to damage internal organs without necessarily causing significant damage to outer layers.
* The contact area represents the area of contact of the weapon, and the penetration determines how deep the attack goes (and is apparently ignored entirely for BLUNT attacks -- indicated by numbers in parentheses). Large contact areas combined with low penetration represent slashing attacks, while small contact areas with high penetration behave as piercing attacks.
* The velocity seems to adjust the amount of actual force used during the attack (otherwise based on the size of the weapon, the material from which the weapon is made, and the strength of the wielder) - for example, war hammers have a 2x velocity multiplier, presumably to model the fact that the hammer's mass is concentrated at the tip which, when combined with a long handle, permits swinging it harder than a weapon whose mass is evenly distributed (such as a sword).
* Crossbows can be made of metal, wood, and bone. Metal crossbows are made by a [[weaponsmith]] at a [[forge]], while wood and bone crossbows are made by a [[bowyer]] at a bowyer's workshop. The material of a crossbow does not affect its firing ability, only its melee damage. A dwarf's marksmanship skill is only affected by the core [[item quality|quality]] of the bow. This may be a consideration when deciding which dwarf you want outfitting your marksdwarves: a [[experience|legendary]] bowyer is a better choice than a proficient weaponsmith.
* Dwarves will never select a pick for a weapon if allowed "individual choice." You must specify picks as part of their uniform or on the individual equip screen if you wish to utilize them as weapons.

=== Training weapons ===
All [[training weapon]]s must be made of [[wood]] at the [[carpenter's workshop]].

{| class="wikitable" border="border"
|-
! Type
! Size
! Attack
! [[Attack type]]
! Contact Area
! Penetration
! Velocity
! Skill Used
|- valign="top"
|rowspan="3"| Training Axe
|rowspan="3"| 800
| Hack || Blunt || 30000 || (6000) || 1.25x
|rowspan="3"| Axe
|-
| Flat slap || Blunt || 30000 || (6000) || 1.25x
|-
| Pommel strike || Blunt || 100 || (1000) || 1.0x
|- valign="top"
|rowspan="4"| Training Sword
|rowspan="4"| 300
| Slash || Blunt || 20000 || (4000) || 1.25x
|rowspan="4"| Sword
|-
| Stab || Blunt || 50 || (2000) || 1.0x
|-
| Flat slap || Blunt || 20000 || (4000) || 1.25x
|-
| Pommel strike || Blunt || 100 || (1000) || 1.0x
|- valign="top"
|rowspan="2"| Training Spear
|rowspan="2"| 400
| Stab || Blunt || 200 || (10000) || 1.0x
|rowspan="2"| Spear
|-
| Shaft bash || Blunt || 10000 || (6000) || 1.25x
|}

=== Foreign weapons ===
Using any multi-grasp weapon in a single hand (i.e. with a shield in the other hand) gives you a disability to hit. Do not equip two-handed swords with a shield, for instance.

In Adventurer Mode, however, it is possible to wield a two-handed sword, or any multi-grasp weapon in one hand, without penalty (allowing for the simultaneous use of a shield) if your character passes the one-handed check for single-handing a multi-grasp weapon. For example, if you create a Human character, and manage to spawn into a world with a "broad body" or a "tall body" in the character description, you will be able to single-hand any multi-grasp weapon (and will be forced to, much like you are forced to single-hand any single-grasp weapon), which allows for the simultaneous, disability-free use of a shield, thus making your damage and defensive capabilities much higher than they would be with a single-grasp weapon and shield. Note that upping Strength to Superior (and eventually Superhuman) will make all attacks more likely to deal extra damage, making cutting off the limbs of your enemies much easier.

{| class="wikitable" border="border"
|-
! Type
! Size
! Attack
! [[Attack type]]
! Contact Area
! Penetration
! Velocity
! Skill Used
! Used by
! Hands Used
|- valign="top"
|rowspan="4"| [[two-handed sword|2H Sword]]
|rowspan="4"| 900
| Slash || Edge || 100000 || 8000 || 1.25x
|rowspan="4"| Sword
|rowspan="4"| [[Goblin]], [[Human]]
|rowspan="4"| Multi-grasp
|-
| Stab || Edge || 50 || 4000 || 1.0x
|-
| Flat slap || Blunt || 100000 || (8000) || 1.25x
|-
| Pommel strike || Blunt || 100 || (1000) || 1.0x
|- valign="top"
| [[Blowgun]] (Melee)
| 150
| Bash || Blunt || 10000 || (4000) || 1.25x
| Sword
| Subterranean animal peoples
| Single-grasp?
|- valign="top"
| [[Bow]] (Melee)
| 300
| Bash || Blunt || 10000 || (4000) || 1.25x
| Sword
| [[Elf]], Goblin, Human, [[Kobold]]
| Single-grasp?
|- valign="top"
| [[Flail]]
| 500
| Bash || Blunt || 200 || (4000) || 2.5x
| Mace
| Goblin, Human
| Single-grasp
|- valign="top"
|rowspan="3"| [[great axe|Great Axe]]
|rowspan="3"| 1300
| Hack || Edge || 60000 || 8000 || 1.25x
|rowspan="3"| Axe
|rowspan="3"| Goblin, Human
|rowspan="3"| Multi-grasp
|-
| Flat slap || Blunt || 60000 || (8000) || 1.25x
|-
| Pommel strike || Blunt || 100 || (1000) || 1.0x
|- valign="top"
|rowspan="3"| [[Halberd]]
|rowspan="3"| 1200
| Slash || Edge || 20000 || 8000 || 1.25x
|rowspan="3"| Axe
|rowspan="3"| Goblin, Human
|rowspan="3"| Multi-grasp
|-
| Stab || Edge || 50 || 2000 || 1.0x
|-
| Shaft bash || Blunt || 20000 || (6000) || 1.25x
|- valign="top"
|rowspan="3"| [[Dagger]] (Large)
|rowspan="3"| 200
| Slash || Edge || 1000 || 800 || 1.25x
|rowspan="3"| Dagger
|rowspan="3"| Goblin, Kobold
|rowspan="3"| Single-grasp
|-
| Stab || Edge || 5 || 1000 || 1.0x
|-
| Pommel strike || Blunt || 20 || (600) || 1.0x
|- valign="top"
|rowspan="4"| [[long sword|Long Sword]]
|rowspan="4"| 700
| Slash || Edge || 60000 || 6000 || 1.25x
|rowspan="4"| Sword
|rowspan="4"| Elf, Goblin, Human
|rowspan="4"| Single-grasp
|-
| Stab || Edge || 50 || 3000 || 1.0x
|-
| Flat slap || Blunt || 60000 || (6000) || 1.25x
|-
| Pommel strike || Blunt || 100 || (1000) || 1.0x
|- valign="top"
| [[Maul]]
| 1300
| Bash || Blunt || 100 || (6000) || 2.0x
| Hammer
| Goblin, Human
| Multi-grasp
|- valign="top"
|rowspan="2"| [[Morningstar]]
|rowspan="2"| 500
| Bash || Edge || 10 || 500 || 2.0x
|rowspan="2"| Mace
|rowspan="2"| Goblin, Human
|rowspan="2"| Single-grasp
|-
| Pommel strike || Blunt || 50 || (1000) || 1.0x
|- valign="top"
|rowspan="2"| [[pike (weapon)|Pike]]
|rowspan="2"| 800
| Stab || Edge || 20 || 12000 || 1.0x
|rowspan="2"| Pike
|rowspan="2"| Goblin, Human
|rowspan="2"| Multigrasp
|-
| Shaft bash || Blunt || 10000 || (6000) || 1.25x
|- valign="top"
|rowspan="4"| [[Scimitar]]
|rowspan="4"| 300
| Slash || Edge || 20000 || 4000 || 1.25x
|rowspan="4"| Sword
|rowspan="4"| Goblin, Human
|rowspan="4"| Single-grasp
|-
| Stab || Edge || 50 || 2000 || 1.0x
|-
| Flat slap || Blunt || 20000 || (4000) || 1.25x
|-
| Pommel strike || Blunt || 50 || (1000) || 1.0x
|- valign="top"
| [[Scourge]]
| 300
| Lash || Edge || 10 || 50 || 2.0x
| Whip
| Goblin
| Single-grasp
|- valign="top"
| [[Whip]]
| 100
| Lash || Blunt || 1 || (10) || 5.0x
| Whip
| Goblin, Human
| Single-grasp
|}

===Special variations===
Some rare entities have their own [[divine equipment|procedurally generated variations]] of weapons. Currently, these weapons are produced by copying the default properties of the "base" weapon, and adding an adjective ("bulky", "large-headed", "branching", etc.) or renaming the weapon altogether ("blade", "curved sword"). Dwarves in [[strange mood]]s which select from all weapons with a certain tag may produce one of these procedurally generated weapons. Since they retain the properties of their base items, these weapons should be as usable as standard weapon of the base type.

== Size==

Weapons have a minimum size to use at all, and a minimum size to use one-handed. Adult dwarves vary in size between 33750 and 93750 (average 60000) based on their height and broadness.

Unfortunately this is currently bugged in Fortress mode.{{Bug|0005812}} 'One-handed' vs. 'two-handed' checks are performed correctly, but 'can wield' vs. 'can't wield' ignores height and broadness modifiers. So Dwarves in Fortress mode will never equip two-handed swords, great axes, halberds, mauls, or pikes. Other weapons have a minimum wielding size of less than 60000, and are wielded one-handed if the individual dwarf is large enough. See [http://www.bay12forums.com/smf/index.php?topic=119068.msg3790913#msg3790913 this] forum post.

The following table shows approximately how many dwarves ''should be'' able to use each weapon one or two handed (see [http://www.bay12forums.com/smf/index.php?topic=101379.msg3029579#msg3029579 this forum post] for details), with all fractional numbers being approximate. While there are seven categories each for height and broadness, the number used is chosen randomly from within each category.

Where the size checking bug affects weapon wielding for dwarves, correct approximate figures are given in brackets.
{| class="wikitable" border="border"
|-
! Type
! Min Size
(Two-Handed)
! Min Size
(One-Handed)
! Dwarves
Can't Wield
! Dwarves Wield
Two-Handed
! Dwarves Wield
One-Handed
|- valign="top"
| [[battle axe|Battle Axe]]
| 42500
| 47500
| 1/49 (0)
| 10/49 (11/49)
| 38/49
|- valign="top"
| [[Crossbow]] (Melee)
| 15000
| 0
| -
| -
| 49/49
|- valign="top"
| [[Mace]]
| 32500
| 37500
| -
| 1/49
| 48/49
|- valign="top"
| [[Pick]]
| 42500
| 47500
| 1/49 (0)
| 10/49 (11/49)
| 38/49
|- valign="top"
| [[short sword|Short Sword]]
| 32500
| 37500
| -
| 1/49
| 48/49
|- valign="top"
| [[Spear]]
| 5000
| 47500
| -
| 11/49
| 38/49
|- valign="top"
| [[war hammer|War Hammer]]
| 32500
| 37500
| -
| 1/49
| 48/49
|- valign="top"
| Training Axe
| 42500
| 47500
| 1/49 (0)
| 10/49 (11/49)
| 38/49
|- valign="top"
| Training Sword
| 32500
| 37500
| -
| 1/49
| 48/49
|- valign="top"
| Training Spear
| 42500
| 47500
| 1/49 (0)
| 10/49 (11/49)
| 38/49
|- valign="top"
| [[two-handed sword|2H Sword]]
| 62500
| 77500
| 32/49 (ALL)
| 14/49 (0)
| 3/49 (0)
|- valign="top"
| [[Blowgun]] (Melee)
| 15000
| 0
| -
| -
| 49/49
|- valign="top"
| [[Bow]] (Melee)
| 15000
| 0
| -
| -
| 49/49
|- valign="top"
| [[Flail]]
| 42500
| 47500
| 1/49 (0)
| 10/49 (11/49)
| 38/49
|- valign="top"
| [[great axe|Great Axe]]
| 62500
| 77500
| 32/49 (ALL)
| 14/49 (0)
| 3/49 (0)
|- valign="top"
| [[Halberd]]
| 62500
| 77500
| 32/49 (ALL)
| 14/49 (0)
| 3/49 (0)
|- valign="top"
| [[Dagger]] (Large)
| 5000
| 27500
| -
| -
| 49/49
|- valign="top"
| [[long sword|Long Sword]]
| 52500
| 57500
| 11/49 (0)
| 7/49 (18/49)
| 31/49
|- valign="top"
| [[Maul]]
| 62500
| 77500
| 32/49 (ALL)
| 14/49 (0)
| 3/49 (0)
|- valign="top"
| [[Morningstar]]
| 32500
| 37500
| -
| 1/49
| 48/49
|- valign="top"
| [[pike (weapon)|Pike]]
| 62500
| 77500
| 32/49 (ALL)
| 14/49 (0)
| 3/49 (0)
|- valign="top"
| [[Scimitar]]
| 32500
| 37500
| -
| 1/49
| 48/49
|- valign="top"
| [[Scourge]]
| 22500
| 27500
| -
| -
| 49/49
|- valign="top"
| [[Whip]]
| 22500
| 27500
| -
| -
| 49/49
|}

==Material==

Weapons and armor (with a few exceptions) can only be forged from weapon grade metal (Adamantine, Steel, Iron, Silver, Bronze, Bismuth bronze, Copper, and divine metal), wood, or bone. The exceptions include Obsidian short-swords and items created during a strange mood.

{{v0.31 material metal table head}}

{{v0.31 material metal table row|name=Adamantine|color={{Tile|/|3:1}}3:3:1|source=[[Raw adamantine]]|notes= |soliddensity=0.200|mp=25000|val=300|valinc=+50|impactyield=5000|impactfracture=5000|impactelasticity=0|shearyield=5000|shearfracture=5000|shearelasticity=0
}}

{{v0.31 material metal table row|name=Divine metal|notes= |soliddensity=1.0|val=300|impactyield=1000|impactfracture=2000|impactelasticity=0|shearyield=1000|shearfracture=2000|shearelasticity=0
}}

{{v0.31 material metal table row|name=Steel|color={{Tile|/|0:1}}0:7:1|source=[[Iron]] + [[Pig iron]] + [[flux]] stone + [[fuel]] '''!'''|notes= |soliddensity=7.85|val=30|valinc=+20|mp=12718|impactyield=1505|impactfracture=2520|impactelasticity=940|shearyield=430|shearfracture=720|shearelasticity=215
}}

{{v0.31 material metal table row|name=Bismuth bronze|color={{Tile|/|6:1}}6:6:1|source=2 [[Copper]] + 1 [[Tin]] + 1 [[Bismuth]] '''!'''|notes= |soliddensity=8.25|val=6|valinc=+4|mp=11868|impactyield=602|impactfracture=843|impactelasticity=547|shearyield=172|shearfracture=241|shearelasticity=156
}}

{{v0.31 material metal table row|name=Bronze|color={{Tile|/|6:0}}6:4:0|source=[[Tin]] + [[Copper]]|notes= |soliddensity=8.25|val=5|valinc=+3|mp=11868|impactyield=602|impactfracture=843|impactelasticity=547|shearyield=172|shearfracture=241|shearelasticity=156
}}

{{v0.31 material metal table row|name=Iron|color={{Tile|/|0:1}}0:7:1|source=[[Hematite]], [[Limonite]], [[Magnetite]]|notes= |soliddensity=7.85|mp=12768|val=10|valinc=+2|impactyield=542|impactfracture=1080|impactelasticity=319|shearyield=155|shearfracture=310|shearelasticity=189
}}

{{v0.31 material metal table row|name=Copper|color={{Tile|/|6:0}}6:4:0|source=[[Native copper]], [[Malachite]], [[Tetrahedrite]]|notes= |soliddensity=8.93|mp=11952|val=2|valinc=+0, +0, -1*|impactyield=245|impactfracture=770|impactelasticity=175|shearyield=70|shearfracture=220|shearelasticity=145
}}

{{v0.31 material metal table row|name=Silver|color={{Tile|/|7:1}}7:7:1|source=[[Native silver]], [[Horn silver]], [[Galena]] (50%), [[Tetrahedrite]] (20%) |notes= |soliddensity=10.49|mp=11731|val=10|valinc=+0, +0, +5*, +7*|impactyield=350|impactfracture=595|impactelasticity=350|shearyield=100|shearfracture=170|shearelasticity=333
}}

{{v0.31 material metal table row|name=Platinum|color={{Tile|/|7:1}}7:7:1|source=[[Native platinum]]|notes= Only available as Artifact Weapons.|soliddensity=21.4|mp=13182|val=40|valinc=+?, +?, +?, +?|impactyield=350|impactfracture=700|impactelasticity=152|shearyield=100|shearfracture=200|shearelasticity=164
}}

{{v0.31 material metal table row|name=Bone|color={{Tile|/|7:1}}7:7:1|source=Creatures|notes= |soliddensity=0.50|mp=NONE(burn at 10250)|val=1|valinc=+?, +?, +?, +?|impactyield=200|impactfracture=200|impactelasticity=100|shearyield=115|shearfracture=130|shearelasticity=100
}}

{{v0.31 material metal table row|name=Wood|color={{Tile|/|6:0}}7:7:1|source=Trees|notes= |soliddensity=0.50|mp=NONE(burn at 10250)|val=1|valinc=+?, +?, +?, +?|impactyield=10|impactfracture=10|impactelasticity=1000|shearyield=40|shearfracture=40|shearelasticity=1000
}}

{{v0.31 material metal table row|name=Shell|color={{Tile|/|2:0}}7:7:1|source=Creatures|notes= Only available as Artifact Weapons.|soliddensity=0.50|mp=NONE(burn at 10250)|val=1|valinc=+?, +?, +?, +?|impactyield=200|impactfracture=200|impactelasticity=100|shearyield=115|shearfracture=130|shearelasticity=100
}}

{{v0.31 material metal table row|name=Leather|color={{Tile|/|2:0}}7:7:1|source=Creatures|notes= Material data added for comparison.|soliddensity=0.50|mp=NONE(burn at 10250)|val=1|valinc=+?, +?, +?, +?|impactyield=10|impactfracture=10|impactelasticity=50000|shearyield=25|shearfracture=25|shearelasticity=50000
}}

{{v0.31 material metal table row|name=Obsidian|color={{Tile|/|0:1}}7:7:1|source=Lava|notes= Only available for Short Swords.|soliddensity=2.67|mp=13600|val=3|valinc=+0|impactyield=1000|impactfracture=1000|impactelasticity=2222|shearyield=35|shearfracture=35|shearelasticity=114
}}

{{v0.31 material metal table row|name=Crystal glass|color={{Tile|/|7:1}}7:7:1|source=Sand|notes= Only available as Trap Components.|soliddensity=2.6|mp=13600|val=10|valinc=+0|impactyield=1000|impactfracture=1000|impactelasticity=2222|shearyield=33|shearfracture=33|shearelasticity=113
}}

{{v0.31 material metal table row|name=Clear glass|color={{Tile|/|3:0}}7:7:1|source=Sand|notes= Only available as Trap Components.|soliddensity=2.6|mp=13600|val=5|valinc=+0|impactyield=1000|impactfracture=1000|impactelasticity=2222|shearyield=33|shearfracture=33|shearelasticity=113
}}

{{v0.31 material metal table row|name=Green glass|color={{Tile|/|2:0}}7:7:1|source=Sand|notes= Only available as Trap Components.|soliddensity=2.6|mp=13600|val=2|valinc=+0|impactyield=1000|impactfracture=1000|impactelasticity=2222|shearyield=33|shearfracture=33|shearelasticity=113
}}

|}

*''Combat information'' is used internally by the game to determine the combat properties of weapons and armor made from this metal:
**'''Density''': Used in conjunction with other factors - heavier weapons (higher numbers) hit with more force, light weapons tend to have less penetration. Value shown here is g/cm3, which is the raw value divided by 103
**'''Impact yield''': Used for blunt-force combat; ''higher'' is better. This is the raw value divided by 103 (i.e., kPa).
**'''Impact fracture''': Used for blunt-force combat; ''higher'' is better. This is the raw value divided by 103 (i.e., kPa).
**'''Impact elasticity''' (or '''strain at yield'''): Used for blunt-force combat; ''lower'' is better. This is the raw value.
**'''Shear yield''': Used for cutting calculations in combat; ''higher'' is better. This is the raw value divided by 103 (i.e., kPa).
**'''Shear fracture''': Used for cutting calculations in combat; ''higher'' is better. This is the raw value divided by 103 (i.e., kPa).
**'''Shear elasticity''' (or '''strain at yield'''): Used for cutting calculations in combat; ''lower'' is better. This is the raw value.

*General Term Explanations (From Wikipedia)
**'''Yield Strength''' - The stress at which material strain changes from elastic deformation to plastic deformation, causing it to deform permanently.
**'''Fracture Strength''' - The stress coordinate on the stress-strain curve at the point of rupture.
**'''Stress''' - Force per area = F/A
**'''Strain''' - Deformation of a solid due to stress = Stress/Young's Modulus

=== Explanation ===
* '''Yield Strength''' is the amount of stress required to permanently deform (bend) a material (plastic deformation).
* '''Fracture Strength''' is the amount of stress required to permanently break (rupture) a material.
* '''Elasticity''' or '''Strain at yield''' is the amount of deformation (bending) that occurs at the yield point.

=== Implications ===
Yield strength combined with strain at yield can tell what a material will do under stress (be it from a hammer, axe, or arrow); higher yield means that it takes more stress to deform, while lower strain at yield means that it will deform less when stress is applied.

== Combat formulae ==

Penetration is poorly understood, but most of the rest of combat is fairly well understood.

First, you need to calculate your weapon's momentum.

Melee Weapon Momentum: M = Skill * Size * Str * Vel / (106 * (1 + i_Size/(w_density*w_size) )
* Dwarf Melee Momentum: M = 0.6 * Str * Vel / (1 + i_Size/(w_density*w_size) )
* Quick attacks halve melee momentum, wild and heavy attacks multiply it by 1.5
* Attacking a prone opponent in melee doubles momentum.

Ranged Weapon Momentum: M = (w_density*w_size)/105 * min(105*(SHOOT_FORCE/20)/(w_density*w_size), SHOOT_MAXVEL/10)
* Bow and Crossbow Momentum: M = (w_density*150)/105 * min(105/(w_density*3), 20)
** If 20 is smaller because the ammunition is density 1666 or less, M = w_density*3/100 = w_density*0.03
** If 20 is larger because the ammunition is density 1667 or larger, M = 50
* Blowgun Momentum: M = (w_density*20)/105 * min(105/(w_density*4), 100)
** If 100 is smaller because the ammunition is density 250 or less, M = w_density/50 = w_density*0.02
** If 100 is larger because the ammunition is density 251 or more, M = 5

where:
* '''M''' is the momentum.
* '''Skill''' is a gradual multiplier based on skill level, from 1x base up to 2x at Grand Master.
* '''Str''' is the creature's strength (e.g. 1250 for the average dwarf)
* '''Vel''' is the weapon's velocity modifier if present (e.g. 1.25x, 2x)
* '''Size''' is the average creature size (e.g. 60000 for dwarves)
* '''i_Size''' is the specific creature's size
** Dwarves range from a minimum size of 33750 to a maximum size of 93750, with an average size of 60000.
* '''F''' is "fatness modifier" (also includes muscle) = i_Size/Size; dwarf with size of 66150 will have F=66150/60000=1.1025
* '''w_density''' is the weapon's material's density for melee weapons, or the ammunition's density for ranged weapons
* '''w_size''' is the weapon's size for melee weapons, or the ammunition's size for ranged weapons
* '''SHOOT_FORCE''' is the ranged weapon's SHOOT_FORCE constant, which is used to determine its maximum momentum.
* '''SHOOT_MAXVEL''' is the ranged weapon's SHOOT_MAXVEL constant, which is used to determine its maximum velocity, where ammo momentum = ammo mass * ammo velocity.

An edged weapon undergoes the following comparison:

M >= (aSY/wSY + (A+1)*aSF/wSF) * (10 + 2*a_quality) / (Sha * w_quality),

where:
* '''aSY''' is the armor's SHEAR_YIELD, which is based on its material
* '''wSY''' is the weapon's SHEAR_YIELD, which is based on its material
* '''aSF''' is the armor's SHEAR_FRACTURE, which is based on its material
* '''wSF''' is the weapon's SHEAR_FRACTURE, which is based on its material
* '''A''' is attack [[DF2014:Material_science#Contact_Area|contact area]], typically between
* '''Sha''' is weapon material [[edge|sharpness]] multiplier (1x for most metals, 1.2x for [[divine metal]], 1.5x for [[glass]], 2x for [[obsidian]], 10x for [[adamantine]] and 0.1x for all other materials)
* '''w_quality''' is weapon [[quality]] multiplier (1x for normal quality, 1.4x for fine, 2x for masterwork, etc.)
* '''a_quality''' is armor [[quality]] multiplier

Expressed in the above terms,

* 0.6 * Str * Vel / (1 + i_Size/(w_density*w_size)) >= (aSY/wSY + (A+1)*aSF/wSF) * (10 + 2*Qa) / (Sha * w_quality)
* 0.6 * Sha * w_quality * Str * Vel / (1 + i_Size/(w_density*w_size)) >= (aSY/wSY + (A+1)*aSF/wSF) * (10 + 2*a_quality)
* 0.6 * Sha * w_quality * Str * Vel / ((1 + i_Size/(w_density*w_size)) * (10 + 2*a_quality)) >= aSY/wSY + (A+1)*aSF/wSF

Because Shear Yield and Shear Fracture are always within a power of 10 of each other for actually available materials, but the smallest possible A value is 20 (a blowgun dart, which is smaller than the smallest item of clothing/armor a dwarf can wear), this means that in practice, Shear Fracture is significantly more important than Shear Yield, and you can reliably compare weapons and armor without paying attention to Shear Yield. In both cases, higher is better on both weapons and armor, as is quality. Sharpness only matters to the weapon, and smaller contact area is better for the attacker.

If the test is passed, attack momentum is decreased by some 5% and the layer is considered punctured/severed, and the process continues to the next layer, including working through layers of the defender's body. If the test is failed, the attack becomes blunt for this layer.

If the attack is blunt, either due to starting off blunt or due to failing the above test, it is then subjected to this test:

2 * w_size * wIY > A * a_density

where:
* '''a_density''' is the armor material's density
* '''wIY''' is the weapon's impact yield in MPa (i.e. raw value divided by 106).

Failure means the attack bounces off, meaning denser, larger armor resists blunt attacks better, but larger blunt weapons with larger contact areas and higher impact yields get through armor better. This also means adamantine armor is some of the worst in the game at outright deflecting attacks, due to its poor density, but this is not typically relevant, as impact yields are typically at least 10 times larger than density values for the actual metals available, so this step is routinely passed by most weapons regardless of relative materials.

On success, the following test is applied:

M >= (2*aIF - aIY) * (2 + 0.4*a_quality) * A,

where:
* '''aIF''' is the armor's impact fracture in MPa (i.e. raw value divided by 106)
* '''aIY''' is the armor's impact yield in MPa (i.e. raw value divided by 106).

Note that the armor wants as high impact yield as possible to make this test fail. The armor also wants low impact fracture, although the weapon's impact fracture does not matter, and high quality and high contact area.

On a success, attack momentum is decreased by some 5% and the layer is considered punctured/severed, and the process continues to the next layer, including working through layers of the defender's body. If the attack was edged, it becomes edged again. On a failure, the momentum is multiplied by SHEAR_STRAIN_AT_YIELD/50000 for edged attacks or IMPACT_STRAIN_AT_YIELD/50000 for blunt attacks, then it becomes *permanently* blunt, and is passed on to the next layer. This means most rigid metal armor will reduce blocked attacks by 98%-99%, but elastic armor, such as a mail shirt, has both strain at yield values raised to 50000, so it multiplies by 1 at this step (i.e. does nothing to the momentum, but does still convert it to blunt) regardless of material.

== Combat testing ==
In regards to edged weaponry: [[Adamantine]] and [[steel]] take first and second place respectively, with [[iron]] the third best material in the game, matched by the [[bronze]]s. Beyond that is [[copper]], the second worst material, and [[silver]] is the worst weapon material available (and due to the existence of training weapons, not even useful in that regard).

Additionally, with regards to blunt weapons almost all of the non-adamantine materials perform equally well, with a very slight edge towards steel and silver. Here is the thread with the details: [http://www.bay12forums.com/smf/index.php?topic=53571.0].

Keep in mind with how unbelievably complicated this system is nothing should be taken as word of law yet.

{| {{prettytable}}
|- bgcolor="#999999"
!
! Best
! Better
! Good
! Fair
! Poor
! Terrible
! Notes
|-
| Armor
| Adamantine
| Steel
| Iron
| Bronze, Bismuth Bronze
| Copper
|
|
|-
| Edged Weapons
| Adamantine
| Steel
| Iron
| Bronze, Bismuth Bronze
| Copper
| Silver
| For piercing iron armor, copper is better than bronze. For piercing copper or bronze armor, bronze is better than copper.
|-
| Ammunition
| Steel, Iron, Bronze, Bismuth Bronze, Copper, Silver
|
| Adamantine
|
|
|
| Adamantine bolts deflect off of adamantine armor, but otherwise their performance is on par with bolts made out of other metals.
|-
| Blunt Weapons
| Platinum
| Steel, Silver
| Copper, Bismuth Bronze, Bronze, Iron
|
|
| Adamantine
| All six standard weapon metals perform nearly identically. Steel has a slightly higher rate of critical wounds, while silver is slightly more likely to penetrate armor. Platinum (only available as [[artifact]] weapons) has twice the density of silver and several other improved properties, making it the best metal for impact weapons, though very limited in production. Adamantine's light weight makes it a terrible choice for blunt weapons, roughly the same as making a weapon out of [[featherwood]] or cork.
|}

Cross referencing this table with the table at the top of this section seems to indicate that low densities, high impact fractures, and high shear fractures contribute to the killing power of edged weapons.

===Analysis===

Testing of weapons (15 dwarves vs. 15 dwarves combats) in the [[object testing arena]] shows that the best dwarven-made weapon against unarmored humanoids is the battle axe, while the war hammer performs the best against armored targets. {{version|0.31.12}}.

Even in 15×(steel armor+silver war hammer) versus 15×(adamantine armor+adamantine battle axe) matches, hammerdwarves won with less than 50% casualties (mostly one-strike kills). However, when the dwarves in question were without armor or only wearing leather/cloth, the result was inverted — axedwarves won with less than 50% casualties. In battles against megabeasts, 6 silver hammerdwarves were barely able to scratch a [[bronze colossus]] (attacks were glancing away) due to bronze being a better "weapon" material.

This is because silver has the highest solid density of all materials that can regularly be made into weapons by dwarves. Tests show that indeed [[gold]] and [[platinum]] (increasingly dense) do increasing amounts of damage, and that war hammers remain the tool of choice, however they can only be produced by a moody dwarf (and a very lucky one at that).

For more on ranged ammunition see the forum thread [http://www.bay12forums.com/smf/index.php?topic=116151.0 Dwarven Research: A Comparison Study on the Effectiveness of Bolts vs Armors].

More arena tests are available in the [[Main:Military testing|Military testing]] article.

There is a bug with melee weapon momentum that causes certain weapons to swing faster than they should do, giving them greater performance. This bug is based on the weight of the weapon, with weapons weighing just under a whole number getting the greatest benefit. Two major beneficiaries of this weight bug are copper whips and iron or steel picks.

==Bugs==
*Equipping weapons/armor on military is erratic{{Bug|535}}
*'One-handed' vs. 'two-handed' checks are performed correctly, but 'can wield' vs. 'can't wield' ignores height and broadness modifiers, so dwarves in Fortress mode cannot equip two-handed swords, great axes, halberds, mauls, or pikes.{{bug|5812}}

==See also==
* [[User:Shinziril#Weapons_and_Armor|Outstanding research]] on weapons and armor by Shinziril

{{Weapons}}
{{Industry}}
{{Category|Weapons}}

Mandate

2017-08-17T16:42:07Z

Larix: Update for 0.40+

{{Quality|Exceptional|11:16, 18 May 2015 (UTC)}}
{{av}}
{{buggy}}
A '''mandate''' is a [[noble]]'s request that your [[dwarves]] produce a certain item or type of item, or an [[Trading|export]] ban on certain items. Starting nobles such as the [[expedition leader]] will not make mandates; upgraded nobles like the [[mayor]] will. Fulfilling the mandate gives the noble a happy [[thought]].

Mandates should not be confused with [[demand]]s.

Only some nobles make mandates, and the number of mandates that can be active simultaneously varies:
* '''1 mandate:''' [[Baron]], [[Mayor]]
* '''2 mandates:''' [[Count]]
* '''3 mandates:''' [[Duke]]
* '''5 mandates:''' [[Monarch]]

Mandates are announced at the bottom of the screen, but if you miss the message, you can see if a noble is mandating anything on the [[nobles screen|noble's screen]]. If the uppercase bracketed word '[MANDATE]' next to a noble's name is grey, he is making no mandates. If brown, he is making a production mandate, and you have a lot of time to complete it. If yellow, you have a month or two before the mandate expires. If red, the mandate will expire very soon. If white, then it is an export ban.

Mandates of a noble will end automatically when the noble dies. Mandates of a mayor end instantly when they are voted out of office, but will remain in force if a mayor is replaced by nominating another one from the nobles screen. If the replaced mayor has no other administrative position, such a lingering mandate will only be displayed on the dwarf's personal thoughts page, not on the nobles screen, and is thus easy to overlook and accidentally violate.

== Production Mandate ==

When a noble makes a production mandate, you will have roughly half a year to fulfill it. These mandate the production of certain goods, specifying the desired type, just like export bans. In previous versions, items (of any type) of a desired material could be mandated. This is no longer possible in 34.11.

Getting the required items from a [[caravan]] will not fulfill a mandate.

If a production mandate expires without being fulfilled, the noble will get an unhappy [[thought]], and one or more dwarves will be sentenced to punishment for the 'violation of production order' [[Justice|crime]]. The dwarf chosen tends to have a skill appropriate to the mandate, but random dwarves may be chosen as well. If the noble can't sentence any dwarves for punishment because all your dwarves are nobles, or the sentenced dwarves can't be punished because no officer is assigned, he will get another unhappy thought.

Delaying fulfillment of a production mandate may prevent another, worse, mandate from being enacted (for a few months, at least). The color of the mandate indicator on the Nobles screen changes from brown to bright yellow to red, as the deadline approaches.

You can determine your progress towards fulfilling the mandate by viewing the {{k|n}} (then hit enter on the Noble with a mandate), and you will see the mandate listed like this example "Mandates: Make floodgates (2/3)", where in this example we have produced one floodgate and still need to produce two more.

== Export Bans ==

Export bans forbid the export of a certain item type, like [[armor|greaves]]. These bans are temporary, they last about half a year (more or less the time you have to fulfil a production mandate) and then are ended by your noble.

Violating an export ban by [[trade|trading]] any of the item away is a [[Justice|crime]] for each of the haulers who brought a prohibited item (that was sold) to the [[trade depot]] - each dwarf will be incriminated the instant the item is carried off the map (whether by a pack animal or a wagon). While selecting goods to be brought to the depot, the "culling on mandates" option will prevent banned objects from being selected, though if a finished goods bin contains a single banned object, the entire bin will be excluded. Items that are subject to export bans are displayed in purple text in the trade window. Note that if an item is traded to a caravan and is subsequently placed under an export ban, dwarves '''will''' be punished even though the trade took place before the ban went into effect, so if the caravan hasn't already left, any banned goods should be immediately purchased back from the traders; if a good was ''offered'', then nothing can be done (aside from exploiting various oddities in the trade system, or arranging an [[unfortunate accident]]). Oddly, trading banned items which were carried to the depot in [[bin]]s (but not the bins themselves) does ''not'' result in any perceived crimes, perhaps because only the bin was brought to the depot, not the items inside it; however, the noble that issued the mandate will receive an unhappy thought that nobody could be punished.{{verify}}

[[Melt]]ing a banned item also does not violate the restriction.

== Mandates & preferences ==
Personal [[preference]]s determine what type of items a noble bans for export or wants to have produced via mandates. Nobles with a preference for a specific item will either ban that item or mandate its production. Nobles with no preference for a specific item type will never issue any mandates.

Nobles with preferences for items you don't want excluded from trade or that are just too hard to produce (a judgment call) will be a problem for your fortress. You have, however, (limited) control over choosing one noble who makes mandates, for example when appointing your [[baron]], or overriding dwarven elections by appointing a [[Mayor]] you prefer. Choose your baron or mayor wisely: take a look at their preferences, and decide if they might be a problem. [[Anvil]]s take three bars (or nine wafers) to make and can only be produced from a few metals of high military value (and many good sites lack iron ores), thus regular mandates for their production may be hard to fulfill. But even a ban on the export of [[mug]]s can be a problem if a fort relies on them as a trade good. If unavoidable, such nobles may be destined for an [[unfortunate accident]] - for the good of the fortress as a whole.

==Requirements==

These are the criteria for a noble to issue a mandate{{cite forum|139032/5334341}}:
* Hasn't made a mandate/demand lately
* Isn't dead, hasn't left the map, isn't a projectile, and isn't caged
* Isn't insane (or in the middle of a mood)
* Isn't incapacitated (unconscious, webbed, or paralyzed)
* Isn't nauseated, winded, stunned, dizzy, or feverish
* Isn't bleeding
* Has a soulBug: By this requirement, no nobles should give mandates
* Is a member of your fortress

It isn't currently known if exposure to [[cave spider]] venom, which causes permanent mild dizziness, is sufficient to prevent mandates. Other procedurally-generated [[syndrome]]s can cause temporary illnesses, which may also block mandates if applied periodically.

==Bugs==
* A mandate will remain in effect, even after the noble who issued it (a mayor, for example) has been replaced.{{bug|3047}}

{{Category|Nobles}}
{{Category|Justice}}

Captain of the guard

2017-08-17T16:30:45Z

Larix: No auto-upgrades.

{{Quality|Superior|12:14, 4 May 2014 (UTC)}}
{{av}}

{{Noble
| noble= Captain of the Guard
| office= Office
| quarters= Quarters
| dining= Dining Room
| stands=1
| racks=1
| chests=1
| cabinets=1
| function=
* Law enforcement
* Leading the [[fortress guard]]
}}

Once you have reached 50 population and elected a [[mayor]], the position of '''captain of the guard''' will appear. The captain is basically a fancy appointed [[noble]] [[sheriff]] with a military [[squad]] and basic rooming requirements attached. The position of sheriff will disappear from the nobles screen when the position of captain of the guard becomes available.

The captain of the guard leads the [[fortress guard]], which, alongside its regular military duties, aids in the enforcement of [[justice]] by capturing criminals and delivering beatings. As such the captain of the guard functions as both a sheriff and a [[militia captain]]. Once your fortress has reached a middling population, be prepared to dig out and furnish rooms for your middling captain. See [[fortress guard]] for why you might want your guardsman to be the ''opposite'' of a man of justice.

The captain of the guard is a squad leader: as soon as the position is available, a "captain of the guard" squad (with no members yet assigned) will appear at the head of the squadron list. A captain of the guard can be assigned both through the nobles screen and through the military screen, by creating the squad and appointing a dwarf to the first position.

{{gamedata| [POSITION:CAPTAIN_OF_THE_GUARD]
[NAME:captain of the guard:captains of the guard]
[SITE]
[NUMBER:1]
[RESPONSIBILITY:LAW_ENFORCEMENT]
[SQUAD:10:fortress guard:fortress guards]
[APPOINTED_BY:EXPEDITION_LEADER]
[APPOINTED_BY:MAYOR]
[REQUIRES_POPULATION:50]
[REQUIRES_MARKET]
[PRECEDENCE:105]
[DO_NOT_CULL]
[COLOR:1:0:1]
[ACCOUNT_EXEMPT]
[DUTY_BOUND]
[REQUIRED_BOXES:1]
[REQUIRED_CABINETS:1]
[REQUIRED_RACKS:1]
[REQUIRED_STANDS:1]
[REQUIRED_OFFICE:250]
[REQUIRED_BEDROOM:250]
[REQUIRED_DINING:250]}}
{{Nobles}}
{{Category|Military Ranks}}
{{Category|Justice}}

Sheriff

2017-08-17T16:27:10Z

Larix: Sheriffs don't auto-upgrade.

{{av}}
{{Quality|Fine}}
{{Noble
| noble=Sheriff
| quarters=Modest Quarters
| dining=Modest Dining Room
| office=Modest Office
| stands=1
| racks=1
| chests=1
| cabinets=1
| function=
* Law Enforcement
}}

The '''Sheriff''' is the noble responsible for crude law enforcement until your fortress grows large enough to require a [[Captain of the guard]]. The sheriff will subdue and imprison lawbreaking dwarves. Without a [[jail]], the sheriff will have no choice but to issue summary [[justice]] in the form of a beating. The sheriff will still perform justice jobs if [[draft]]ed to the military. ''Having a weak sheriff is sometimes a good thing. A sheriff with good strength, training or a [[weapon]] could heavily injure or kill a criminal, which is very bad if said criminal is a legendary dwarf who did nothing wrong but fail to make the 50 adamantine war hammers a noble demanded.''

When your fortress reaches 50 dwarves, the sheriff's position will disappear. A [[Captain of the guard]] must then be appointed as law enforcement agent.

The sheriff can be designated through the [[Nobles screen|{{k|n}}obles screen]].

{{gamedata| [POSITION:SHERIFF]
[NAME:sheriff:sheriffs]
[SITE]
[NUMBER:1]
[RESPONSIBILITY:LAW_ENFORCEMENT]
[APPOINTED_BY:EXPEDITION_LEADER]
[APPOINTED_BY:MAYOR]
[REPLACED_BY:CAPTAIN_OF_THE_GUARD]
[PRECEDENCE:130]
[DO_NOT_CULL]
[COLOR:1:0:1]
[ACCOUNT_EXEMPT]
[DUTY_BOUND]
[REQUIRED_BOXES:1]
[REQUIRED_CABINETS:1]
[REQUIRED_RACKS:1]
[REQUIRED_STANDS:1]
[REQUIRED_OFFICE:100]
[REQUIRED_BEDROOM:100]
[REQUIRED_DINING:100]}}
{{Nobles}}
{{Category|Military Ranks}}
{{Category|Justice}}

Expedition leader

2017-08-17T16:22:40Z

Larix: Expedition leaders aren't auto-upgraded.

{{Quality|Superior|19:51, 30 October 2013 (UTC)}}
{{av}}
{{Noble
| noble= Expedition Leader
}}
'''Expedition Leader''' is a [[noble]] position automatically filled on [[embark]]. It is the job of this official to speak with, and console or simply hear the complaints of unhappy dwarves, and to entertain foreign diplomats. Once the population reaches 50, a [[mayor]] will be elected and the expedition leader position will be removed.

*An expedition leader or mayor is required to appoint other nobles. Should your leader suffer an [[unfortunate accident]], you will have to wait for a new leader to be elected before appointing nobles.

*An expedition leader or mayor is able to appoint replacements for elected positions, including their own.{{bug|2512}}

There is a certain set of [[skills]] that are relevant for an expedition leader, there are also certain [[Personality|personality traits]] that influence if experience is gained in the skill whatsoever, furthermore there are [[Attributes#Soul_Attributes|soul attributes]] that affect the skills and other skills that affect the same attributes [[cross-training]], the ones relevant for an expedition leader are as follow:
{| {{prettytable}}
|- style="background:#ddd"
! rowspan="2" colspan="2" | Skill (relevant for Expedition Leader)
! rowspan="2" colspan="2" | Personality Trait (needed to gain Social Skill)
! colspan="2" | Attribute (affected by Social Skill)
|-
! style="width:1em" | Body
! style="width:1em" | Soul
|-
| rowspan="6" | Social - Other
| rowspan="3" | [[Consoler]]
| rowspan="3" | Straightforwardness (Honesty)
| rowspan="3" | > 39
| rowspan="3" |
| Linguistic Ability
|-
| Empathy
|-
| Social Awareness
|-
| rowspan="3" | [[Pacifier]]
| rowspan="3" | Cooperation (Compromising)
| rowspan="3" | > 39
| rowspan="3" |
| Linguistic Ability
|-
| Empathy
|-
| Social Awareness
|-
| rowspan="23" | Social - Broker
| rowspan= "3" | [[Comedian]]
| rowspan= "3" style="width:5em" | Self-consciousness (Neurosis)
| rowspan= "3" style="width:1em" | < 76
| rowspan= "3" | Agility
| Creativity
|-
| Kinesthetic Sense
|-
| Linguistic Ability
|-
| rowspan="3" | [[Conversationalist]]
| rowspan="3" | Friendliness (Reserved)
| rowspan="3" | > 39
| rowspan="3" |
| Linguistic Ability
|-
| Empathy
|-
| Social Awareness
|-
| rowspan="3" | [[Flatterer]]
| rowspan="6" | Straightforwardness (Honesty)
| rowspan="3" | < 61
| rowspan="3" |
| Linguistic Ability
|-
| Empathy
|-
| Social Awareness
|-
| rowspan="3" | Liar
| rowspan="3" | < 40
| rowspan="3" |
| Creativity
|-
| Linguistic Ability
|-
| Social Awareness
|-
| rowspan="2" | [[Intimidator]]
| rowspan="2" | Cooperation (Compromising)
| rowspan="2" | < 61
| rowspan="2" | Agility
| Kinesthetic Sense
|-
| Linguistic Ability
|-
| rowspan="3" | Judge of intent
| rowspan="3" colspan="2" |
| rowspan="3" |
| Intuition
|-
| Empathy
|-
| Social Awareness
|-
| rowspan="3" | [[Negotiator]]
| rowspan="3" colspan="2" |
| rowspan="3" |
| Linguistic Ability
|-
| Empathy
|-
| Social Awareness
|-
| rowspan="3" | [[Persuader]]
| rowspan="3" | Assertiveness (Leadership)
| rowspan="3" | > 39
| rowspan="3" |
| Linguistic Ability
|-
| Empathy
|-
| Social Awareness
|-
|}
The better match with the table Skills, traits and attributes the better expedition leader the dwarf will be, try to avoid traits that halt experience gain for a relevant skill, otherwise time will be lost training a dwarf that will never get better at that skill.

{{gamedata| [POSITION:EXPEDITION_LEADER]
[NAME:expedition leader:expedition leaders]
[SITE]
[NUMBER:1]
[REPLACED_BY:MAYOR]
[RULES_FROM_LOCATION]
[RESPONSIBILITY:MEET_WORKERS]
[RESPONSIBILITY:RECEIVE_DIPLOMATS]
[RESPONSIBILITY:MILITARY_GOALS]
[PRECEDENCE:110]
[DO_NOT_CULL]
[ACCOUNT_EXEMPT]
[DUTY_BOUND]}}
{{Nobles}}

Modification:Expanded Plants/Timing

2017-05-01T11:48:48Z

Larix: In standard DF, a day is 1200 steps and a month 28 days.

The duration values for the day are different from those in the vanilla game.

1 day = 1 day = 1120 ticks

1 week = 7.5 days = 8400 ticks

1 month = 30 days = 33600 ticks

1 season = 90 days = 100800 ticks

{| class="wikitable"
|-
! Season !! Month !! Week 1 !! Week 2 !! Week 3 !! Week 4
|-
| Early spring || March || 0 || 8400 || 16800 || 25200
|-
| Mid-spring || April || 33600 || 42000 || 50400 || 58800
|-
| Late spring || May || 67200 || 75600 || 84000 || 92400
|-
| Early summer || June || 100800 || 109200 || 117600 || 126000
|-
| Mid-summer || July || 134400 || 142800 || 151200 || 159600
|-
| Late summer || August || 168000 || 176400 || 184800 || 193200
|-
| Early autumn || September || 201600 || 210000 || 218400 || 226800
|-
| Mid-autumn || October || 235200 || 243600 || 252000 || 260400
|-
| Late autumn || November || 268800 || 277200 || 285600 || 294000
|-
| Early winter || December || 302400 || 310800 || 319200 || 327600
|-
| Mid-winter || January || 336000 || 344400 || 352800 || 361200
|-
| Late winter || February || 369600 || 378000 || 386400 || 394800
|-
| Early spring || March || 403200
|}

v0.34 Talk:Pressure plate

2017-04-01T01:19:30Z

Larix: /* Table of sizes != Table of weights */

The level of detail in this article is truly impressive. I thank thee, whoever had to do the experiments to figure it out. [[User:ZortLF2|ZortLF2]] ([[User talk:ZortLF2|talk]]) 18:44, 18 August 2013 (UTC)

== Expected FPS crunch from lightspeed repeaters ==

I've played around with devices that send multiple open/close signals in close succession, e.g. ten doors linked to pressure plates, each activated two steps apart. The opening/closing sequence caused a massive slowdown of the game. A "flickering" door, run by a multi-plate repeater with a period of about 15 steps per full open&close cycle similarly caused massive lasting slowdown as long as it was active.

To verify, i built a simple door into a niche and ran it manually by a dwarf per Pull Lever/R - that reduced FPS from the low 40s to 12. It didn't matter if the door was accessible or not: i walled the door off, and even when completely surrounded by walls, putting the door on this fast repeat killed the frame rate; it _seems_ that pathing calculations aren't the main culprit. I don't know what exactly consumes all those cycles, but buildings that are opened/closed via mechanism definitely eat a lot of processing power, and it gets quite bad when this happens in quick succession. A true light speed repeater would probably not be very fun to run. --[[User:Larix|Larix]] ([[User talk:Larix|talk]]) 05:29, 17 March 2014 (UTC)

== Table of sizes != Table of weights ==

:I am confused by the section [[DF2012:Pressure plate#Choosing Weights|Choosing Weights]]. It references the [[DF2012:List of creatures by adult size|list of creatures :by adult size]]. That list explicitly documents ''sizes'', but this page implies that it documents ''weights''. That is an error, right?

If there's an error, it's probably the mention of weights in this article. As far as i can tell, pressure plates measure the ''size'' of creatures. My tests of citizen-triggered plates show that my fortress-mode dwarfs have sizes in the range of 60.000 to over 90.000, while weight (measured by examining minecarts dwarfs were riding in, verified by cart-sensing pressure plates) ranges from 70-110 kg (up to 130 including equipment).--[[User:Larix|Larix]] ([[User talk:Larix|talk]]) 01:19, 1 April 2017 (UTC)

Pressure plate

2017-04-01T00:50:08Z

Larix: /* Choosing Weights */ Updated for DF2014 - lower default minimum creature size, stepping choice via upper-/lowercase, lower child size is respected (the last one was at least in .34 already).

{{Quality|Exceptional|09:41, 18 May 2015 (UTC)}}
{{av}}
'''Pressure plates''' act in similar ways to [[lever]]s, in that they require [[mechanism]]s to be built, and then a pair of mechanisms to be linked to a [[floodgate]], [[Trap_component|spike trap]], [[bridge]], or what-have-you. Their accompanying activity is triggered the instant a creature has stepped on them (not including the delay associated with the triggered item); leave a time delay space for traps based on enemy movement as necessary.

Pressure plates are sensitive to some creatures and uninfluenced by others (see [[#Unusual Triggers|Unusual Triggers]]). They are not sensitive to inert weight. Pressure plates trigger when the accumulated weight of sensitive creatures reaches a threshold specified by the player (see [[#Choosing Weights|Choosing Weights]]). Pressure plates are not targeted by [[building destroyer]]s.

==Types==

'''One-use''' pressure plates send their signal, then deconstruct the first time they're triggered, leaving behind the mechanism used to construct them and destroying any mechanisms used to link them to other objects. As such, use low quality mechanisms to link with these.

'''Resetting''' pressure plates can be reused as many times as you want. They disengage 99 ticks after their trigger is removed.

==Uses==
Pressure plates are used as triggers for a variety of other device actions, such as [[bridge]] raising, or [[trap design|traps]] involving the release of [[magma]] or [[water]].

Pressure plates send an ''open'' signal the instant their criteria are met, and a ''close'' signal 99 ticks after their triggering criteria are no longer met. If a pressure plate sends an ''open'' signal to a device that is already opened, nothing happens. The only exception to this is the [[gear assembly]], which toggles its engaged/disengaged state on every signal from a [[lever]] or [[pressure plate]].

(See the individual device pages for complete details of how ''open'' and ''close'' signals affect each device.)

==Operation==
Making complicated devices with pressure plates requires a full and detailed understanding of how pressure plates function.

Resetting pressure plates send two signals: an ''open'' signal, when first triggered by an appropriate creature or fluid; and a ''close'' signal, set to occur 99 ticks after the pressure criteria are no longer met. They do not send continuous ''open'' signals while the pressure criteria are met. A pressure plate that is untriggered then retriggered before it has sent a ''close'' signal will not send an ''open'' signal on the second trigger, and will abort the ''close'' signal scheduled to occur from the untriggering.

Special care must be taken when linking multiple pressure plates to a single device. When doing so, it's possible for one of the plates to become activated before another plate has sent a ''close'' signal. Unlike with single plates, the triggering of the second plate will not abort the ''close'' signal scheduled from the first plate, and the triggered device can become deactivated (closed) despite a triggered pressure plate linked to the device.

Similar situations can occur when activating a bridge or other refractory building with a pressure plate: if the pressure plate sends an ''open'' too rapidly after sending a ''close'', the bridge will ignore the ''open'' and wedge close.

===Build order===
One essential consideration with carefully timed devices is build order. Pressure plates can send ''open'' and ''close'' signals at different times depending on what sort of building is being triggered and whether the building was built before or after the pressure plate. That is because furniture is evaluated in the reverse order in which it is built-- when you build a pressure plate before the furniture it's linked to, in many cases that furniture will not receive a signal until the tick following pressure plate activation.

* Linked [[Door|doors]] and [[Hatch|hatches]] always open the same tick that a pressure plate is triggered, but close depending on build order: if built before the pressure plate, they close 99 ticks after the trigger is removed, and if built after, they close 100 ticks after the trigger is removed.
* Retracting [[Trap#Upright_spear/spike|spikes]] built before a pressure plate retract 40 ticks after triggering and extend 139 ticks after the trigger is removed. If built after the triggering pressure plate, they retract 41 ticks after triggering and extend 140 ticks after the trigger is removed.
* [[Gear assembly|Gear assemblies]] will appear to be unaffected by build order-- they will engage or disengage on the same tick that a pressure plate is triggered, regardless of build order-- but gear assemblies built after a pressure plate will not transmit (or stop transmitting) power until the tick following pressure plate activation (or 100 ticks after criteria are no longer met), whereas gear assemblies built before a plate linked to them will toggle at 0 and 99 ticks.
* [[Drawbridge|Bridges]], [[Bars|vertical bars]], [[Floodgate|floodgates]], and [[Grate|grates]] built before a pressure plate open 100 ticks after the trigger is sent, and close 199 ticks after the trigger is removed. If they are built after a triggering pressure plate, they open 101 ticks after a trigger is sent and close 200 ticks after the trigger is removed.

Essentially, pressure plates send open signals immediately upon triggering and close signals 99 ticks after their trigger is removed; pressure plates built before the device they trigger work a tick later; and doors and hatches are always opened on the exact tick that they're triggered by a pressure plate, regardless of build order, although their close tick is still affected by build order.

===Unusual triggers===
Pressure plates will be set off by a sufficiently large [[undead]] corpse reanimating on their tile. They will be set off by creatures that fall onto them, even if those creatures [[gravity|fall]] onto another creature occupying the same tile. However, if a creature dies upon contact with the ground, as with a fall from a great height, that creature will not set off a pressure plate upon landing. A mechanic who completes the first attachment job on a pressure plate will not cause an ''open'' to be sent to the building being linked, but a ''close'' will be sent-- when the ''open'' is sent, the building is not yet linked! This tends to toggle gears upon linkage, and makes futile single-use, civilians-trigger pressure plates. Neither [[Trading|merchants]], their pack animals, nor [[trading#Liasons|diplomats]] will set off pressure plates, even pressure plates set to be triggerable by civilians. Should an invading force arrive, they will not activate any pressure plates that have been observed by any diplomat from their civilization. Flyers and swimmers will set off pressure plates in any tile they move through.

Regardless of whether a pressure plate is set to civilians-trigger or not, any creature that is [[unconscious]] or [[web|webbed]] will set off a pressure plate-- diplomat, sieging human, [[trapavoid]]er, or your own dwarf.

===Hanging pressure plates===
Like other buildings, pressure plates built on top of a constructed wall remain even after that constructed wall is removed{{Bug|0377}}. All linkages to such a plate need to be completed before removing the construction supporting the plate. Creatures falling through a hanging pressure plate will not trigger that plate, but fluid falling through or pumped into a square occupied by a hanging pressure plate will trigger that plate as normal. Flyers or swimmers moving through the tile containing the hanging pressure plate will trigger it as normal.

==Advanced techniques==

===Latching Pressure Plates===
[[Image:Mini_Resetable_Trigger_Once_Plate.PNG‎|thumb|right|133px|'''Resettable Latching Plate System'''. Uses scaffolding (not shown) just like a [[Screw pump#Pump stack|pump stack]].]]

While ordinary one-use plates are easy to use, they deconstruct immediately after triggering and destroy all but one of the mechanisms used. Frequently, it's desirable to have a system that triggers once, then waits to be reset manually. For example, you might have a pressure plate that seals off your entrance and floods it with magma, but you don't want the flood to stop or the drawbridges to open like it would for a resetting pressure plate, but you also don't want to rebuild and reconnect the one-use pressure plate after every siege when half the parts are submerged in magma. This is when you should use a pressure plate linked to a [[Memory (computing)|latch]].

Suppose you want to use a pressure plate to seal off your main entrance. You build the setup shown, being sure to construct the lower pumps before the upper pumps and the gear assembly on top after both pumps are done. Then connect the plate in room 2 to the drawbridges that seal the entrance and hook a resetting, enemy triggered plate from your main hallway to the hatch in room 1. The resetting pressure plate in room 2 should be set to trigger whenever any water is on it. You also connect a [[lever]] to the [[gear assembly]] above the pumps, which becomes your reset lever, and pull the lever to disengage the gear once its set up. You also connect that gear to a power source with at least 25 [[power]]. Lastly, you fill area 1 with 7/7 water (to prevent evaporation) by channeling through the floor and designating a [[activity_zone#Pit/Pond|pond zone]] above it. After it's full, remove the pond zone and build a floor over it for good measure. During construction, you will need scaffolding just like what you use for a [[Screw pump#Pump stack|pump stack]]. This setup uses the same trick of channeling through the floor and building the lower pump first to allow them to share their power source. Remember to forbid the access doors when you're done setting everything up.

You can [[power]] this from any source, but if your map gives 40 wind power you can just use a [[windmill]]. Build a [[windmill]] right above where it says "power here" and then build a gear assembly directly below it. Putting a windmill directly on top of a gear you disengage can cause the windmill to collapse, so don't try that unless it says the windmill has a stable foundation. You may also want to construct a wall around your windmill to prevent a [[building destroyer]] from smashing it.

Now, whenever your pressure plate is triggered, the hatch will immediately open and dump the water from 1 onto the plate at 2, holding that plate down until you use your reset lever to activate the pump and put the water back on top of the hatch. Don't forget to turn the pumps off after all the water has moved, or it will continue to reset itself until the pumps are stopped. You can eliminate that minor problem by hooking the pressure plates in the [[User:Uristocrat/Toggle_System|toggle system]] to the gear assembly on top of the pumps instead of a lever, but that's significantly more complex.

===Lightspeed repeater===
Pressure plates have a refractory period of 99 ticks, limiting [[repeater]]s to triple-digit cycles. However, multiple pressure plates attached to a target can be "staggered" such that the ''open'' signal from one plate is followed much sooner by the ''close'' signal from another plate. Using three pressure plates, a repeater can be constructed to toggle a target three times in 100 ticks:

Time --->

Repeater 1 ---O--C--O--C--O--C--O--C
Repeater 2 -----O--C--O--C--O--C--O-
Repeater 3 -------O--C--O--C--O--C--
What the door sees ---O-OCOCOCOCOCOCOCOCOCOC

This can be extended, with additional pressure plates, up to a maximum of one cycle every two ticks (one tick for open, and one for close) using 50 pressure plates. While these designs were [http://www.bay12forums.com/smf/index.php?topic=92454.msg2585477#msg2585477 originally created with fluid-logic], the introduction of [[minecart]]s provides a much simpler way to stagger the signals from multiple pressure plates.

Note that only a few targets that don't have a built-in delay can handle switching at such speeds ([[door]]s, [[hatch]]es, and [[gear assembly|gears]]).

Keep also in mind that quickly switching buildings will dramatically reduce the performance of your game due to map connectivity information being constantly rebuilt - a single door opening and closing every dozen steps may reduce your frame rate by about a third.

===Priority close===
Pressure plates are very timely when detecting a trigger and sending an ''open'' signal, but require 99 ticks when sending a ''close'' signal. Unfortunately, there are situations where closing a hatch or door 100 ticks later might just be too late. This limitation can be overcome by constructing multiple pressure plates that are continually refreshed in a cycle less than 100 ticks. When a trigger condition occurs the cycle is stopped, leading the pressure plate that would have been refreshed next to send a ''close'' signal much sooner. [http://www.bay12forums.com/smf/index.php?topic=128095.msg4449221#msg4449221 A well-calibrated design] should be able to provide a ''close'' signal in five ticks or less.

==Construction==
Pressure plates are built on any [[floor]] using {{k|b}}, {{k|T}}, {{k|p}}. You will be prompted to enable what type of things should trigger the plate (water, magma, creatures, minecarts, or some combination of the four). You are then instructed to set up a range between two values of weights- a minimum to a maximum. {{k|e}} and {{k|r}} affect the minimum weight, and {{k|d}} and {{k|f}} affect the maximum.

The number of mechanisms required to build a pressure plate depends on how many types of things (water, magma, creatures and/or minecarts) can trigger it. If only one of them can trigger it, it takes one mechanism. If two can (water and magma, water and creatures, or any other pair) then it takes two mechanisms. If all four can trigger it, it will take four mechanisms.

NOTE: The creature selection screen has an additional setting that allows the pressure plate to ignore, or be triggered by, your citizens. "Citizens" include [[Domestic animal|tame animals]] but not merchants or liaisons. Pressure plates that can be triggered by citizens will remain triggerable by non-citizens as well-- there is no way to make a pressure plate that is triggerable by only civilians, although a pressure plate with a narrow weight threshold could potentially trigger for only goblins and dwarves.

Construction is done by a [[mechanic]], who will require one to four [[mechanism]]s. After construction is completed, use the {{k|q}} key to view the building, and press {{k|a}} to link the pressure plate to choose which trap, floodgate, or other device will be triggered by it. Your mechanic will haul one mechanism to the desired device, work for awhile, and then take another mechanism to the pressure plate itself and complete the task. Your pressure plate is now ready for action.

===Choosing Weights===

For a table of creatures you can organize by increasing or decreasing [[size|weight]], see [[List of creatures by adult size]].

[[Vermin]] inherently do not trigger traps - aside from their weight being consistently less than 10000, they aren't treated as actual creatures for the purpose of triggering any sort of trap. The actual size of a creature likely depends on individual "build" : skinny and/or small creatures have less size/weight than enormous, fat ones of the same species. As shown in the list, children and adolescents are usually smaller than fully grown creatures and may not trigger plates adjusted to adults' size. Creatures with the trapavoid token will not trigger pressure plates, regardless of weight.

On-screen numbers are shown divided by 10 (rounded down). For example 50,000, the default minimum weight, will appear to be 5,000 in-game. It is easy to double check what you want to set it to by using a lookup and reverse lookup on the list, to compare what the game says about a creature, and what the list says.

{{k|e}} and {{k|E}} lower the minimum creature weight to which a pressure plate will react, {{k|r}} and {{k|R}} increase it. {{k|d}} and {{k|D}} reduce the maximum registered creature size while {{k|f}} and {{k|F}} increase it. The lowercase letters adjust sensitivity in steps of 10 000 (1000 on-screen), the uppercase letters in steps of 100 000 (10 000 on-screen).

A pressure plate set to trigger on {{k|T}}rack can also be adjusted to respond only to [[Minecart]]s of defined weights. The default settings are 1 as minimum and "any" as maximum, which responds to carts of any weight. If only carts of specific weights are supposed to trigger a signal, different minimum and maximum values can be chosen, in steps of 50 kg, ranging from 1 to 2000. {{k|t}} and {{k|y}} lower and increase the minimum, {{k|g}} and {{k|h}} affect the maximum weight setting. Only carts falling within the limits specified will trigger a signal, carts that are too light or too heavy will not. The gross weight of the cart will be consulted, i.e. the weight of the cart including its cargo (and potentially rider). Differing weights of empty carts only cover part of the choosable weight range - the heaviest empty carts are made from platinum and weigh 856 kg.

{{buildings}}

Fluid logic

2017-03-26T21:57:23Z

Larix: /* Examples */ There are no designs with three inputs.

{{Quality|Exceptional|23:23, 20 September 2016 (UTC)}}
{{av}}
Fluid logic is a form of [[computing]] which uses a fluid (generally [[water]]), controlled by various means, to trigger [[pressure plate]]s and hopefully accomplish some desirable result.

==Infinite Flow Gates==

These logic gates are relatively simple and cheap to make, but require an infinite amount of [[flow]] and infinite drainage to operate. You can build a circuit system to prevent the loss of water, but closing constructions like [[floodgate]]s will always destroy water, so you'll always have to replace it somehow. The following examples use raising [[bridge]]s and floodgates, as they have the same delay of 100 steps when reacting to on/off signals. The bridges work as inverted input as they block passage when receiving an on signal while floodgates open in that case. The channel in the gates stands for the drainage.

There are two versions of these gates here. 

<div style="position:relative; float:none;">
'''AND'''
{| cellpadding="0" cellspacing="0" style="border-spacing:0; border-style:solid; border-width:thin; border-color:#000000;"
|
{| cellpadding="0" cellspacing="0" style="border-spacing:0; padding:0; margin:0; vertical-align:middle;"
|-
|{{RTL|#222}}
|{{RTL|#222}}
|{{RTL|#222}}
|{{RTL|#222}}
|{{RTL|#222}}
|-
|{{RTL|#00A|≈|#DDD}}
|{{RTL|#A00|X|#444}}
|{{RTL|#0A0|X|#444}}
|{{RTL|#00A|^|#DDD}}
|{{RTL|#222|·|#BBB}}
|-
|{{RTL|#222}}
|{{RTL|#222}}
|{{RTL|#222}}
|{{RTL|#222}}
|{{RTL|#222}}
|}
|}
</div>
An AND gate is simply created by putting two floodgates ''in a row'', each one connected to one of the input triggers: {{Raw Tile|X|#A00|#444}}{{Raw Tile|X|#0A0|#444}}. When both floodgates receive an on signal, they will open and let the water from the left side pass. The [[pressure plate]] behind the floodgates has to be constructed to react on 4-7 water.
* If you use two 1x1 raising bridges, you'll get a NOR operation instead.
* The output can also be inverted by using a 0-3 pressure plate.
* You can add more floodgates to process more than two signals in the conjunction.
* You can use a 0-3 and a 4-7 pressure plate at the same time to get the result and its inversion at the same time.
* You can use a single floodgate and a 0-3 pressure plate to get a NOT gate.
* You can use a single 1x1 raising bridges and a 4-7 pressure plate to get a NOT gate, too.

<div style="position:relative; float:none;">
'''OR'''
{| cellpadding="0" cellspacing="0" style="border-spacing:0; border-style:solid; border-width:thin; border-color:#000000;"
|
{| cellpadding="0" cellspacing="0" style="border-spacing:0; padding:0; margin:0; vertical-align:middle;"
|-
|{{RTL|#222}}
|{{RTL|#222}}
|{{RTL|#222}}
|{{RTL|#222}}
|-
|{{RTL|#00A|≈|#DDD}}
|{{RTL|#A00|X|#444}}
|{{RTL|#DDD}}
|{{RTL|#222}}
|-
|{{RTL|#00A|≈|#DDD}}
|{{RTL|#222}}
|{{RTL|#00A|^|#DDD}}
|{{RTL|#222|·|#BBB}}
|-
|{{RTL|#00A|≈|#DDD}}
|{{RTL|#0A0|X|#444}}
|{{RTL|#DDD}}
|{{RTL|#222}}
|-
|{{RTL|#222}}
|{{RTL|#222}}
|{{RTL|#222}}
|{{RTL|#222}}
|}
|}
</div>
An OR gate is simply created by putting two floodgates in ''parallel'', each one connected to one of the input triggers: {{Raw Tile|X|#A00|#444}}{{Raw Tile|X|#0A0|#444}}. When one of the floodgates receives an on signal, it will open and let the water from the left side pass. The pressure plate behind the floodgates has to be constructed to react on 4-7 water.
* If you use two 1x1 raising bridges, you'll get a NAND operation instead.
* The output can also be inverted by using a 0-3 pressure plate.
* You can add more floodgates to process more than two signals in the conjunction.
* You can use a 0-3 and a 4-7 pressure plate at the same time to get the result and its inversion at the same time.

<div style="position:relative; float:none;">
'''XOR'''
{| cellpadding="0" cellspacing="0" style="border-spacing:0; border-style:solid; border-width:thin; border-color:#000000;"
|
{| cellpadding="0" cellspacing="0" style="border-spacing:0; padding:0; margin:0; vertical-align:middle;"
|-
|{{RTL|#222}}
|{{RTL|#222}}
|{{RTL|#222}}
|{{RTL|#222}}
|{{RTL|#222}}
|-
|{{RTL|#00A|≈|#DDD}}
|{{RTL|#A00|X|#444}}
|{{RTL|#0A0|╬|#444}}
|{{RTL|#DDD}}
|{{RTL|#222}}
|-
|{{RTL|#00A|≈|#DDD}}
|{{RTL|#222}}
|{{RTL|#222}}
|{{RTL|#00A|^|#DDD}}
|{{RTL|#222|·|#BBB}}
|-
|{{RTL|#00A|≈|#DDD}}
|{{RTL|#A00|╬|#444}}
|{{RTL|#0A0|X|#444}}
|{{RTL|#DDD}}
|{{RTL|#222}}
|-
|{{RTL|#222}}
|{{RTL|#222}}
|{{RTL|#222}}
|{{RTL|#222}}
|{{RTL|#222}}
|}
|}
</div>
A XOR gate is created by putting 1x1 raising bridges and floodgates together. The red bridge and floodgate {{Raw Tile|X|#A00|#444}}{{Raw Tile|╬|#A00|#444}} are linked to the same input and the green bridge and floodgate {{Raw Tile|X|#0A0|#444}}{{Raw Tile|╬|#0A0|#444}} are both linked to the other input. When one of the inputs sends an on signal, the bridge will raise/close and the appropriate door will be opened. Only when the floodgate and the bridge at one passage are open, what happens when exactly one input signal is on, the water will flow to the right. The pressure plate behind the bridges has to be constructed to react on 4-7 water.
* If you exchange bridge and floodgate for one of the two inputs, you'll get a XNOR operation instead.
* The output can also be inverted by using a 0-3 pressure plate.
* You can use a 0-3 and a 4-7 pressure plate at the same time to get the result and its inversion at the same time
* Processing more input signals is possible but requires an exponentially increasing number of bridges, floodgates, and mechanisms. It is easier to link the output to another XOR gate.

As mentioned, you can just add more floodgates and bridges and even pressure plates to expand your gates to process more input signals and process more complex operations at once. You can combine floodgates and bridges as you need them. Putting them in a row will connect them as AND. Every time you add a new parallel passage with floodgates and bridges this will work as an OR for each other passage. The XOR gate for example is nothing else than combined logic: A XOR B = (A AND NOT B) OR (NOT A AND B).
But sometimes it is easier to use more but simpler gates.

==Fluid Preserving Gates==
At the moment there doesn't exist a full concept of a fluid-preserving fluid logic gate. Each design working with floodgates or equivalent components in the gates will have to deal with the destruction of the fluid. A way to handle this can be the usage of [[Hatch cover|hatches]]. [[Evaporation]] is another known problem.

==CMOS Transmission Gate and Inverter Logic==
Perhaps the closest to utilizing water as a stand-in for electricity, transmission gate logic can be accomplished by simply having an infinite water source in place of all +Vs, and infinite drainage for all grounds. Simple floodgates behave as standard transmission gates, while bridges are inverted gates. However, unlike the other forms of fluid logic, but as with real world electrical circuits, a dedicated inverter is required, which must be hooked up to +V and ground.

==Advanced Complementary fluid logic Gates==
This type of logic uses the different behaviour of raising bridges and floodgates when switched to minimise water consumption and remove the need of a drain. The use of (typically) two buildings for every input, one of which is always open while the other is closed, ensures that only very little water will flow during operation, and only when there is a state change. Thus, this variation of fluid logic is conceptually very similar to real CMOS circuits, which use a similar paradigm to limit power consumption.

===Basic Design===
Let's say we want to evaluate the logical expression ''f''. It can be a simple '''AND''' or '''OR''' gate, or anything more complicated. Follow the following scheme:

{| style="border-spacing: 0"
|{{H2O}}
|{{H2O}}
|{{H2O}}
|-
|{{RTF|╗}}
|{{RTF|A}}
|{{RTF|╔}}
|-
|{{RTF|║}}
|{{RT0|^|#808}}
|{{RTF|║}}
|-
|{{RTF|║}}
|{{RTF|B}}
|{{RTF|║}}
|-
|{{RTF|╚}}
|{{RTF|═}}
|{{RTF|╝}}
|}

Here, {{Tile|A|#FFF|#000}} is a set of floodgates and/or drawbridges that let water flow exactly when ''f'' evaluates to true, {{Tile|B|#FFF|#000}} is the same except that it lets water flow when ''f'' evaluates to false, {{Tile|^|#808|#000}} is a pressure plate set to activate on a sufficient water level. Notably, a drain is not needed.

===Examples===
In the following examples, {{Tile|X|#000|#888}} is a floodgate, and {{Tile|╬|#FFF|#000}} is a drawbridge. Red ones are connected to input A and green ones to input B.

====NOT====
{| style="border-spacing: 0"
|{{H2O}}
|{{H2O}}
|{{H2O}}
|-
|{{RTF|╗}}
|{{RT|╬|#F00|#000}}
|{{RTF|╔}}
|-
|{{RTF|║}}
|{{RT0|^|#808}}
|{{RTF|║}}
|-
|{{RTF|║}}
|{{RT|X|#FFF|#800}}
|{{RTF|║}}
|-
|{{RTF|╚}}
|{{RTF|═}}
|{{RTF|╝}}
|}

The pressure plate must activate on a water level of 5-7. When input turns off, the drawbridge lowers and the floodgate closes. Water can flow onto the pressure plate and fills the tile completely, turning output on.

When input turns on, the bridge raises and cuts off incoming water, while the floodgate opens and the water on the pressure plate's tile spreads over the now two open tiles. Water depth over the pressure plate lowers to 3-4, insufficient to keep the pressure plate active, which will turn off.

Siphoning the water off into a drain is unnecessary: the spread of water into opened tiles is sufficient to reliably produce a measurably different liquid level. This holds for all binary logic gates under this doctrine.

====AND====
{| style="border-spacing: 0"
|{{H2O}}
|{{H2O}}
|{{H2O}}
|{{H2O}}
|-
|{{RTF|╗}}
|{{RT|X|#FFF|#800}}
|{{RTF|╔}}
|{{RTF|═}}
|-
|{{RTF|║}}
|{{RT|X|#FFF|#080}}
|{{RTF|╚}}
|{{RTF|╗}}
|-
|{{RTF|║}}
|{{RT0|^|#808}}
|{{RT|╬|#F00|#000}}
|{{RTF|║}}
|-
|{{RTF|║}}
|{{RT|╬|#0F0|#000}}
|{{RTF|╔}}
|{{RTF|╝}}
|-
|{{RTF|╚}}
|{{RTF|═}}
|{{RTF|╝}}
|}

====OR====
{| style="border-spacing: 0"
|{{H2O}}
|{{H2O}}
|{{H2O}}
|{{H2O}}
|-
|{{RTF|╗}}
|{{RT|╬|#F00|#000}}
|{{RTF|╔}}
|{{RTF|═}}
|-
|{{RTF|║}}
|{{RT|╬|#0F0|#000}}
|{{RTF|╚}}
|{{RTF|╗}}
|-
|{{RTF|║}}
|{{RT0|^|#808}}
|{{RT|X|#FFF|#080}}
|{{RTF|║}}
|-
|{{RTF|║}}
|{{RT|X|#FFF|#800}}
|{{RTF|╔}}
|{{RTF|╝}}
|-
|{{RTF|╚}}
|{{RTF|═}}
|{{RTF|╝}}
|}

For the AND gate, the pressure plate should respond to 6-7 or 7-7 water. Since the OR gate is in effect a NOR gate with inverted output, the plate must respond to "low" water, 0-5 is recommended.

====XOR====
This is not as straightforward as the previous ones. The ''true'' expression is the following: (A '''and not''' B) '''or''' ('''not''' A '''and''' B). The ''false'' expression: (A '''and''' B) '''or''' ('''not''' A '''and not''' B).

So the gates look like the following:

{| style="border-spacing: 0"
|{{H2O}}
|{{H2O}}
|{{H2O}}
|{{H2O}}
|-
|{{RTF|╗}}
|{{RT|X|#FFF|#800}}
|{{RT|X|#FFF|#080}}
|{{RTF|╔}}
|-
|{{RTF|║}}
|{{RT|╬|#0F0|#000}}
|{{RT|╬|#F00|#000}}
|{{RTF|║}}
|-
|{{RTF|║}}
|{{RT0|^|#808}}
|{{000}}
|{{RTF|║}}
|-
|{{RTF|║}}
|{{RT|X|#FFF|#800}}
|{{RT|X|#FFF|#080}}
|{{RTF|║}}
|-
|{{RTF|╚}}
|{{RTF|═}}
|{{RTF|═}}
|{{RTF|╝}}
|-
|}

If both inputs have the same value (both on or off), the two closed floodgates or raised bridges will form an impassable wall, blocking inflow of water. The second row of floodgates "behind" the pressure plate ensures that when the gate is deactivated by an "on" signal raising bridges, there is still space opened for water to spread into and lower fluid level. Either combination of one "on" with one "off" input opens a direct path for water to enter. The pressure plate must be set to react to 7/7 fluid, anything less can result in false positives.

===Advantages And Disadvantages===
The basic advantage of this design is that it uses much less water than infinite flow gates. A river is enough to supply even the more complex systems, as long as sufficient liquid depth is provided. A drain is not needed.

The disadvantage is that it requires more resources to construct, and more careful planning, since floodgates tend to block paths. The presented drain-less gates depend on precise fluid depth and require that all incoming logic fluid is at the full 7/7 depth. This may necessitate building a reservoir or pumping system to compensate for flow irregularities or overcome the sluggishness of otherwise pressureless fluids. That's especially true when you decide to use [[magma|magma/lava]] as fluid.

==Speed Improvements==
The main factors that affect the speed of these gates are the delays of floodgates and bridges, and the switch-off delay of pressure plates. These cannot be eliminated, although designs that seek to replace as many buildings as possible with doors and hatches may minimize delays.

Another factor is the flowing speed of the water. It can be improved. First, the water should flow in from a reservoir a few z-levels higher than the gates themselves (the more the better). This way, water will flow in much faster. In infinite-flow gates, you can then replace the pressure plates with up stairs, and make a 2x1 room one z-level above. On one tile is a down stair, and on the other is the pressure plate. Now the water will also flow out faster, or at least the pressure plate will switch off sooner. To minimize latency when deactivated, assuming sufficient inflow, the pressure plate can be set to trigger only on a full 7 units of water. This increases the water consumption a bit, but it still remains relatively low.

==Edge Detector==
In some situations, it is beneficial to have logic that triggers during a state ''transition'' rather than based on steady states - for example, turning a lever "on" could trigger one brief event while turning the lever "off" would trigger a different event (or possibly the same event).

{| style="border-spacing: 0"
|colspan="7"| Z+0
|-
|{{H2O}}
|{{RTF|╠}}
|{{RTF|═}}
|{{RTF|═}}
|{{RTF|═}}
|{{RTF|╗}}
|{{000}}
|-
|{{H2O}}
|{{RT|X|#FFF|#800}}
|{{000}}
|{{RT|╬|#800}}
|{{000}}
|{{RTF|║}}
|{{000}}
|-
|{{H2O}}
|{{RTF|╚}}
|{{RTF|═}}
|{{RTF|╦}}
|{{RTF|═}}
|{{RTF|╣}}
|{{000}}
|-
|{{H2O}}
|{{RT|╬|#800}}
|{{H2O}}
|{{RT|X|#FFF|#800}}
|{{000}}
|{{RTF|║}}
|{{000}}
|-
|{{H2O}}
|{{RTF|╔}}
|{{RTF|═}}
|{{RTF|╩}}
|{{RTF|═}}
|{{RTF|╝}}
|{{000}}
|-
|colspan="7"| Z=-1
|-
|{{000}}
|{{000}}
|{{000}}
|{{RTF|╔}}
|{{RTF|═}}
|{{RTF|═}}
|{{RTF|╗}}
|-
|{{000}}
|{{000}}
|{{000}}
|{{RTF|║}}
|{{RT|^|5:1}}
|{{RTF|#}}
|{{RTF|║}}
|-
|{{000}}
|{{000}}
|{{000}}
|{{RTF|╠}}
|{{RTF|═}}
|{{RTF|═}}
|{{RTF|╣}}
|-
|{{000}}
|{{000}}
|{{000}}
|{{RTF|║}}
|{{RT|^|5:1}}
|{{RTF|#}}
|{{RTF|║}}
|-
|{{000}}
|{{000}}
|{{000}}
|{{RTF|╚}}
|{{RTF|═}}
|{{RTF|═}}
|{{RTF|╝}}
|}

Both pressure plates should trigger on depth 2-6. Link the bottom pressure plate to machines you wish to activate on ''positive'' transitions (e.g. stepping onto a pressure plate, or pulling a lever) and the upper pressure plate to machines you wish to activate on ''negative'' transitions (e.g. stepping off of the pressure plate, or pulling the lever again), then link the trigger itself (a lever or pressure plate) to both floodgates and both raising bridges.

Each time the input trigger is toggled, the appropriate pressure plate will activate, remain active until the water finishes flowing, then deactivate after about 100 steps.

An edge detector can be realized very space efficient in advanced complementary fluid logic (as long as both pressure plates are linked to a single item). Input goes to floodgate and bridge, the pressure plates are working on 0-5 and 6-7, respectively.

{| style="border-spacing: 0"
|colspan="5"|
|-
|{{H2O}}
|{{RTF|╔}}
|{{RTF|═}}
|{{RTF|═}}
|{{RTF|═}}
|{{RTF|╗}}
|-
|{{H2O}}
|{{RT|X|#FFF|#800}}
|{{RT|^|5:1}}
|{{RT|^|#808}}
|{{RT|╬|#800}}
|{{RTF|║}}
|-
|{{H2O}}
|{{RTF|╚}}
|{{RTF|═}}
|{{RTF|═}}
|{{RTF|═}}
|{{RTF|╝}}
|}

==Memory Cells==

Fluid logic offers options for comparatively small [[Memory_(computing)|memory]] cells requiring very few mechanisms. They are usually quite primitive, so that more complicated memory manipulation requires additional machinery, but for simply "holding" a bit of information, they are hard to beat in compactness.

====S/R Latch====

{| style="border-spacing: 0"
|-
|{{888}}
|{{888}}
|{{888}}
|{{888}}
|{{888}}
|-
|{{H2O}}
|{{RT0|┼|#0F0}}
|{{RT0|^|#F0F}}
|{{RT0|┼|#F00}}
|{{888}}
|-
|{{888}}
|{{888}}
|{{888}}
|{{888}}
|{{888}}
|}

Design by [[User:Hussell/SetResetLatch|Hussell]].

A "set/reset" latch will activate when it receives a "set" signal - opening the door {{Tile|┼|#0F0}} , letting in water and triggering the pressure plate reacting to liquid of levels 5-7 - and stays active when the set signal turns off again. It will only deactivate when it receives an explicit "reset" signal - opening the door {{Tile|┼|#F00}}
behind the plate, allowing water to spread off the plate, lowering liquid depth enough to fall under the activation threshold. Further activity of the reset signal will, once again, not change the cell's state once it has been reset.

As usual in real-world set/reset latches, the inputs should not both be "on" at the same time.

====D-Latch====

{| style="border-spacing: 0"
|{{H2O}}
|{{H2O}}
|{{H2O}}
|-
|{{RTF|╗}}
|{{RT|┼|#FFF|#800}}
|{{RTF|╔}}
|-
|{{RTF|║}}
|{{RT|┼|#FFF|#080}}
|{{RTF|║}}
|-
|{{RTF|║}}
|{{RT0|^|#808}}
|{{RTF|║}}
|-
|{{RTF|╚}}
|{{RTF|═}}
|{{RTF|╝}}
|-
|}

This cell "tests" the state of the "Data" (hence D ) input controlling the door {{Tile|┼|#FFF|#800}} and the pressure plate (set to trigger on 5-7 liquid) will take on that input's state when the "enable" input opens door {{Tile|┼|#FFF|#080}}: if the data input is on, water can pass from the source to the pressure plate and fills the cell. If the data input is off, water will spread from the plate to the door's tile and lower liquid depth over the plate.

This cell will turn "on" whenever both data and enable input are on, but will only turn "off" when the data input is off at the moment the enable input ''switches'' from off to on, making it a hybrid of a Latch (reacts to changes in data as long as enabled) and a flipflop (only reacts to data state the moment enable changes from off to on). While this is clearly a weakness of the design, it is very compact and uncomplicated, needing a mere four mechanisms to link the doors to the inputs.

====Toggle Flipflop====

{| style="border-spacing: 0"
|{{H2O}}
|{{H2O}}
|{{H2O}}
|-
|{{RTF|╗}}
|{{RT|╬|#FFF|#800}}
|{{RTF|╔}}
|-
|{{RTF|║}}
|{{RT|┼|#FFF|#080}}
|{{RTF|║}}
|-
|{{RTF|║}}
|{{RT0|^|#808}}
|{{RTF|║}}
|-
|{{RTF|╚}}
|{{RTF|═}}
|{{RTF|╝}}
|-
|}

This is a cell which changes state to the opposite whenever its "control" input switches from off to on. The door {{Tile|┼|#FFF|#080}} is activated by the control input, and both the door and the bridge {{Tile|╬|#FFF|#800}} are linked to the pressure plate (triggering on 5-7 water).

The operation is not immediately obvious, thus a breakdown, beginning with the cell in the "off" state:

Water on the plate is 4 or less, the bridge is lowered. When the "clock/control" turns on, the door opens and water rushes onto the plate. The plate triggers and sends "on" signals to both bridge and door. The signal to the door is ignored, since the door's already open. The bridge receives a "raise" signal and reacts to it with a 100 step delay. Neither the bridge raising nor the door closing (when the control turns off again) does anything to the pressure plate's state, it remains "on".

Water on the plate is 5 or more (usually 7), the bridge is raised. When the clock turns on, water spreads from the plate to the door's tile. Water level on the plate falls under the activation threshold. After the normal pressure plate reset delay of 99 steps, "off" signals are sent to the door and the bridge. The door will immediately close, the bridge will lower 100 steps later. The cell is "off" and will remain so until the clock turns on again.

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

Textile industry

2016-10-03T19:13:32Z

Larix: /* Value */ No artefact value bonus for weave and dye. Quality is pseudo-randomly assigned, not a fixed function of worker skill.

{{Quality|Exceptional|23:36, 17 May 2015 (UTC)}}
{{av}}

The '''textile industry''' involves making [[thread]], [[cloth]], [[clothing]], [[bag]]s, [[rope]]s and [[craft]]s out of [[plant fiber]], [[silk]], [[wool]], and, to a limited extent, [[hair]]. A textile industry is one way to keep your dwarves clothed and happy (their starting clothing will slowly [[wear]] away, and high-value replacements boost happiness), and can be a very lucrative option as a [[wealth]] industry, especially if the goods are high quality. The best choice for textile trade goods are dresses and robes because they have the highest base [[value]]. A textile industry is also important for healthcare: cloth and thread are needed for bandages and suturing respectively, although the necessary materials can normally be acquired via [[caravan]]s too.

See also the [[Leather#Leather industry|leather industry]], which can provide an alternative source of clothing.

==Basic materials==
===Crops===
There are twelve [[crop]]s that can be [[Farming|grown]] for use in the textile industry, eight of which can be [[plant processing|processed]] by a [[thresher]] at a [[farmer's workshop]] into [[thread]] (and then into [[cloth]] by a [[weaver]] at a [[loom]]), and four of which can be [[miller|milled]] into [[dye]].

The easiest way to feed your fortress is with subsurface farming, and consequentially the easiest way to establish a textile industry is with underground [[crop]]s. The first of these are [[pig tail]]s, which can be either [[alcohol|brew]]ed or made into [[thread]] by a thresher. Pig tails can be grown in the summer and in the autumn. The second are [[dimple cup]]s, which grow in all [[season]]s and can be milled into blue dimple [[dye]].

[[Farming#Above Ground Farming|Above ground]] crops are a more varied and, in some cases, valuable commodity. However, they are more difficult to establish, as you must rely on plants [[plant gathering|gathered]] on your map or [[seed]]s and plants brought in by human and elven [[caravan]]s. They do have the advantage of growing in all seasons. The counterpart to pig tails underground used to be [[rope reed]], but six new crops have been added since: [[kenaf]], [[cotton]], [[ramie]], [[flax]], [[hemp]] and [[jute]]. [[Hemp]], in addition to being processable, can also be [[millstone|milled]] into [[flour]], making it a good choice for food production, moreover, hemp and rope reeds are the only plants usable to make thread that are found outside tropical biomes. Rope reeds, like pig tails, can be [[alcohol|brew]]ed into drinks. [[Blade weed]] is similarly widely available and can be used to make emerald dye, as is [[hide root]], used to make redroot dye (at half the value of the others). The highest-value and most difficult to acquire dye is [[sliver barb]], a black dye-producing crop that only grows in [[evil]] areas; it is never available from caravans or from embark, and must be pulled from the earth itself via plant gathering, often under the risk posed by [[weather|evil weather]].

For easy reference, the plants are listed below:
{|border="1" cellpadding="5" style="margin:1em 1em 1em 0;background:#F9F9F9;border:1px #AAA solid;border-collapse:collapse"
! colspan=10|Thread Plants
|-
! Plant !! Type !! [[Climate|Wet]] !! [[Climate|Dry]] !! [[Biome]] !! [[Calendar|Spring]] !! Summer !! Autumn !! Winter
|-
| [[Pig tail]] || [[Underground]] || X || X || [[Biome#Underground|Subterranean water]] || || X || X ||
|-
| [[Rope reed]] || [[Above ground]] || X || || [[Biome#Groups|Not Freezing]] || X || X || X || X
|-
| [[Flax]] || Above ground || || X || [[Grassland]], [[Savanna]] || X || X || X || X
|-
| [[Jute]] || Above ground || || X || [[Tropical]] || X || X || X || X
|-
| [[Hemp]] || Above ground || || X || [[Temperate]] || X || X || X || X
|-
| [[Cotton]] || Above ground || || X || Tropical || X || X || X || X
|-
| [[Ramie]] || Above ground || || X || Tropical || X || X || X || X
|-
| [[Kenaf]] || Above ground || || X || Tropical || X || X || X || X
|-
|}

{|border="1" cellpadding="5" style="margin:1em 1em 1em 0;background:#F9F9F9;border:1px #AAA solid;border-collapse:collapse"
! colspan=12|Dye Plants
|-
! Plant !! [[Dye]] !! colspan=2|Colour !! Type !! [[Climate|Wet]] !! [[Climate|Dry]] !! [[Biome]] !! [[Calendar|Spring]] !! Summer !! Autumn !! Winter
|-
| [[Dimple cup]] || Dimple Dye || Midnight Blue ||bgcolor="#003366" |     || [[Underground]] || X || X || [[Biome#Underground|Subterranean water]] || X || X || X || X
|-
| [[Blade weed]] || Emerald Dye || Emerald ||bgcolor="#50c878" |     || [[Above ground]] || || X || [[Biome#Groups|Not Freezing]] || X || X || X || X
|-
| [[Hide root]] || Redroot Dye || Red ||bgcolor="#ff0000" |     || Above ground || || X || Not Freezing || X || X || X || X
|-
| [[Sliver barb]] || Sliver Dye || Black ||bgcolor="#000000" |     || Above ground || || X || [[Surroundings#Evil|Evil]], Not Freezing || X || X || X || X
|-
|}

===Wool and hair===
[[Wool]] is a textile material obtainable by [[shearing]] one of a small number of creatures at a [[farmer's workshop]]: [[sheep]], [[llama]]s, and [[alpaca]]s. These animals can be sheared once every few months; as they also produce [[milk]], they are versatile animals that can supplement your textile industry. [[Troll]]s can also be sheared by their master [[goblin]]s, explaining how many goblin thieves and besiegers come dressed in troll fur items that are fully wearable but cannot be otherwise obtained.

[[Hair]] is another textile material that comes from animals, but is only obtained by [[butcher]]ing certain animals such as [[horse]]s, [[yak]]s and [[grizzly bear]]s, as a byproduct of the [[meat industry]]. Hair is quite limited; it can only be made into (dyeable) [[thread]], and cannot be made into proper cloth or clothing. As such, it is mostly useful as cheap [[suturing]] material for dwarven [[healthcare]]. With the library update, a [[bookbinder]] can use animal hair thread with a written on [[quire]] and a [[book binding]] to create a book. Like with suturing, its best to temporarily forbid all other threads from the stocks menu if you want to force your dwarves to use these "useless" threads. Otherwise, Urist McBinder will gladly grab your masterfully dyed giant cave spider silk thread instead.

Wool has only half the value of crop based thread. The same goes for hair of the more common and domestic animals, but the increasingly wild and rare animals listed under '[[Value#Material_multipliers]] - animals' have more valuable hair.

===Silk===
Raw [[silk]] is harvested from spider webs created by [[phantom spider]]s, [[cave spider]]s, [[brown recluse spider]]s, and [[giant cave spider]]s. The first three kinds of spiders are [[vermin]] that will leave behind [[web]]s in the fortress or forests, which can be collected by the automatic "collect webs" job at a [[loom]]. This silk is worth half as much (6☼) as plant based textile. The vermin spiders can bite dwarves and although their bites are non-lethal, the dwarf in question will be very woozy for a while afterwards. Note that [[cat]]s kill spiders mercilessly, so if you want to use them for textiles, "vermin breeding chambers", or at the very least locking up your cats, are necessary precautions.

[[Giant cave spider]]s, on the other hand, are extremely dangerous creatures, as they are the size of grizzly bears, do not feel pain, and can shoot webbing at any helpless dwarf who happens to be nearby. They reside in the caverns, and their webs can only be collected "in the wild" at extreme hazard, requiring significant military escort if you want your dwarf to return alive; it might be a good idea to change [[standing orders]] to ignore webs until you can clear out the caverns or otherwise provide an escort.

Giant cave spider silk thread (and what you produce from it) is worth only twice as much (24☼) as easily available pig tail thread (12☼). For low-quality production, skillful dyeing adds more value than a better material (a no-quality dye adds 20☼, masterful dyeing adds 240☼ to the value). Note, however that the material multiplier is incorporated into the thread, cloth, and finished good values; the actual difference in final value for a masterful robe is up to 1052☼. This makes giant cave spider [[silk farming]] a lucrative project once your textile industry matures.

===Trading and gathering===
The raw materials for a textile industry can be acquired via trading, as caravans bring large amounts of [[cloth]] and some thread, dye, and finished clothing, and can bring more if you ask. If you have the wealth for it, you can simply buy caravan cloth in bulk and then refine it to your needs. Caravan trading is enough to clothe even the largest fortress in adequate clothing, but you shouldn't rely on it for wealth. One can also gather the necessary plants from above ground, but this has a low overall yield, depends heavily on where you embarked, and is unpredictable.

==Thread==
Once you have the basic materials, you are ready to process them into thread. Crops, wool, and hair use two [[job]]s under [[plant processing]] at a [[farmer's workshop]]: you either {{k|p}}rocess the plants, or {{k|S}}pin the wool or hair. Making thread out of silk is done in one step: if there are spider webs on the map, dwarves with the [[weaving]] labor enabled will gather the webs and automatically spin them into [[silk]] thread. Note, however, that this applies to giant cave spider silk as well, and that collecting it benefits from military protection.

Thread can be [[Dye|dyed]], which increases its value as well as the value of anything woven from it (cloth can also be dyed directly, see below). Thread's primary use is for [[suturing]] at a hospital, and for decorating finished clothing - otherwise it is an intermediate good that needs to be woven into cloth and, finally, the finished product. For animal hair, though, thread itself is the finished product.

==Cloth==
By default, any non-hair thread produced is automatically queued up for [[weaving]] at a [[loom]], but this can be changed with [[standing orders]] under {{k|o}}, and may be necessary in the case of giant cave spider webs. Plant fibers will be queued for weaving into cloth as soon as they are processed at the [[farmer's workshop]]. If you prefer to create dyed cloth by dyeing the thread beforehand, you may want to set workshop [[Orders]] so that dwarves only weave [[dye]]d thread. Cloth can still be dyed after weaving.

==Clothes and cloth goods==
Once the thread is sewn into cloth, it can be put to use by a [[clothier]] at a [[clothier's shop]] to create [[clothes]], the usual end product for the textile industry. Clothing is required for a mature fortress, as clothes will eventually [[wear]] away, and necessitate replacement; a highly skilled clothesmaker is a boon for any fortress.

Even [[wear|worn]] clothing can still fetch a hefty price--1/2 to 3/4 its original value--and your dwarves will make sure there is an abundant supply. A high-quality textile industry provides sufficient value to purchase the entire caravan using only cast-off clothing.

If you plan to use clothing for trading, you can moderately increase its value by sewing images onto it. Items that are [[decorate]]d in this manner are considered local for purposes of trade offerings and, depending on the quality of the decoration, an image can add significant value to an item. Note, however, that it is generally more profitable to create a second piece of clothing than to decorate an existing one.

Although clothes are the main good, the clothier's shop can also produce [[rope]]s and [[bag]]s. Both can be made elsewhere, by the [[metal industry]] and by the [[leather|leather industry]] respectively, but if you have the raw resources, why not here? Ropes are necessary for [[restraint]]s, [[traction bench]]es, and [[well]]s, and [[bag]]s are used to store seeds, milling products, and powders (including dye), as well as [[sand]] for the [[glass industry]].

Cloth can also be used to make [[craft|cloth crafts]] at a [[craftsdwarf's workshop]], which is a valuable but rarely needed trade good.

==Size==
{{new in v0.42}}
To create differently sized clothes, request the clothes to be made from their respective workshops as usual. Afterwards, go back to the main workshop menu and look at the {{k|d}}etails of the issued job. {{k|f}}ilter for the race you want to make clothing for and press {{k|enter}} twice.

==Dyeing==
Dyeing an object is not necessary in the sense that dwarves do not demand colorful clothes, but it is an easy way to greatly increase its [[value]] if you have a skilled [[dyer]]. Both thread and cloth can be dyed, but dyed objects cannot be redyed - the coloration is permanent.

Once you have harvested dye plants (which are described in basic materials, above), you are ready to [[miller|mill]] them at a [[millstone]] or [[quern]]. Note that this requires an empty [[bag]] into which the dye will be deposited. Each plant that is processed into dye creates 1 unit of dye, which is enough to dye 1 unit of thread or cloth. A single bag will hold the entire "stack" of dye, regardless of how big the stack of plants was.

Dye can then be applied at a [[dyer's shop]] by a [[dyer]].

==[[Value]]==
Clothes and cloth goods can have many modifiers, so it can be difficult to determine exactly how to produce the most valuable goods. Despite their complexity, cloth goods follow many of the same rules for [[item value]] calculations as other goods. Notably, the cloth, thread, and embroidery are calculated like [[decoration]]s, while dyes are just added directly. The specific formula for a cloth item's value is as follows:

{| border="1" style="border: 1px solid black; border-spacing: 0; margin: 1em auto; text-align:center; border-collapse: collapse;"
|+ '''Cloth Item Value'''
|-
!
! {{tc|teal|item}}
! {{tc|green|cloth}}
! {{tc|red|thread}}
! {{tc|blue|cloth/thread dye}}
! {{tc|purple|embroidery}}
! {{tc|purple|embroidery dye}}
|-
| Summed Elements
| {{tc|teal|(type * material * quality)}}
| {{tc|green|(decoration * material * quality)}}
| {{tc|red|(decoration * material)}}
| {{tc|blue|(powder * material * quality)}}
| {{tc|purple|(decoration * material * quality)}}
| {{tc|purple|(powder * material * quality)}}
|-
| Values
| {{tc|teal|Type: [[DF2014:Maximizing_value#Cloth|Inherent value of item]];Material: Material value of cloth used to make the item; Quality: [[DF2014:Item_quality|1-5,12,or 120 (for artifacts)]], influenced by the clothier skill of the item maker}}
| {{tc|green|Decoration: 10; Material: Material value of cloth used to make the item; Quality: [[DF2014:Item_quality|1-5 or 12]], influenced by the weaver skill of the cloth maker}}
| {{tc|red|Decoration: 10; Material: Material value of thread used to make the cloth}}
| {{tc|blue|Powder: 1; Material: Milled value of plant used to make dye; Quality: [[DF2014:Item_quality|1-5 or 12]], influenced by the dyer skill of the dye maker}}
| {{tc|purple|Decoration: 10, Material: Material value of cloth used for embroidery, ignoring cloth quality; Quality: [[DF2014:Item_quality|1-5,12,or 120 (for artifacts)]], influenced by the clothier skill of the embroiderer}}
| {{tc|purple|Powder: 1; Material: Milled value of plant used to make dye; Quality: [[DF2014:Item_quality|1-5 or 12]], influenced by the dyer skill of the dye maker}}
|}

Note that the skill of the threadmaker doesn't provide quality to the thread and is thus not relevant (for the item OR the embroidery); neither is the weave quality of the cloth used in the embroidered design. The formula can be simplified (to use fewer terms) as:

item_material * (item_type * item_quality + item_cloth_quality*10 + 10) + item_dye_material*item_dye_quality + 10*embroidery_material*embroidery_quality + embroidery_dye_material*embroidery_dye_quality

The formula is quite complicated, so use this example.

''This is an '''exceptional''' pig tail fiber cloak. It is made from '''pig tail''' fiber cloth. The thread is midnight blue, '''superbly''' colored with '''dimple dye'''. On the item is an '''exceptionally''' designed image of waves in rope reed fiber by Urist McClothier. It is made from well-crafted '''rope reed''' fiber cloth. The thread is emerald '''exceptionally''' colored with '''emerald dye'''.''

First, the item value:

(item type * material * item quality)

('''cloak''' * '''pig tail''' * '''exceptional''')

(('''26''' * '''2''' * '''5''')

= '''260'''

Next, add the cloth quality of the item (ignore cloth quality on embroidery):

{{tc|green|(decoration * material * cloth_quality)}}

{{tc|green|('''decoration''' * '''pig tail''' * '''normal''')}}

{{tc|green|('''10''' * '''2''' * '''1''')}}

= {{tc|green|'''20'''}}

Next, add the thread value of the item (ignore any embroidered thread):

{{tc|red|(decoration * material)}}

{{tc|red|('''decoration''' * '''pig tail''')}}

{{tc|red|('''10''' * '''2''')}}

= {{tc|red|'''20'''}}

Then the item's dye value is added (ignore dye on embroidery ''for now'' - it's checked below):

{{tc|blue|(powder * dye_material * dye_quality)}}

{{tc|blue|('''powder''' * '''dimple dye''' * '''superb''')}}

{{tc|blue|('''1''' * '''20''' * '''4''')}}

= {{tc|blue|'''80'''}}

Lastly, the embroidery:

{{tc|purple|(decoration * embroider_material * embroider_quality) + (powder * dye_material * dye_quality)}}

{{tc|purple|('''decoration''' * '''rope reed''' * '''exceptional''') + ('''powder''' * '''emerald dye''' * '''exceptional''')}}

{{tc|purple|('''10''' * '''2''' * '''5''') + ('''1''' * '''20''' * '''5''')}}

= {{tc|purple|'''200'''}}

So the total value of this item would be:

260 + {{tc|green|20}} + {{tc|red|20}} + {{tc|blue|80}} + {{tc|purple|200}}

= '''580'''

Embroidering an item will almost always generate less value than making clothes, since an embroidered image has a somewhat low value compared to the most valuable clothes (notably robes and cloaks) and the value granted by cloth quality is discarded when embroidering. Low-quality images created with high-quality cloth are even worth less than the roll of cloth used.

Theoretically, the most valuable non-artifact/non-adamantine clothing item is worth '''3064'''. It would be a masterful giant cave spider silk robe, made from masterful giant cave spider silk cloth masterfully dyed with dimple/sliver/emerald dye. It would be worth 2344: ((33 * 4 * 12) + (10 * 4 * 12) + (10 * 4) + (1 * 20 * 12). The embroidery would be masterfully designed using masterfully-dyed giant cave spider silk cloth, adding 720: (10 * 4 * 12) + (1 * 20 * 12). Note, however, that the second piece of cloth would have likely been worth more as a second robe than as a decoration on the first.

==Industry management==
Overall, the textile industry consists of eight different jobs: ([[grower|growing]], [[plant processing]], [[shearing]], [[spinning]], [[weaver|weaving]], [[clothier|clothes making]], [[milling]], and [[dyeing]]). The value of the finished product is determined by the [[quality]] of three specific steps (as well as the base material): weaving, dyeing, and clothes-making. Obviously, then, the more skilled your weavers, dyers, and clothiers, the better and more valuable your items will be.

If your intent is to produce equal volumes of thread and dye (so that all of your thread can be dyed), then you need to establish a year-round growing cycle with two equally-sized plots above and below ground as follows:
::{| class="wikitable"
|-
!
! Spring
! Summer
! Autumn
! Winter
|-
| '''Underground'''
| [[Dimple cup]]
| [[Pig tail]]
| [[Pig tail]]
| [[Dimple cup]]
|-
| '''Above ground'''
| [[Rope reed]]
| [[Sliver barb]]
| [[Blade weed]]
| [[Rope reed]]
|}
This will give you one cloth crop and one dye crop each harvest. This is not the only way to do it, but it is an example of a growing plan that will keep a [[miller]], a [[thresher]], a [[dyer]], a [[weaver]], and some [[grower]]s employed evenly year-round and provide high-value materials for any tailors in your fort. If you have access to [[silk]] on your map, you may prefer to substitute a food crop for one of the fiber crops, or brew the excess [[pig tail]] into [[dwarven ale]].

Large fields, [[fertilizer]], and skilled [[grower]]s will produce more raw materials; skilled craftsdwarves will use up the materials faster. Choose the largest plot size you can sustainably increase harvests, because eventually your craftsdwarves will be able to go through materials faster than you can grow them and you'll find yourself queueing up new orders each season. To boost profits, set your workshop [[orders]] to use only dyed thread, leaving out [[hide root]] from your growing plan because of its lower [[item value]], and keep the supply channels full of plant products so that you always have materials to support standing (repeat) work orders.

{{Farming FAQ}}
{{Workshops FAQ}}
{{Category|Guides}}
{{Category|Materials}}
{{Category|Industry}}
{{Industry}}

Bituminous coal

2016-06-29T18:31:33Z

Larix: "fire-safe" is a technical term which only concerns use for building of forges/furnaces, and b.coal _is_ that kind of fire-safe.

{{Quality|Superior|09:13, 18 May 2015 (UTC)}}
{{stonelookup/0|uses=
* Create 9 [[fuel#Coke, from bituminous coal or lignite|coke]] at [[smelter]]}}{{av}}

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

Bituminous coal is flammable - 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]].

However, since its ignition point is above the cutoff for fire-safety, it is considered a [[fire-safe]] material and as such can be used for the construction of non-[[magma]] [[furnace]]s and [[forge]]s.

Bituminous coal is '''not''' the same as [[fuel|"refined coal" or "coal"]], though it is directly related.

Because bituminous coal only costs 3 embark points, and produces a large amount of fuel when processed, it may be wise to bring some bituminous coal with you on embark as an early source of fuel.

==See also==
* [[Lignite]]
* [[Fuel]]

{{d for dwarf}}
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.

<gallery>
File:Coal bituminous.jpg| A piece of bituminous coal.
</gallery>
{{gamedata}}
{{stones}}
{{Category|Economic Stone}}

DF2014:Scroll

2016-06-28T05:43:30Z

Larix: Scrolls are made with a single roller, the second roller listed in the description is a bug.

{{Quality|Tattered|16:32, 15 February 2016 (UTC)}}
{{av}}
{{new in v0.42}}

:''See also: [[book]]''

A '''scroll''' is made from a [[sheet]] and a scroll roller at a [[craftsdwarf's workshop]] or [[metalsmith's forge]].

Scroll rollers can be made from [[log]]s or [[stone]]s in the [[craftsdwarf's workshop]], metal [[bar]]s in the [[metalsmith's forge]], or [[glass]] in the [[glass furnace]].

Scrolls can be found under "tools" in the {{k|z}} Stocks screen and written scrolls can be found in the {{k|L}} Artifacts screen.

==Bugs==
While production of a scroll only uses one roller as component, the in-game description of the finished scroll mentions two roller materials. {{bug|9249}}

{{Category|Items}}

v0.34:Exploit

2016-06-21T05:18:54Z

Larix: Undo revision 225186 by Ravendarksky (talk)this is the 0.34 article, so should reference the 0.34 state of matters.

{{quality|Exceptional|15:49, 24 August 2010 (UTC)}}{{av}}

An '''exploit''' is a quirk of a game that allows players to gain what other players may consider an unfair advantage, usually by making use of a feature that is not working properly or which defies logic. 'Exploiting the game' is distinct from '[[Main:cheating|cheating]]' because exploits occur within the game as written and do not need any external [[Main:utilities|utilities]] or [[Main:modding|modding]]. Whether a player chooses to make use of an exploit or not depends on their personal taste; given that [[Main:Dwarf Fortress|Dwarf Fortress]] is a single-player game, the user alone can decide what liberties to take and what options to shun. Among DF players there is much discussion about what actually should be considered an exploit, going from making sweetpod syrup instead of sugar, growing crops in winter, or even underground, as the one extreme, to justifying 'water wheel batteries' as the other. This page takes a rather relaxed approach in that you considering it an exploit is basically enough to add it, if you don't get too much opposition.

== Atom Smasher ==
{{main|Dwarven atom smasher}}

Lowering a raised [[drawbridge]] can be used to obliterate most creatures or items beneath it. The drawbridge will be destroyed if it is used to crush a creature of too large a size.

==Manager Exercise Program==

As a [[Manager]], skill is gained as tasks are approved, not completed. Simply by queuing lots of jobs ({{key|j}} {{key|m}} {{key|q}}) (and providing a meager office), the manager will quickly level to [[legendary]] as an [[Organizer]]. The tasks can then be removed once approved.

==Merchant Swindles==

There are a variety of ways to steal cargo from [[merchant]]s without seizing it; all amount to naked theft. Tearing down the [[trade depot]] while the merchants are there is the easiest way.

Also, marking items for [[dump]]ing, using view creature mode ({{key|v}}), the stocks menu ({{key|z}}), items in room mode ({{key|t}}), or mass dump mode ({{key|d}})-({{key|b}})-({{key|d}}) then marking the entire depot, lets you relieve merchants of their goods. Just reclaim the items from your garbage dump [[zone]] later. You can even take clothing and equipment off merchant and guards this way.

You can make a wall around the merchants (and even the poor animals) and let them starve to death, letting you take what ever you want. Wait quite a while for them to starve. They will become [[Insanity|very angry]] if you do, so never open the door once they are on the brink of death.

However, the merchants will consider any lost goods to be stolen goods regardless of the method used to take possession of or destroy them.{{Verify}} See [[40d:Trading#Note_that_the_civ|the 40d page]] and [http://www.bay12forums.com/smf/index.php?topic=43771.msg829692#msg829692 This forum post]. So unless you specifically want to take the clothing off the backs of the merchants or steal from your own civ, you might as well just seize the goods anyway.

== Quantum stockpiles ==

A Quantum Stockpile (QSP) allows you to store an infinte number of items in a single tile. QSPs can make for super efficient storage, allowing more compact fortresses, shorter hauling routes, more efficient manufacturing flows, stocktaking at a glance with look {{K|k}} and [http://www.bay12forums.com/smf/index.php?topic=92241.msg3276117#msg3276117 possibly higher FPS].

Note that, due to {{bug|5994}}, deconstructing [[construction]]s near a quantum stockpile can potentially create many simultaneous [[hauling]] jobs. There is currently no easy way to prevent this. Undumps, due to their single-job nature, will not have this problem, and minecart stops will generate only a limited number of jobs due to their [[minecart#Capacity|capacity]].

=== Simple Quantum Stockpiles ===
The simplest QSP is created by designating a garbage dump [[activity zone]], dumping the items you want to store and then reclaiming them when you are ready to use them. If you place this garbage dump on top of an existing [[stockpile]], the dumped items will automatically be considered part of the stockpile, allowing the use of stockpile links to distribute the items to workshops or other stockpiles.

A similar effect may be achieved for stones by building a wall two tiles in front of a catapult and digging a channel between the wall and catapult. By firing the catapult at the wall, the stone falls into the trench. The stone will pile up in the channel, putting it out of sight and out of mind. Not only does this train [[siege operator]]s, but it clears the stone that your [[miner]]s leave everywhere.

Another way to quantum stockpile is to not have appropriate stockpiles to move items back to after you move them to the trading depot. The depot can hold an infinite number of items, and those items will not be removed if there is nowhere else to place them. This is also useful for anything you want to trade anyway.

=== The Minecart Stop ===
This method allows the type of items to be stored in the Quantum Stockpile to be completely controlled and to be as broad or specific as required. Collection of items is automatic with no user input required (just like a normal stockpile), and the number of haulers collecting for the stockpile is controlled by the size and number of receiving stockpiles. Distribution is also automatic, with dwarves coming to collect items as needed (just like from a normal stockpile).

This can be utilised as part of a [[minecart]] transport system, or standalone with no tracks or moving minecarts whatsoever. The steps below are to create a standalone Quantum Stockpile, but the same general principles apply if used in a minecart transport system.

''Setup:''
rrrr r receiving stockpile
S S track stop, set to dump south
d d distribution stockpile

# Build a track stop {{K|b}} - {{K|C}} - {{K|S}}. Ensure you set the dumping direction {{K|d}}.
# Designate a 1x1 distribution stockpile {{K|p}} on the square where the stop will dump and define preferences {{K|q}} to make the settings {{K|s}} store only what you want, with no barrels {{K|E}}, bins {{K|C}} or wheelbarrows {{K|w}}. Make it take from links only {{K|a}} but don't make any links.
# Designate a receiving stockpile {{K|p}} (can be anywhere, but optimally right next to the constructed track stop) of any size. The larger it is, the more dwarves will simultaneously collect items. Define the preferences {{K|q}} of this stockpile to be the same as the distribution stockpile, with the possible exception of the number of wheelbarrows. If the QSP is for heavy items (e.g. loose [[stone]]s), you may want to use [[wheelbarrow]]s in the receiving stockpile to speed up collection. Wheelbarrows will place a limit of up to three dwarves simultaneously collecting, unless you make multiple receiving stockpiles, each with its own set of wheelbarrows.
# Construct a new hauling route {{K|h}} - {{k|r}}, assign a vehicle {{K|v}} (you'll need to make a minecart), and define a new stop {{K|s}} on your constructed track stop. {{K|Enter}} to define the stop, {{K|Enter}} again to set the desired items to the same as your stockpiles, {{K|x}} to remove all existing conditions, {{K|s}} to make a stockpile link and choose the receiving stockpile/s {{K|p}}.

It is a little fiddly to initially set up, and if you miss any step it won't work at all, but once in operation it's an extremely efficient storage system, and scales easily with the size of your fortress, number of haulers and number of items to store.

This method cannot store any items in [[bin]]s or [[barrel]]s at all, including bolts (which shouldn't be stored in a bin anyway {{bug|2706}}), and all types of drinks (you will see your dwarves leave barrels and pots of alcohol all over the place). [[Food]] stored using this method tends to attract [[vermin]], especially swarms of [[fly|flies]], since it can't be placed in barrels. This method works well for [[furniture]], [[wear|cast-off]] [[clothing]], [[metal]] and [[stone]]. A quantum minecart stop can be combined with some sort of [[garbage disposal]] mechanism to easily handle [[refuse]] and [[invader]]s' corpses.

Note however that if your dwarves are under [[standing orders]] to ignore outdoor refuse (the default setting) they will also not load an outdoor refuse pile into the minecart.

=== The Undump ===
This technique was [http://www.bay12forums.com/smf/index.php?topic=92241.0 developed] before minecarts were implemented. While still a valid method, it has been superseded by the Minecart Stop QSP which achieves the same result, is easier to set up and has fewer drawbacks.

''Setup:''
H Hatch cover
===== ^ pressure plate, citizens trigger, linked to hatch
^sHs= = Wall
===== s Stockpile (same type)

The idea is that haulers try to place some item on the right stockpile, step on the pressure plate and make the hatch cover retract. This makes them cancel the hauling job because they can't reach the right stockpile. They then drop the item on the left stockpile, on top of as big of a pile as you want.

More information on this method can be found on the inventor's [[User:Vasiln/Undump|user page]].

Drawbacks to this design:
#It's slow, because the one target stockpile generates only one job at a time. If you have more than one target stockpile they create lag because of pathing issues. You probably want to keep your normal stockpiles and use the undump to clean them up slowly. At which point you could consider just using the normal quantum stockpile dumping. Or you build more undumps.
#Job cancellation spam. You can turn that off.
#Oftentimes, dwarves drop the item on top of the pressure plate instead of on the stockpile. A feeder stockpile just outside the undump helps here.
#You obviously need some materials to build it.
#You need to create an open space tile where the hatch cover is (channelling only leaves a ramp), which means digging in the level below.
#You want to set the pressure plate to the lowest minimum weight (10000, which gets a zero cut off and displays as 1000). This can get tedious, so getting a macro is advised.
#If your stockpile management is exceptional already, the undump may not be of as much use to you.
However, there is a multitude of potential applications that get discussed in [http://www.bay12forums.com/smf/index.php?topic=92241.0 this] thread.

== Building destroyer door ==

Forbid something a dwarf is carrying as he goes through a door, and he'll drop it. The door won't close and won't stop any normal creature from going through, but building destroyers seem to stop in their tracks, waiting for it to close before moving on. Note: your civilians can pass the creature safely, but attacking it cancels your protection. {{Verify}}

== HFS's back door ==

There's a convoluted way to dig down through [[semi-molten rock]] and evade the head-on encounter with [[hidden fun stuff]]. Doing this can enable you to, among other things, mine undiggable [[slade]] and duplicate rare minerals. See the page for [[semi-molten rock]] for details.

== Forgotten beast zoo ==

Wall off all the passageways into your lowest level at the outermost square of the map - except one, which leads to a little vestibule surrounded by fortifications. Wave hello to the various ungainly "[[forgotten beast]]s" which accumulate inside.

Alternatively, by using a [[giant cave spider]] or web-spewing forgotten beast to place [[web]]s on cage traps you can capture and display non-web-spewing forgotten beasts, titans, and more.

== Dwarven Water Reactor ==

A [[screw pump]] requires 10 power to move water; a [[water wheel]] supplies 100 power if it's got water moving it. Arrange the former to feed the latter, while the latter powers the former, and you can get [[Water wheel#Perpetual motion|perpetual motion]] going - with a surplus of [[power]] available.

== Urist McAdventurer the Shield-wall ==

Adventurers are not limited in the number of items they can hold in their hands, allowing them to equip a virtually unlimited number of shields or bucklers with little effect to the adventurer's performance. This offers multiple chances to block attacks (vastly reducing the number that cause damage) and quickly trains up the shield user skill, further increasing the effectiveness of those shields. There is an indirect limit on how many shields you can equip based on how the total weight of your adventurer's items affects your speed, but the tradeoff between wearing a dozen (or more) shields is well worth the minor reduction in speed.

== Infinite drink in adventure mode ==

Thirst can be quenched indefinitely in adventure mode by emptying a waterskin when you only have 1 unit of liquid left and refilling it from the pool that forms; giving you 3 units of drink. This is especially useful if you managed to find alcohol and fill your waterskin with some, as alcohol never freezes in cold weather.

== Backpack of holding ==

In adventurer mode, if you try to pick something up while both your hands are already holding something, it'll go straight in your backpack, even if it would not have fit had you first picked it up and then tried to put it inside. That means you can stuff as much as you want into your backpack.

== And we'll throw in the barrel/bag for free ==

On [[embark]] buying things which are stored in [[barrel]]s gets the barrel for free, with at most 10 items per barrel, so, for example, the 15 units of randomly chosen [[meat]] which come with the default supplies will get you two free barrels, one completely filled with 10 units of meat and one half filled with 5 units of meat; you get another two free barrels from the 15 units of randomly chosen [[fish]]. You can get rid of all of that food, then for the same cost select one unit each of meat from 30 different kinds of animals, giving you 30 free barrels instead of only 4, since each different kind of animal meat is put in its own barrel. Note that different types of meat from the same kind of animal goes into a single barrel, so choosing 1 yak brain + 1 yak eye + 1 yak spleen will get you only one free barrel instead of three.

The same thing goes for things stored in [[bag]]s. Each unit of [[sand]] comes in its own bag, and since each unit of sand costs only 1 embark point while bags cost a minimum of 10 embark points each, you can get bags for ten times cheaper by buying sand, then [[dumping]] out the sand after embark.

== Infinite Adamantine / Metals ==

Because one bar of metal produces 25 bolts and a single bolt can be melted to 0.1 bars of metal, you can create unlimited adamantine wafers in your fortress using a [[Stupid_dwarf_trick#Bolt_Splitting_Operation|clever setup]] with marksdwarves to separate the stacks of adamantine bolts into single bolts. See this [http://www.bay12forums.com/smf/index.php?topic=51423.0 forum thread] for more details.

Coins may also be split at a [[trade depot]] and melted down individually for up to a 50x return. Smelt a stack of coins, then trade it to a caravan. You can then buy the stack back in pieces, and each individual smaller stack will melt and produce .1 bars. One bar produces 500 coins, but splitting it into stacks of 1 coin each would create 500 melt jobs, producing 50 bars in return. The process is discussed in greater detail, both with and without use of macros on this [http://www.bay12forums.com/smf/index.php?topic=111680.0 forum thread]. While potentially time consuming, this new method both results in far more bars produced per stack (potentially a net profit of 49 bars instead of 1.5), and can duplicate any metal, not just military ones while simultaneously training your broker. Combined with a magma smelter and properly written macros, this method turns a smelter into a free metal generator. Those who are less patient may instead opt to simply melt the coin stacks immediately after they are minted - while this yields only a 10% gain, it is far less time consuming.

For multiplying weapons/armor-grade metals, forging and melting giant axe blades, large serrated discs, and leggings will yield a 50% gain per item; note that this does ''not'' work with adamantine, since adamantine goods require 3 times as many wafers, instead leading to a 70% loss per item. For adamantine only, [[minecart]]s return 180% of their material when melted.

See the [[Melt item]] article for the best yields when melting down items made of mundane metals for the current version.

== Quick trade goods ==

Since [[trap component#spiked ball|spiked balls]] have an extremely high base [[item value]] of ''126'', they can be produced en masse from cheap [[wood]] or other materials and sold off to unsuspecting merchants. This makes for quick cash in any fortress that has a skilled carpenter and an excess of wood on hand.

In fact, any [[trap component]]s make extremely high-value trade goods, especially since metal components require only 1 [[bar]]. (They also increase the [[value]] of [[noble]]'s rooms, and are useful in defense.)

[[Prepared meal]]s can also be quick and valuable trade goods. Purchase an abundance of raw food when the traders arrive, and set your [[kitchen]] to work cooking that food into lavish meals. Then haul the stacks of meals back to the depot and trade them for whatever supplies you really want. The caravan will buy back meals composed of their own ingredients at 25x to 100x their initial value.

== Silk farm ==

{{main|Silk farming}}
A silk farm can serve as a safe and endless source of silk thread from [[giant cave spider]]s or other [[forgotten beast|web-spewing beasts]]. Its essence is a room with a bait creature separated from a web-spewing creature by fortifications. The webber will attempt to attack the bait by shooting [[web]]s through the fortifications. Weavers can collect the webs as silk thread and create silk cloth.

== Dwarven Road-Dar ==

Dwarven radar is a handy way of checking for caverns and other special features using the [[farm plot]]s, paved [[road]]s, and [[activity zone]]s. Know where the carverns are before you designate your carefully planned, fully symmetric living quarters!

For more details, see the [http://www.bay12forums.com/smf/index.php?topic=93694.0 forum thread].

== Dwarven vacuum cleaner/quantum teleporter ==

Due to a {{bug|5994|bug|link=yes}} in version 0.34, removing a [[construction]] teleports all free items in the surrounding map tile to the location of the removing dwarf. The teleported items can even travel through solid rock, providing a very safe, quick, and convenient means to empty traps and battlefields of corpses and spoils. Of particular note, drowning pools can be emptied without draining and refilling their water. After "vacuuming" everything into a safe area, your dwarves can sort through the loot at their leisure.

== Danger Room ==
{{Main|danger room}}

An [[Trap#Upright Spear/Spike|upright spike trap]] full of training spears (''not'' menacing spikes or metal spear, or even [[elf|Elven]] wooden spears) is linked to a [[lever]], which is pulled repeatedly. Dwarves are stationed on the trap. The dwarves quickly learn how to dodge, block and parry these "attacks", gaining [[combat skill]]s much more quickly than through normal [[training]]. Unless they die.

== Shaft of Enlightenment ==

Creatures with at least Dabbling in a weapon skill that fall onto an [[DF2012:Spike#Upright_Spear.2FSpike|upright spear / spike]] with an appropriate weapon equipped can experience godly increases in certain combat skills, up to [[legendary]] +70.{{bug|6397}} A drop of 2-3 [[z-level]]s, low-quality wooden [[training spear]]s, and wooden floors are recommended to maximize survivability. See this [http://www.bay12forums.com/smf/index.php?topic=134512.0 forum thread] for details.

v0.34:Melt item

2016-06-21T05:11:52Z

Larix: Undo revision 225187 by Ravendarksky (talk) revert to correct value _for 0.34_.

{{quality|Exceptional|18:12, 28 April 2011 (UTC)}}{{av}}{{buggy}}
You can '''melt''' items at a [[smelter]], using the [[furnace operator]] labor, to recover some of the [[metal]] they were made of. [[Decoration]]s in a different metal are not recovered or considered; the metal recovered is the specific metal that basic item was listed as being made from. The % return is predictable and consistent for each item type, and ranges from 10%-150%, depending on the item. Higher skill levels in furnace operator speed up the process, but have no effect on the % return.

Items that yield more than 100% can be used to increase the amount of a metal you have available by producing those items and then melting them down again as many times as required. This is generally considered to be an [[Exploit#Infinite_Adamantine_.2F_Metals|exploit]] of an error in the game mechanics. However, using a dwarf with a high skill level to make the items will result in him throwing severe tantrums when you start melting all his ☼masterwork☼ items, so you will need to disable your legendary armorer/weaponsmith while using the exploit, and make sure the skill levels don't get too high on the dwarfs making the items, or you will have tantrum spirals, fist fights, and/or lots of <s>useless junk</s> valuable trade goods lying around.

Recovered metal is measured in 1/10th's, and 1/10ths of bars of each metal are saved at the smelter where the item was melted. Fractional bars are not "shared" between smelters, nor do they exist as usable objects as is. When 10/10ths of a type of metal are accumulated at the same smelter, 1 bar of that metal is produced. If the smelter is torn down or destroyed, all fractions are lost.

:''Example:'' If two items of the same metal worth .4 bars each are melted at the same smelter, that smelter has .8 bars worth waiting in it.
:If a similar item of a ''different'' metal is then melted there, that smelter would have .8 bars of the first metal and .4 bars of the second.
:If a similar item of the first metal is then melted at a ''different'' smelter, that smelter will have .4 of that metal, and have no connection to the fractions in the first smelter.
:If (finally!), a 3rd, similar item of the first metal is melted at the first smelter, adding another 4/10ths, and giving a total of 12/10ths of that type of metal, 1 bar of that metal is produced, and 2/10th's are waiting (plus the 4/10 of the second metal, also waiting).

So, it makes sense to designate one smelter as "melting" smelter (or for one metal type), to guarantee that fractions will add up effectively.

==Designating items to melt==
You can designate metal items for melting from any interface that allows you to view the object's description screen, such as from the [[Stocks]] page or the Loo{{k|k}} interface.

To bring up an individual object description screen when the object is:
:* On the '''ground''': Type {{k|k}}, scroll to the object, select it from the list, and type {{k|Enter}}.
:* In a '''workshop''': Type {{k|t}}, highlight the workshop, select the object from the list, and type {{k|Enter}}.
:* '''Held''' by a dwarf: Type {{k|v}}, highlight the dwarf, type {{k|i}} to show his inventory, select the object from the list, and type {{k|Enter}}.
:* Inside another object: Display the container's object description screen, navigate to the specific object you wish to see, and type {{k|Enter}}.
:* In the '''stocks''' menu: Type {{k|z}}, hit right-direction a few times to select "stocks" and press return. Scroll to the type of object you wish to melt, type {{k|Tab}} to show individual items (You have to have an exact number or this won't work. See [[Bookkeeper]] for how to get this), scroll to the specific object, and type {{k|v}} to view.

To designate the item, simply type {{k|m}} to mark the object for melting. If the item is designated for melting and [[forbidden]] then the item will '''not''' be melted.

However, this only marks which items you want to be melted - you still have to place the job-order in a smelter...

==Melting the items==
Items designated to be melted will be left alone until you queue a "Melt a metal object" job {{k|o}} at a [[Smelter]]. Melting down an object requires the [[Furnace operator]] labor (and consumes a unit of [[fuel]] for a non-magma smelter).

The job gives the same experience to the [[furnace operator]] skill regardless of % yield of the item melted.

==Yield==
Testing is incomplete, but preliminary results show a yield of 0.3 bars times the object's material size for anything that has a material size, or 1 bar for most furniture (regardless of size).

Note that the Efficiency column is only accurate for ordinary metals - when using [[adamantine]], the number of wafers required comes from the "Material size" column instead of "Bars to make", so if that number is larger, the efficiency will be reduced accordingly.

{| style="margin:1em 1em 1em 0;background:#F9F9F9;border:1px #AAA solid;border-collapse:collapse;" class="wikitable sortable"
! Item !! Material size !! Bars to make !! Bars returned !! Efficiency
|-
! colspan="5"|[[weapon|Weapons]] (made by Weaponsmith)
|-
| Crossbow || 3 || 1 || 0.9 || 90%
|-
| Mace || 3 || 1 || 0.9 || 90%
|-
| Spear || 3 || 1 || 0.9 || 90%
|-
| Short sword || 3 || 1 || 0.9 || 90%
|-
| War hammer || 3 || 1 || 0.9 || 90%
|-
| Battle axe || 4 || 1 || 1.2 || '''120%'''
|-
| Pick || 4 || 1 || 1.2 || '''120%'''
|-
| Ammo (stack of 25) || (1) || 1 || 0.3{{verify}} || 30%
|-
| Ammo (stack of 1) || (1) || 1/25 || 0.1{{verify}} || '''''250%'''''
|-
! colspan="5"|Siege Equipment (Weaponsmith)
|-
| Ballista arrow || (4) || 3 || 0.5{{verify}} || 17%
|-
| Ballista arrow head || (4) || 3 || 0.5{{verify}} || 17%
|-
! colspan="5"|[[trap_component|Trap Components]] (Weaponsmith)
|-
| Giant Axe Blade|| 5 || 1 || 1.5 || '''''150%'''''
|-
| Enormous Corkscrew|| 5 || 1 || 1.5 || '''''150%'''''
|-
| Spiked Ball|| 4 || 1 || 1.2 || '''120%'''
|-
| Large Serrated Disc|| 4 || 1 || 1.2{{verify}} || '''120%'''
|-
| Menacing Spike|| 5 || 1 || 1.5{{verify}} || '''''150%'''''
|-
! colspan="5"|[[trap_component|Trap Components]] (Mechanic)
|-
| Mechanisms || (3) || 1 || 0.5 || 50%
|-
! colspan="5"|[[Armor]] (Armorsmith)
|-
| Cap || 1 || 1 || 0.3 || 30%
|-
| Helm || 2 || 1 || 0.6 || 60%
|-
| Gauntlet || 2 || 0.5 || 0.6 || '''120%'''
|-
| Leggings || 5 || 1 || 1.5 || '''''150%'''''
|-
| Greaves || 6 || 2 || 1.8 || 90%
|-
| Low boot || 1 || 0.5 || 0.3 || 60%
|-
| High boot || 2 || 0.5 || 0.6 || '''120%'''
|-
| Buckler || 2 || 1 || 0.6 || 60%
|-
| Shield || 4 || 1 || 1.2 || '''120%'''
|-
| Mail shirt || 6 || 2 || 1.8 || 90%
|-
| Breastplate || 9 || 3 || 2.7 || 90%
|-
! colspan="5"|[[tool|Tools]] (Metalcrafter)
|-
| Nest box || 1 || 1 || 0.3 || 30%
|-
| Jug || 1 || 1 || 0.3 || 30%
|-
| Pot || 1 || 1 || 0.3 || 30%
|-
| Hive || 1 || 1 || 0.3 || 30%
|-
| Minecart || 6 || 2 || 1.8 || 90%
|-
| Minecart ([[adamantine]]) || 6 || 1 || 1.8 || '''''180%'''''
|-
| Wheelbarrow || 6 || 2 || 1.8 || 90%
|-
! colspan="5"|[[Furniture]] (Blacksmith)
|-
| Anvil || (9) || 3 || 1 || 33%
|-
| Armor stand || (9) || 3 || 1{{verify}} || 33%
|-
| Barrel || (9) || 3 || 1 || 33%
|-
| Bin || (9) || 3 || 1{{verify}} || 33%
|-
| Blocks || (4) || 1 || 0.5 || 50%
|-
| Bucket || (3) || 1 || 1 || '''100%'''
|-
| Cabinet || (9) || 3 || 1{{verify}} || 33%
|-
| Cage || (6) || 3 || 1 || 33%
|-
| Chair || (9) || 3 || 1{{verify}} || 33%
|-
| Chest || (9) || 3 || 0 || N/A
|-
| Coffin || (9) || 3 || 1{{verify}} || 33%
|-
| Crutch || (3) || 3 || 0.5 || 17%
|-
| Door || (9) || 3 || 1{{verify}} || 33%
|-
| Floodgate || (9) || 3 || 1{{verify}} || 33%
|-
| Grate || (9) || 3 || 1{{verify}} || 33%
|-
| Hatch cover || (9) || 3 || 1{{verify}} || 33%
|-
| Pipe section || (9) || 3 || 1 || 33%
|-
| Splint || (2) || 3 || 0.5 || 17%
|-
| Statue || (9) || 3 || 1{{verify}} || 33%
|-
| Table || (9) || 3 || 1{{verify}} || 33%
|-
| Traction bench || (9) || 3 || 1{{verify}} || 33%
|-
| Weapon rack || (9) || 3 || 1{{verify}} || 33%
|-
! colspan="5"|[[Furniture]] (Metalcrafter)
|-
| Chain || (4) || 1 || 1 || '''100%'''
|-
! colspan="5"|[[Furniture]] (Trapper)
|-
| Animal trap || (3) || 1 || 1 || '''100%'''
|-
! colspan="5"|Other objects (Metalcrafter)
|-
| Amulet || (1/3 to 1) || 1/3 to 1 || 0.1{{verify}} || 10% to 30%
|-
| Bracelet || (1/3 to 1) || 1/3 to 1 || 0.1{{verify}} || 10% to 30%
|-
| Coins (stack of 500) || (1) || 1 || 1.1 || '''''110%'''''
|-
| Coins (stack of 1) || (1) || 1/500 || 0.1 || '''''5000%'''''
|-
| Crown || (1/3 to 1) || 1/3 to 1 || 0.1{{verify}} || 10% to 30%
|-
| Earring || (1/3 to 1) || 1/3 to 1 || 0.1{{verify}} || 10% to 30%
|-
| Flask || (1/3) || 1/3 || 0.2 || 60%
|-
| Figurine || (1/3 to 1) || 1/3 to 1 || 0.2 || 20% to 60%
|-
| Goblet || (1/3) || 1/3 || 0.2 || 60%
|-
| Instrument || (1) || 1 || 1 || '''100%'''
|-
| Toy || (1) || 1 || 0.2{{verify}} || 20%
|-
| Ring || (1/3 to 1) || 1/3 to 1 || 0.1 || 10% to 30%
|-
| Scepter || (1/3 to 1) || 1/3 to 1 || 0.2{{verify}} || 20% to 60%
|}

All melting yields for items ''not'' specified in the raws (weapons, armor, tools, etc.) are hardcoded.

Metal bars are able to be melted and remade into a bar at a smelter. (Melt 1 tin bar, return as 1 tin bar + experience.)

Due to a bug, chests cannot be melted. Attempting to do so at a normal smelter will merely consume fuel, while doing so at a magma smelter will do nothing at all; Furnace Operator skill will still be granted, though this isn't particularly valuable.

==Bugs==
*A number of items produce more metal when melted than they cost to produce.{{bug|6027}}
*Designating items to be melted from the [[stocks]] screen can cause a crash.{{bug|6431}}
*Melting [[minecart]]s assigned to routes can cause a crash.{{bug|6242}}
*Metal chests cannot be [[melt]]ed; attempting to do so will leave the chest intact but cause the furnace operator to gain experience (and waste [[fuel]] at non-magma smelters). {{bug|2493}}

{{Category|Jobs}}
{{Category|Items}}

Minecart

2016-05-15T11:07:01Z

Larix: /* Physics */ Edits to subtiles, numerical values for derail and shotgun speed requirement.

{{Quality|Masterwork|08:15, 19 May 2015 (UTC)}}
{{av}}
[[File:Leitnagel Hund.png|thumb|Minecarts]]
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]].

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.

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

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

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

After you have created the stops and assigned a cart to the track, you must create logic routes connecting several stops and designate starting conditions for each stop. This is done with the {{k|h}}auling key. The most basic conditions are how the cart's movement is initiated and in which direction the cart should start moving. Carts can be either 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.

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.

===Capacity and weights ===
Minecarts have five times the [[Weight|capacity]] of [[wheelbarrow]]s.

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

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

'''Weights of different carts'''

{| class="wikitable"
|-
! Type of cart
! Empty cart
! Fully loaded (items)
|-
| oaken minecart
| 28Γ
| 378Γ (10 oak logs)
|-
| platinum minecart
| 856Γ
| 10482Γ (83 gold bars)
|}

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

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

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

====Simple tracks====

'''Carved'''

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

'''Constructed'''

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

====Ramps====

'''Carved'''

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

'''Constructed'''

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

'''Examples of ramps'''

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

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

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

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

{{anchor|Tracks}}

=== Hauling route ===
A hauling route is a list of directions describing how and under what conditions a minecart will move. The proper setting up of routes is essential for a working rail system. Routes, stops, departure conditions and stockpile links are managed from the {{k|h}}auling menu.

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

New routes are created with the {{k|h}}auling key. Existing ones can be removed (without confirmation) with the {{k|x}} key, and also {{k|n}}icknamed. Before operating, the route must have a {{k|v}}ehicle assigned to it (this can be done with either the route or a stop selected). Assigning a full minecart to a route may result in a slow hauling job if the contents are heavy.

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

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

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

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

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

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

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

Counter-intuitive to their construction method, Track Stops are considered [[building]]s and must be removed by {{k|q}} {{k|x}}.
* See [[#More_on_Track_stop |More on Track Stops]]

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

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

[[File:minecart-example-1.png|Stockpiles designated.]]

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

Next, carve the track:

[[File:minecart-example-2.png|Track carving designation.]]

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

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

[[File:minecart-example-3.png|Track carved.]]

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

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

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

[[File:minecart-example-6.png|Track stop constructed.]]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Now we've got everything set up:

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

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

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

=== Troubleshooting ===

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

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

'''Possible Causes:'''
* 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.
** 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...)
* 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.
* The track stop might not be built on top of a track. The track stop must be deconstructed to remedy this issue.
* Your track might not be built correctly. Make sure all connected tracks between destinations are not one-way tracks.
** This can be especially confusing with ramps. To carve a two-way track on a (natural) ramp, you must designate the ramp and one square beyond in the direction you want the track to go.
** Ramps '''must''' have a solid 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.
* The desired/kept items might not be configured correctly.

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

'''Possible Causes:'''
* 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".
* The take conditions must correspond with the contents of the stockpile.
* 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.)
* Make sure the minecart itself has not been designated to be dumped (such as when using mass-dump).

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

'''Possible Causes:'''
* 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.
* 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).

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

'''Possible Causes:'''
* 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

==== Impulse ramps ====
Carts can be given momentum without rollers or changing z-level 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.

Example of straight impulse acceleration:

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

If a cart enters from the left, it will speed up on every track/ramp and exit to the right going very very fast - more than one tile every step. If it enters from the right then it will bounce back impulsed by the ramp if it's going slow enough.

As another oddity, carts coming from ramps will in some cases "teleport" through most of the next tile. This is called the "checkpoint effect", and is explained in detail in the Physics section, below. This negates the deceleration of the next tile if it is a ramp "angled" in a different direction. You can just make an upward spiral alternating impulse ramps and regular upward ramps. It takes no power, is quick and cheap to build, requiring only channeling and track carving, and the cart goes up fast, but not so fast that it launches its contents.

Example of an impulse elevator:

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

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

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.

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

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

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

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

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

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

=== Controlling traffic ===

==== Switching ====

As 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.
{{diagram|spaces=yes|\
->
A ════┤≡════ B
┤ : roller pushing to East
≡ : door
}}
The roller pushes the cart east, but until the "departure condition" is fulfilled, the door remains closed and blocks the path.

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

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

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

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

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

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

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

==== Controlling Speed ====


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

Will derail at > 0.5 t/st:

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

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

O : wall/column.
}}

This behavior can be used to build a "speed limiter", that will ensure that when a minecart exits it is traveling below derail speed:
{{diagram|spaces=yes|\
░░░░ ░░░░░ ░░░░░
in ═╔═╗░ ░╔S╗░ ░╔S╗░
out ═╬═╝░ out ═╗═╝░ out ═╗═╝░
░╚S╝░ ░╚═╝═ in ░╚S╝░
░░░░░ ░░░░ ║░░░
in
░ : wall
S : Track Stop (High Friction or lower)
}}
If the minecart is traveling below derailment speed, it will not be affected; if above, will be slowed down and checked again. Granted, you could do the same just with track turns, but it may take a lot of turns and time.

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

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

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

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

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

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

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

== Physics ==


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

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

The difference between "Push" and "Ride" is whether the dwarf will go along with the cart or not.
{{DFtext|Push}}: the dwarf will give the cart an initial push, not enough to go up a ramp, but enough to go some way along flat track, and the dwarf will remain at the first stop, ready for a new job.
{{DFtext|Ride}}: the dwarf will give the cart the same initial push and then hop aboard the cart riding with it to the next stop.
{{DFtext|Guide}}: minecarts seem to ignore all laws of physics. That is:
*Ignore the weight of any and all items inside. Therefore:
**Move at the speed of the dwarf that is guiding them. It is thus recommended to pick the most [[attribute#Agility|agile]] of your dwarves for cart-guiding tasks.
*Ignore working rollers.
*Will ''not'' collide with other guided carts even when a full frontal collision would be expected.
*Will go up ramps like nobody's business.
This is therefore the recommended method of transport for simple non-powered rail systems, despite it diverting a dwarf from other, potentially more important tasks.

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

=== Numbers behind the scene ===

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

This means a cart falling (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}}

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

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

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

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

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

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

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

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

=== Corner Ramp Derail ===

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

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

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

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

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

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

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

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

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

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

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

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

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

Three successive ramps results in the highest attainable speeds.

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

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

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

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

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

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

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

== Adventure mode ==
In addition to being used for hauling, minecarts can also be ridden in [[adventure mode]]. (Adapted from forum thread {{cite forum|122903/4258212}})

# If the minecart is in your inventory, drop it. If it is already on the ground, proceed to step 2.
# Press {{k|u}} when you are 1 tile away from the minecart (or standing on the same tile as the minecart).
# You will be presented with the following options:
[[File:minecart adventure mode menu.png|left]]
{{clear}}
* If you {{DFtext|Push}} the minecart, it will move a few tiles in the direction you chose. Physics comes into play here, so it will gain/lose speed depending on the usual factors.
* If you {{DFtext|Ride}} the minecart, you will hop into the minecart, even if you were a tile away, and it will move in the chosen direction with you in it. It will gain/lose speed depending on the usual factors. Whilst the minecart is in motion, you should press {{k|.}} to skip your turn; if you attempt to move whilst the minecart is still in motion, the laws of physics come into play, and you will take [[wound|damage]]. 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.

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

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

== See also ==
* [http://www.bay12forums.com/smf/index.php?topic=109460.0 The "How Does Minecart" Thread] by '''Girlinhat''' et al.
* [http://www.bay12forums.com/smf/index.php?topic=112831.0 SCIENCE: Quantifying minecart physics] by '''Snaake''' et al.
* [http://www.bay12forums.com/smf/index.php?topic=129676.0 How to build a Multi-cart Ore to Magma Minecart Project without needing power] by '''WanderingKid'''.
* [http://www.bay12forums.com/smf/index.php?topic=144328.0 My very own Minecart Education Thread. Ten Lessons, now complete.] by '''Larix'''.

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

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

[[ru:Minecart]]

Minecart

2016-05-02T15:45:40Z

Larix: /* Physics */ Correction for a misinterpretation of minecart data dumps.

{{Quality|Masterwork|08:15, 19 May 2015 (UTC)}}
{{av}}
[[File:Leitnagel Hund.png|thumb|Minecarts]]
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]].

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.

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

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

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

After you have created the stops and assigned a cart to the track, you must create logic routes connecting several stops and designate starting conditions for each stop. This is done with the {{k|h}}auling key. The most basic conditions are how the cart's movement is initiated and in which direction the cart should start moving. Carts can be either 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.

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.

===Capacity and weights ===
Minecarts have five times the [[Weight|capacity]] of [[wheelbarrow]]s.

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

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

'''Weights of different carts'''

{| class="wikitable"
|-
! Type of cart
! Empty cart
! Fully loaded (items)
|-
| oaken minecart
| 28Γ
| 378Γ (10 oak logs)
|-
| platinum minecart
| 856Γ
| 10482Γ (83 gold bars)
|}

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

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

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

====Simple tracks====

'''Carved'''

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

'''Constructed'''

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

====Ramps====

'''Carved'''

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

'''Constructed'''

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

'''Examples of ramps'''

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

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

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

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

{{anchor|Tracks}}

=== Hauling route ===
A hauling route is a list of directions describing how and under what conditions a minecart will move. The proper setting up of routes is essential for a working rail system. Routes, stops, departure conditions and stockpile links are managed from the {{k|h}}auling menu.

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

New routes are created with the {{k|h}}auling key. Existing ones can be removed (without confirmation) with the {{k|x}} key, and also {{k|n}}icknamed. Before operating, the route must have a {{k|v}}ehicle assigned to it (this can be done with either the route or a stop selected). Assigning a full minecart to a route may result in a slow hauling job if the contents are heavy.

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

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

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

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

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

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

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

Counter-intuitive to their construction method, Track Stops are considered [[building]]s and must be removed by {{k|q}} {{k|x}}.
* See [[#More_on_Track_stop |More on Track Stops]]

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

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

[[File:minecart-example-1.png|Stockpiles designated.]]

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

Next, carve the track:

[[File:minecart-example-2.png|Track carving designation.]]

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

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

[[File:minecart-example-3.png|Track carved.]]

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

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

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

[[File:minecart-example-6.png|Track stop constructed.]]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Now we've got everything set up:

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

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

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

=== Troubleshooting ===

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

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

'''Possible Causes:'''
* 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.
** 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...)
* 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.
* The track stop might not be built on top of a track. The track stop must be deconstructed to remedy this issue.
* Your track might not be built correctly. Make sure all connected tracks between destinations are not one-way tracks.
** This can be especially confusing with ramps. To carve a two-way track on a (natural) ramp, you must designate the ramp and one square beyond in the direction you want the track to go.
** Ramps '''must''' have a solid 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.
* The desired/kept items might not be configured correctly.

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

'''Possible Causes:'''
* 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".
* The take conditions must correspond with the contents of the stockpile.
* 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.)
* Make sure the minecart itself has not been designated to be dumped (such as when using mass-dump).

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

'''Possible Causes:'''
* 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.
* 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).

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

'''Possible Causes:'''
* 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

==== Impulse ramps ====
Carts can be given momentum without rollers or changing z-level 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.

Example of straight impulse acceleration:

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

If a cart enters from the left, it will speed up on every track/ramp and exit to the right going very very fast - more than one tile every step. If it enters from the right then it will bounce back impulsed by the ramp if it's going slow enough.

As another oddity, carts coming from ramps will in some cases "teleport" through most of the next tile. This is called the "checkpoint effect", and is explained in detail in the Physics section, below. This negates the deceleration of the next tile if it is a ramp "angled" in a different direction. You can just make an upward spiral alternating impulse ramps and regular upward ramps. It takes no power, is quick and cheap to build, requiring only channeling and track carving, and the cart goes up fast, but not so fast that it launches its contents.

Example of an impulse elevator:

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

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

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.

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

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

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

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

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

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

=== Controlling traffic ===

==== Switching ====

As 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.
{{diagram|spaces=yes|\
->
A ════┤≡════ B
┤ : roller pushing to East
≡ : door
}}
The roller pushes the cart east, but until the "departure condition" is fulfilled, the door remains closed and blocks the path.

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

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

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

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

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

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

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

==== Controlling Speed ====


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

Will derail at > 0.5 t/st:

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

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

O : wall/column.
}}

This behavior can be used to build a "speed limiter", that will ensure that when a minecart exits it is traveling below derail speed:
{{diagram|spaces=yes|\
░░░░ ░░░░░ ░░░░░
in ═╔═╗░ ░╔S╗░ ░╔S╗░
out ═╬═╝░ out ═╗═╝░ out ═╗═╝░
░╚S╝░ ░╚═╝═ in ░╚S╝░
░░░░░ ░░░░ ║░░░
in
░ : wall
S : Track Stop (High Friction or lower)
}}
If the minecart is traveling below derailment speed, it will not be affected; if above, will be slowed down and checked again. Granted, you could do the same just with track turns, but it may take a lot of turns and time.

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

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

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

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

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

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

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

== Physics ==


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

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

The difference between "Push" and "Ride" is whether the dwarf will go along with the cart or not.
{{DFtext|Push}}: the dwarf will give the cart an initial push, not enough to go up a ramp, but enough to go some way along flat track, and the dwarf will remain at the first stop, ready for a new job.
{{DFtext|Ride}}: the dwarf will give the cart the same initial push and then hop aboard the cart riding with it to the next stop.
{{DFtext|Guide}}: minecarts seem to ignore all laws of physics. That is:
*Ignore the weight of any and all items inside. Therefore:
**Move at the speed of the dwarf that is guiding them. It is thus recommended to pick the most [[attribute#Agility|agile]] of your dwarves for cart-guiding tasks.
*Ignore working rollers.
*Will ''not'' collide with other guided carts even when a full frontal collision would be expected.
*Will go up ramps like nobody's business.
This is therefore the recommended method of transport for simple non-powered rail systems, despite it diverting a dwarf from other, potentially more important tasks.

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

=== Numbers behind the scene ===

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

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

Every tick the cart adjusts sub-tile position units by the amount of their velocity, as well as adjusts velocity depending on current tile (speed is reduced by the "friction" of the tile, or accelerated if going "down" a ramp). On flat (non-ramp) tiles, the cart will move to the next tile when the sub-tile position goes 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.

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

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

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

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

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

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

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

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

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

Each non-ramp tile is functionally composed of 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.

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.

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

When carts move beyond the 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.)

Ramp tiles are longer, approximately 141,420{{cite forum|157627/0}} in the direction where it "slants downward", (to approximate a 45 degree slope, it is square root of two times longer,) and centered at 70,710. Because of this, a cart with no velocity dropped from a hatch will land at the center of a tile, at position 70,710, and 70,710, 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 141,420 position, and have twice as far to travel. This means that if a cart enters a ramp from the side, it will gain twice the momentum of simply starting at the midpoint of a ramp.

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

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

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

If a cart is passing West-to-East over this setup, the valid ramp to the South will apply "Southward" acceleration to the cart (-Y velocity) as it passes through the ramp tile. Assuming it only spends at two ticks in that tile, it will 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

This means a cart falling (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}}

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

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

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

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

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

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

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

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

=== Corner Ramp Derail ===

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

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

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

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

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

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

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

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

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

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

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

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

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

Three successive ramps results in the highest attainable speeds.

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

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

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

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

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

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

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

== Adventure mode ==
In addition to being used for hauling, minecarts can also be ridden in [[adventure mode]]. (Adapted from forum thread {{cite forum|122903/4258212}})

# If the minecart is in your inventory, drop it. If it is already on the ground, proceed to step 2.
# Press {{k|u}} when you are 1 tile away from the minecart (or standing on the same tile as the minecart).
# You will be presented with the following options:
[[File:minecart adventure mode menu.png|left]]
{{clear}}
* If you {{DFtext|Push}} the minecart, it will move a few tiles in the direction you chose. Physics comes into play here, so it will gain/lose speed depending on the usual factors.
* If you {{DFtext|Ride}} the minecart, you will hop into the minecart, even if you were a tile away, and it will move in the chosen direction with you in it. It will gain/lose speed depending on the usual factors. Whilst the minecart is in motion, you should press {{k|.}} to skip your turn; if you attempt to move whilst the minecart is still in motion, the laws of physics come into play, and you will take [[wound|damage]]. 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.

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

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

== See also ==
* [http://www.bay12forums.com/smf/index.php?topic=109460.0 The "How Does Minecart" Thread] by '''Girlinhat''' et al.
* [http://www.bay12forums.com/smf/index.php?topic=112831.0 SCIENCE: Quantifying minecart physics] by '''Snaake''' et al.
* [http://www.bay12forums.com/smf/index.php?topic=129676.0 How to build a Multi-cart Ore to Magma Minecart Project without needing power] by '''WanderingKid'''.
* [http://www.bay12forums.com/smf/index.php?topic=144328.0 My very own Minecart Education Thread. Ten Lessons, now complete.] by '''Larix'''.

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

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

[[ru:Minecart]]

Gravity

2016-04-30T12:28:37Z

Larix: Ballista arrows hitting the map edge also fall at fixed speed.

{{Quality|Superior|07:37, 17 May 2015 (UTC)}}
{{av}}

:''"The bigger they are, the harder they fall"''

'''Gravity''' in Dwarf Fortress shares similarities to the real world but has some key differences. Items, creatures and fluids will descend under gravity, moving to a lower [[z-level]] in the right circumstances. While this mimics the real world, the biggest key differences are listed below:
* In a [[cave-in]], terrain collapses to the lowest point instantly, however items, creatures and buildings fall more slowly (over multiple ticks)
* Buildings in a cave in will instantly deconstruct before they fall, and the resulting items will then fall separately
* Items and creatures that are thrown, shot, cut off and sent flying, knocked back or generally expected to travel in a parabolic arc will tend to do so (within the limitations of the game tiles); one notable exception is for [[siege engine]]s, which currently launch projectiles in a flat trajectory. When the projectile reaches the limit of its range or hits an obstacle, it stops moving forward completely and falls down vertically, at a fixed speed of 6 steps per z-level, without accelerating.
* Creatures and items accelerate while falling. Water falls at a semi-random rate, taking between 5 and 20 ticks to fall a single z-level.
* Creatures that fall into water decelerate, generally suffering less overall damage upon impact with the bottom. Drowning while stunned, however, is still a concern.
* The [[density]] of the material in the landing zone can have a significant effect on the outcome of a fall. Light materials like [[featherwood]] reduce the risk of serious injury, while dense materials like [[platinum]] increase it.
* Creatures that are dropped onto a standing creature's head will generally suffer little damage regardless of how many z-levels they fell. The unfortunate creature who broke their fall may suffer significant damage, however.
* The value of g in df for a falling dwarf is .032075 ± .000015 Z-levels/tick^2 based on drops of 59 z-levels done on v0.34.10. More recent tests on v0.42.0X show this value appears to have stayed constant. The value of g is the same for inanimate objects and may be the same for liquids. The latter needs testing.
* Falling entities observe the (mostly-hard) speed limit of terminal velocity, 270000 distance units per tick. Since a tile is 50% higher than it is wide, that translates to a maximum free-fall speed of 1.8 zlevels/step. Both creatures and objects are subject to this limitation. It should take 56 steps and 52 z-levels to reach this speed. Presumably, a 200-z fall is no different in effect from an exact 52-z one, since the falling object's or creature's velocity will not increase past this point.

In general, falls of 1-2 z-levels are unlikely to cause significant damage to your dwarves, and goblins have been seen to fall more than four with only light bruising and stunning. Large falls (30+ z-levels) will tend to cause the hapless victim to explode upon impact. The minimum drop with 100% mortality appears to be around 25 z-levels.[http://www.bay12forums.com/smf/index.php?topic=110718.0|1]

On the other hand, falling items and creatures can cause grave injury to any creature they fall upon, even when falling a single z-level.{{bug|5945}} A falling [[giant cave spider]] web can easily break the neck of your master weaver, while [[wear|worn]] [[clothing]] is liable to maim or kill anyone below. Refuse dumping may therefore be [[Trap_design#Falling_debris_trap|weaponized]]. Just take care that your own dwarves do not mistakenly pummel one another with falling stones.

Gravity

2016-04-30T11:18:52Z

Larix: Terminal velocity, objects and creatures behave the same, exception for (some?) siege projectiles.

{{Quality|Superior|07:37, 17 May 2015 (UTC)}}
{{av}}

:''"The bigger they are, the harder they fall"''

'''Gravity''' in Dwarf Fortress shares similarities to the real world but has some key differences. Items, creatures and fluids will descend under gravity, moving to a lower [[z-level]] in the right circumstances. While this mimics the real world, the biggest key differences are listed below:
* In a [[cave-in]], terrain collapses to the lowest point instantly, however items, creatures and buildings fall more slowly (over multiple ticks)
* Buildings in a cave in will instantly deconstruct before they fall, and the resulting items will then fall separately
* Items and creatures that are thrown, shot, cut off and sent flying, knocked back or generally expected to travel in a parabolic arc will tend to do so (within the limitations of the game tiles); one notable exception is for [[siege engine]]s, which currently launch projectiles in a flat trajectory. When the projectile reaches the limit of its range, it stops moving forward completely and falls down vertically, at a fixed speed of 6 steps per z-level, without accelerating (tested with catapult stones in DF 0.42.06).
* Creatures and items accelerate while falling. Water falls at a semi-random rate, taking between 5 and 20 ticks to fall a single z-level.
* Creatures that fall into water decelerate, generally suffering less overall damage upon impact with the bottom. Drowning while stunned, however, is still a concern.
* The [[density]] of the material in the landing zone can have a significant effect on the outcome of a fall. Light materials like [[featherwood]] reduce the risk of serious injury, while dense materials like [[platinum]] increase it.
* Creatures that are dropped onto a standing creature's head will generally suffer little damage regardless of how many z-levels they fell. The unfortunate creature who broke their fall may suffer significant damage, however.
* The value of g in df for a falling dwarf is .032075 ± .000015 Z-levels/tick^2 based on drops of 59 z-levels done on v0.34.10. More recent tests on v0.42.0X show this value appears to have stayed constant. The value of g is the same for inanimate objects and may be the same for liquids. The latter needs testing.
* Falling entities observe the (mostly-hard) speed limit of terminal velocity, 270000 distance units per tick. Since a tile is 50% higher than it is wide, that translates to a maximum free-fall speed of 1.8 zlevels/step. Both creatures and objects are subject to this limitation. It should take 56 steps and 52 z-levels to reach this speed. Presumably, a 200-z fall is no different in effect from an exact 52-z one, since the falling object's or creature's velocity will not increase past this point.

In general, falls of 1-2 z-levels are unlikely to cause significant damage to your dwarves, and goblins have been seen to fall more than four with only light bruising and stunning. Large falls (30+ z-levels) will tend to cause the hapless victim to explode upon impact. The minimum drop with 100% mortality appears to be around 25 z-levels.[http://www.bay12forums.com/smf/index.php?topic=110718.0|1]

On the other hand, falling items and creatures can cause grave injury to any creature they fall upon, even when falling a single z-level.{{bug|5945}} A falling [[giant cave spider]] web can easily break the neck of your master weaver, while [[wear|worn]] [[clothing]] is liable to maim or kill anyone below. Refuse dumping may therefore be [[Trap_design#Falling_debris_trap|weaponized]]. Just take care that your own dwarves do not mistakenly pummel one another with falling stones.

Farming

2016-03-27T20:35:37Z

Larix: farming always depended on the "BIOME" settings in the raws; it's more noticeable in .40.+, because it's not just the "NOT_FREEZING" token now.

{{Quality|Masterwork|23:04, 8 April 2015 (UTC)}}
{{av}}
[[Image:Df-crops-diagram.png|thumb|200px|General farming flowchart.]]

'''Farming''' is the act of growing [[crop|crops]] for [[food]], [[alcohol]] production and [[cloth]] manufacturing. While small forts can easily be sustained by plant gathering, [[hunting]] and trading, farming is vital to large settlements.

Farming is done at a '''farm plot''' building ({{k|b}}-{{k|p}}, resize with {{k|u}}{{k|m}}{{k|k}}{{k|h}}). Building uses no resources, and can only be done on soil or muddied rock. Mud-free stone will not allow the building of a farm plot on top. The "Farming (Fields)" [[labor]] must be enabled. Farm plots only display the kind of crops that they are able to grow when selected with the {{k|q}}uery key.

Depending on where the farm plot is constructed, different crops may be planted. Farm plots built [[above ground]] are not suitable for the crops grown on [[Tile_attributes | subterranean]] farm plots and vice versa. Note that the attributes {{DFtext|Inside|6:0:0}}, {{DFtext|Outside|3:0:1}} are of no relevance. You can grow surface plants indoors by channelling out the roof above the desired plot and then constructing a floor ({{k|b}}-{{k|C}}-{{k|f}}) over the open space. Doing this changes the tile from {{DFtext|Dark|0:0:1}} to {{DFtext|Light|6:0:1}}, despite there being a roof (you do '''not''' need to make the roof out of [[glass]] for this to work).

Note that although you can construct a farm plot anywhere there is either a soil floor or a mud covering, this does not always mean the seeds you have - especially imported ones - can be planted there. Not all crops can be grown in a given biome, and some biomes will prevent the planting of '''all''' above-ground crops.

The yellow warning message, {{DFtext|No mud/soil for farm, Mud is left by water|6:0:1}}, is displayed on all above-ground tiles, regardless of whether the farm will function.{{version|0.34.11}} This warning may be ignored. Tiles that actually lack mud or soil are excluded from the construction entirely with a red warning message (either {{DFtext|Blocked|4:0:1}} or {{DFtext|Needs soil or mud|4:0:1}}).

See the article on [[crop]]s for details on the conditions needed to grow the available plants.

== Introduction to Farming ==

First, build a farm plot "building" ({{k|b}}-{{k|p}}, resize with {{k|u}}{{k|m}}{{k|k}}{{k|h}}) on [[soil]] or [[irrigation|muddy]] rock. Keep your farms ''small'' -- 2x2 up to 4x4 or so. Farms are surprisingly productive. You can always make more farms later if you run low on plants, and having several small farms lets you diversify your crops. (Each farm plot can only grow one kind of plant per season.)

Once the farm plot has been built, you must select which crops to grow. Press {{k|q}} and move the cursor over the farm. You will see a list of crops you can select to grow in the local biome and current season. You can change which season is displayed by pressing {{k|a}},{{k|b}},{{k|c}}, or {{k|d}}. Move the blue selector up and down with {{k|-}} and {{k|+}}, and press {{k|Enter}} to choose a crop to plant during that season (highlighted in white). Crops displayed in red cannot be grown at the moment, either due to a lack of seeds, or a lack of growing days left before the crop goes out of season.

You must have the appropriate [[seed]]s to plant a crop on a plot. To easily see how many of each seed you have, you can go to the Kitchen menu ({{k|z}} {{k|right}} {{k|Enter}}).

Since your dwarves require food, booze and clothing, you should set up a combination of plants that will supply all of these. [[Plump helmet]]s are a good beginning crop for a first cave farm, and [[Strawberry|strawberries]] are a good choice for outdoor fields -- both can be eaten raw, or brewed. [[Pig tail]]s produce cloth, which will become important once your clothing starts to [[wear]]. Check the [[crop]]s page for details on different seeds.

Cooking plants destroys their seeds, so you should disable the cooking of plants in the Kitchen menu. Eating them, brewing them, or processing them through a farmer's workshop, quern or millstone will produce seeds.

Instructing a plot to remain fallow ({{k|z}}) during a particular season will tell dwarves not to plant in that plot during that season. Note that, unlike in real life, crop rotation is not necessary; soil productivity is only affected by fertilizing, and the same crop may be grown indefinitely without a decrease in performance, even without fertilizer.

=== Yield and Fertilization ===
{| class="wikitable" style="float:right; margin: 1em"
! Farm Size !! Potash !! Per Square
|-
| 1 || 1 || 1.000
|-
| 2 || 1 || 0.500
|-
| 3 || 1 || 0.333
|-
| 4 || 2 || 0.500
|-
| 5 || 2 || 0.400
|-
| 6 || 2 || 0.333
|-
| 7 || 2 || 0.286
|-
| 8 || 3 || 0.375
|-
| 11 || 3 || 0.272
|-
| 15 || 4 || 0.266
|-
| 19 || 5 || 0.263
|-
| 23 || 6 || 0.260
|-
| 27 || 7 || 0.259
|}
Each farm tile requires a single seed to be planted. Unfertilized farm tiles can produce a stack of 0-6 plants when harvested, depending upon the skill of the planter and random chance. Experimentally, fertilizing a farm plot boosts production by 1-3 additional plants per stack each harvest, though the exact mechanism is unknown. For unskilled planters, yield can be effectively doubled with the use of fertilizer. This can be particularly important early on, when your fortress's seed supply is limited, because those extra plants mean more seeds for planting next season. Many crops, like quarry bushes, are impossible to farm effectively in the beginning without fertilizer.

To fertilize a farm plot, one needs [[potash]], which is produced by processing [[ash]]. Each plot must be re-fertilized each season, and the fertilizer must be in place at the time the seeds reach maturity. It does not matter whether the plot is fertilized at the time of planting. {{cite forum|139382/5375231}}

Fertilizing a farm plot requires ''floor(plot_size / 4) + 1'' potash. The table on the right illustrates the efficiency of potash as a function of plot size. Generally, larger farms use less, approaching a limit of 1/4 bar per square. The worst yields per tile are multiples of 4; if one plants to optimize harvest yield, it's most efficient to have plots of size ''4n - 1'', where n is the number of potash used. Suitable sizes are 1x3, 1x7, 3x5, 3x9, 5x7, and 7x9. If one plans to optimize farmer experience, plots of size 2 or 4 can fertilized and seeded quickest, and experience can be distributed among more farmers. This ensures that if a bounty of crop is needed in the future, your farmers can yield more without potash, can plant and harvest quicker, and will have more time for other jobs in between.

Fertilizer may be applied to a plot by pressing {{k|f}} while viewing the plot. Only dwarves with the Farming (Fields) labor will apply fertilizer; this grants 30 XP of farming experience for each unit of potash used. Pressing {{k|s}} toggles seasonal fertilization. This does nothing until the next [[season]], at which time the plot will be automatically fertilized. Note that if you do not have a potash stockpile near your farm plots, your legendary farmers may spend all of their time hauling single bars of potash from all the way on the other side of your fortress, rather than growing food.

'''Potash Production Chain:'''
Wood [[Stockpile]] > Wood [[Furnace]] produces [[Ash]] (as [[bars]]) > [[Ashery]] produces [[potash]] (as [[bars]]).
Note: 5 bars are stored in a [[bin]]. An [[Ashery]] requires a [[block]], barrel, and bucket as components.

=== Subterranean Farming ===

To grow the six "dwarven" plants, you will need an underground farm plot. The seeds and spawn available to your dwarves at embark will only grow underground. Underground farm plots must be placed on soil or [[mud]]dy stone.

Muddying a stone floor requires temporarily covering it with water; common methods include a [[Irrigation#via_Buckets|bucket brigade]] or '''controlled''' [[flood]]ing (see: [[Irrigation]]) by temporarily diverting a river or pool, using a [[floodgate]] or [[door]] to stop the flow. You may also find a muddied area in a [[cavern]], but note that each tile underneath the farm plot must be muddied. Most caverns have entire open areas which will be permanently covered in mud, but if you dig into the walls of a cavern or chisel away a pillar, the freshly cut floor area will not be muddied until you get it wet. Underground caverns are dirty, and frequently contain [[Mud|piles of mud]] that are perfect for quickly setting up farms. However, given the wide variety of creatures found in caverns, you may want to take precautions. Consider keeping a [[squad]] close at hand to guard the farm, or walling off a muddied area for your dwarves' exclusive use.

Underground farming is not restricted to soil layers and caverns; underground floor of any material -- rough stone, smoothed stone, ore, gem -- can support subterranean farm plots once there is a layer of mud covering it. See [[irrigation]] for tips on getting the right amount of water to the farm plots.

=== Above Ground Farming ===
Farming of above ground crops is only possible on tiles that lie in a biome supporting their growth. Which crops are farmable depends on the biome - only plants "native" to a biome can actually be grown in a location: you cannot farm yams in a [[taiga]], or [[hemp]] in a [[tropical]] rainforest. There are also biomes where aboveground farming is entirely impossible, since no crops are native to them: these are the notoriously cold [[Glacier]] and [[Tundra]], but also all [[Mountain]] and [[Ocean]] [[biome]]s. The most widespread crops can be farmed in all land biomes with the exceptions mentioned above; this ubiquitous availability uses the internal reference NOT_FREEZING, but that label is somewhat misleading, since it's a [[Biome token|shorthand]] for a group of specific biomes and doesn't imply anything about the actual temperature - mountains and oceans are generally infertile, no matter what temperature range the embark screen lists, and a [[Taiga]] with "freezing" temperatures allows farming above ground plants.

Above ground farming is basically the same as underground farming, with the simplifying distinction that above ground plots typically do not require preparatory work. However, there are some complications.

The first complication is that seeds cannot be chosen at embark, as dwarven civilizations do not have access to those sort of plants. They can be bought from [[Elves|elven]] and [[human]] caravans; above-ground plants can be gathered using the [[Plant gathering]] designation, and then [[brewer|brewed]], [[miller|milled]], [[thresher|threshed]] or [[food|eaten]] directly (depending on the plant) to produce seeds.

The second complication is that the farming must be done on [[soil]] or muddied rock, which is [[above ground]]. Typically, it is done on the surface, which is dangerous (due to aggressive animals, ambushes and sieges). However, any land which has ever been exposed to sunlight becomes permanently marked as "above ground". So, if you have multiple Z-layers of soil, you can channel some above-ground land, remove the resulting ramps, then construct a floor above, where the surface once was. The (now inside and protected) lower soil will still be suitable for farming outdoor plants like [[strawberry|strawberries]], [[longland grass]], [[rope reed]], and anything else you may find. If your soil is not thick enough, you may still get a secure above ground farm by doing the same with any stone and muddying it. Alternatively, you may build a greenhouse by [[wall]]ing around some soil.

The various crops require particular environments to grow. On an embark which crosses multiple biomes, it's not unusual for aboveground farms in different biomes to have different lists of available crops.

Note that when creating an above ground plot, the interface may incorrectly display "No mud/soil for farm", even though mud is present. {{bug|249}} The message can be ignored.

== Farm plots in action ==

Once a farm plot has been built and crops have been selected for the current season, dwarves with the [[growing]] labor enabled will begin planting the selected seeds. One seed is used per tile. The higher a Dwarf's grower skill in planting, the more plants will be harvested from each seed planted. The farming labor is fairly low in priority, so if you want a full-time farmer, it is best to disable all other labors.

Plants take time to grow, depending on their type. Once a plant is fully grown, a dwarf will harvest it. By default, any dwarf will do this. Harvesting plants is not affected by any skill, although it provides a small amount of grower experience. So it's a good idea to set only your planters to harvest, not anyone. To do that, set option "Only Farmers Harvest" {{k|o}}{{k|h}}. This is useful only to train your planter faster; once they're skilled enough, everyone can be allowed to harvest again so the haulers can take care of half the farming work.

<div style="float:right">
{| style="border-spacing: 0"
|{{RT|≈|6:0}}||{{RT|`|0:1}}||{{RT|τ|6:1}}||{{RT|═|6:0}}||{{RT|≈|6:0}}
|-
|{{RT|≈|6:0}}||{{RT|≈|6:0}}||{{RT|τ|6:1}}||{{RT|═|6:0}}||{{RT|≈|6:0}}
|-
|{{RT|≈|6:0}}||{{RT|≈|6:0}}||{{RT|τ|6:1}}||{{RT|═|6:0}}||{{RT|≈|6:0}}
|-
|{{RT|≈|6:0}}||{{RT|τ|6:1}}||{{RT|═|6:0}}||{{RT|≈|6:0}}||{{RT|≈|6:0}}
|-
|{{RT|≈|6:0}}||{{RT|τ|6:1}}||{{RT|═|6:0}}||{{RT|≈|6:0}}||{{RT|≈|6:0}}
|}
</div>
In the farm plot shown on the right, {{Tile|≈|6:0}} indicates tiles awaiting planting, {{Tile|═|6:0}} indicates tiles that have been planted and are now growing, and {{Tile|τ|6:1}} indicates [[longland grass]] plants that are ready for harvesting.

If harvested plants are not moved to a stockpile in time, they will wither. These plants will eventually [[rot]] away. There's no use for withered plants. If, when the seasons change, the previous crop can not grow anymore, all immature plants will be destroyed yielding neither seed nor plant. If the farmers are "aware" of this limitation, they will automatically stop planting crops that haven't enough time to ripen, but you might lose a few seeds in your first year when growers of insufficient skill plant seeds too close to the cutoff.

Depending on the number of growers and their experience and the rate at which the plant grows, not all squares of large plots may be used.

Any farm plot that has both Above Ground and Subterranean tile attributes within the plot will only be partially planted, if at all. Verify using {{k|k}} over each square of the plot and remake as needed to follow the proper attributes.

== Management ==

Create a custom [[stockpile]] near your [[farm]] which only accepts [[seed]]s. This will consolidate your seeds into one place, instead of having them littered all through the [[dining room]]. As a single barrel can hold up to 10 seed [[bag]]s (each of which can hold 100 seeds of a specific type), and there is a maximum of 200 seeds of each type in the whole fortress, this stockpile need only be three or four tiles. (For DF2014 the theoretical maximum is 31 tiles for 200 seeds of each of 155 crops, but the actual maximum needed is much less because no fort will be situated in the right place to grow all of those. Four tiles gives enough space for 20 different crops.) Unfortunately, due to an outstanding bug, consolidating your seeds will increase the amount of planting job cancellation spam; see the [[#Bugs|Bugs]] section below for workarounds.

It may also be a good idea to set aside a few seeds from each type of crop and [[forbid]] them, as a seed bank in case of [[fun|fun times]].

You can also create a custom stockpile that will only accept [[plant]]s, to avoid having it all mixed up with your [[meat]] and [[drink]]s. It would be a good idea to have this stockpile near your [[still]], [[farmer's workshop]], [[kitchen]], etc. If you suffer from plump helmet overflow, create a plump-helmet-only stockpile, forbid plump helmets from all other food stockpiles, and let the crops in the field die if they can't be picked. It is worth noting that withering crops in the field do not produce miasma.

Use the [[stocks]] menu, and go to the Kitchen tab. From here you can see how many of each kind of food you have. If you're running out of a certain kind of seed, toggle the corresponding plant "Cook" setting to red. [[Cooking]] plants doesn't leave a seed. If you have too many of a certain kind of seed, or of plump helmet, as noted above, toggle the seed "Cook" setting to blue. Just make sure you check on the stocks and toggle it back before you run out, or use the seed bank idea above.

===Managing Seeds===
[[Seed]]s are used to grow [[crop]]s. You may begin the game with a certain number of seeds, [[trade]] for them, or [[plant gathering|gather]] them. In addition to this, eating, [[milling]] and [[brewing]] plants often yield a seed (assuming your fortress hasn't hit the seed cap for that plant). [[Cooking]] plants does not yield seeds, and cooking seeds makes them unusable for planting, so you may want to watch out and make sure you don't convert the last of your plants into +strawberry roast+ without the ability to make more.

You can create a custom [[stockpile]] near your [[farm]] which will only accept [[seed]]s. This will consolidate your seeds into one place, instead of having them littered all through the [[dining room]]. Seeds are stored in [[bag]]s (up to 100 seeds per bag), and seed bags can be stored in barrels. It is recommended not to use barrels on seeds stockpiles, however, since the hauling habits of the current version lead to barrels getting carted around to collect each and every loose seed, interrupting the planting work.

Each plant has a seed cap set at 200 (this value can be adjusted in [[d_init.txt]]). [[Brewing]], [[milling]], and [[food|eating]] raw plants will not generate additional seeds once the cap is reached, although you may still get additional seed bags via [[trading]] and thus exceed this limit. Once the count of seeds falls below 200, new seeds will again be generated.

There is also a fortress-wide total seed cap, initially set at 3000 (also configurable in [[d_init.txt]]). Once your fortress reaches this cap new seeds will still be generated, but the oldest seeds on the map will disappear. Unfortunately, this cap counts all seeds on the map, including those carried by traders {{bug|8108}}, and removes old seeds even if they have already been planted {{bug|8107}}. Finally, because the two caps behave differently, they can cause undesirable behavior when both are in operation {{bug|8091}}.

Seeds may be toggled for [[cooking]] on the Kitchen tab of the [[stocks]] menu. Disabling seed cooking will keep your seeds safe from starving dwarves. Although the item properties label them as EDIBLE_RAW, [[quarry bush|rock nuts]], like all other seeds, are ''not'' consumed as-is.

===Managing Crops===
When your [[crop]]s are ripe, your dwarves will harvest them from the farm plots. This will yield one or more [[stack]]s of [[plant]]s, which will be [[hauling|hauled]] to the appropriate [[stockpile]]. It is generally a good idea to have sufficient [[barrel]]s to hold the food, as [[food]] is subject to [[wear|withering]] and the predation of [[vermin]]. [[Metal]] barrels are especially effective against vermin.

You can create a custom stockpile that will only accept [[plant]]s, to avoid having it all mixed up with your [[meat]] and [[drink]]s. It would be a good idea to have this stockpile near your [[still]], [[farmer's workshop]], [[kitchen]], etc. You may also choose to make more specialized stockpiles, for instance if your [[windmill]] is located far away from your farms, you might have small nearby stockpiles dedicated solely to millable plants and [[flour]] so as to save on hauling.

The Kitchen tab on the [[stocks]] menu allows you to control which crops, if any, your dwarves will use as ingredients when cooking. Be careful when you are cultivating new crops or running low on others, and make sure you don't cook the last of them instead of recovering the valuable seeds. Note that experienced [[farmer]]s and crop [[fertilize|fertilization]] significantly increase the return on planted seeds, and can be quite useful when attempting to build your seed stockpile.

==Bugs==

* "Store item in container" jobs block access to items already in the container. This causes stored seeds to become unavailable, spamming job cancellations. {{bug|9004}}
** Workaround #1: set your seed stockpile to only take from links ({{k|a}}). When seed supplies run low, toggle it back to "anywhere" temporarily to gather up all the loose seeds.
** Workaround #2: disable barrels ({{k|E}}) in the seed stockpile. This means making the stockpile larger, as only one seed bag will be stored per tile. However, at 100 seeds per bag and with the 200 seed cap per seed type (cf. [[seed]]), this still only amounts to 12 tiles for a full underground-crop seed stockpile, assuming each seed type is only stored in 2 bags. Haulers will still lock a whole bag to gather individual seeds, but this is better than locking a whole barrel full of seed bags.
** Workaround #3: create two custom [[stockpile]]s which only accept [[seed]]s. Disable barrels in the first stockpile, and set it to give to the second stockpile. Set the second to only take from links.
** Workaround #4: disable seeds in all stockpiles and recruit a few extra farmers. No hauled seeds means no planting job cancellation spam.

* Fortress-wide seed cap counts seeds carried by traders {{bug|8108}}
* Fortress-wide seed cap removes seeds that have already been planted {{bug|8107}}
* Conflict between seed caps can cause all seeds for a crop to disappear {{bug|8091}}

{{Farming FAQ}}

== See also ==
* [[Irrigation]]
* [[Tile attributes]]
* [[Crops]]
* [[How large a farm do i need|How large a farm do I need?]]

{{Category|Buildings}}
{{Industry}}

Rush

2015-12-17T23:31:50Z

Larix: fixed link - "bulrush" is not a rush

{{Quality|Fine|14:51, 11 March 2011 (UTC)}}{{grasslookup/0|wiki=Juncus}}{{av}}

'''Rush''' is a type of grass that grows exclusively in temperate wetlands. It can have brown flowers.

{{gamedata}}
{{Plants}}

Instrument

2015-12-10T19:11:50Z

Larix: fixed typo "plectum"->plectrum, added frame, some more materials

{{Quality|Fine|01:53, 7 March 2015 (UTC)}}
{{av}}
{{old}}
An '''instrument''' {{Tile|¿|7:1}} is a new kind of procedurally generated good.

Instruments come in two types. Some instruments are built by individual components which must be assembled, and some are made in a single step, like how instruments were made in previous versions or like other craft goods. Instruments that are assembled can be further subdivided into "big" and "small". "Big" instruments can then be placed like [[furniture]] with {{k|b}}-{{k|I}} command. "Small" instruments can be carried around by dwarves or placed in [[coffer]]s in [[tavern]]s or [[temple]]s. Instruments made in a single step are always "small".

Instruments or their components are made out of a variety of materials, including [[wood]], [[bone]], [[stone]], [[silk]] [[thread]], [[plant fiber]] [[thread]], [[glass]], [[ceramic]]s, [[metal]], or [[leather]]. Out of those, [[thread]] can only used for Instrument parts, not for a full instrument. Most of instruments/components are made in [[craftsdwarf's workshop]]s, except [[ceramic]] ones are made at [[kiln]], [[leather]] ones at [[leather works]], [[glass]] ones at [[glass furnace]] and [[metal]] ones at [[metalsmith's forge]]. In the case of metal, there's currently no way to define what kind of metal is to be used; a dwarf will pick up the closest metal bar to make the component, unlike how other goods are made at the [[forge]]. Assembling the instrument after all the components are finished is also performed in craftsdwarf's workshops.

Types of instruments, their names and the kinds of components they are built of are generated at [[world generation]] and are usually specific for each [[civilization]]. Traders may bring instrument components, but your civilization may not be able to assemble the instrument out of them, depending on what instruments your dwarves know how to make.

==Components==
Below is a very incomplete table of what kind of parts can an instrument have and what materials they may require (please update)
{|class="wikitable sortable"
!Component name
!Materials
|-
|Bag
|Leather
|-
|Bellows
|Leather
|-
|Bells
|Wood, Stone, Metal, Glass
|-
|Block
|Wood, Glass
|-
|Blowpipe
|Wood, Metal
|-
|Body
|Wood, Ceramic, Glass, Stone, Metal
|-
|Bow
|Metal, Glass
|-
|Case
|Stone, Ceramic, Bone
|-
|Chest
|Wood
|-
|Chimes
|Bone
|-
|Console
|Bone
|-
|Drone pipes
|Metal, Glass
|-
|Drum
|Wood, Ceramic
|-
|Drums
|Wood, Bone
|-
|Frame
|Bone, Wood
|-
|Hammer
|Stone, Wood
|-
|Head
|Leather
|-
|Heads
|Leather
|-
|Keyboard
|Wood, Bone, Ceramic, Metal
|-
|Mallet
|Wood
|-
|Melody pipe
|Metal, Glass
|-
|Neck
|Ceramic, Metal, Glass, Wood
|-
|Pipes
|Ceramic
|-
|Plectrum
|Wood, Stone, Metal, Glass, Bone
|-
|Pump
|Ceramic
|-
|Sound-Chest
|Stone
|-
|Stand
|Wood, Stone, Bone, Ceramic, Metal
|-
|Sticks
|Wood, Ceramic, Glass
|-
|Strings
|Silk, Plant Thread, Metal
|-
|Triangles
|Metal
|-
|Yoke
|Bone
|}

User:Larix/MPL/3

2015-12-10T18:39:57Z

Larix: Style edit, destructive reading

'''Advanced circuits'''

As with other alternative logic disciplines, MPL is in many ways inferior to mechanical logic when it comes to the actual logic gates. Mechanical logic performs nearly instantaneously and requires little space. It's also a lot easier to run multiple mechanical operations off a single switch by running power through "master gears", while in MPL you have to individually connect every single device to every desired signal source. Mechanical logic, however, is not capable of generating signals by itself, of lasting data storage and incrementation ("counting") - the only "output" of mechanical logic is transfer of power and all states of mechanisms directly reflect the state of inputs, they cannot hold a "memory state" while input changes. Alternative logic types are required to generate and store signals. For counting, for repeating signals and to implement "memory", your options are fluids and minecarts, and MPL is an attractive choice here, because it's naturally liquid-less and can be implemented without use of power.

This is only a selection of MPL circuits i've built. They're mostly custom-made on the spot when i had the need for a circuit to perform a specific operation. Once again, they were practically applied, these are ''not'' theoretical "this should work because the logic is sound" circuits, i even built and tested the straight Set/Reset latch which could not conceivably fail. I've had too many cases of the inconceivable happening with minecarts.

===Counter===

[[File:Zählwerk mit Bauten.png]]

For speed regulation and cart management, there are a bump wall and bunker pit to the east. The operational unit is the angled three-pit ramp in the middle. The ramps are engraved with track like this:

║
=╠

When the hatch cover is open, a cart coming from the west will pass through to the east, one from the north will pass through to the south. If the hatch cover is closed, a cart coming either from the west or from the north will exit to the north. Thus, the procession of operation when counting is:

1. cart enters the circuit on the outer ring, entering the three-ramp pit from the west.

2. as long as the hatch cover remains open, the cart will pass the ramp West->East, gets regulated by the bunker pit and remains circling around the outer ring.

3. once the hatch cover closes, the cart is diverted to the north and starts bouncing between the bump wall and the closed hatch cover.

4. once the hatch cover opens again, the cart passes through the pit to the south and leaves the counter circuit, e.g. entering the next one in the line.

A series of such counters, arranged in a circle, can be operated from a single input signal connected to all hatch covers and will thus count how often this input has cycled. The reaction time to a changed signal is fairly long, up to 50 steps, so the input shouldn't cycle too quickly, or signals will get missed.

It is easy enough to glue two of these counters together and have a pressure plate on the connecting track, so it sends a signal of its own after every second advancement. This is in effect a binary counter, and combining several of these allows to perform binary counting.

===Luxury one-bit memory/counter===

[[File:Rechner-Speicher-Zelle.png]]

This is a binary counter cell which can add and subtract, and can also be set to one or zero. In the adder/subtractor design i came up with, the "memory" is the part which performs the actual calculations, directed by signals sent from another circuit "reading" the input. All carry calculations are done in the counter/result memory itself and additions are performed from highest to lowest bit.

The device consists of two counters, linked through a northern and a southern loop. When the central hatch cover in the cart's current half of the cell opens, it passes through the loop to the other half. If the hatch in the pit on the loop is open, the cart passes through without further effects, if the hatch is closed, the cart is sent on the "inner" branch of the switchover loop and touches a pressure plate which sends the carry (south sends negative/subtractive, north sends positive/additive carries) to the next higher bit. If both operative hatches are opened, the memory cell's status will change to the opposite; depending on further hatches opened or not, this may generate carries and work as addition or subtraction. If only one operative hatch is opened, together with the hatch in the resultant switchover loop, the cell's value is "set" to a specific value - if the cart was already on the desired side of the cell, nothing changes, obviously.

The full installation shown here makes for a ''very'' component-expensive bit of memory. Its benefit is that it allows a lot of operations on the memory directly. I built cells of this type taking four different input configurations allowing it to run addition, subtraction, "write" (i.e. setting the memory to a desired value) and bitwise XOR (addition without carry). The memory itself produces a permanently "held" ''on'' signal as output, deriving independent ''on-off'' cycles would need extra "converter" units or destructive reading. In my four-function application, one bit took four hatch covers, three pressure plates and seventeen linkages, not even counting the input regulator and any possibly more complicated output machinery, for a cool 37+ mechanisms ''per bit''. Its multi-purpose functionality makes it an interesting option for a "result" or "arithmetic" register, much less so for a plain memory bank that's only supposed to store and not directly manipulate data.

===Bridge Repeater===

[[File:Brückentakter.png]]

A curiosity, a powerless repeater sending a signal every ~205 steps which can be used to operate a constantly opening and closing bridge. The only operational pit is the one to the north, a looped-ramp pit (ramps SW and NW) with the northern ramp covered with a hatch cover linked to the output plate. As long as the hatch cover is open, the cart will cycle through the pit and the flat half-circle directly west of it. Once the hatch closes - one hundred steps after the cart went over the pressure plate - the cart will pass over the hatch, bump into the wall and move incredibly slowly to the south, fall into the bunker pit, leave at a slightly more sustainable speed and touch the plate again.

===Double-action switch===

[[File:Kippschalter.png]]

An "edge detector" or, more simply put, a device to convert lever pulls into single on-and-off signal cycles. The cart starts out on the hatch to the west, over the eastern ramp of a bunker pit. Once the input signal turns on, both hatches open, the cart falls into the pit, cannot leave to the west and thus leaves to the east, across the pressure plate and starts circling through the loop to the east until the hatches close again, when the cart will return from the pit to the north, pass the pressure plate again and bump against the wall to the west, coming to rest on the starting hatch cover again.

===Auto-derailer===

[[File:Und-Gatter ohne.png]]

A device i used quite a lot in my first designs. The ramps are engraved with NW and SW track. The cart will cycle through the array, generally emerging on the northern track tile, cycling around to the south and entering the ramp again. It will keep accelerating until it becomes fast enough to derail. If there is open track to the north of the northern ramp on the level below, the cart will leave the array to the north at this point. Depending on the starting conditions, the cart can take anywhere from ten to 350 steps before leaving the derailer. If the cart is kept in the derailer, e.g. by blocking the exit path with a door, the cart will not accelerate notably beyond the original derail speed, it will just be kept within the array at derail-capable speed.

The main interest in the basic circuit is that it can be used to introduce a significant delay into a circuit, without moving parts and with very low space consumption.

===Clock-capable repeaters===

[[File:UhrwerkBremsen.png]]

The visible ramp openings belong to looped pits, engraved SE-SW on the southern branch, NW-NE on the northern branch, with the second pit covered by the straight track leading out of the niches. The track stops on the exit points have high friction, the track stop just south of the northeastern ramp has low friction, all others medium friction. The return time is exactly 300 steps, 1/4 of a DF day. Collecting a single signal and plugging it into a four-step counter will give a full day.

[[File:DieUhr1.png]]

These are actually four repeaters, three of which are used to run a precise clock. Each repeater consists of two derailers, coupled like this below:

[[File:DieUhr2.png]]

There's a medium-friction track stop on each connection track, the final tile, under the pressure plate, is a corner sending the cart onto the "backwards" ramp of the partnered derailer. This results in the cart being so fast on entry that it derails over the ramp pit, slams into the wall and falls down onto the "forward" ramp. This greatly increases the time required to build up to derail speed, giving a full return time of 720 steps for each repeater. I started three of these repeaters 240 steps apart, so every 240 steps one "full round" signal is received and can be counted, five of them add up to a full day.

{{Diagram|spaces=yes|\
.
^╗ ╔╗
║▲# ║╚#
#▲╝║▲# #╗╝║╔#
#▲══▲# #═║║═#
#▲║╔▲# #╝║╔╚#
#▲║ #╗║
╚╝ ╚╝

Buildings Track

}}

A clock-capable repeater with a period of 600 steps - half a day. In the two "combs" of three ramps each on the eastern and western side, the cart bounces between the two border ramps and is displaced by 1/29th of a ramp's width everytime it passes the middle tile. After 29 passages (about 290 steps), it is displaced far enough to make it off the comb and into the switchover loop. All ramps are impulse ramps - the bordering ramps mustn't offer exits to above or the cart will just climb the ramps and disappear onto the level above.

===Memory===

Minecarts can be held in a loop or on a straight rail just going back and forth by hatches and other buildings. By combining "data" and "enable" or "reset" buildings on the same circuit, all with their own links, this can be used to store data in an adressable form.

1. Basic Set/Re-set latch

{{diagram|spaces=yes|\
.
# # # #
▼ ║ ▼ ▼
▼ ║ ¢s ¢s
║ # ║ ┼e
▼ ║ ¢r ¢r
▼ ║ ▼ ▼
║ # ^ ^
▲ ▲ ▲
# # #
1 2 3 4
.
}}

1 Track/ramps

2 engraved track on the ramps in the pits

3 buildings

4 space-saving expansion using a door to "e"nable the cell, designed by Nil Eyeglazed/VasilN.

In the "off" state, the cart remains in the northern ramp-pit, because its exit is blocked by the closed hatch to the south.

If a "set" signal is received (and in the expansion, if the "enable" door is opened as well), the cart leaves the northern pit, jumps across the southern pit, bumps into the wall, gets reflected by the ramp and settles into the southern pit, bouncing between the hatch cover blocking exit to the north and the ramp above to the south, keeping the pressure plate activated. Further "set" signals will not do anything.

If a "reset" signal arrives (once again, only respected if "enable" is also set in the expansion), the cart leaves the southern half of the array, travels north and settles into the northern pit, letting the pressure plate reset and thus dropping the saved bit. Additional reset signals, once again, will not change the memory state.

As usual in Set/Reset-latches, a currently-on cell will not react to changes of the "set" signal and vice versa; the memory cell will hold the saved state indefinitely if both inputs remain off and it will produce an erroneous output (false "on" in this case) if both signals are on simultaneously.

The possibility to "adress" this memory can be realised in different ways and a further non-destructive "read-out" producing a signal cycle instead of the constantly-held "on" can be provided just by adding another pit to the south. It is a very compact design and can be packed extremely tightly: with an extra read-out, it comes to a length of eleven tiles, while it's two z-levels high and a single tile wide. Neighbouring memory cells can share a wall tile, so each past the first will only take ten tiles of added length. Materials required come to one door and three hatch covers with four linkages among them for input and at least one pressure plate and one linkage for output - four furniture and eleven mechanisms.

2. Adding dedicated "read" branches

{{diagram|spaces=yes|\
.
# #
▲ ▲
^ ║
¢o- ▼
▼ ▼
║ ║
▼ ▼
¢s ▼
┼e ║
¢r ▼
▼ ▼
║ ║
▼ ▼
¢o+ ▼
^ ║
▲ ▲
# #

}}

I implemented the main memory of my dwarven computer with this type of memory cell. It can be set (via the "s" hatch) or reset (via "r") as long as the cell is selected ("e"nabled). It will not normally produce any output unless specifically requested by opening the "o"utput hatches. For reasons of functionality, it has two output hatches and pressure plates and can thus generate separate output signals depending on whether the cell is currently in set or reset state.

A major downside of this design is the duration of the output signals: the cart will start activating the pressure plate shortly after the hatch opens and will keep passing over the plate until the hatch closes again, after about 100 steps. Only 100 steps after the cart last touched the plate will the plate reset and send its off signal. The result is a signal remanence of about 200 steps. Such delays can easily stack up in cascaded logical processes, jeopardising the practicality of usage through excessively long signals.

3. Short-pulse memory cells

{{diagram|spaces=yes|\

# # # # #
# ║ # # ║
a¢ ║ a¢ a¢ ║
c+ ║ b┼ b┼ ║
b¢ ║ c¢ c¢ ║
╔▼ ╔║ ▼ ▼══╗ ║══╗
║+d ║║ ║ d┼ ║╝ ║ ║╝
║^ ║║ ▼ ^▲▲▲ ╚╔║╗
▼╗ ║╗ d¢ ### ###
e¢▲# ╚║# ^ III.a III.b
## ## ▼
I.a I.b ☺
eG
#
#
II.

}}

To adress the concerns pointed out above, i developed a few memory cell designs that will only send one short-term signal pulse. To achieve this, the cart must be delayed until the output request has timed out and then sent back to its memory holding location on a path that bypasses the pressure plate.

Key for all cells:
a - set
b - reset
c - enable

d - request for an output
e - building that moderates the delay for returning the cart

I.: building-moderated delay, lateral bypass

d & e are activated by the read signal: the door lets a "set" cart out of its pit. It passes over the pressure plate ''once'' and then cycles through the four-tile circle in the very south; the cart must come in at the correct speed for the orbit to properly establish and remain stable. Once hatch e closes again, the cart leaves straight to the north (instead of SE while circling) and returns to the "set" pit.

II.: building-moderated, vertical bypass

Instead of keeping the cart in motion until the read signal turns off, this design makes use of the different delays for different buildings. In the south, there's a floor grate over a bunker pit. When a read is performed, an "on" cart leaves its pit to the south, touches the pressure plate and comes to rest on the grate. The grate takes 100 steps to open. At this point, the cart drops into the pit, picks up speed and leaves to the north. Immediately north of the grate, it passes over a tile of ordinary floor (here engraved with a friendly face) before facing a pit. Since it comes from normal floor, the cart ignores the pit (has no downward connection and wouldn't change the cart's speed in any way) and jumps instead. The jump is far enough that the cart passes over the pressure plate north of the pit without touching it. The assumption is that by this time the actual read signal has timed out again and the read hatch is already closed, keeping the cart constrained in the holding pit.

III.: path-moderated, lateral bypass

Of course, we can also give a cart enough path that it takes 100+ steps to return to the holding pit (assuming the read request is produced by a short-term signal that shuts the requesting building after about 100 steps). It uses the same "ramp comb" as the third model of a clock repeater. The sole difference is that the corner at the entrance to the array ensures that the cart enters it in the middle of the tile, so that it takes only 15 passes over the central displacement ramp to exit the array, giving a total return delay of about 160 steps.

All designs have been tested and work. They're all notably bigger and clunkier than the simple straight designs shown above and are only worth the effort when the well-regulated short output signal is desired.

''If'' timing is crucial, these and similar approaches become mandatory, since they limit the necessary "cooldown" time until the next signal can be processed to significantly under 200 steps, while especially in long cascading approaches the above "cumulative remanence" designs can quickly escalate out of control.

Similar and better timing for reading stored information is possible with fluid-mechanical logic, at the price of power consumption.

4. One-building toggle memory cell

{{Diagram|spaces=yes|\
.
###
╔▲▲▲
║ ║╗
║ ╔╝
╔══┼▼▼^▲#
#▲ ▼
#▲═╔▼
#▲╚╝#
}}

The cart's in one of the double-ramp pits when the door is closed. Whenever the door opens, the cart leaves its pit, goes through a ramp comb starting in the middle of the tile and enters the other double-ramp pit of the array after ~160 steps. As long as the door is opened by short-duration signals, the cart will properly settle into the opposite state after each signal received.

===Mini-Excursus: Material costs of memory===

For me, the crux of building advanced logic machines is the extreme cost of memory.

The memory designs seen here range from two hatches and one pressure plate for the non-enabled S/R latch (five mechanisms not counting output links) to seven buildings (with fourteen mechanisms for links) and two pressure plates for an enabled cell with bidirectional outputs and hatch-moderated holding/lateral bypass. As an even more extreme case, the big complicated count-capable memory cell at the start clocks in at over thirty mechanisms.

Looking at other designs, fluid-logic data latches can be operated with a single door for enabling and a large shared bridge as data input (serving up to twelve cells). Actually reading the cells tends to become a bit complicated but can be done at lowish mechanism cost if rather slowly through destructive reading (set a cell to a given state and test if output ''changes''). Cost per bit stored in a full installation would be just under six mechanisms and one door. Similar designs are possible with MPL, although they are slightly costlier in mechanisms and space and are somewhat slower.

The "cart placement" memory cells developed by Bloodbeard and tinypirate come at costs of ten to fifteen mechanisms per bit, depending on the functionality included in the cell. They'd also require either a very costly big reading array or destructive reads.

All these reasonably write-able memory cells have a common theme - each takes several mechanisms and usually a few buildings to implement. A reasonably convenient and quick cell can't be had for less than ten mechanisms. Considering each mechanism takes one rock and a fair bit of time to make and installing/linking takes a fair amount of time and attention, it should be easy to see that memory is a serious limitation for dwarven computers. Even a modest kilobyte can easily take 100.000 mechanisms (more than the biggest machine on record that ever got finished), and you can't really do much computing with that little memory.

With my concept of storing information purely in minecart weights and evaluating sets of carts selectively i managed to circumvent the problem to a degree: with eight different weight groups of carts, each cart can hold three bits of information, and reading can be grouped - you only read one set of carts at a time, while several other sets are kept in readiness. Consequently, i managed to build a memory array holding 768 bits of information at a cost of under 500 mechanisms. The downside is that this kind of memory would be extremely laborious and slow to write to, i never considered using it as anything other than a ROM. At three bits per cart, it also took over 200 minecarts to fill. A full kilobyte implemented like this may cost "only" 2000-3000 mechanisms, but it would also require about 2500 minecarts, each individually selected, placed and put in motion.

===Appendix: Destructive Reading===

If our memory cell has a constantly-active output, we're in trouble when we want to reference only one of several cells for use by another device. Transmitting the "state" of one of several cells to a receiver can be done by AND gates, e.g. mechanically:

{{Diagram|spaces=yes|\
.
Power in
║
┤┤┤┤┤┤ "distributor" roller
☼☼☼☼☼☼ state 1-6
☼☼☼☼☼☼ select 1-6
┤┤┤┤┤┤ "collector" roller
║
Power out
}}

Each "state" gear assembly is linked to the output of a memory cell.
Each "select" gear assembly is linked to a "read selector".
Power will come out (and activate whatever we've placed to the south) when both the state and the select gear of (at least) one cell are active at the same time. Having the gears next to each other doesn't pose a problem, since power only passes gears in cardinal directions; power can only get to a select gear - and through it to the collection roller and output - if the state gear of the very same cell is engaged.

Clearly, this method works, but it requires a fair number of mechanisms installed and dissipates quite a bit of power.

But we can reduce the architecture cost by reading the cells destructively. "Destructive read" means that we ''change the state of the memory cell'' and observe whether the output changes or stays the same. If the output changes, the cell was previously in the opposite state, if not, it was already in the "written" state. I've come up with two basic premises:

A - output to door or hatch, relevant is the last signal received, requiring flipping.

Under this premise, we link ''all'' the outputs we wish to collect to a single piece of furniture, preferably a door or hatch cover. In DF switching, furniture always takes on the state of the ''last valid signal'' it received. So if a door is linked to ten different memory cells, it doesn't matter if one or nine of the cells are in "on" state, it only matters if the last change in memory cells was from "off" to "on" or vice versa. To read a memory cell in this way, we
* first send a signal cycle to the door ("on" signal, followed normally by "off"), shutting it.
* send a "write" signal to the memory cell we wish to test, setting it to a specific value, either "on" or "off". The cell must have an output plate that goes active in the position we're setting the cell to in the read operation. I.e. if we read by turning the cell off, we must have an output plate that's active when the cell's off.
-> If the cell changes state, the door opens. If the cell stays in the same state, the door remains shut.
* now we test the shut/open state of the door with a logic device, e.g. by running a minecart so that it tries to pass, activating/deactivating the actual output.

The cost of this reading array consists of the door, its linkages, the testing mechanism for the door itself and a simple circuit to flip the door shut. We need no extra machinery for the destructive read itself - that's done by the same mechanism that's used for normally setting the cell to zero.

B - output to gear assembly, test via edge detector.

Gearboxes toggle their state whenever they receive a signal, no matter which kind. Thus, a gear assembly operates as a parity gate. Here, it doesn't matter what kind of signal was last received, it only matters if the ''total'' number of signals received since the gear was constructed is even or odd. We can simply link all our outputs to a single gear assembly, but of course, whether this assembly is deactivated or activated depends on how many memory cells in total are on or off. When we want to read a cell, we still just set it to a given state, but now we only know that the gear assembly's state ''will change if the memory cell's state changes''. We cannot know whether it'll engage or disengage. Thus, we need something that only gives output upon state changes (a.k.a. an edge detector). Fortunately, that's pretty simple with minecart-actuated mechanical logic:

{{Diagram|spaces=yes|\
.
# #
┬┴ ▲
^┴☼ ║
┬┴ ║
# #
.
}}

To the left, the buildings. There are two rollers, both pushing to the north; one on the southern end, one on the northern end of the track. The northern tile is a track ramp with NS track. Power goes through the switched gear, distributed by a three-tile NS roller (push direction irrelevant, only used to provide power and hold up the roller on the ramp).

When power is provided, a minecart on the track will remain on the ramp, held at its "top" by the roller. When power turns off, the cart rolls off the ramp, across the central tile and comes to rest on top of the southern roller, against the wall. When power turns on again, the cart crosses the central tile once more and gets dragged "up" the ramp by the northern roller.

The result is indeed that this device produces no output in a stable "on" or "off" state, but does produce one signal cycle (on followed ~100 steps later by an off) everytime power supply changes. And since power supply changes everytime the gear assembly toggles, that produces our output. Evidently, this thing not only produces a signal cycle during reading, but when writing as well. We need further machinery to make sure the output is only processed when we actually want to read something. Still, the main cost of this reading mechanism is again the single gear assembly and its links. We don't need to "flip" our gear like a door before reading, making the reading process much faster. Once again, the reading itself is done by the normal mechanism that writes the reference state to the memory cell.

Two final notes:

Destructive reads, as the name implies, destroy the memory state they read. We can restore the cell's state from the output generated, if we so desire, but that means extra effort.

Destructive reading allows relatively cheaper largish memory, but it still only reduces the cost per-bit from about a dozen to at best six mechanisms.

User:Larix/MPL/7

2015-12-04T00:34:54Z

Larix: /* Designs */ opulent memory cell

At long last, i explored the potential of switching high-speed minecarts' path via doors and found that this doctrine offers very attractive options for core operations like decoding and arithmetics, requiring very few mechanisms, no power and only a single minecart per function, while the high operation speeds mean the "linear" evaluations still execute at impressively high speeds.

== The atom of cart+door-logic: the door switch ==

As noted in the article on minecarts, paths of high-speed minecarts can be switched by offering them a track corner backed by a door or other switchable building. If the building is closed, the cart takes the corner. If the building is open, the cart's speed carries it over the corner and through the opening:

{{diagram|spaces=yes|\
->══╗D->1
║
v
0
}}

Note: in all diagrams, ''some'' track should be engraved under installed doors. The exact configuration is irrelevant (gets ignored at those speeds anyway), but i've seen a case or two where plain floor underneath the doors seemed to cause misfunctions.

The cart must move at speeds in excess of 50.000 to actually switch, slower carts will follow the corner in every case.

A fast cart can derail over a corner if there's no blocking building behind it. If the door ''D'' is open (input signal is on/1), the cart continues in a straight line. If the door is closed (input signal off/0), the straight path is blocked and the cart takes the corner.

== Benefits and drawbacks ==

The advantages of this door switch are:

* takes no power to operate, only signals
* the "gate" reacts instantly to changing input when a door is used for switching
* evaluation time is very short: a cart passes through the array in less than five steps and both "on" and "off" output are reached at nearly the same time.

The disadvantages are:
* depending on layout, a cart could end up in the door jamb while the door tries to close. This results in the door staying wedged open. Proper timing of input acquisition vs. evaluation can completely avoid this.
* overall space consumption per gate is pretty large, because most paths require walls to keep carts contained
* speeds well in excess of what rollers can do are required for operation. That's fortunately easy enough to solve via impulse ramps. Of coure, due to the high operation speeds, dwarfs should be kept out of active circuits.
* high speeds can make picking up the resulting outputs difficult: very fast carts can skip past output pressure plates without touching them. This can be solved by using the checkpoint effect.

== Designs ==

What makes Cart and Door Logic (CDL from here on) so interesting is that it can't just switch a cart coming from one input direction to one of two output paths. It can also switch carts coming from one of two possible ''input'' directions to one of four possible outputs:

{{diagram|spaces=yes|\
I1
║
╚═ O1'
I2═╗D═ O2
║║
O2'O1
}}

The cart comes from one of the two input directions I1 and I2. If the door D is open, the cart passes through in a straight line and leaves on path O1 or O2. If the door is shut, the cart is diverted and takes the path O1' or O2'.

This fully granular splitting of the inputs to individual outputs means ''any'' binary logic gate can be built with two linked doors. Notably, an XOR gate built only from doors will look like this:

{{diagram|spaces=yes|\
╚═╗#
A#╚╗#
╚╗B╚═NXOR
#╚╗#
#║
XOR
}}

With the same position of doors, any other logic-gate function can be derived, it only takes different pathing on the output side behind the doors.

Making use of the full spread, decoding of a multi-bit input to single outputs - e.g. when choosing a function specified by an encoded command or addressing a memory location - can be done at relatively low cost in mechanisms and furniture, while offering a fairly short runtime of three to five steps per "gate"/bit consulted.

As a very attractive option, this doctrine can be used to make a powerless full adder with short runtime and very low mechanism count:

{{diagram|spaces=yes|\
╚═╗#
A#╚═╗#
╚╗B1╚╗#
#╚╗##╚═╗#
#╚═╗C2╚S'
# ╚╗##
#S
}}

Inputs A and B are evaluated. If both are on, a carry is produced (1) and sent to the next adder cell. After the "generated" carry has been tested for, the "equal" (northeastern branch) and "inequal" (southwestern branch) results for the A/B comparison are collected and checked from both sides against the carry-in ''C''. If A and B are equal while C is on, or if A and B are inequal and C is off, a sum is generated (S). If A and B are inequal and C is on, a "propagated" carry (2) is sent to the next adder cell. If the sum is not generated, a "non-sum" output can be read at S', e.g. to actively clear a bit at the register to which the result is written.

While this is a ripple-carry adder, the evaluation proceeds at less than ten steps per added bit. If the starting speed is at the limit of what's reachable by ramps, a twelve-bit addition takes less than 100 steps for the evaluation.

What i find particularly interesting about this adder is that it does the complete addition with three switchable doors per bit. Doors A and B are only linked to their input(s), door C is generally linked twice, to both the generated and propagated carry plates of the previous bit. Depending on the design of the components the adder outputs to, a single sum plate per bit could be sufficient, depending on the memory architecture used.

=== Memory ===

Memory cells can of course be built in CDL, and while they tend to take up a lot of space, they react extremely quickly and can be run with very low tolerances. A data-type memory cell with extended functionality can be built like this:

{{Diagram|spaces=yes|\
.
# #
#╔╗ #╔╗
#▲║ #╗║
## #▲║ ## #╗║
#╔▲╗ #▲║ #╔╝╗ #╗║
#^▲r╔═══╗╚╝# #╔╗╬╔═══╗╚╝#
▲#╔╚▲▲▲╝e╝d# ╔#╔╚╔╔╔╝╚╝╗#
▲#▲####║# ║ ╔#╚####║# ║
╚═╝# #╚══╝ ╚═╝# #╚══╝
# # # #
buildings and track
(impulse) ramps
.
}}

All absolurely required walls are displayed, although more walls may be desirable to keep citizens out of the circuit.

In normal "dormant" state (all doors shut), the cart circulates counter-clockwise either in the northern or the central loop, constantly accelerated and thus held at very high speed by a line of three impulse ramps. When the "e"nable door opens, the cart leaves its loop and tests the state of the "d"ata door by approaching it from the west. When this door is closed, the cart is diverted to the north, into the "off" holding loop. When the data door is open, the cart passes through its tile and passes through the southern branch and to the central "on" holding loop. The cart will keep going through the test cycle until the enable door closes again. As an important note, the enable door ''must'' turn off before the data door returns to its default state or the cell may settle into an erroneous state.

When the "r"ead door in the west opens while the cart is in the "on" loop, the cart will leave this loop, touch the pressure plate ''once'' and then keeps circulating in the westmost loop until the read door closes again. At this point it will return to the normal holding loop in the centre. The cart is guaranteed to touch the pressure plate upon entering the loop because it moves from a ramp to the flat corner with the plate - making this tile a checkpoint and thus guaranteeing the presence of the cart in the tile. In all subsequent passes, the cart will be moving at significantly more than one tile per step and goes through the longer loop. Now, the tile just north of the plate is a checkpoint and due to the high movement speed, the cart is guaranteed ''not'' to touch the plate - it simply skips past the entire tile, always.

The cell reacts to read and to write signals with a delay of less than ten steps and outputs a minimal-length signal cycle upon receiving a "read" request. All that for the cost of three mechanism-operated doors, the absolute minimum possible for this functionality. The main downside is the great space consumption of close to fifty tiles floor space. And it probably can't be packed tighter than 80-90 tiles per cell, offering around 200 bits of memory per entire z-level on a 3x3 embark (vs. 2000 with water or mechanical-minecart memory cells).

Another significant disadvantage is that it's based on switching of doors, which is extremely FPS-hungry: everytime a door opens or closes via mechanisms, the entire connectivity map for the entire embark must be re-built. When many doors keep opening and closing in short order, the game gets awfully choppy.

=== Afterthoughts ===

1. I've sketched a few more designs; incrementation, derivation of the binary complement and comparison should be quite feasible in CDL - fast and with few mechanisms. Using weight-calibrated pressure plates and providing different-weight evaluation carts could offer deriving very different functions from the same overall device: the adder should be able to also do bitwise AND and bitwise XOR without changing anything in the switching and output logic, merely by picking different carts to run the course. Input selection would also allow doing direct copy from source to target and bitwise OR.

2. To provide carts with sufficient speed for proper and fast evaluation, a simple impulse-ramp circuit is recommended:

{{diagram|spaces=yes|\
# #
#╔╗R #╔╗
#▲║ #╗║
#▲║ #╗║
#▲║ #╗║
#╚╝# #╚╝#
#D #║
}}

D: door opened to start an evaluation/operation run. R: return path feeding the cart back into the holding coil. Carts should only return once D is shut again, or you get multiple runs.

Just enough ramps in a row that there's a full step of acceleration on every cycle. The cycle takes a while to rev up to full speed, but once it's at full speed, it holds that speed for an indefinite time, responds to opening of the door in at most five steps and the speed loss in my twelve-bit adder was compensated in short order.

3. Carts in these circuits should preferably move at speeds well in excess of one tile per step. Making sure that a cart actually touches an output pressure plate cannot be guaranteed by spacing - which tiles are actually visited depends on distances travelled and speed (largely influenced by the number of turns a cart takes, which varies). However, the checkpoint effect can be used: when moving ''off'' a ramp to a different tile, a cart will ''always'' touch the tile past the ramp and spend exactly one step there, regardless of speed. I put an impulse ramp before every pressure plate in the adder, which increases space and time consumption a bit, but there's no reliable alternative. The under 100 steps for a twelve-bit addition include that regulation cost.

4. It should be evident that a door can bifurcate as many input paths as it has "faces", i.e. four (five if going very crazy and including carts dropped from above). I've designed a layout for a three-in-six-out switch that can reduce door/mechanism count in large decoders another notch. I've built and tested a sample four-bit decoder using a total of seven doors for the decoding work: on the fourth bit, where eight paths must be forked into sixteen, runs through three doors, two three in/six out, one two in/four out. The three-to-six split looks like this:

{{diagram|spaces=yes|\
. A B C
║ ║ ║
║ ╚═╬══╗#
#╔╚╗D╔╝╗#║#
#║#║║║#║#║#
C aBc A b
}}

D is the ''single'' door switching the three input lines A, B, C to the output lines A/B/C when the door is open, a/b/c when shut. The main downside of this switch logic is evidently that accounting for the various decoding results is messy because results are all over the place. Probably worth it when looking at machinery costs (~one door and link per 2-3 outputs produced, no power) and speed (read-trigger-to-decoded-output of 10-15 steps, can decode once every 140 steps).

Four-in-eight-out switches are possible but ludicrously large.

As per usual, all circuits presented here have been built and tested. They are only presented in diagram form because i find it easier to explain their function this way (and don't want to spam the site with even more screenshots).

== Link ==

Video of the twelve-bit full adder:
http://mkv25.net/dfma/movie-2716-powerlessminecartadder

User:Larix/MPL/6

2015-12-03T23:42:17Z

Larix: /* Basic operations */ another option for basic gates

== Excursus: signalless logic ==

Machinery in Dwarf Fortress is commonly controlled by levers or pressure plates, constructions which send signals. Dwarven computers commonly use signal input and signal processing to produce an output, which also commonly consist of signals or directly signal-controlled events like raising and retracting spikes or opening/closing doors to the magmaduct.

When playing around with minecart logic, i wondered whether there might be other options, though: after all, a wooden cart smacking into an aluminium cart results in much less outgoing speed than a copper cart propelling the aluminium cart. In addition, the "pushing" cart will not stop in the place formerly occupied by the pushed cart, but rather in the adjacent tile - and it will not stop if it encounters no cart to push. Based on those ideas, i experimented with a logic paradigm using nothing but minecart collisions as decisive interactions, needing no signals to work at all.

I've only produced some very basic proofs of concept to show that such logic has the ''potential'' to be used in computation. Building any machines emulating classic logic gates and computer components would probably be a fool's errand, the basic interactions simply don't fit those paradigms and quickly result in phantasmagoric monstrosities in construction.

=== Basic operations ===

I'm only going to show collisions between one moving and one standing minecart. Those are easy enough to understand and work with.

{{diagram|spaces=yes|\
.
[#000][#0f0]■═══[#000][#ff0]■═ before
.
═══[#000][#0f0]■═[#000][#ff0]■ after
.
}}

The green cart comes from the left, pushes the yellow cart and stops while the yellow cart moves on. This is in fact '''the''' basic outcome of a minecart collision. We can run a series of minecarts over this track and eventually, the stationary cart will occupy the start of the track. Effectively, we could count down like this, but nothing of interest would happen if we reached zero.

Having just another new stationary cart is rarely of interest, but we can change the architecture so that an incoming cart encountering a stationary cart in its way will ''not'' stop in the adjacent square - because that square itself forces the minecart to move. This means letting the arriving cart move over an upward ramp or making it jump over a hole. If it encounters and pushes a stationary cart, it will stop in its current square and either fall down to a lower z-level or roll down the ramp.

So we get those two basic functions:

{{diagram|spaces=yes|\
.
O O ║ ║
[#000][#ff0]■ ║ [#000][#ff0]■ ║
▼ ║ ▼ ║
delete spawn
}}

A cart moves in from the south, across the ramp. If the place directly outside the ramp is occupied, the incoming cart stops and rolls down the ramp. If the place is empty, the incoming cart climbs up the ramp and rolls over the tile to the north. In the "delete" example, the incoming cart will be reflected and keeps moving if the place is occupied. If the place is free, it bumps into the limiting wall and stops moving. If this "gate" is empty, it "deletes" the moving cart - and becomes occupied.

In the "spawn" example, the incoming cart will also stop and roll down the ramp if the tile above the ramp is occupied, but the cart which stood there will move off the square and leave to the north. If the place is empty, the incoming cart itself will pass to the north. This "gate", if occupied, "spawns" an additional moving cart, while becoming empty.

Exploiting jumping carts, a "toggle" gate is also possible:
{{diagram|spaces=yes|\
.
O O
╔═ [#000][#ff0]■═
▼▼ ═╝
+ +
║ [#000][#0f0]■
toggle
.
}}

The operating cart arrives from south, with a speed of 35000+. Since the tile immediately south of the pit is ordinary floor, the cart will not enter the pit but jumps instead. If the SE corner next to the wall is occupied, the operating cart pushes the occupant off around the corner, falls into the pit and accelerates west. If the corner is unoccupied, the operating cart keeps flying until it is stopped by the wall, allowing it to settle onto the corner tile without rolling off. The occupation status of this gate changes to the opposite everytime it is tested. Notably, it produces no output when changing from empty to occupied, but a double output when changing from occupied to empty.

Of course, variations on these concepts are possible: one and the same location can be accessed from multiple sides, under different doctrines - e.g. a delete gate that can be emptied by carts approaching from another direction, operating as a spawn gate for them. A spawn gate can be combined with a length of track with a standing cart originally placed several tiles away from the ramp. When a series of carts is sent over the ramp, there'll always be an output cart, but the location of the standing cart will keep moving closer to the ramp. Effectively, such a track will "count down" until at zero it spawns a cart rolling off the ramp. Multiple carts can await a collision, and the collision may reconfigure the queue following Newton's cradle principles.

=== Pathing and regulation ===

Those two basic operations by themselves offer very little. It takes proper combination and direction to make them do something interesting.

In spawn gates, a moving cart leaving the gate will always be generated. You might wish to replace the stationary cart after the spawned cart has done its thing. This can be done by a simple loop coming in from a different direction:

{{diagram|spaces=yes|\
.
║ ║
O[#000][#ff0]■══╗ O║══╗
▼ ║ ║ ║
▼ ║ ║ ║
╚═B.B. ╚═B.B.
║ ║
state restoration
}}

A spawned cart goes through the Black Box (B.B.) to attend to other business, then goes over the track loop and bumps into the western wall, taking up the occupancy slot. If the gate was empty, the incoming cart will pass right through, no black box process is performed and the gate remains empty. As another option, a delete gate can be put in the way of a moving cart, which gets emptied by a perpendicular spawn gate built over the same core grid. The next time a cart checks the delete gate, it stops and doesn't move on.

Carts can be placed back into gate slots not only by ordinary loops but also by lifting the cart to the level above and dropping it through a hole in the floor. This allows to approach a single tile from all four possible directions, opening some avenues for complexer circuits.

=== Application ===

The core machine logic devices are heinously complicated to build from these basic components. It can be done, but it's deeply impractical:

{{diagram|spaces=yes|\
. one
bO ║
╔═▼▼╝╗
║▼ ║
║▼ ║
║╚═══╬═ zero
a╚║O ║
▼ ║
▼ ║
╚═══╝
║
basic bifurcation
}}

There's only one target cart in the system, which resides either at ''a'' or ''b''.
The circuit only checks whether the spawn gate at ''a'' is occupied and returns a "one" if yes, a "zero" if no. No matter whether this is the case, there'll always be a cart leaving from ''a'' to the north. If it's the target cart, it will find an empty slot at ''b'' and stops there. The spawned input-collector cart will now go around the outer loop. pushes the target cart back into position ''a'' and leaves towards the "one" direction. If ''a'' was empty, the input-collector will pass it, goes to the north, checks the delete gate at ''b'' and finds it occupied by the target cart and leaves in the "zero" direction. Funnily enough, almost the same circuit with opposite "reset" pathing will always toggle the state of the circuit (and still has two separate outputs), offering an extremely high-speed low-tech incrementer.

I also built a read-/writable binary "memory cell" based on this principle. It uses the same basic bifurcation, using the "state restoration" paradigm from above to restore the memory state after reading, and weight-/speed-based differentiation to "write" (i.e. toggle or leave unaltered). "Storage" and "reader" cart should be the same weight (they'll also switch role on each read event), while the "writing" cart must be significantly lighter to keep toggles and "empty writes" (i.e. memory was already in the desired state) apart. It works flawlessly, but is of course impressively large, complicated and slow.
Three minecarts out of five, wouldn't build a megabyte memory out of these.

Technically, i think it should be possible to build most classic logic gates simply by combining several of these identity testers with proper paths; apart from XOR and XNOR, each individual logic gate should take four spawn and two delete gates. No competition for any discipline of signal-based logic.

I managed to build a NAND/OR gate from these components, but it's not pretty. Fun to look at, but ridiculously large - it takes four spawn and three delete gates to operate.

Since weight differences can greatly alter the resultant speed after collisions, it's possible to modify the spawn gate so that it alone suffices for an identity check/bifurcation:

{{diagram|spaces=yes|\
zero one
║ ║
a║ ║
▼ ║
▼ ║
╚══╝
║
in
weight-regulated
bifurcation
}}

A lightweight cart is sent into the gate from the south, checking whether location ''a'' is occupied or not. The crucial point is that a very heavy cart is used to occupy the slot. I used a wooden cart as input and a wooden cart full of water, on top of a medium-friction track stop, as "marker". The input cart could never give enough of a push to move the marker off the check location. This gate will thus only ever output the input cart itself, on either of the two output branches, depending on whether or not ''a'' is occupied. Carts can be filled with or emptied of water without needing signals or power, as long as you have an infinite water source available.

Where this type of logic looks attractive, is in applications where counting and sequential operations take place. As mentioned, toggling and thus counting by increment should be comparatively quite fast. A count-down track can be used to regulate conditional loops, replacement loops can be used in binary incrementers.

Signalless circuits can count inputs sent via minecart push, and they can count such signals at speeds much higher than the ~100 steps dictated by pressure plate recovery. The fastest i managed to create is a ternary counter that can handle input periods all the way down to 27 game steps. It sends a "carry" whenever the circuit itself "overflows", on every third input:

{{diagram|spaces=yes|\
z+0 z-1
..╔╗
..╔╝ ###
..▼ #║#
..▼ #║#
.╔╣# ###
.║▼ ╔══╗ .╩#####
#║▼▼╩▼▼╝ #╦═#╔═#
.╚╝ #║ #######
}}

The double-ramp pit with return loop to the north, when supplied with one minecart, provides regular pushes to the cart just south of it, with a period of exactly 27 steps. After each push, the oscillating cart accelerates down the ramp going north, reaching a speed of ~ 39.000. It climbs the ramp to the north in a single step thanks to the checkpoint effect, returns through the loop and enters the pit again from the north, accelerating towards the south now. In the end, it delivers a push to a cart standing on the level floor (NSW track) just south of the oscillator pit, with a speed just under 50.000.

The track loop directly south of the oscillator contains two minecarts, one on the tile directly on the oscillator exit, the other in one of three possible positions somewhere on the track loop, depending on the current count.
The cart that gets pushed by the oscillator rolls onto the WNE ramp. Since that ramp is connected to wall (N and E) and has exactly one floor connection (W), it accelerates to the west. The southward speed remains unchanged and carries the cart off the ramp and onto the adjacent SEW ramp after three steps, before the westward speed carries it off west. On the SEW ramp, walls are to the S and W, and floor to the east, so acceleration goes to the east now. Thanks to the checkpoint effect, the cart climbs up the ramp to the south in a single step if the southern tile just outside the pit is unobstructed. The cart then properly takes the SW corner, turning around to the west. It pushes the other cart present in the loop and comes to rest on the adjacent square. The second cart finishes the course and comes to rest on the tile south of the oscillator in time to take the next push.

If the secondary counting cart stands on the "exit" tile of the pit, the arriving cart pushes it without leaving the pit. It will then accelerate to the east, passes across the adjacent EW track ramp in a single step (due to checkpoint effect) again and pushes the cart in the ''next'' counting circuit, before it accelerates to the west, climbs the SEW ramp in one step and leaves the pit to the west, coming to rest against the wall there. The circuit has passed on a signal and can accept new input, sending the next "carry" once three more inputs have been received.

This circuit is tailored to the behaviours of colliding carts: the minecart engine keeps track of "sub-coordinates" of a cart on its current tile, and the durations of acceleration and effects of diagonal movement depend very much on these, not directly visible, exact locations. Furthermore, collisions - both with other minecarts and with walls - stop a cart at the very border of its tile in the direction where collision took place. The carts on the oscillator output are practically scraping on the wall, thus the odd WNE ramp: a certain amount of west shift is necessary to enable proper operation.

=== Computing by speed ===

A much more fiddly application is to use carts of varying weights and speeds in collisions and using the outgoing speed as basis for computation. Carts of different speeds can path differently - the best-known example are probably derailing carts: past 50 000 speed, carts will only follow a corner if there's a wall or path-blocking building behind it, otherwise, they pass in a straight line. If different output speeds can be generated in a collision and both speeds above and below the derail threshold are possible, a simple not-backed track corner can already separate speedy from slower carts. In addition, placing braking architecture like track stops and ramps can help separate different-speed derailing carts and perpendicular downward ramps can separate below-derail carts. Offering different paths for the different speeds allows performing different operations depending on the "input" - consisting of the momentum of the incoming and the weight of the pushed cart.

I used this principle first and it shows most promise for more conventional applications like memory and logic gates. Getting three distinct results out of a single collision was already quite doable; four was harder, but still possible. I managed to build a full adder on this principle, the addition itself really being a single minecart collision which was then separated into the four possible results just by track and constructions.

=== Outlook ===

Signalless logic is as yet more a funny concept than a really useful computing paradigm. I find it interesting to know that some "proper" computing procedures like binary addition, bit shift operations and program loops can be built and controlled without using a single mechanism, which flies in the face of classical dwarfputing, which measures its dwarfiness by number of mechanisms installed.

As mentioned above, the independence from signal and building timeouts suggests there might be some potential to integrate signalless processing into conventional computers, performing sequential operations at high speed without switch lag and handing over the results to signal processing again.

User:Larix/MPL/3

2015-12-03T20:17:18Z

Larix: More concentration on memory, some cleanup

'''Advanced circuits'''

As with other alternative logic disciplines, MPL is in many ways inferior to mechanical logic when it comes to the actual logic gates. Mechanical logic performs nearly instantaneously and requires little space. It's also a lot easier to run multiple mechanical operations off a single switch by running power through "master gears", while in MPL you have to individually connect every single device to every desired signal source. Mechanical logic, however, is not capable of generating signals by itself, of lasting data storage and incrementation ("counting") - the only "output" of mechanical logic is transfer of power and all states of mechanisms directly reflect the state of inputs, they cannot hold a "memory state" while input changes. Alternative logic types are required to generate and store signals. For counting, for repeating signals and to implement "memory", your options are fluids and minecarts, and MPL is an attractive choice here, because it's naturally liquid-less and can be implemented without use of power.

This is only a selection of MPL circuits i've built. They're mostly custom-made on the spot when i had the need for a circuit to perform a specific operation. Once again, they were practically applied, these are ''not'' theoretical "this should work because the logic is sound" circuits, i even built and tested the straight Set/Reset latch which could not conceivably fail. I've had too many cases of the inconceivable happening with minecarts.

===Counter===

[[File:Zählwerk mit Bauten.png]]

For speed regulation and cart management, there are a bump wall and bunker pit to the east. The operational unit is the angled three-pit ramp in the middle. The ramps are engraved with track like this:

║
=╠

When the hatch cover is open, a cart coming from the west will pass through to the east, one from the north will pass through to the south. If the hatch cover is closed, a cart coming either from the west or from the north will exit to the north. Thus, the procession of operation when counting is:

1. cart enters the circuit on the outer ring, entering the three-ramp pit from the west.

2. as long as the hatch cover remains open, the cart will pass the ramp West->East, gets regulated by the bunker pit and remains circling around the outer ring.

3. once the hatch cover closes, the cart is diverted to the north and starts bouncing between the bump wall and the closed hatch cover.

4. once the hatch cover opens again, the cart passes through the pit to the south and leaves the counter circuit, e.g. entering the next one in the line.

A series of such counters, arranged in a circle, can be operated from a single input signal connected to all hatch covers and will thus count how often this input has cycled. The reaction time to a changed signal is fairly long, up to 50 steps, so the input shouldn't cycle too quickly, or signals will get missed.

It is easy enough to glue two of these counters together and have a pressure plate on the connecting track, so it sends a signal of its own after every second advancement. This is in effect a binary counter, and combining several of these allows to perform binary counting.

===Luxury one-bit memory/counter===

[[File:Rechner-Speicher-Zelle.png]]

This is a binary counter cell which can add and subtract, and can also be set to one or zero. In the adder/subtractor design i came up with, the "memory" is the part which performs the actual calculations, directed by signals sent from another circuit "reading" the input. All carry calculations are done in the counter/result memory itself and additions are performed from highest to lowest bit.

The device consists of two counters, linked through a northern and a southern loop. When the central hatch cover in the cart's current half of the cell opens, it passes through the loop to the other half. If the hatch in the pit on the loop is open, the cart passes through without further effects, if the hatch is closed, the cart is sent on the "inner" branch of the switchover loop and touches a pressure plate which sends the carry (south sends negative/subtractive, north sends positive/additive carries) to the next higher bit. If both operative hatches are opened, the memory cell's status will change to the opposite; depending on further hatches opened or not, this may generate carries and work as addition or subtraction. If only one operative hatch is opened, together with the hatch in the resultant switchover loop, the cell's value is "set" to a specific value - if the cart was already on the desired side of the cell, nothing changes, obviously.

The full installation shown here makes for a ''very'' component-expensive bit of memory. Its benefit is that it allows a lot of operations on the memory directly. I built cells of this type taking four different input configurations allowing it to run addition, subtraction, "write" (i.e. setting the memory to a desired value) and bitwise XOR (addition without carry). The memory itself produces a permanently "held" ''on'' signal as output, deriving independent ''on-off'' cycles would need extra "converter" units or destructive reading. In my four-function application, one bit took four hatch covers, three pressure plates and seventeen linkages, not even counting the input regulator and any possibly more complicated output machinery, for a cool 37+ mechanisms ''per bit''. Its multi-purpose functionality makes it an interesting option for a "result" or "arithmetic" register, much less so for a plain memory bank that's only supposed to store and not directly manipulate data.

===Bridge Repeater===

[[File:Brückentakter.png]]

A curiosity, a powerless repeater sending a signal every ~205 steps which can be used to operate a constantly opening and closing bridge. The only operational pit is the one to the north, a looped-ramp pit (ramps SW and NW) with the northern ramp covered with a hatch cover linked to the output plate. As long as the hatch cover is open, the cart will cycle through the pit and the flat half-circle directly west of it. Once the hatch closes - one hundred steps after the cart went over the pressure plate - the cart will pass over the hatch, bump into the wall and move incredibly slowly to the south, fall into the bunker pit, leave at a slightly more sustainable speed and touch the plate again.

===Double-action switch===

[[File:Kippschalter.png]]

An "edge detector" or, more simply put, a device to convert lever pulls into single on-and-off signal cycles. The cart starts out on the hatch to the west, over the eastern ramp of a bunker pit. Once the input signal turns on, both hatches open, the cart falls into the pit, cannot leave to the west and thus leaves to the east, across the pressure plate and starts circling through the loop to the east until the hatches close again, when the cart will return from the pit to the north, pass the pressure plate again and bump against the wall to the west, coming to rest on the starting hatch cover again.

===Auto-derailer===

[[File:Und-Gatter ohne.png]]

A device i used quite a lot in my first designs. The ramps are engraved with NW and SW track. The cart will cycle through the array, generally emerging on the northern track tile, cycling around to the south and entering the ramp again. It will keep accelerating until it becomes fast enough to derail. If there is open track to the north of the northern ramp on the level below, the cart will leave the array to the north at this point. Depending on the starting conditions, the cart can take anywhere from ten to 350 steps before leaving the derailer. If the cart is kept in the derailer, e.g. by blocking the exit path with a door, the cart will not accelerate notably beyond the original derail speed, it will just be kept within the array at derail-capable speed.

The main interest in the basic circuit is that it can be used to introduce a significant delay into a circuit, without moving parts and with very low space consumption.

===Clock-capable repeaters===

[[File:UhrwerkBremsen.png]]

The visible ramp openings belong to looped pits, engraved SE-SW on the southern branch, NW-NE on the northern branch, with the second pit covered by the straight track leading out of the niches. The track stops on the exit points have high friction, the track stop just south of the northeastern ramp has low friction, all others medium friction. The return time is exactly 300 steps, 1/4 of a DF day. Collecting a single signal and plugging it into a four-step counter will give a full day.

[[File:DieUhr1.png]]

These are actually four repeaters, three of which are used to run a precise clock. Each repeater consists of two derailers, coupled like this below:

[[File:DieUhr2.png]]

There's a medium-friction track stop on each connection track, the final tile, under the pressure plate, is a corner sending the cart onto the "backwards" ramp of the partnered derailer. This results in the cart being so fast on entry that it derails over the ramp pit, slams into the wall and falls down onto the "forward" ramp. This greatly increases the time required to build up to derail speed, giving a full return time of 720 steps for each repeater. I started three of these repeaters 240 steps apart, so every 240 steps one "full round" signal is received and can be counted, five of them add up to a full day.

{{Diagram|spaces=yes|\
.
^╗ ╔╗
║▲# ║╚#
#▲╝║▲# #╗╝║╔#
#▲══▲# #═║║═#
#▲║╔▲# #╝║╔╚#
#▲║ #╗║
╚╝ ╚╝

Buildings Track

}}

A clock-capable repeater with a period of 600 steps - half a day. In the two "combs" of three ramps each on the eastern and western side, the cart bounces between the two border ramps and is displaced by 1/29th of a ramp's width everytime it passes the middle tile. After 29 passages (about 290 steps), it is displaced far enough to make it off the comb and into the switchover loop. All ramps are impulse ramps - the bordering ramps mustn't offer exits to above or the cart will just climb the ramps and disappear onto the level above.

===Memory===

Minecarts can be held in a loop or on a straight rail just going back and forth by hatches and other buildings. By combining "data" and "enable" or "reset" buildings on the same circuit, all with their own links, this can be used to store data in an adressable form.

1. Basic Set/Re-set latch

{{diagram|spaces=yes|\
.
# # # #
▼ ║ ▼ ▼
▼ ║ ¢s ¢s
║ # ║ ┼e
▼ ║ ¢r ¢r
▼ ║ ▼ ▼
║ # ^ ^
▲ ▲ ▲
# # #
1 2 3 4
.
}}

1. Track/ramps

2. engraved track on the ramps in the pits

3. buildings

4. space-saving expansion using a door to "e"nable the cell, designed by Nil Eyeglazed/VasilN.

In the "off" state, the cart remains in the northern ramp-pit, because its exit is blocked by the closed hatch to the south.

If a "set" signal is received (and in the expansion, if the "enable" door is opened as well), the cart leaves the northern pit, jumps across the southern pit, bumps into the wall, gets reflected by the ramp and settles into the southern pit, bouncing between the hatch cover blocking exit to the north and the ramp above to the south, keeping the pressure plate activated. Further "set" signals will not do anything.

If a "reset" signal arrives (once again, only respected if "enable" is also set in the expansion), the cart leaves the southern half of the array, travels north and settles into the northern pit, letting the pressure plate reset and thus dropping the saved bit. Additional reset signals, once again, will not change the memory state.

As usual in Set/Reset-latches, a currently-on cell will not react to changes of the "set" signal and vice versa; the memory cell will hold the saved state indefinitely if both inputs remain off and it will produce an erroneous output (false "on" in this case) if both signals are on simultaneously.

The possibility to "adress" this memory can be realised in different ways and a further non-destructive "read-out" producing a signal cycle instead of the constantly-held "on" can be provided just by adding another pit to the south. It is a very compact design and can be packed extremely tightly: with an extra read-out, it comes to a length of eleven tiles, while it's two z-levels high and a single tile wide. Neighbouring memory cells can share a wall tile, so each past the first will only take ten tiles of added length. Materials required come to one door and three hatch covers with four linkages among them for input and at least one pressure plate and one linkage for output - four furniture and eleven mechanisms.

2. Adding dedicated "read" branches

{{diagram|spaces=yes|\
.
# #
▲ ▲
^ ║
¢o- ▼
▼ ▼
║ ║
▼ ▼
¢s ▼
┼e ║
¢r ▼
▼ ▼
║ ║
▼ ▼
¢o+ ▼
^ ║
▲ ▲
# #

}}

I implemented the main memory of my dwarven computer with this type of memory cell. It can be set (via the "s" hatch) or reset (via "r") as long as the cell is selected ("e"nabled). It will not normally produce any output unless specifically requested by opening the "o"utput hatches. For reasons of functionality, it has two output hatches and pressure plates and can thus generate separate output signals depending on whether the cell is currently in set or reset state.

A major downside of this design is the duration of the output signals: the cart will start activating the pressure plate shortly after the hatch opens and will keep passing over the plate until the hatch closes again, after about 100 steps. Only 100 steps after the cart last touched the plate will the plate reset and send its off signal. The result is a signal remanence of about 200 steps. Such delays can easily stack up in cascaded logical processes, jeopardising the practicality of usage through excessively long signals.

3. Short-pulse memory cells

{{diagram|spaces=yes|\

# # # # #
# ║ # # ║
a¢ ║ a¢ a¢ ║
c+ ║ b┼ b┼ ║
b¢ ║ c¢ c¢ ║
╔▼ ╔║ ▼ ▼══╗ ║══╗
║+d ║║ ║ d┼ ║╝ ║ ║╝
║^ ║║ ▼ ^▲▲▲ ╚╔║╗
▼╗ ║╗ d¢ ### ###
e¢▲# ╚║# ^ 3.a 3.b
## ## ▼
1.a 1.b ☺
eG
#
#
2.

}}

To adress the concerns pointed out above, i developed a few memory cell designs that will only send one short-term signal pulse. To achieve this, the cart must be delayed until the output request has timed out and then sent back to its memory holding location on a path that bypasses the pressure plate.

Key for all cells:
a - set
b - reset
c - enable

d - request for an output
e - building that moderates the delay for returning the cart

1.: building-moderated delay, lateral bypass

d & e are activated by the read signal: the door lets a "set" cart out of its pit. It passes over the pressure plate ''once'' and then cycles through the four-tile circle in the very south; the cart must come in at the correct speed for the orbit to properly establish and remain stable. Once hatch e closes again, the cart leaves straight to the north (instead of SE while circling) and returns to the "set" pit.

2.: building-moderated, vertical bypass

Instead of keeping the cart in motion until the read signal turns off, this design makes use of the different delays for different buildings. In the south, there's a floor grate over a bunker pit. When a read is performed, an "on" cart leaves its pit to the south, touches the pressure plate and comes to rest on the grate. The grate takes 100 steps to open. At this point, the cart drops into the pit, picks up speed and leaves to the north. Immediately north of the grate, it passes over a tile of ordinary floor (here engraved with a friendly face) before facing a pit. Since it comes from normal floor, the cart ignores the pit (has no downward connection and wouldn't change the cart's speed in any way) and jumps instead. The jump is far enough that the cart passes over the pressure plate north of the pit without touching it. The assumption is that by this time the actual read signal has timed out again and the read hatch is already closed, keeping the cart constrained in the holding pit.

3.: path-moderated, lateral bypass

Of course, we can also give a cart enough path that it takes 100+ steps to return to the holding pit (assuming the read request is produced by a short-term signal that shuts the requesting building after about 100 steps). It uses the same "ramp comb" as the third model of a clock repeater. The sole difference is that the corner at the entrance to the array ensures that the cart enters it in the middle of the tile, so that it takes only 15 passes over the central displacement ramp to exit the array, giving a total return delay of about 160 steps.

All designs have been tested and work. They're all notably bigger and clunkier than the simple straight designs shown above and are only worth the effort when the well-regulated short output signal is desired.

''If'' timing is crucial, these and similar approaches become mandatory, since they limit the necessary "cooldown" time until the next signal can be processed to significantly under 200 steps, while especially in long cascading approaches the above "cumulative remanence" designs can quickly escalate out of control.

Similar and better timing for reading stored information is possible with fluid-mechanical logic, at the price of power consumption.

4. One-building toggle memory cell

{{Diagram|spaces=yes|\
.
###
╔▲▲▲
║ ║╗
║ ╔╝
╔══┼▼▼^▲#
#▲ ▼
#▲═╔▼
#▲╚╝#
}}

The cart's in one of the double-ramp pits when the door is closed. Whenever the door opens, the cart leaves its pit, goes through a ramp comb starting in the middle of the tile and enters the other double-ramp pit of the array after ~160 steps. As long as the door is opened by short-duration signals, the cart will properly settle into the opposite state after each signal received.

===Mini-Excursus: Material costs of memory===

For me, the crux of building advanced logic machines is the extreme cost of memory.

The memory designs seen here range from two hatches and one pressure plate for the non-enabled S/R latch (five mechanisms not counting output links) to seven buildings (with fourteen mechanisms for links) and two pressure plates for an enabled cell with bidirectional outputs and hatch-moderated holding/lateral bypass. As an even more extreme case, the big complicated count-capable memory cell at the start clocks in at over thirty mechanisms.

Looking at other designs, fluid-logic data latches can be operated with a single door for enabling and a large shared bridge as data input (serving up to twelve cells). Actually reading the cells tends to become a bit complicated but can be done at lowish mechanism cost if rather slowly through destructive reading (set a cell to a given state and test if output ''changes''). Cost per bit stored in a full installation would be just under six mechanisms and one door. Similar designs are possible with MPL, although they are slightly costlier in mechanisms and space and are somewhat slower.

The "cart placement" memory cells developed by Bloodbeard and tinypirate come at costs of ten to fifteen mechanisms per bit, depending on the functionality included in the cell. They'd also require either a very costly big reading array or destructive reads.

All these reasonably write-able memory cells have a common theme - each takes several mechanisms and usually a few buildings to implement. A reasonably convenient and quick cell can't be had for less than ten mechanisms. Considering each mechanism takes one rock and a fair bit of time to make and installing/linking takes a fair amount of time and attention, it should be easy to see that memory is a serious limitation for dwarven computers. Even a modest kilobyte can easily take 100.000 mechanisms (more than the biggest machine on record that ever got finished), and you can't really do much computing with that little memory.

With my concept of storing information purely in minecart weights and evaluating sets of carts selectively i managed to circumvent the problem to a degree: with eight different weight groups of carts, each cart can hold three bits of information, and reading can be grouped - you only read one set of carts at a time, while several other sets are kept in readiness. Consequently, i managed to build a memory array holding 768 bits of information at a cost of under 500 mechanisms. The downside is that this kind of memory would be extremely laborious and slow to write to, i never considered using it as anything other than a ROM. At three bits per cart, it also took over 200 minecarts to fill. A full kilobyte implemented like this may cost "only" 2000-3000 mechanisms, but it would also require about 2500 minecarts, each individually selected, placed and put in motion.

User:Larix/MPL/2

2015-12-03T14:03:40Z

Larix: /* Esoteric use of bridges for switching */ no need to link, image's been deleted

'''Basic logic gates in MPL'''

These designs all use straight track ramps in the pits and only use hatches for switching. They are very reliable, but slow and space-hungry, since every single bifurcation will require a one by two pit and entrance and exit tracks. They are constructed with a constantly-moving cart, waiting for input changes and adjusting their output according to the new logic condition with a moderate delay. They can be switched in full operation, and only the XOR/XNOR one runs a small risk of creating a false output when switched at the wrong moment. With some fancy pathing, all of these logic gates can also be used in their opposing function.

All designs were built and tested and have proven functional.

===NOT/IDENTITY===

[[File:Nicht-Gatter.png]]

The pressure plate is active only when the hatch cover is closed. If the hatch is open, the cart will move in a circle, never swinging out to the west. A pressure plate on the circle track gives an "identity" signal, useful if your input signal is generated by a device you do not wish to directly tamper with.

===AND/NAND===

[[File:UndNichtUnd.png]]

The pressure plate to the southwest collects the AND, the one in the northeast the NAND signal. The AND plate is only activated when the cart can pass without hindrance through both pits.

[[File:Undvarianten.png]]

To the north, a near-minimal AND gate (could be made one tile smaller), to the south an AND-based custom gate, designed to give a notable result if the first input is on and the second off.

===OR/NOR===

[[File:OderNichtUnd.png]]

If both hatches are closed, the cart will bounce between the two ramps, constantly returned and sent to the other. To the far southeast there's a ramp directly against a wall, used to limit the speed of carts which got to pass through a ramp-pit. Carts passing through the E-W ramp will otherwise accelerate so much that they derail/jump and stop.

===XOR/XNOR===

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

In the centre, a 'bump ramp' to limit incoming carts' speed, to the southeast a "bunker", a two-pit EW ramp with the second ramp underground with no exit at all; this returns the cart onto its entrance tile, at a moderate speed, somewhere around what a medium-speed roller.does. When both inputs are equal, the cart passes over the northern pressure plate, if they're different, they pass over the southern plate. Some variations on this design work, too. As far as i could determine, this design stays in its state reliably and can be switched during operation, although opening the second hatch cover while the cart is on top of it may result in a temporary false result or too-long return time. If the gate is supposed to be built with no more than two switchable devices - hatch covers in this case - one of the paths must lead over a hatch cover, a design i prefer to avoid when possible.

The concept of the AND and OR gates can be expanded to accomodate additional inputs.

'''Four-input AND:'''

[[File:Vierfachprüfer.png]]

'''Three-input OR:'''

[[File:Dreifachoder2.png]]

===Cooking with doors===

A door can be used to block a cart from exiting a ramp '''to''' a specific flat floor tile, while a hatch is best used to block a cart from exiting '''from''' a specific ramp tile. Doors can thus be combined with hatch covers to build logic gates consisting of a single 2x1 pit.
A door-and-hatch AND gate would simply put a hatch cover on top of the output ramp and the door in the output tile. Only if both devices are opened, the cart can leave on the output side, otherwise it will be returned on the input side. A dual-function AND/NAND gate based on this design could be built by simply taking the NOT/identity gate above and adding a switchable door on the NW corner just east of the pit. As a nice benefit, in such a circuit, both gates are in fact checked simultaneously - the cart's attempt to move out of the pit takes a single game step, and if on that step either building is shut, the cart will return, and only if both are open will it pass.

'''Door-and-hatch OR gate:'''

[[File:Oderminimal.png]]

This circuit doesn't use straight track ramps, the northern pit is engraved with a track crossing (NESW), the southern ramp is a normal NE corner track ramp. If the door is open, the cart will pass through the single pit to the north and leave to the west. If the door is closed but the hatch cover open, the cart will leave the pit from the southern ramp, going east. If both devices are closed, the cart will leave from the northern pit, going north. This design needs a fairly high operation speed, more than a dwarven push can produce, thus the impulse ramp to the east. In the form presented, the circuit can only perform "single-pass" checks. Since a cart passing straight across the northern hole gains no ramp acceleration, an additional accelerator would be required for long-term operation.

===Esoteric use of bridges for switching===

Since bridges really are treated like normal (all-direction) track by the game in their lowered/extended position and also overwrite the track features of the tile below, a retracting bridge over a flat tile of non-track floor can also change the behaviour of a minecart: a cart coming from ordinary floor will jump over a pit even if moving at low speed, but a cart coming from a track tile will enter a pit containing a track ramp unless it's moving at derail speed over flat floor. Thus, extending/retracting the bridge will switch the cart's behaviour between going down the ramp and ignoring the ramp and jumping over it.

Combining this feature with a two-long bridge on the other end of a straight double-ramp pit, i constructed a full bit-compare logic gate using only those two switchable devices to generate the four possible outputs for the four possible input signal combinations. It is a curiosity, since for most logical purposes, such distinctions are not needed and since only bridges can be used, the gate reacts with a significant delay to input and should not be switched during operation - a bridge changing state under a cart will throw the cart around and force it to stop. It's worth mentioning that the more classical use of bridges to cover/reveal track corners offers the same functionality in switching cart paths - a full bit-compare gate can be built with two 1x1 bridges over flat track, too.

User:Larix/MPL/1

2015-12-03T13:49:38Z

Larix: Updated, consolidated

'''Foundations: minecart physics'''

MPL (Minecart Pathing Logic) opens and closes buildings mechanically to switch the paths of moving minecarts between binary alternatives. To run long-term logic circuits on this basis, we need ways to set and keep carts in motion and basic concepts of switching.

===Gaining Speed===

Minecarts can receive speed from installations on a track in two ways, from rollers and from ramps. They can also get moved in the course of "route" handling, being pushed, ridden or guided by a dwarf, but guided carts largely ignore terrain and pushed/ridden carts require the presence of a dedicated labourer on the site for each such action, which is rarely desirable in dwarven computing. Moving a cart via "pushing" it is nevertheless useful to test small circuits without the need to build powered machinery or linking up levers for a starter mechanism.

''Rollers'' are pretty straightforward: they increase a cart's speed to the roller's "operation speed", in the roller's movement direction. Operation speeds are:
*lowest - 10.000
*low - 20.000
*medium - 30.000
*high - 40.000
*highest - 50.000
Minecart speeds are calculated in 1/100 000 tiles per game "step". A highest-speed roller will impart a speed of half a tile per step. Higher speeds are easiest achieved through ramps (notionally an effect of gravity), which can get a cart up to 270.000, between two and three tiles per step. That's over five times the speed imparted by a highest-speed roller. Even higher speeds are possible but not very practical.

There are a few not-so-obvious caveats concerning rollers:

* Rollers only increase, never decrease speed. A cart moving in the roller's direction but faster than the roller's operation speed will be unaffected.
* Direction is important. A cart moving "against" the roller's direction is effectively moving at negative speed in the roller's direction, so the roller will attempt to "increase" its speed in its operative direction. This is done by substantially reducing the cart's movement speed (by 100.000 per step), and if that lowers it below zero, movement will be reversed, sending the cart off in the roller's direction. This "braking power" of rollers is not dependent on the roller's set speed. A 1x1 lowest-speed roller will stop and reverse a cart propelled by a highest-speed roller.
* A cart encountering a roller working perpendicular to its movement direction will still have its movement speed increased in the roller's direction, while the cart's movement speed in its original direction will remain unaffected. The result is a ''diagonal''ly-moving cart. The best explanation for this is that minecarts' movement is calculated separately on the three spatial axes. If a cart is moving with some speed on the x-axis and encounters a roller also working on the x-axis, the roller will only change the x-movement parameter and nothing peculiar will happen. If the cart encounters a roller working on the y-axis, the roller will "set" the cart's movement speed on the y-axis, without changing the x-movement parameter. The cart will now have non-zero speed on two axes. That's problematic, because a minecart will remain on its course unless it runs into a corner tile from one of the corner's "connections". Diagonally-moving carts will move at some angle to actual tracks, completely ignoring their directions (including track ramps, meaning that launching or accelerating them via ramps becomes almost or entirely impossible). They can re-join normal tracks if they encounter a properly aligned track corner, but determining whether their movement direction is sufficiently "in line" with a corner is very much hit-and-miss; this "catching" feature can be used for some rather esoteric minecart switches, but takes very carefully set-up tracks and rollers.

''Ramps'' give a uniform acceleration towards the ramp's "down" direction. A cart going across a track ramp will be accelerated when moving "down" and decelerate when going "up". So far, so obvious. However, the exact rules get rather complicated:

* a ramp will only provide acceleration if it has an actual "up" and an actual "down" connection - at least one "branch" must touch a wall, exactly one a "non-wall". A ramp not so connected will provide no acceleration. A cart will accelerate if it is moving towards the "down" connection of the ramp, ''regardless of where it came from''.

This is the basis of "impulse ramps" - a cart moving to the north and passing over a track ramp connected to a wall to the east and with a proper "down" connection to floor to the north or west will accelerate, even though the cart clearly didn't enter from above. A cart set down on a legal ramp will roll "down" the ramp, gaining speed from a complete standstill. The reverse is also somewhat true - tracks which are not properly connected will be treated as flat floor, even if z-level-changes take place. Sending carts up such "flat" ramps is entirely possible, but quite speed-sensitive.

* To make matters even weirder, proper ramps have a different tile length than ordinary floor - they are about sqrt2 normal tiles long/wide. The game needs to convert distances and relative cart position whenever a cart moves from flat floor to ramps or vice versa, or when switching between ramps with different slant (down direction). This conversion causes very peculiar behaviour:

- carts will always touch a tile with a new alignment (first flat tile behind ramps, first ramp tile behind flats etc.), they cannot skip it.

- when coming off ramps to a different kind of tile (flat tile or different-slanted ramps), the cart "teleports" through the new tile to its very end. It will spend exactly one step on this tile, regardless of its incoming speed. Furthermore, it'll gain one step's worth of acceleration ''opposed'' to the last amount of ramp acceleration it received.
I.e. when a cart leaves a line of north-pointing ramps to flat track, it'll spend exactly one step on the first tile of flat track and gains ~5000 units of southward speed.

The independence of acceleration from actual level changes and the "teleportation" feature of the "checkpoint" tiles when leaving ramps allow to provide perpetual motion to minecarts:

{{diagram|spaces=yes|\
╔╗ ╔╗ ╔╗ #
#▲║ #╗║ ▼║ ║
╚╝ ╚╝ ▼║ ║
╚╝ #
impulse ramp double ramp "booster"
}}

The impulse ramp cycle to the left accelerates the cart everytime it passes over the ramp from north to south. The implementation of ramps doesn't care where a cart comes from, as long as the ramp is properly connected, it will accelerate any cart that's on it.

The booster cycle to the right makes use of "checkpoint" conversion. The first ramp it crosses will be passed normally, giving the normal acceleration. Checkpoint effects mean the cart then passes the "upward" ramp in a single turn and leaves the pit, with a net gain of speed. The cycle can be run in both directions.

Practically, both designs must be implemented differently - the cart will soon overspeed and blast out of the cycle if built like that.

===Basic pathing rules===

Minecarts are completely ''deterministic''. If two carts encounter an identical pathing situation with the exact same entrance parameters, they'll behave absolutely identically. There are no known components of chance involved. This doesn't mean carts cannot behave in unexpected ways - there are many obscure rules for what a cart can and cannot do or how movement is resolved.

On ''flat track'', a cart will generally keep moving in a straight line. It can only change path by moving over a corner track tile - with exactly two connections - with no exit in the direction the cart is moving to. I.e. a cart moving from south to north will keep this direction unless it encounters either a SE or a SW corner tile. It will of course stop if it encounters a wall or other solid obstacle and may revert or go on a diagonal if it passes over an active roller. Carts moving very quickly will ignore corner tiles unless the straight path is blocked by a solid obstacle, like a wall or door.

On ''ramps'', pathing gets a bit more complicated, because acceleration becomes a factor and because ramps can move a cart to a different z-level.

*As has been mentioned, a ramp will cause acceleration if it is both "up"- and "down"-connected. Only one down connection is allowed, a track ramp with more than one "down" connection will not accelerate a cart. More than one "up" connection, however, is perfectly acceptable. A track crossing can accelerate a cart just fine if three of the connections touch walls and only one a floor or hole.

*If the down direction is perpendicular to the cart's entrance direction, the cart will move diagonally to some degree. Whether such diagonal acceleration sends the cart on a diagonal trajectory (usually causing it to slam into a wall and stop), fails to move it off its path or bends it around a corner, depends on the entrance speed and architecture of the circuit.

*Carts will jump across open pits even at fairly low speeds, but will always enter a pit containing a ramp (preferably a track ramp, but unengraved ramps are entered just the same) when coming from a floor tile or bridge and moving at less than 50.000 speed. Carts going faster than that cannot enter a downward ramp when coming from a flat tile. They will go down the ramp if they already came from a proper ramp, a long slope consisting of nothing but downward ramps works perfectly fine and entering a downward ramp from flat floor can be forced through an impulse ramp, although those tend to make a route one-directional. Corners on upward track ramps cause a degree of diagonal movement which must be cancelled out by a flat-track corner behind the ramp, otherwise the cart will leave its path after a while.

*Carts jumping over a hole are in flight for six steps. During this time, they are not in contact with the floor and will not interact with ramps, corners, track stops or pressure plates they pass over. This feature can be used to let carts bypass track features depending on their speed or movement direction.

*Carts going up ramps to tiles with open space above them (i.e. no closed ceiling) can "jump". This can lead to carts bumping into the ceiling (and stopping) or jumping past engraved tracks on the tile just behind the ramp. This can be prevented by putting a "downward" impulse ramp on the tile behind an exit ramp.

*Carts will only go up a ramp if the ramp has track connection to the wall which the cart tries to climb over. If a ramp is not so connected, the cart only recognises the wall and behaves appropriately - bumps into the wall or, if that's possible, follows an engraved corner.

===Basics of track switching===

To do anything with logic, we need something that reacts differently to different "inputs". In MPL the different reactions take the shape of a choice of path, where different inputs result in different paths taken. Input generally takes the form of signals or power, and there are various ways to turn such an input into a pathing choice. A simple and very versatile ''switch mechanism'' is the '''roller''': it acts directly on the movement parameters of a minecart, so of course it can affect the path the cart takes. The roller-driven track switch is in fact shown as the first option in the "minecart" article. The most effective design makes use of the fact that rollers working against a cart's movement direction will reliably turn the cart around. This is much more reliable than using a roller working towards the desired "branch direction", due to roller/cart interactions explained above: if the "unswitched" cart goes from south to north and the branch is supposed to go off to the east, a roller pushing to the east will send the cart on a diagonal northeasterly course that requires catch corners to get under control; but a roller pushing towards the south into a NE corner will revert the cart and the corner will send it on the easterly course without any need for further regulation; this even works flawlessly when the roller sits right on top of the corner. The combination of path reversal with the guiding power of the track corner results in a perfectly reliable, compact and fast-acting switch layout. Since rollers are driven by power, additional gear assemblies placed in the power train provide a very natural interface with mechanical logic. Constructing switches with rollers placed perpendicularly to the incoming cart's direction is possible, but the early-supposed method of restraining walls is utterly obsolete (opposing roller into a corner is superior in all regards). A "catching corners" setup offers some interesting options but is complicated to construct.

Tracks can also be switched by "overwriting" a corner with a straight pseudo-track by opening or closing a '''bridge'''. Bridges are treated as all-directions track by minecarts and will overrule the directions of track engraved into the floor beneath when extended/lowered. We would construct a bridge on top of a track corner (one tile is enough, but larger bridges may offer additional options) and extend/retract it by our input. The cart will follow the corner when the bridge is raised/retracted and move in a straight line when the bridge is lowered/extended. Other "above floor" building types like hatches (and presumably bars and grates) will not overwrite track directions when closed.

Buildings that serve as '''obstacles''' in a cart's path, like a raising drawbridge, a door, floodgate etc. will, if put in the way of a straight-moving cart, simply stop it. Combined with a roller, they can still be used in logic to introduce a delay and if you're working with very fast-moving carts, they can be used as another type of switching device by putting it directly behind a track corner. The fast cart will ignore a corner and continue in a straight line if open floor is available in that direction, but will follow the corner if the straight line is blocked. Opening/closing the door or other building will thus switch the cart between going around the corner and going in a straight line. This paradigm can be used to construct very fast-reacting logic circuits with comparatively few buildings and mechanisms. I've explored the concept and found it quite promising. More information on this "Cart-and-Door-Logic" can be found in chapter 7.

Path-blocking buildings can be used in another switching schematic, too, by combining them with ramps to accelerate carts stopped by the obstacle. This is the basis of this entire logic discipline.

===Combining ramps with path-blocking buildings===

A cart encountering a solid obstacle on its course will entirely stop moving in this direction. With the ability of ramps to provide acceleration to any minecart touching them, carts can be made to ''return'' from such collisions: construct the obstructing building immediately behind a track ramp; a cart that cannot pass will "roll down" the ramp after stopping and gain speed in the ramp's downward direction. For logic purposes, this will usually be the "return" direction, away from the obstacle. The return path can also branch the cart away from the actual origin location. If the obstacle can also be removed/opened at will, a cart can now either pass through or return, meaning we can have a single "input" direction and two different "output" directions, and the cart will reliably take one of those two depending on the "signal" governing the obstruction. Doors, hatches, grates, bars, bridges and floodgates all serve as obstacles to minecarts and can be switched between open and closed by levers or pressure plates. Using them, we can switch minecarts between different paths (in binary fashion).

'''Hatches''' are a very convenient tool to switch paths of incoming minecarts: they react instantly to received signals and are easy to build. The most reliable switching method is to put the hatch cover over a ramp a cart is trying to pass from below. In this case, the cart will never be in the same tile as the hatch: if the hatch is closed, the cart will bump against it from below and roll back down the ramp. If the hatch is open, the cart will pass directly from the ramp tile below the hatch to the floor tile next to the ramp and hatch.

Alternatively, a hatch can be put over a ramp and the cart's path routed across the hatch itself. If the hatch is open, the cart will instantly dive into the hole (a horizontally-moving cart will treat a downwards-leading track ramp as a track corner and will not jump past the hole but dive into it, provided it is moving at less than derail speed); if the hatch is closed, the cart will pass over it in a straight line. Hatch covers have the same friction as not-engraved floor. Except in case of very slow-moving carts, this higher friction is irrelevant. Should the hatch open while the cart is directly on top of it, the cart will not enter the ramp in the normal way, but rather loses its entire forward momentum and "falls" into the pit. It will pick up speed from the ramp it lands upon, but will behave differently from the usual cases. A hatch cover over a ramp is also a very convenient signal-operable starting mechanism for minecarts. The cart is simply placed on top of the closed hatch cover and gets dropped onto the ramp below when the opening signal is received.

Design:
from the side:

H__
__/#

from above:
closed hatch:
.¢==
open hatch:
.▼==

'''Doors''' also react instantly to signals but require an adjacent wall to be built. Constructed walls can be deconstructed after the door is built, this will not impinge the efficiency of the door. To switch tracks in combination with ramps, the only applicable use of doors consists of placing the door on the level floor right next to a ramp-hole a cart tries to emerge from. If the cart encounters a closed door while trying to ascend, it will fall back into the hole. This design works similarly to the first application of hatch covers. It can cause an operation error when a door receives a close signal the very same instant a cart is passing through it. Since the cart will only spend a single step on the exit tile, this will not happen frequently, but unless you invest in measures specifically to prevent it, it will occur from time to time. The door will get wedged open in spite of the signals indicating it should be closed, but the cart will keep moving normally.

Design:
from the side:

D_
__/#

from above:
closed door:
.▼D=

open door:
.▼==

Floor '''grates''' and floor '''bars''' work similarly to hatches, '''flood gates''', wall grates and vertical bars similarly to doors, with the notable difference that each of these buildings has an added 100-step delay before reacting to a signal. Apart from designs hinging on specific delays before releasing a cart or switching a track, those buildings are largely useless for our purposes.

Raising '''bridges''' can be used in the same way as doors, but react in opposite ways to signals: a raising bridge switched "off" will grant passage, when switched "on" it will block passage. Retracting bridges work like hatches, but can span larger gaps than the one-tile hatch covers and provide less friction. Bridges take 100 steps to react to a signal and will throw, hurl or crush a cart passing over them while they change state, sharply limiting their usefulness in logic.

===Logic, building blocks: Operative ramps===

I built most of my pathing logic with double-ramp pits, with hatches over one of the pit exits to switch the paths while providing sufficient speed to keep the carts in circulation.

The simplest design has been mentioned above - the '''straight double ramp''':

from the side (notionally):
__..__
##\/##

from above:

upper level:
==▼▼==

bottom level:
##▲▲##

track on the ramps: == (EW)

I'll go through the possible cases assuming first a cart coming from the west:

If the exit is open, the cart will roll down the ramp, accelerate and emerge on the other side, continuing east, at increased speed.

If the exit is closed, the cart will roll down the ramp, bump into the obstacle (hatch/door/wall/ceiling) and gain speed from a standstill on the eastern ramp. Due to ramp teleportation, that will give it enough speed to emerge from the pit again and return to the west.

If a cart falls into the pit, either coming from the north or south or dropped (say, by opening a hatch cover it was sitting on), it will accelerate on the pit it fell into and emerge from the adjacent pit. A cart falling into the western pit will try to exit to the east.

Of course there are all kinds of exceptions for particularly fast- or slow-moving carts as well as for carts that enter the pit on a diagonal trajectory.

Another very simple but somewhat less predictable design is the '''"loop ramp"''':

from above:

top level:
=▼
=▼

bottom level:
###
#▲#
#▲#
###
engraved track on the ramps
╗
╝

A cart arriving on the northern track will roll into the northern pit, gains speed on that ramp, teleport-lifts out the southern ramp and leaves on the southern track. Alternatively, it will not gain the proper kind of speed on the first ramp, thus will not get off the southern ramp but accelerates off this ramp too, lifting itself out of the northern ramp and returning along that track. Peculiarly, the "back-swing" only happens in a few cases - it should only occur as an unusual effect of corner pathing - the cart either tries to leave to a diagonally-adjacent tile or towards the wall while on the "up" ramp. In those cases, the cart can collide with the walls of the pit and start over accelerating from scratch or gets redirected to the tile it came from instead of leaving the pit. Whether this happens depends on the exact entry parameters of the cart, both speed and carried-over distance.

A hatch cover or other means of blocking the exit from one of the ramps will ensure a cart will return on its path, which is evidently only an actual switching method if the cart would have passed through originally.

'''Other''' means of combining pairs of '''ramps''' in a single two-by-one pit aren't functionally different from the above two.

It is possible to build functional ramped pits larger than that, although one must keep always in mind that to provide acceleration to a cart a ramp must have at least one wall connection and _exactly_ one "down" connection. Ramps with multiple wall connections work adequately, but a ramp with more than one downward connections will not accelerate carts; apparently the game needs a definite cardinal direction to accelerate a cart towards, if two or three directions are offered, the engine decides to pick "none of the above".

The movement pattern inside larger pits can easily become too complicated to base logical operations on, the largest pits i worked with contain no more than three ramps. There's a lot of potential there, both for fiendishly clever devices and immense operator frustration.

Ceramic industry

2015-11-28T23:48:10Z

Larix: Several small edits

{{Quality|Exceptional|13:30, 26 August 2014 (UTC)}}
{{av}}

==Introduction to Ceramics==

The '''ceramic industry''' produces a variety of goods used for [[Finished goods|trade]], [[Container|storage]], [[block|construction]]s, and [[decoration]] in support of a [[fortress]]. Although the industry produces a fairly limited variety of goods when compared to others, ceramic goods are naturally worth three to ten times the [[Item value|value]] of similar goods made from common [[Stone industry|stone]] or [[Wood industry|wood]], making it a lucrative option for wealth creation. Ceramic goods are divided into three distinct categories (called wares) based on the raw materials used. [[Earthenware]] items are produced from generic [[clay]], [[stoneware]] from [[fire clay]] and [[porcelain]] from the stone [[kaolinite]]. In order to ensure water tight [[earthenware]] containers ([[jug]]s & [[large pot]]s), as well as to increase overall item value, [[earthenware]] items require an additional production step called [[Glazer|glazing]]. The ceramics industry also produces [[Gypsum plaster]] which is critical for Dwarven [[healthcare]]. [[Pearlash]], a critical production material for the [[glass industry]] is also created as a crossover material from the ceramic industry.

All '''ceramic goods''' are produced by a '''[[potter]]''' at a '''[[kiln]]''' which requires a [[fuel]] source.
Regardless of material category, the specific goods that can be produced are:
:[[Jug]]s, [[large pot]]s, [[block|bricks]] (clay blocks), [[statue]]s, [[craft]]s, and [[hive|beehives]]. [[Gypsum plaster]] and [[pearlash]] are also created at a kiln, but use the [[Furnace operator]] instead of the potter labor.

=== Industry Requirements: Resources, Facilities, and Labor ===
* Resources: [[Clay]], [[Fire clay]], [[Kaolinite]], [[Ash]] (from [[Wood]]), [[Cassiterite]], and [[fuel]]
* Facilities: [[Kiln]] or [[Magma kiln]], [[Wood furnace]]
* Labors: Item [[hauling]], [[Potter]], [[Furnace operator]], [[Glazer]], [[Mining]] (for Porcelain / fuel), [[Wood cutting]] (for fuel).
* Crossover industry requirements: [[Gypsum plaster]] stone: [[gypsum]], [[alabaster]], [[selenite]], or [[satinspar]]; [[Potash]] (for Pearlash)

== Categories of Ceramic Wares: ==
==== Earthenware ====
[[Earthenware]] ceramics are made using generic [[clay]] which can be collected from any generic clay [[soil]] tile using the clay collection [[activity zone]], which are are typically the most abundant and readily available ware type. Earthenware items have a base value of 3☼ (equivalent to the highest value stone - [[obsidian]]). Earthenware items are '''not''' water proof and as such require a finishing step of [[Glazer|glazing]] should the intended final use require liquid storage. Glazing can also be used to increase the value of the item. Glazed earthenware products can take a considerable toll on your wood resources, in particular if you are using wood for fuel as well as the glazing material (ash).

==== Stoneware ====
[[Stoneware]] ceramics can only be made from [[Fire clay]] which is a fairly rare type of [[soil]]/clay. As with generic clay, Fire clay is collected using the clay collection [[activity zone]]. Stoneware items have a base value of 4☼. They do not require glazing in order to be water proof.
==== Porcelain ====
[[Porcelain]] ceramics can only be made from [[Kaolinite]], a dark red [[magma safe]] [[stone]] which may be found in large clusters in sedimentary layers. It must be [[mining|mined]] rather than collected, making it a finite resource, (similar to [[crystal glass]] as used in the [[Glass industry]]). Porcelain items have a value multiplier of 10x (equivalent to [[silver]].) Porcelain items are naturally water proof (do not require glazing). While the stone itself is magma safe, porcelain blocks are not.

==== Gypsum Plaster ====
[[Gypsum plaster]], while technically not a direct product of the ceramic industry, is produced at a [[kiln]], and can be included in your ceramic industry layout. Gypsum plaster is used to create casts which are used for [[healthcare]]. Gypsum plaster can be created from any of the following stone types: [[gypsum]], [[alabaster]], [[selenite]], or [[satinspar]]. The stone, along with an empty bag, must be brought to a kiln where a [[Furnace operator]] will pulverize the raw stone and place the plaster powder into the bag for storage.

== Earthenware Production ==
==== Raw Material Collection: Clay ====
[[File:Earthenware Only.jpg|Thumb|right|400px|]]
Earthenware ceramics require generic clay as the basic raw material. There are several types of soil that provide clay, including [[clay]], [[clay loam]], [[sandy clay]], and [[silty clay]]. To collect clay, you will need to do the following:
# Use the [[Activity zone]] ({{k|i}}) function and select an area of soil (preferably in a secure, underground area) that contains clay, then select {{k|c}} to ensure that the zone is designated for clay collection.
# Ensure that at least one Dwarf has the [[Hauling#Item hauling|item hauling]] labor enabled, which is the labor required to collect clay from a zone.
# Select a [[Kiln]] and issue a clay collection order. If you plan on producing a lot of items, it is a good idea to set this order on repeat.
As long as at least one tile of clay is available on your fortress map you will be able to harvest clay indefinitely, but there are associated problems with single source tile collection zones, for example cancellation spam will occur if there are multiple haulers attempting to collect clay while the single tile is occupied. Ideally your collection zone should contain 4-6 tiles of clay providing soil, and should increase based on your overall ceramic production goals. Once harvested, clay appears on the map as a boulder (similar to stone boulders), and it does not require any kind of a container for storage or transport. If there are no [[stockpiles]] set up to store the clay, the clay boulder will be left at the collection site, and will be transported by a [[potter]] once it is needed.

==== Item Production: Firing Clay ====
Earthenware items are produced at a [[kiln]] by a Dwarf with the [[potter]] [[labor]] enabled. Select the kiln and then designate the item to be made. There is no requirement to first create items on a potters wheel, so it is assumed that your potter hand throws the items to be made and places them directly into the kiln for firing, which strengthens and hardens the item. Kilns require a [[fuel]] source, whereas [[magma kiln]]s can produce all items using [[magma]] as the fuel. A standard [[kiln]] will consume one unit of [[fuel]] per job. (For a discussion of fuel sources, see the [[fuel industry]].)

=== Glazing ===
[[File:Glazing only.jpg|Thumb|right|400px|]]
[[Glaze|Glazing]] is a process that covers a selected ware with a substance that, when re-fired, results in a glassy, non porous coating which serves to protect the ware, make it impermeable to liquids, and to enhance its visual appeal. Earthenware must be re-fired with a glaze material (or medium), of which there are two types ([[ash]] and [[cassiterite]] / tin) to produce a completed glazed product. Earthenware ceramic containers must be glazed in order to hold [[water]] or more importantly [[booze]] and [[oil]]. Glazing also increases the value of the items, the amount determined by the type of glaze medium used. Glaze mediums are applied at a kiln to [[jug]]s, [[statue]]s, [[large pot]]s, and [[craft]]s made from either stone or ceramics, by a [[glazer]]. Earthenware items re-fired in a kiln with a bar of [[ash]] produce [[ash glaze]]d items which adds 50☼ to the items value. Earthenware items re-fired with boulders of [[cassiterite]] produce [[tin glaze]]d items which adds 100☼ to the items value. [[Cassiterite]] is an ore which, when smelted, produces [[tin]], and is typically rare, and usually cannot be purchased from caravans. Note that glazes are not products in themselves, you do not make a glaze and then apply it to the ware. It is effectively a unique (to ceramics & some stone items) form of item decoration.

[[File:Ash Only.jpg|Thumb|left|400px|]]

==== Production of Glaze Medium ====
* [[Ash]] bars are produced by a [[wood burner]] at a [[wood furnace]] using the logs of felled [[tree]]s.
* [[Cassiterite]] is an [[ore]] of [[tin]], collected by [[mining]]. It is typically rare, and when present, is used to support the [[metal industry]].
{{clear}}

== Stoneware Production: ==
[[File:Stoneware Only.jpg||Thumb|right|400px|]]
==== Raw Material Collection: Fire clay ====
Stoneware is notable in that it can only be made from [[fire clay]]. The collection of fire clay is done exactly the same as regular clay collection.
==== Item Production: Firing Fire Clay ====
Stoneware items are produced by firing them at a [[kiln]] by a Dwarf with the [[potter]] [[labor]] enabled. Kilns require a [[fuel]] source, whereas [[magma kiln]]s can produce all items using [[magma]] as the fuel.
{{clear}}

== Porcelain Production: ==
[[File:Porcelain only.jpg||Thumb|right|400px|]]
==== Raw Material Collection: Kaolinite ====
The stone [[kaolinite]] must be mined and collected as with other stone resource gathering. It appears dark red in color, and is a sedimentary stone found in large clusters. The presence of kaolinite and wood or [[bituminous coal]] (for fuel) in abundance can result in rapid (sometimes <del>too rapid</del> lots of [[fun]]) wealth generation for a fortress. If you do not have any [[kaolinite]] readily available, you may be able to procure some through [[trading]]. Check with your [[outpost liaison]] and request the stone. They probably won't bring a lot, but it will give you something to work with.

==== Item Production: Firing Porcelain ====
Porcelain items are produced at a [[kiln]] by a Dwarf with the [[potter]] [[labor]] enabled. Kilns require a [[fuel]] source, whereas [[magma kiln]]s can produce all items using [[magma]] as the fuel.

== Ceramic Industry Output ==
*'''Jugs and Large Pots:''' Given that there is considerable work required to use [[earthenware]] jugs and large pots for liquid storage (i.e. glazing), it is reasonable to question their utility. One consideration for their use would be the consideration item [[weight]]. Earthenware is the lightest of the three ware types with a [[density]] of 1360, which is much less than almost every type of stone, and also much less than all three types of glass (2600). [[Jet]] (stone) is the exception, as its density is just below that of earthenware (1320). The lightest normal (not [[adamantine]]) metal is [[aluminum]] at 2700. Large pots used for [[booze]] storage are typically hauled all over your fortress, so the lighter and thereby faster they are, the more efficient they become. So the extra effort of producing glazed earthenware large pots will result in the largest, and effectively lightest liquid containers, (unless, of course you have gobs of adamantine to spare.)
*'''Crafts:''' The ceramic industry is one of the few industries that does not benefit from a nearby [[craftsdwarf's workshop]]. As with the [[metal industry|metal]] and [[glass industry|glass industries]], a unique facility is required to create crafts, and for ceramics this is the [[kiln]]. That said, the kiln cannot be used to make ceramic goblets, instruments, or toys.
*'''Ceramic Bricks (aka blocks):''' While all ceramic bricks are [[fire-safe]], they are not [[magma safe]], (even though porcelain is made from the magma safe stone kaolinite). Ceramic bricks provide no functional benefit over stone blocks, and are less useful than the magma safe glass blocks produced by the glass industry. If kaolinite is set to "non-economic" via the {{k|z}} Stone menu, a mason can convert one kaolinite boulder into four magma-safe blocks.
*'''Statues:''' If high value decorative metals ([[gold]], [[silver]], [[platinum]] & their [[metal|alloy]]s) are in short supply, and you are lucky enough to have some kaolinite, porcelain [[statue]]s can be used to create high value rooms.

== Benefits of Skilled Labor & Strange Moods ==
A skilled [[potter]] will generate items of a higher value. If fuel is in ready supply, a [[potter]] can be quickly skilled up by churning out earthenware craft items. Neither the [[potter]] nor [[glazer]] labor qualify for [[strange mood]]s. It can be worthwile to give these dwarves some experience in a desirable "moodable" skill like [[weaponsmith]] to avoid getting another legendary [[woodcrafter]].

Due to a bug, [[glazer]]s currently receive no experience for glazing, and will therefore never improve in [[skill]]. As the values associated with glazing are based on the material used, it can be assumed that high skill in glazing would likely only reduce the amount of time to complete production, rather than increase value. {{bug|4577}}

==Advanced Industry Management==
# '''Optimal Clay Collection:''' A robust ceramic industry will demand a lot of clay, so it is a good idea to put a dedicated kiln on repeating collection orders, preferably with nine redundant iterations to prevent the [[manager]] from tasking any other production from that kiln. Clay collection is time-consuming, and if you are outstripping your supply you will start to see job cancellations as the potter's increasing skill / speed of production outpaces the clay supply. To ensure a smooth production process have several dwarves with item hauling enabled for each kiln set to gather clay and make sure you have a large gathering area.
# '''Managing your Stocks:''' Clay is [[stockpile]]d under Stone, and each clay boulder takes up a single tile, so it's a good idea to create fairly large clay stockpiles close to your kilns. [[Wheelbarrow]]s may be useful for collecting clay, but it needs to be determined if a second collection trip occurs for each clay boulder produce in collection, (e.g. one trip to harvest the clay and one to transport it) which might diminish the utility of the wheelbarrow. It may be more efficient to create a stockpile right next to your collection area, and then create a second stockpile next to your kilns, which takes from the first (in which case wheelbarrow use will save time.) Alternatively, quantum stockpiles are a useful space saving, (but management intensive) alternative. Kaolinite boulders also takes up a full tile, so somewhat large stockpiles are useful for that as well.
# '''Ware Specific Production:''' If you are fortunate enough to have both generic and fire clay, as well as kaolinite, or you purchase the material from caravans, you will want to control the ceramic item produced by the related ware type. This is challenging, as you can't fine-tune what your dwarves will use through the kiln menu or the Manager's screen. You can't tell them exactly what material to fire or what kind of thing to glaze, only what to make and what type of item to glaze. This can be solved by using the 'give' and 'take' options within stockpiles, and the use of dedicated kilns. Ideally you should create a single kiln for each ware type and link it to a dedicated stockpile using the take option. You should also link the kiln to a fuel stockpile, (you can use the same fuel stockpile for each kiln). (See [[stockpile]] for additional details.) Another approach uses the fact that dwarves will always go for the nearest available resource. Make a custom dedicated stockpile right next to a kilns isolating the raw material, and you can more or less force the potters to use that material over another. If you only have one production kiln, this has the major disadvantage of requiring you to haul raw material back and forth when you change ware type, as dwarves will have to carry away the no longer needed material and carry in the newly desired one.
# '''Glaze Specific Production:''' If you have lots of wood and cassiterite available allowing for both glaze types, you will face the same production problems as you would with multiple ware source material. Optimally, dedicate one kiln to a stockpile with a specific glaze material (ash or cassiterite), a fuel stockpile, and an earthenware goods stockpile. You can chose (control) the item to be glazed, and by linking the kiln to a specific glaze material stockpile, you will also control the glaze type. It is also useful to keep a [[wood furnace]] producing ash and a wood stockpile close by, which should keep your stocks of ash readily available. Ash is produced as a bar, and is stored in [[bin]]s, so your ash stockpile can be fairly small and still hold a considerable amount of ash.

=== Ceramics Industry Integrated Flowchart ===
{{collapsible|Production Flowchart (click to enlarge)|
[[File:Ceramics Flowchart (All).jpg|thumb|800px|center|Ceramic Industry Production Flowcharts]]
}}

== Ceramic Industry Crossover ==
# '''Glass Industry:''' As there is some natural overlap with the [[glass industry]] with regard to materials required, it may be useful to set up your ceramics industry near your glass industry. [[Potash maker]]s use ash at [[Ashery|asheries]] to produce [[potash]], which in turn feeds kilns that make [[pearlash]], which is used to make [[clear glass]] and [[crystal glass]]. As ceramics already requires ash production, and uses kilns as the primary production facility, there is some efficiency advantage to be had by keeping the distance between the two industries short.
#'''Jewelry Industry:''' Clay can be used by a [[gem cutter]] to advance their cutting [[skill]]. As clay is effectively unlimited, and as it requires no processing step (unlike [[glass]]) in order to be used, it is a very efficient material for training your gem cutters, and it can be transported more quickly than stone. The main drawback is the time it takes for an [[hauling|item hauler]] to gather the clay.
#'''Fuel Industry:''' The ceramic industry relies on fuel to function properly. Until magma becomes available, a steady supply of [[coke]] or [[charcoal]] will be necessary.
#'''Wood Industry:''' The glazing of earthenware products relies on [[ash]]. If you plan on developing a large ceramic industry, integration of ash production directly into the ceramics facility layout is recommended.

== Notes, Tips, and Tricks: ==
* '''Embark:''' To ensure that you can set up a basic ceramic industry, make sure that either '''"clay"''' or '''"shallow clay"''' in shown as available in the [[embark]] screen. The specific type of clay available, (such as fire clay) cannot be determined ahead of time, (unless you use DFHack's pre-embark estimate, which is not always accurate.)
* Raw clay boulders can also be used in construction, similar to stone boulders.
* It is possible to create clay soil tiles in areas where there are no naturally occurring tiles. When an underground plant ([[tree]]s, [[shrub]]s, [[grass]] or moss) grows on a muddy stone floor tile (after discovering a [[Caverns|cavern]]) and is either trampled, gathered, cut down or removed via building a dirt road on top of it, the floor tile turns into a soil type appropriate to the [[biome]] - for biomes which lack soil layers altogether (such as mountains and glaciers), a random soil type will be selected, which might sometimes be clay.
* Ceramics are considered to be [[fire-safe]] but typically are not [[magma safe]]. Raw clay is not [[fire-safe]].
* '''Stupid Dwarf Ceramics:''' Create an oriental themed fortress using porcelain statues, and ceramic blocks for internal construction. Use fire clay to create 1000 Terracotta statues for an elaborate tomb in which to enshrine a dead [[noble]].

{{D for Dwarf}}
Being somewhat sensitive as to their height (or relative lack thereof) in comparison to other sentient races, the ingenious yet vertically insecure Dwarves are prone to compensate for their diminutive stature by making "really big things". Take, for example, the ceramic statue. Given that the average statue is large enough to take up the entire space of a tile upon which it is placed (thereby prohibiting passage), and therefor it must be considerably larger than a chest or cabinet (large furniture items which do allow pass through), it can only be surmised that the statues are quite large. It follows that a "really big kiln", (say 10-12 feet tall) would be required to fire one of these "really big statues" using incredibly accurate temperature control. For a Dwarf, these feats of engineering are taken in (short legged) stride. Given the size, weight, and relative fragility of an un-fired statue, it must be assumed that your basic kiln also includes a crane (or two) and the necessary scaffolding surrounding the kiln that will allow careful placement of the statues within the massive firing chamber.

{{Category|Industry}}
{{Ceramic industry}}
{{Industry}}

DF2014 Talk:Quarry bush

2015-11-18T19:58:45Z

Larix:

Just putting in a quick note. I've verified the Plant Gathering section in several forts. i can't recall if you often get more than just one leaf capture from an herbalist or not, so i just listed it as adding 1 extra leaf. --[[User:MisterB777|MisterB777]] ([[User talk:MisterB777|talk]]) 16:06, 21 April 2015 (UTC)

This article says the the Quarry Bush Press Cake is very high value. However, the linked article for Press Cake has a table that lists all cakes as low value. Which is true? [[Special:Contributions/104.1.93.93|104.1.93.93]] 18:51, 18 November 2015 (UTC)

: Quite right, press cake and paste are minimum-value. I've edited it, thanks for spotting. --[[User:Larix|Larix]] ([[User talk:Larix|talk]]) 19:58, 18 November 2015 (UTC)

Quarry bush

2015-11-18T19:55:11Z

Larix: /* Rock nuts */ corrected and consolidated

{{Quality|Exceptional|15:01, 29 January 2015 (UTC)}}
{{plantlookup|uses=
* [[Food]]|wiki=no}}
{{av}}

The '''quarry bush''' is one of the six known [[subterranean]] [[crop]]s, and as such it may only be grown [[underground]]. They can be [[farming|planted]] in [[Spring]], [[Summer]] and [[Autumn]].

Quarry bushes may be [[plant processing|processed]] at a [[farmer's workshop]] into [[bag|bags]] of quarry bush leaves, which then must be [[cooking|cooked]] at the [[kitchen]] to be edible. You will need an empty bag to be available for this task.

Processing quarry bushes at a [[farmer's workshop]] requires one [[bag]], and will produce 5 quarry bush leaves (and one rock nut) for every plant in a given stack of quarry bushes. Quarry bush leaves will be removed from their bag if taken for cooking while still in a farmer's workshop.

[[Cook]]ing quarry bush leaves can result in very large stacks of Prepared Food, thus saving space and [[barrel|barrels]]. In a fortress that relies on selling large expensive stacks of Prepared Food, quarry bush leaves are great filler: a lavish meal made from [[whip wine]] and [[cheese|dwarven cheese]] with two stacks of quarry bush leaves for filler is worth almost ten times more than an easy meal made from wine and cheese alone.

Quarry bushes cannot be [[brewing|brewed]] into [[alcohol]].

==Rock nuts==

Quarry bush [[seed]]s are known as '''rock nuts'''. Although their material definition marks them as being edible raw, dwarves will '''not''' eat them.

Rock nuts can be milled at a [[millstone]] or [[quern]] into rock nut paste, using the {{k|s}} job to mill seeds/nuts to paste. This paste can then be used in cooking, or pressed at a [[screw press]] into a rock nut [[Press_cake|press cake]] and a [[jug]] of rock nut [[oil]].

Both the rock nut paste and rock nut press cake are cookable and considered a single food category, referred to as "rock nut" in the [[Status#Kitchen_Status_Screen|cooking permissions screen]] (not to be confused with "rock nuts", the entry for the seeds), the Stocks screen compacted view, and Prepared meal descriptions.

The rock nut oil can be cooked or used in place of tallow to make [[soap]].

Use moderation when commanding rock nuts converted to paste - the nuts are required to re-plant the crop; if you grind up your entire supplies, you can't grow new quarry bushes.

The main attraction of grinding up rock nuts is the production of rock nut oil as soapmaking ingredient. Both the globs of paste and the press cakes are minimum-value cooking ingredients, at 1☼ each. When looking at cooking ingredients, the quarry bush leaves completely overshadow what can be gained from an oil-pressing operation.

==Plant Gathering==

Due to a quirk in the Raws, a wild Quarry Bush plant growing underground (not planted) can yield 6 leaves if placed in a [[Activity_zone#Plant_collection|Gathering zone]]. An [[Herbalist]] will first harvest a single leaf growth, then collect the entire plant, which can be processed as usual afterwards for 5 more leaves.

==Food Value==

Thanks to the increased value of rock nut oil as a by product of rock nut processing, the highest potential value of products gleaned from one quarry bush plant is 56 (five leaves at a value of 10 each, plus oil and a press cake).

*Grow time: 500
*Plant value: 2
*Spice value: 10(x5)
*Seed value: 1
*Mill value: 1
*Press cake value: 1
*Press oil value: 5

{{gamedata}}
{{Plants}}

Ivory

2015-11-15T15:02:20Z

Larix: Teeth are explicitly mentioned in the job descriptions, "treated as ivory" makes no real sense.

{{Quality|Fine|08:16, 10 August 2010 (UTC)}}{{av}}

'''Ivory''' is a resource used to create or decorate crafts at the [[craftsdwarf's workshop]]. The exact material category when crafting is "ivory/tooth", signifying that some teeth (notably those of large carnivores) can also be used for the job.

Ivory and teeth are obtained from [[butcher]]ing certain animals at the [[butcher's shop]]. Loose teeth may also be produced by bouts of teeth-tearing [[combat]] by animals and invaders that drop no teeth or ivory when butchered. Such knocked-out teeth are not useable for crafting.

[[Goblin]]s will often wear [[jewelry]] made of [[troll]] ivory.

{{Translation
| dwarven = sosad
| elvish = ciquara
| goblin = stuz
| human = bemeh
}}

Bone carver

2015-11-15T14:49:02Z

Larix: Teeth aren't considered ivory, they're an explicitly mentioned crafting material in their own right (in a shared job).

{{Quality|Exceptional|00:35, 12 June 2010 (UTC)}}
{{Skill
| color = 1:1
| skill = Bone Carver
| profession = [[Craftsdwarf]]
| job name = [[Bone carving]]
| tasks =
* Decorate with [[Bone]]
* Decorate with [[Shell]]
* Make [[Bone]] [[Craft]]s
* Make [[Shell]] [[Craft]]s
* Make [[Bone]] [[Bolt]]s
* Make [[Bone]] [[Armor]]
* Make [[Totem]]
| workshop =
* [[Craftsdwarf's workshop]]
| attributes =
* Agility
* Creativity
* Spatial Sense
* Kinesthetic Sense
}}
{{av}}

'''Bone carver''' is the skill related to the '''bone carving''' [[labor]]. Bone carvers make [[bone]], [[shell]], [[ivory|ivory/tooth]], [[horn]] and [[pearl]] [[finished goods|goods]] at a [[craftsdwarf's workshop]]. These include bone [[bolt]]s for [[crossbow]]s and [[totem]]s from [[skull]]s. Bone carvers also [[decorate]] objects with these materials.

==Notes==
*Hooves are considered by the craftsdwarf's workshop to be horn.

{{skills}}

DF2014 Talk:Steel

2015-11-05T17:12:44Z

Larix: Created page with " == "100% recipes" == Converting iron to steel is a two-step process - first, pig iron must be manufactured, then the pig iron combined with raw iron to steel. Both the produ..."

== "100% recipes" ==

Converting iron to steel is a two-step process - first, pig iron must be manufactured, then the pig iron combined with raw iron to steel. Both the production of pig iron and that of steel take one carbon and one fuel (and a flux stone).

Thus, each bar of steel consumes one coal as reagent when working with magma, two bars as reagent and fuel (for every ''single'' bar of steel) when working without magma. One bituminous coal converts to nine coal with magma, to eight (effectively) when fuelled with coal; wood produces one charcoal per log.

I corrected the amounts of fuel, which were listed at barely half the actual requirements, but i'm not convinced writing out the info that's already clearly laid out in the paragraph above is useful.--[[User:Larix|Larix]] ([[User talk:Larix|talk]]) 17:12, 5 November 2015 (UTC)

Steel

2015-11-05T17:05:20Z

Larix: /* 100% Reaction Recipes */ corrected amounts and spelling for "full recipes", commented it out for now.

{{Quality|Masterwork|23:34, 27 April 2013 (UTC)}}
{{Alloy3
|name=Steel
|color=0:7:1
|color1=0:0:1
|color2=0:0:1
|color3=7:0:1
|tile3=•
|uses=
* [[weapon|Melee Weapons]]
* [[Crossbow]]s
* [[Bolt]]s
* [[Pick]]s
* [[Armor]]
* [[Anvil]]
* [[Metalsmith's forge|Metal crafting]]
|recipe=
* 1 [[iron]] [[bar]]
* 1 [[pig iron]] [[bar]]
* 1 [[flux]] [[stone]]
* 1 [[fuel|coal]] [[bar]]
|properties=
* [[Material value]] 30
}}{{av}}

'''Steel''' is the best common metal for smithing most [[weapon]]s and [[armor]]. Steel also has the third highest value, tied with that of [[gold]].

Steel can be created at a [[smelter]] by a [[dwarf]] with the [[furnace operator]] [[labor]] activated.

==Sedimentary Layers==

To smelt steel, you will need [[iron]] ore, [[flux]] stone, and [[fuel]]. Flux is used to remove impurities including carbon during the smelting process, while fuel (coke or charcoal) removes oxygen and puts back in a small amount of carbon. The end result is steel: iron with just the right amount of carbon in it. The three ores of iron (hematite, magnetite, and limonite) can only be found in [[sedimentary layer]]s, with the exception of hematite, which can occasionally be found in igneous extrusive layers. Furthermore, four of the five [[flux]] stones (calcite, chalk, dolomite, and limestone) are found only in sedimentary layers, as well as both [[coal]] ores (bituminous coal and lignite) for making [[coke]] fuel.

If you have no sedimentary layers at your fortress site, your only hope to make steel is with:
* hematite from [[igneous extrusive]] layers, or iron ore imported from [[trade]] caravans
* melting iron items brought by [[siege]]rs and caravans
* marble from [[metamorphic]] layers, or imported [[flux]]
* coke from imported [[bituminous coal]], or [[charcoal]] from [[wood]]

Note that bituminous coal, like most stones, costs only 3☼ at embark or from caravans. With [[Sample_Starting_Builds#Minmax_build|a cunning enough starting build]], it is possible to embark with enough for several hundred units of coke. This is only possible if your parent [[civilization]] has access to coal; otherwise it will not be available at all, meaning you will have to cut down trees and burn a log to make charcoal for every bar of steel, even with access to magma smelters. This is much easier with the multi-tile trees in DF2014.

==Recipe==
Steel production is fairly complex compared to the creation of other [[alloy]]s. ''Important note'': in steelmaking, [[coke]] or [[charcoal]] is also used as an ingredient, apart from its use as [[fuel]]. A conventional (non-magma) smelter will require an additional unit of fuel in each reaction.

The first step is '''to create [[pig iron]]''':

:*1 bar of [[iron]]
:*1 [[flux]] stone
:*1 unit of [[fuel]] (as a source of carbon)
:*1 unit of fuel, or magma (to heat the forge)
:'''Produces''':
:*1 bar of pig iron

[[Image:SteelSword.png|thumb|right|200px|''A [[steel]] [[short sword]].'']]

The second step combines the pig iron with plain iron '''to produce steel''':

:*1 bar of iron
:*1 bar of pig iron
:*1 [[flux]] stone
:*1 unit of fuel (as a source of carbon)
:*1 unit of fuel, or magma (to heat the forge)
:'''Produces''':
:*2 bars of steel

The overall reaction consumes 2 bars of iron, 2 units of flux, and 2 units of fuel as ingredients (plus an extra 2 fuel at a conventional smelter for heating). This produces 2 bars of steel.

Remember that smelting [[iron]] [[ore]] also requires 1 unit of fuel at a conventional smelter, producing 4 bars of [[iron]], which translates to half a unit of additional fuel used in the recipe above (although you will need a full unit up front.)

[[File:SteelChart.png|center|485px]]



{{Translation
| dwarven = deler
| elvish = inire
| goblin = zodsto
| human = kadest
}}

{{gamedata}}
{{metals}}

DF2014 Talk:Plant fiber

2015-10-29T08:25:21Z

Larix:

{{newpage|type=cp|113.240.83.39}}

deleted ad link.--[[User:Larix|Larix]] ([[User talk:Larix|talk]]) 08:25, 29 October 2015 (UTC)

Plant fiber

2015-10-29T08:23:02Z

Larix: External .com link, probably unsolicited ad.

{{av}}
{{Quality|Fine|13:04, 22 June 2010 (UTC)}}

'''Plant fiber''' is a type of [[thread]], created from harvested plants by a [[thresher]] at a farmer's workshop. It can then be [[dyeing|dyed]], used to create [[cloth]], or used by a [[suturer]] in a [[hospital]]. Producing plant fiber threads will also create seeds for the corresponding crop.

There are currently eight crops which can be used for textile production: [[rope reed|rope reeds]], [[pig tail|pig tails]], [[hemp]], [[cotton]], [[ramie]], [[flax]], [[jute]] and [[kenaf]]. Pig tails are the only fiber-producing crop which can be grown [[underground]]; the others are all above-ground crops. The value of the plant fiber does not change depending on the crop used.

When used to create cloth, all plant fibres have a material value of 12☼, twice as much as [[wool]] and low-value [[silk]], but half as much as the precious [[giant cave spider]] silk.

==See Also==
* [[Silk]]
* [[Yarn]]
* [[Textile industry]]

Morganite

2015-10-23T07:43:40Z

Larix: Reverted link to nowhere, fixed grammar. "Other games" section deleted, seems unrelated to DF.

{{Quality|Fine}}{{gemlookup/0}}{{av}}

'''Morganite''' is a purple, semi-precious [[gem]] found within [[granite]], [[schist]], and [[marble]].

==In Real Life==
Morganite is a pink beryl named after the famous industrialist and gem collector J. P. Morgan. Like most beryls its base chemical composition is Be3Al2Si6O18, its distinctive pink color and mild fluorescence under UV come from impurities in the matrix.

{{gamedata}}
{{gems}}

DF2014 Talk:Minecart

2015-10-09T20:15:06Z

Larix: /* Physics, "numbers behind the scenes" */ new section

Minecart

2015-10-09T20:00:14Z

Larix: /* Numbers behind the scene */ Removed some strange claims. See discussion.

{{Quality|Masterwork|08:15, 19 May 2015 (UTC)}}
{{av}}
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]].

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.

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

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

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

After you have created the stops and assigned a cart to the track, you must create logic routes connecting several stops and designate starting conditions for each stop. This is done with the {{k|h}}auling key. The most basic conditions are how the cart's movement is initiated and in which direction the cart should start moving. Carts can be either 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.

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.

===Capacity and weights ===
Minecarts have five times the [[Weight|capacity]] of [[wheelbarrow]]s.

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

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

'''Weights of different carts'''

{| class="wikitable"
|-
! Type of cart
! Empty cart
! Fully loaded (items)
|-
| oaken minecart
| 28Γ
| 378Γ (10 oak logs)
|-
| platinum minecart
| 856Γ
| 10482Γ (83 gold bars)
|}

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

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

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

====Simple tracks====

'''Carved'''

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

'''Constructed'''

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

====Ramps====

'''Carved'''

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

'''Constructed'''

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

'''Examples of ramps'''

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

Carving track corners into ramps is rather unintuitive and complicated. Since engraving tracks always requires two tiles to connect in a straight line as input, you have to give two separate designations for a single job: a track bit from the ramp tile to the "below" direction and another one to the wall of the "upward" direction. If you wanted to change direction on a ramp from east to north:
{{diagram|spaces=yes|\
z +0 z +1
░░░░░ ░░░░░
░░░░░ ══╗░░
=▲░░ ░░▼░░
░░░░░ ░░░░░
}}
you would need to connect the ramp on z +0 both to the west and to the north by issuing two "carve track" commands, one selecting the ramp and the track tile to the west, and another connecting the ramp tile with the wall to the north. An engraver would then carve a NW track corner into the ramp, allowing carts to pass the corner correctly both going up and down. Such track corners are perfectly serviceable for guided carts, but moving down a route of several of them by pushed or ridden cart is problematic - ramps on corners behave very counter-intuitively, resulting in loss of speed when going down and diagonal movement when going up.

Moving to and from ramps (or between ramps "pointing" in different 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}}

{{anchor|Tracks}}

=== Hauling route ===
A hauling route is a list of directions describing how and under what conditions a minecart will move. The proper setting up of routes is essential for a working rail system. Routes, stops, departure conditions and stockpile links are managed from the {{k|h}}auling menu.

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

New routes are created with the {{k|h}}auling key. Existing ones can be removed (without confirmation) with the {{k|x}} key, and also {{k|n}}icknamed. Before operating, the route must have a {{k|v}}ehicle assigned to it (this can be done with either the route or a stop selected). Assigning a full minecart to a route may result in a slow hauling job if the contents are heavy.

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

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.

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

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

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

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

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

Counter-intuitive to their construction method, Track Stops are considered [[building]]s and must be removed by {{k|q}} {{k|x}}.
* See [[#More_on_Track_stop |More on Track Stops]]

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

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

[[File:minecart-example-1.png|Stockpiles designated.]]

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

Next, carve the track:

[[File:minecart-example-2.png|Track carving designation.]]

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

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

[[File:minecart-example-3.png|Track carved.]]

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

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

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

[[File:minecart-example-6.png|Track stop constructed.]]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Now we've got everything set up:

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

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

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

=== Troubleshooting ===

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

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

'''Possible Causes:'''
* 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.
** 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...)
* 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.
* The track stop might not be built on top of a track. The track stop must be deconstructed to remedy this issue.
* Your track might not be built correctly. Make sure all connected tracks between destinations are not one-way tracks.
** This can be especially confusing with ramps. To carve a two-way track on a (natural) ramp, you must designate the ramp and one square beyond in the direction you want the track to go.
** Ramps '''must''' have a solid 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.
* The desired/kept items might not be configured correctly.

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

'''Possible Causes:'''
* 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".
* The take conditions must correspond with the contents of the stockpile.
* 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.)
* Make sure the minecart itself has not been designated to be dumped (such as when using mass-dump).

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

'''Possible Causes:'''
* 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.
* 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).

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

'''Possible Causes:'''
* 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

==== Impulse ramps ====
Carts can be given momentum without rollers or changing z-level 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.

Example of straight impulse acceleration:

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

If a cart enters from the left, it will speed up on every track/ramp and exit to the right going very very fast - more than one tile every step. If it enters from the right then it will bounce back impulsed by the ramp if it's going slow enough.

As another oddity, carts coming from ramps will in some cases "teleport" through most of the next tile. This is called the "checkpoint effect", and is explained in detail in the Physics section, below. This negates the deceleration of the next tile if it is a ramp "angled" in a different direction. You can just make an upward spiral alternating impulse ramps and regular upward ramps. It takes no power, is quick and cheap to build, requiring only channeling and track carving, and the cart goes up fast, but not so fast that it launches its contents.

Example of an impulse elevator:

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

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

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.

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

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

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

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

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

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

=== Controlling traffic ===

==== Switching ====

As 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.
{{diagram|spaces=yes|\
->
A ════┤≡════ B
┤ : roller pushing to East
≡ : door
}}
The roller pushes the cart east, but until the "departure condition" is fulfilled, the door remains closed and blocks the path.

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

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

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

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

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

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

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

==== Controlling Speed ====


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

Will derail at > 0.5 t/st:

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

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

O : wall/column.
}}

This behavior can be used to build a "speed limiter", that will ensure that when a minecart exits it is traveling below derail speed:
{{diagram|spaces=yes|\
░░░░ ░░░░░ ░░░░░
in ═╔═╗░ ░╔S╗░ ░╔S╗░
out ═╬═╝░ out ═╗═╝░ out ═╗═╝░
░╚S╝░ ░╚═╝═ in ░╚S╝░
░░░░░ ░░░░ ║░░░
in
░ : wall
S : Track Stop (High Friction or lower)
}}
If the minecart is traveling below derailment speed, it will not be affected; if above, will be slowed down and checked again. Granted, you could do the same just with track turns, but it may take a lot of turns and time.

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

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

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

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

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

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

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

== Physics ==


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

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

The difference between "Push" and "Ride" is whether the dwarf will go along with the cart or not.
{{DFtext|Push}}: the dwarf will give the cart an initial push, not enough to go up a ramp, but enough to go some way along flat track, and the dwarf will remain at the first stop, ready for a new job.
{{DFtext|Ride}}: the dwarf will give the cart the same initial push and then hop aboard the cart riding with it to the next stop.
{{DFtext|Guide}}: minecarts seem to ignore all laws of physics. That is:
*Ignore the weight of any and all items inside. Therefore:
**Move at the speed of the dwarf that is guiding them. It is thus recommended to pick the most [[attribute#Agility|agile]] of your dwarves for cart-guiding tasks.
*Ignore working rollers.
*Will ''not'' collide with other guided carts even when a full frontal collision would be expected.
*Will go up ramps like nobody's business.
This is therefore the recommended method of transport for simple non-powered rail systems, despite it diverting a dwarf from other, potentially more important tasks.

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

=== Numbers behind the scene ===

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

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

Every tick the cart adjusts sub-tile position units by the amount of their velocity, as well as adjusts velocity depending on current tile (speed is reduced by the "friction" of the tile, or accelerated if going "down" a ramp). On flat (non-ramp) tiles, the cart will move to the next tile when the sub-tile position goes 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.

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.

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.

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

Water of depth 7/7 provides a friction of about 10000 per step, as does maximum-depth magma. This higher friction may not apply to very slow-moving carts.

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

Note, again, that nearly all of these values are applied ''per tick'', rather than ''per tile''. The exceptions are curves, which is 1k deceleration per direction change at the 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.

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

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

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

Each non-ramp tile is functionally composed of 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.

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.

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

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.

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]]".

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:

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

If a cart is passing West-to-East over this setup, the valid ramp to the South will apply "Southward" acceleration to the cart (-Y velocity) as it passes through the ramp tile. Assuming it only spends 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.

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

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

If the tile to the South is a wall at that point, it will be considered a collision with a wall that ''halts all motion''. If the tile is open, 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.

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

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

Curves are applied "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.

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.

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.

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

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

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

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

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

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

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

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

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

If there is a curve the cart will respect, it checks for derailment. Carts derail 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.

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

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

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

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

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

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

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

Falling carts accelerate similarly to the way that a ramp will accelerate a cart in a special z-only velocity that only applies to airborne carts. (Actually, 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.

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

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

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

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

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

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

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

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

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

=== Corner Ramp Derail ===

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

This is caused by the fact that a cart, after turning the bend in the track 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.)

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

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

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

This seems to be because ramps have a slightly longer length than regular tiles - 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.

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

Another useful thing to note about this exploit is that carts traveling at no less than 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.

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

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

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

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

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

Three successive ramps results in the highest attainable speeds.

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

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

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

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

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

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

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

== Adventure mode ==
In addition to being used for hauling, minecarts can also be ridden in [[adventure mode]]. (Adapted from forum thread {{cite forum|122903/4258212}})

# If the minecart is in your inventory, drop it. If it is already on the ground, proceed to step 2.
# Press {{k|u}} when you are 1 tile away from the minecart (or standing on the same tile as the minecart).
# You will be presented with the following options:
[[File:minecart adventure mode menu.png|left]]
{{clear}}
* If you {{DFtext|Push}} the minecart, it will move a few tiles in the direction you chose. Physics comes into play here, so it will gain/lose speed depending on the usual factors.
* If you {{DFtext|Ride}} the minecart, you will hop into the minecart, even if you were a tile away, and it will move in the chosen direction with you in it. It will gain/lose speed depending on the usual factors. Whilst the minecart is in motion, you should press {{k|.}} to skip your turn; if you attempt to move whilst the minecart is still in motion, the laws of physics come into play, and you will take [[wound|damage]]. 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.

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

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

== See also ==
* [http://www.bay12forums.com/smf/index.php?topic=109460.0 The "How Does Minecart" Thread] by '''Girlinhat''' et al.
* [http://www.bay12forums.com/smf/index.php?topic=112831.0 SCIENCE: Quantifying minecart physics] by '''Snaake''' et al.
* [http://www.bay12forums.com/smf/index.php?topic=129676.0 How to build a Multi-cart Ore to Magma Minecart Project without needing power] by '''WanderingKid'''.
* [http://www.bay12forums.com/smf/index.php?topic=144328.0 My very own Minecart Education Thread. Ten Lessons, now complete.] by '''Larix'''.

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

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

[[ru:Minecart]]

Tutorials

2015-10-05T19:16:48Z

Larix: Moved PeridexisErrant's tutorial to the "older versions" area; looks to be pre-0.34. Btw - it threw a security warning under Firefox for bad certificates.

{{av}}

[[File:NoFunAllowed.jpg|thumb|right|Of course, instead of trial and error you could also just read the wiki...]]
Dwarf Fortress started as a pretty complex game back in the days when it was 2D and barely had a quarter of the features it has now. It's easy to get overwhelmed when you first fire it up. Don't worry though, following a tutorial is a very easy way to learn the basics of the game in an afternoon.

Don't worry if you don't understand why you do things on your first run, even after reading the tutorial's explanation. If one particular thing bugs you, try starting a new fort and skipping it, then seeing what goes wrong! Especially in the current version, trial and error is great way of having lots of [[fun]].

== Installing and Running the Game ==

If you have not installed the game yet see [[Installation]].

== Learning Fortress Mode ==

Most of the tutorials were written for the older (40d) version of Dwarf Fortress. But nonetheless, they are still helpful. If you get stuck within a specific aspect of the game then [[Special:Search|search]] the wiki and don't hesitate to ask questions in the [http://www.bay12forums.com/smf/index.php?board=7.0 forum].

The following tutorials will walk you through world generation, embarking with your 7 dwarves, game basics, and building a full-fledged fortress.

=== Recommended tutorials and wiki articles===
[[File:FlowchartDF.png|thumb|right|200px|[[::From Caravan to Happy Dwarves|From Caravan to Happy Dwarves]] - This is a flowchart showing approximately what sequence of actions players usually take when starting up a new fort.]]
'''For v0.40:'''
*[[Quickstart guide|The Fortress Mode Quickstart Guide]]
*[http://dffd.bay12games.com/file.php?id=10552 Captain Duck's updated play along tutorial]
*[https://www.youtube.com/playlist?list=PL_4titxTj-2v4tg_QisHa5os5qraDpTLZ Ongoing German tutorial series by konni.tv]
'''For v0.34:''' (the previous version)
*[https://www.youtube.com/watch?v=AI9Dy-4slVw&list=PLwWlb_jkC2UmyKmTWqD711j2QYX_Zmw-x A Noob's Guide to Dwarf Fortress] A tutorial series dedicated to beginners.
*[[::From Caravan to Happy Dwarves|From Caravan to Happy Dwarves]]. A minimalistic, but great, diagram (maybe for players with a bit more experience).
*[[User:Calite/Gloss Guide|Jumping Into Fortress Mode]]. An outline of main concepts, though it lacks any technical help.
*[http://www.youtube.com/watch?v=QmkPbGrH7VA&feature=plcp A beginner's tutorial to dwarf fortress.] Look here for a wide variety of guides on how to play fortress mode.
*[http://www.youtube.com/playlist?list=PL2C4E18093853E338 Let's Play/Tutorial Dwarf Fortress by Gerugon] A German video series that will teach you all you need to know to create your own fort.
* [https://www.dropbox.com/sh/8akafeuqfsxth7t/U-zOsO7pNr A quick reference guide on fortress mode] (Credit to spongemandan on reddit.com)

'''For the old versions:''' (but still really great for beginners)
*[http://dftutorial.wordpress.com/ I Play Dwarf Fortress - (And You Can Too!)] Play-Along Beginner's Guide With Pictures
*[[::Bentgirder|Bentgirder]]. A good, mostly-complete tutorial.
*[[40d:Video_tutorials|The legendary video tutorials by Captain Duck]].
*[http://afteractionreporter.com/2009/02/09/the-complete-and-utter-newby-tutorial-for-dwarf-fortress-part-1-wtf/ The Complete and Utter Newby Tutorial for Dwarf Fortress] with lots of screenshots ([http://www.bay12forums.com/smf/index.php?topic=31928.0 forum thread])
*[https://df-walkthrough.rtfd.org PeridexisErrant's DF walkthrough and tutorials]
*[[40d:Indecisive's illustrated fortress mode tutorial|Indecisive's illustrated fortress mode tutorial]].
*[[40d:Quickstart_guide|A quickstart guide]]
*[[40d:What should I build first|"What should I build first?"]]

=== Specific Elements ===

These are not necessarily tutorials, but they can help out with specific parts of the game.

*'''[[Important advice|Important Advice]]''' - Disregard at your own risk.

=== Basics of World Generation ===

*[[World generation]]
*[[Map legend]]

=== Basics of Embarking ===

*[[Embark]]
*[[Location]]
*[[Biome]]
*[[Surroundings]]

=== Feeding Dwarves ===

There are several ways to [[Food|feed]] your dwarves. Your initial supplies will run out, but [[fishing]] and [[plant gathering]] are easy ways to get additional food in a starting fortress. The default embark group starts with a [[fisherdwarf]]; you'll need a [[fishery]] workshop to clean the fish your fisherdwarf catches, to make them edible.

It is very important to have enough [[alcohol]] for your dwarves, so building a [[still]] is almost a requirement during the first year. [[trading|Caravans]] bring some drinks, but not enough.

To ensure sustenance when the fortress grows, [[farming]] is the most reliable way. Above-ground farm plots are easy to set up (if you have soil on your map), but require [[seed]]s that can be obtained from gathered plants or by trading with humans or elves.

Buying food from [[trading|caravans]] is a good way to prevent shortages.

See:
*[[Farming]]
*[[Meat industry]]
*[[Fishing]]
*[[Herbalist|Gathering plants]]
*[[Trading|Trading for food]]
*And not to forget: [[Alcohol]]

=== Mining and Minerals ===

*[[The Non-Dwarf's Guide to Rock]] - A primer, explaining geology in so far as it is implemented in Dwarf Fortress. Note that DF geology is actually quite realistic, so knowledge of real world geology could make much of the game seem very familiar to you.

=== Defending Against Enemies ===

This is one of the most challenging aspects of the game, so if you feel confused even after reading all of this then you are not alone.

*[[Military quickstart]]
*[[Military]] - or for a complete explanation and walkthrough of the military menu (advisable to look at first) the [[Military interface]]
*[[Armor]] and [[Weapon]]s
*[[Sparring]]
*[[Trap]]s

==Adventure Mode==

Currently the only tutorial for [[Adventurer mode|Adventure Mode]] is the [[Adventure mode quick start]] guide. Adventure mode is significantly less complex than Fortress Mode though, so that guide will probably be enough to get you started.

Also see the [[Adventurer mode|Adventure Mode Reference Guide]].

{{Getting Started}}

Justice

2015-09-23T10:18:07Z

Larix: /* Happiness management */ dwarfs are not worried by the dark. "Dank" is a proper english word (and more evocative).

{{Quality|Exceptional|02:20, 28 May 2010 (UTC)}}{{av}}

Justice is available in the game once a [[Sheriff]] or [[Captain of the guard|Captain of the Guard]] has been appointed through the [[Noble|{{k|n}}obles]] screen, and is used to deal with dwarves violating mandates, breaking furniture, starting fights, etc. The dwarven justice screen shows details of crimes and punishments, and is available through the {{k|z}}-status screen (even if no nobles are appointed yet).

==Crimes==
* Violation of Production Order - failing to produce items [[mandate]]d by a [[noble]].
* Violation of Export Prohibition - selling items to a caravan which a [[noble]] forbade exporting.
* Violation of Job Order - failing to complete [[guild]] jobs [[mandate]]d by the [[mayor]] (currently does not happen).
* Conspiracy to Slow Labor - deliberately slowing down the workflow of the fortress by delaying jobs (currently does not happen)
* Murder - killing a fellow dwarf or a tame [[animal]]. Alternatively, being caught [[vampire|sucking blood]] out of another dwarf.
* Disorderly Conduct - attacking another dwarf while throwing a [[tantrum]].
* Building destruction - destroying a [[building]] during a tantrum.
* Vandalism - toppling [[furniture]] or [[door]]s during a tantrum.

If a [[vampire]] is caught feeding on another dwarf, even if the victim survives, it is still considered a murder. The vampire will typically make a false report, to try to frame another dwarf. Witnesses will also sometimes make false reports to try and frame dwarves they have [[grudge]]s against.

In some cases, the player has to convict a criminal or suspect, in others, criminals are convicted without player input. In case of mandate infractions, the player is generally not asked for input, while murderers must be convicted by the player. Practically anybody can be blamed for a murder, including tame animals and long-dead persons. The fort population will feel [[Thought#Justice|affronted]] at particularly nonsensical convictions.

"Violating an export ban" happens when a dwarf carelessly carries a banned item to the trade depot and a merchant leaves the map with it. It often happens when a noble decides to ban an export '''after''' you've traded away a relevant item.

If your dwarves start throwing [[tantrum]]s, then you'll see the harsher crimes, as they let off steam by throwing items around, breaking furniture, toppling doors, and punching fellow dwarves who are just trying to clean up the mess. Often instead of punches, they'll use the weapons they're carrying.

==Punishments==
Dwarves who misbehave can receive punishments if a sheriff has been assigned. In increasing order of severity ( at least that's what your dwarves think):
# Beating by a [[fortress guard]] (more dangerous than it sounds, see below)
# Imprisonment for a period of time.
# Hammering by the [[Hammerer]].
The punishment for a crime, or series of crimes, will be issued by the Sheriff or by a member of the Fortress Guard. If the crime calls for imprisonment, then the guard will try to put the prisoner in [[jail]]; if no jails are available, the guard will "downgrade" the punishment to a beating, giving the criminal a happy thought and the injured party (i.e. the dwarf injured by the criminal, if one exists) an unhappy thought. If the crime calls for hammer strikes, then the Hammerer will attach the prisoner to a restraint before carrying out the sentence; if no justice restraints are available, the punishment will be downgraded to a beating. All punishments will give the criminal an unhappy thought (and the guard/Hammerer a happy thought).

Note that it is usually not a good idea to train your guards to physical perfection if you want your dwarves to survive beatings:
Punches to the head have a very high fatality rate, possibly due to a bug {{bug|2907}}. Therefore it is wise to ensure that any criminals scheduled for beating are fitted with a metal helm as quickly as possible (if you want them to live). Even without headstrikes, beatings can easily result in broken bones or organ damage, making prison sentences a less risky option.

Punishments are performed sequentially; a criminal who has been sentenced to jail time ''and'' a hammering will not be hammered until the entire jail term has been served.

==Cages and Chains==
Metal cages, metal chains, and ropes can be built and designated as [[jail]]s ({{k|q}}uery -> make a {{k|r}}oom -> use for {{k|j}}ustice), where dwarves can be imprisoned for a time as part of their punishment. If the dwarf is particularly unhappy and decides to throw a [[tantrum]], he may end up destroying the restraint (even if it is made of metal) and escaping, leading to further punishment (for building destruction).

It is also strongly recommended to use chains, not cages for imprisonment: dwarves on chains are still free to move one step in any direction, allowing them to keep themselves fed and hydrated when food and booze stockpiles or wells are placed adjacent to the chain. Dwarves in cages are entirely dependent on the assistance of others.

==Happiness management==
A dwarf that is carelessly tied up in a dank dungeon is subject to several unhappy thoughts. Most can be avoided or offset with some care:

Putting food and booze stockpiles right next to the chain allows for happy thoughts from both instead of having to drink water when (if) someone finally brings some. Decorating your jail with numerous valuable engravings and furniture is helpful too. Finally, with a bed and a table next to a chair all within a square of the chain itself, negative thoughts approach zero.

==Backlog==
Crimes do not seem to lapse, so if you've delayed appointing the "executive" nobles for some time, there might be a long list of delinquents and open sentences pending. The law will swiftly proceed to chaining up all delinquents and, once all chains are occupied, beating up any remaining free "criminals". Therefore, beatings are avoided only by constructing restraints first, and possibly way more than recommended in the z-screen.

{{Category|Justice}}

Brown recluse spider

2015-09-05T11:10:06Z

Larix: Being a source of silk really deserves mentioning.

{{quality|Superior}}
{{verminlookup/0}}
{{av}}
{{creaturedesc}}

The '''brown recluse spider''' is a [[Vermin#Hateable vermin|hateable vermin]] that, on top of giving [[thought#Unhappy_Thoughts|unhappy thoughts]] to dwarves who detest them, is very [[syndrome|venomous]]. Brown recluse spider bites cause immediate nausea, fever, and pain, and a short time later result in severe localized necrosis. They are also much faster than your average [[rat]]. Thankfully, the spiders don't seek the vicinity of dwarven settlements and even when a dwarf encounters a spider, this will almost never result in a bite.

Brown recluse spiders spin webs which can be collected by [[weaver]]s for the production of [[silk]]. In their native biomes, brown recluse spider silk can be an important resource of the [[textile industry]].

[[Image:Brown recluse spider, Loxosceles reclusa.jpg|thumb|left|[[preference|Admired]] for its venomous bite.]]

{{gamedata}}
{{vermin}}

Minecart

2015-08-28T11:10:28Z

Larix: /* Corner Ramp Derail */ Lateral speed is induced when exiting the corner ramp, thus must be eliminated /after/ passing it.

{{Quality|Masterwork|08:15, 19 May 2015 (UTC)}}
{{av}}
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]].

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.

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

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

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

After you have created the stops and assigned a cart to the track, you must create logic routes connecting several stops and designate starting conditions for each stop. This is done with the {{k|h}}auling key. The most basic conditions are how the cart's movement is initiated and in which direction the cart should start moving. Carts can be either 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.

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.

===Capacity and weights ===
Minecarts have five times the [[Weight|capacity]] of [[wheelbarrow]]s.

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

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

'''Weights of different carts'''

{| class="wikitable"
|-
! Type of cart
! Empty cart
! Fully loaded (items)
|-
| oaken minecart
| 28Γ
| 378Γ (10 oak logs)
|-
| platinum minecart
| 856Γ
| 10482Γ (83 gold bars)
|}

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

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

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

====Simple tracks====

'''Carved'''

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

'''Constructed'''

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

====Ramps====

'''Carved'''

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

'''Constructed'''

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

'''Examples of ramps'''

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

Carving track corners into ramps is rather unintuitive and complicated. Since engraving tracks always requires two tiles to connect in a straight line as input, you have to give two separate designations for a single job: a track bit from the ramp tile to the "below" direction and another one to the wall of the "upward" direction. If you wanted to change direction on a ramp from east to north:
{{diagram|spaces=yes|\
z +0 z +1
░░░░░ ░░░░░
░░░░░ ══╗░░
=▲░░ ░░▼░░
░░░░░ ░░░░░
}}
you would need to connect the ramp on z +0 both to the west and to the north by issuing two "carve track" commands, one selecting the ramp and the track tile to the west, and another connecting the ramp tile with the wall to the north. An engraver would then carve a NW track corner into the ramp, allowing carts to pass the corner correctly both going up and down. Such track corners are perfectly serviceable for guided carts, but moving down a route of several of them by pushed or ridden cart is problematic - ramps on corners behave very counter-intuitively, resulting in loss of speed when going down and diagonal movement when going up.

Moving to and from ramps (or between ramps "pointing" in different 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}}

{{anchor|Tracks}}

=== Hauling route ===
A hauling route is a list of directions describing how and under what conditions a minecart will move. The proper setting up of routes is essential for a working rail system. Routes, stops, departure conditions and stockpile links are managed from the {{k|h}}auling menu.

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

New routes are created with the {{k|h}}auling key. Existing ones can be removed (without confirmation) with the {{k|x}} key, and also {{k|n}}icknamed. Before operating, the route must have a {{k|v}}ehicle assigned to it (this can be done with either the route or a stop selected). Assigning a full minecart to a route may result in a slow hauling job if the contents are heavy.

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

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.

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

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

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

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

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

Counter-intuitive to their construction method, Track Stops are considered [[building]]s and must be removed by {{k|q}} {{k|x}}.
* See [[#More_on_Track_stop |More on Track Stops]]

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

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

[[File:minecart-example-1.png|Stockpiles designated.]]

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

Next, carve the track:

[[File:minecart-example-2.png|Track carving designation.]]

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

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

[[File:minecart-example-3.png|Track carved.]]

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

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

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

[[File:minecart-example-6.png|Track stop constructed.]]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Now we've got everything set up:

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

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

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

=== Troubleshooting ===

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

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

'''Possible Causes:'''
* 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.
** 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...)
* 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.
* The track stop might not be built on top of a track. The track stop must be deconstructed to remedy this issue.
* Your track might not be built correctly. Make sure all connected tracks between destinations are not one-way tracks.
** This can be especially confusing with ramps. To carve a two-way track on a (natural) ramp, you must designate the ramp and one square beyond in the direction you want the track to go.
** Ramps '''must''' have a solid 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.
* The desired/kept items might not be configured correctly.

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

'''Possible Causes:'''
* 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".
* The take conditions must correspond with the contents of the stockpile.
* 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.)
* Make sure the minecart itself has not been designated to be dumped (such as when using mass-dump).

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

'''Possible Causes:'''
* 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.
* 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).

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

'''Possible Causes:'''
* 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

==== Impulse ramps ====
Carts can be given momentum without rollers or changing z-level 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.

Example of straight impulse acceleration:

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

If a cart enters from the left, it will speed up on every track/ramp and exit to the right going very very fast - more than one tile every step. If it enters from the right then it will bounce back impulsed by the ramp if it's going slow enough.

As another oddity, carts coming from ramps will in some cases "teleport" through most of the next tile. This is called the "checkpoint effect", and is explained in detail in the Physics section, below. This negates the deceleration of the next tile if it is a ramp "angled" in a different direction. You can just make an upward spiral alternating impulse ramps and regular upward ramps. It takes no power, is quick and cheap to build, requiring only channeling and track carving, and the cart goes up fast, but not so fast that it launches its contents.

Example of an impulse elevator:

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

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

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.

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

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

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

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

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

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

=== Controlling traffic ===

==== Switching ====

As 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.
{{diagram|spaces=yes|\
->
A ════┤≡════ B
┤ : roller pushing to East
≡ : door
}}
The roller pushes the cart east, but until the "departure condition" is fulfilled, the door remains closed and blocks the path.

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

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

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

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

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

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

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

==== Controlling Speed ====


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

Will derail at > 0.5 t/st:

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

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

O : wall/column.
}}

This behavior can be used to build a "speed limiter", that will ensure that when a minecart exits it is traveling below derail speed:
{{diagram|spaces=yes|\
░░░░ ░░░░░ ░░░░░
in ═╔═╗░ ░╔S╗░ ░╔S╗░
out ═╬═╝░ out ═╗═╝░ out ═╗═╝░
░╚S╝░ ░╚═╝═ in ░╚S╝░
░░░░░ ░░░░ ║░░░
in
░ : wall
S : Track Stop (High Friction or lower)
}}
If the minecart is traveling below derailment speed, it will not be affected; if above, will be slowed down and checked again. Granted, you could do the same just with track turns, but it may take a lot of turns and time.

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

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

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

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

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

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

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

== Physics ==


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

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

The difference between "Push" and "Ride" is whether the dwarf will go along with the cart or not.
{{DFtext|Push}}: the dwarf will give the cart an initial push, not enough to go up a ramp, but enough to go some way along flat track, and the dwarf will remain at the first stop, ready for a new job.
{{DFtext|Ride}}: the dwarf will give the cart the same initial push and then hop aboard the cart riding with it to the next stop.
{{DFtext|Guide}}: minecarts seem to ignore all laws of physics. That is:
*Ignore the weight of any and all items inside. Therefore:
**Move at the speed of the dwarf that is guiding them. It is thus recommended to pick the most [[attribute#Agility|agile]] of your dwarves for cart-guiding tasks.
*Ignore working rollers.
*Will ''not'' collide with other guided carts even when a full frontal collision would be expected.
*Will go up ramps like nobody's business.
This is therefore the recommended method of transport for simple non-powered rail systems, despite it diverting a dwarf from other, potentially more important tasks.

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

=== Numbers behind the scene ===

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

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

Every tick the cart adjusts sub-tile position units by the amount of their velocity, as well as adjusts velocity depending on current tile (speed is reduced by the "friction" of the tile, or accelerated if going "down" a ramp). On flat (non-ramp) tiles, the cart will move to the next tile when the sub-tile position goes 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.

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.

A push will teleport a cart to the beginning of the next tile (NOT the middle!) in one tick with 19990 speed (10 speed is lost due to track friction), while a roller will give a cart the roller's set speed, and it will start to accumulate regular track friction past the middle of the roller tile. Some track features will affect a minecart when it is past the middle of the previous tile: entering a ramp or a hole/drop will happen when the cart has left the middle of the previous tile, and the ramp will gain additional distance unit depending on the leftover units from the previous tile. When a cart leaves a ramp it will emerge after one tick in the middle of the next regular tile, so its entry coordinate is "50000-speed+friction". Rollers also affect the speed of minecart from the middle of the previous tile.

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

Water of depth 7/7 provides a friction of about 10000 per step, as does maximum-depth magma. This higher friction may not apply to very slow-moving carts.

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

Note, again, that nearly all of these values are applied ''per tick'', rather than ''per tile''. The exceptions are curves, which is 1k deceleration per direction change at the 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.

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

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

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

Each non-ramp tile is functionally composed of 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.

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.

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

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.

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]]".

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:

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

If a cart is passing West-to-East over this setup, the valid ramp to the South will apply "Southward" acceleration to the cart (-Y velocity) as it passes through the ramp tile. Assuming it only spends 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.

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

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

If the tile to the South is a wall at that point, it will be considered a collision with a wall that ''halts all motion''. If the tile is open, 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.

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

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

Curves are applied "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.

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.

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.

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

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

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

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

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

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

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

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

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

If there is a curve the cart will respect, it checks for derailment. Carts derail 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.

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

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

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

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

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

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

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

Falling carts accelerate similarly to the way that a ramp will accelerate a cart in a special z-only velocity that only applies to airborne carts. (Actually, 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.

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

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

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

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

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

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

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

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

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

=== Corner Ramp Derail ===

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

This is caused by the fact that a cart, after turning the bend in the track 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.)

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

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

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

This seems to be because ramps have a slightly longer length than regular tiles - 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.

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

Another useful thing to note about this exploit is that carts traveling at no less than 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.

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

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

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

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

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

Three successive ramps results in the highest attainable speeds.

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

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

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

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

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

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

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

== Adventure mode ==
In addition to being used for hauling, minecarts can also be ridden in [[adventure mode]]. (Adapted from forum thread {{cite forum|122903/4258212}})

# If the minecart is in your inventory, drop it. If it is already on the ground, proceed to step 2.
# Press {{k|u}} when you are 1 tile away from the minecart (or standing on the same tile as the minecart).
# You will be presented with the following options:
[[File:minecart adventure mode menu.png|left]]
{{clear}}
* If you {{DFtext|Push}} the minecart, it will move a few tiles in the direction you chose. Physics comes into play here, so it will gain/lose speed depending on the usual factors.
* If you {{DFtext|Ride}} the minecart, you will hop into the minecart, even if you were a tile away, and it will move in the chosen direction with you in it. It will gain/lose speed depending on the usual factors. Whilst the minecart is in motion, you should press {{k|.}} to skip your turn; if you attempt to move whilst the minecart is still in motion, the laws of physics come into play, and you will take [[wound|damage]]. 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.

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

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

== See also ==
* [http://www.bay12forums.com/smf/index.php?topic=109460.0 The "How Does Minecart" Thread] by '''Girlinhat''' et al.
* [http://www.bay12forums.com/smf/index.php?topic=112831.0 SCIENCE: Quantifying minecart physics] by '''Snaake''' et al.
* [http://www.bay12forums.com/smf/index.php?topic=129676.0 How to build a Multi-cart Ore to Magma Minecart Project without needing power] by '''WanderingKid'''.
* [http://www.bay12forums.com/smf/index.php?topic=144328.0 My very own Minecart Education Thread. Ten Lessons, now complete.] by '''Larix'''.

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

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

[[ru:Minecart]]

Butcher

2015-08-26T18:57:42Z

Larix: Undo revision 220295 by 2602:301:7712:2730:35E8:1AAC:6E7:9039 (talk) Reason: Redundant (see one paragraph above).

{{Quality|Exceptional|12:08, 17 May 2015 (UTC)}}
{{Skill
| color = 6:0
| skill = Butcher
| profession = [[Farmer]]
| job name = [[Butchery]]
| tasks =
* Butcher [[animal]]
| workshop = [[Butcher's shop]]
| attributes =
* Strength
* Agility
* Endurance
* Kinesthetic Sense
}}
{{av}}

'''Butchers''' do the dirty job of killing tame animals, processing animal [[corpse]]s, skeletons and body parts for [[meat]], [[fat]], [[skin]], [[bone]]s, [[Skull|skull]](s) and many other objects at the [[butcher's shop]].

==Fortress Mode==

The work of a butcher is divided into two distinct categories: '''butchering''' and '''slaughtering'''. While both produce the same results (food and raw materials), they have distinctly different inputs - butchering is done on dead wild creatures (and takes a significant amount of time to perform), while slaughtering is done on live tame/trained creatures (and is instantaneous).

To slaughter an animal, do one of the following:
* go into {{K|v}}iew mode, place the cursor on the animal, go to the {{K|p}}references page and press {{K|s}} to flag (or un-flag) the animal for slaughtering
* go to the {{K|z}} ([[Status]]) screen, then the Animals page, select the animal and press {{k|b}} to flag (or un-flag) for slaughter.

Only tame/trained creatures can be slaughtered, and any adopted [[pet]]s are exempt (and will be automatically undesignated if they happen to be adopted while being led to the chopping block).

Assuming you have enabled "Auto slaughter" in your [[standing orders#Workshop orders|workshop orders]], a butcher will then walk up to the animal, lead it to a [[butcher's shop]], then strike down the creature. As mentioned above, slaughtering living animals is ''instantaneous'' - the moment the dwarf sets foot in the workshop, the animal dies and its body is split into individual parts. If "auto slaughter" is ''disabled'' in workshop orders, then nothing at all will happen, since the "slaughter animal" job cannot be added manually.

If the "Auto butcher" order is enabled, then any valid corpse located either in a stockpile or within 43 squares of a butcher's shop will be automatically queued for butchering. During this job, the butcher will pick up the corpse, haul it to the workshop, and then slowly process it into individual parts at a speed based on skill level and [[clutter]] (which can take a long time for particularly large creatures such as [[forgotten beast]]s). If a [[Ambusher|hunter]] successfully kills his target, he will haul the corpse and place it directly inside an appropriate butcher's shop, but unless your butcher happens to be idle at the moment, the corpse will likely be removed from the workshop and placed in a stockpile.

Dwarves will not butcher the corpses of sapient creatures (due to the EAT_SAPIENT_OTHER:UNTHINKABLE [[ethics|ethic]]), and the corpses of tame creatures cannot be butchered (they must be slaughtered while still alive).

The type and number of objects produced from butchering a creature varies greatly, since not all creatures have the same parts. See each animal's page for a breakdown of what happens when you break that animal down.

==Adventurer Mode==
How to butcher in [[adventurer mode]]:

# If the corpse is in your inventory, {{k|d}}rop it or equip it by {{k|r}}emoving it.
# If the corpse is on the ground, move onto the same tile as it.
# Equip a cutting implement or, alternatively, drop it on the same tile as yourself. This can be any object with a sharp edge (i.e.has an EDGE attack type), such as bladed [[Weapon|weapons]] and [[Tool|tools]], [[Bolt|bolts]] and [[Knapper|sharpened rocks]].
# Press {{k|x}} to open the action menu. Then select "{{k|b}}utcher", press {{k|→}} and select the corpse that you want to butcher, press {{k|→}} again and pick the tool that you want to use. [[File:Butchery_adv_action_menu.PNG]]

You will then proceed to butcher the corpse, dropping all of the products on the same tile as yourself.

Also note that small animals like ravens cannot be butchered.

==Effect of skill==
A butcher's skill affects the speed of butchery, which can be important for processing a large number of corpses before they begin to [[rot]]. Note that butcher shops can become [[clutter|cluttered]] quickly, because most animals create a large number of different items of different categories when butchered. So make sure that you have nearby stockpiles for refuse, raw hides, meat, prepared organs and fat. To minimize the amount of [[miasma]] created in case the rotting parts are not removed fast enough, a butcher's shop should always be blocked by a [[door]].

Of course, placing the Butchery outside will prevent any and all miasma generated by rotting, but dwarves won't haul the inedible parts away unless the global orders allow to "gather refuse from outside" ({{k|o}}-{{k|r}}-{{k|o}})
==Bugs==
*A dead tame animal that was not slaughtered cannot be butchered.{{bug|1180}} This includes tame animals killed due to age, starvation or due to goblins.
*Dwarves will not disassemble (butcher) skeletons of sentient creatures for their bones.{{bug|1180}}

==See also==
*[[Meat industry]]

{{Translation
| dwarven = lokast
| elvish = uwale
| goblin = slust
| human = rashcat
}}

{{Skills}}

Cross-training

2015-08-13T08:26:06Z

Larix: Updates for current version. Pump gym's been of very little use for quite a while.

{{Quality|Superior|15:23, 17 May 2015 (UTC)}}
{{av}}

'''Cross-training''' is the process of training your civilian dwarves in military pursuits, or vice versa, and can offer several benefits. First and most importantly, it can be a good way of raising attributes, leading to stronger, tougher, faster dwarves. Secondly, it provides a handy pool of recruits for when your military takes a beating or gives your civilians a halfway decent chance of defending themselves. Thirdly, it can provide useful replacements for when your legendary mason accidentally blunders into a troll and gets all his limbs broken. Finally, it's a more productive use of time than standing around idling.

There is nothing saying you have to use only one of these ideas; they are all various approaches toward addressing these areas.

==Cross-training (starting a reserves program)==
The biggest thing to remember with a reserves program is that if you're going to go, you go all the way. Don't institute something "just for a little while" and come up with a handful of novice reservists; they will not get significant stat increases and you'll only waste time. Time is not something you have a heck of a lot of in a reserves program, typically. Remember that after you draft them, most dwarves are going to need about a year of sparring or training before they're ready for heavy combat. You might not have that much time if you are getting sieges regularly.

===Different Programs:===

====National self-defense training====
''Make sure you're familiar with the [[military interface]], [[squads]] and [[scheduling]] before attempting this.''

This is the process of training all your civilians in military skills - or at least, most of them. The easiest way to do this is to assign every new [[migrant]] or recently grown up child to dedicated training [[squad]]s, and assign that squad a barracks. Then, schedule these squads to train and set the squad to "Active/Training".

National self-defense training is by far the most efficient way to increase attributes related to military skills. This includes strength, agility, toughness, endurance, focus, intuition, kinesthetic sense, spatial sense and willpower - all of these will see dramatic increases and reach the individual maximum when training lasts long enough. To increase the rate at which dwarves gain skills, place one experienced trainer / soldier in each squad, which will make demonstrations much more valuable.

Then, if they ever get caught where they don't want to be (maybe they bump into a thief coming around a corner, or a flying critter jumps them, or you need to urgently order them out of the path of a magma flood, or send them to the [[Lever|control room]] - anything), every dwarf has a better chance at not-dying - which can only be a good thing. You may want to remove the barracks assignment from a reserve squad after you're done training them, or they'll tend to spend all their time on "Individual Combat Drill" rather than performing their civilian jobs.

'''Pros:'''
*Easy, cheap, and no maintenance once set up
*No need for other cross-training for any attribute affected by national self-defense training
*Trainees gain useful military skills
*Trainees will be faster, stronger and tougher both in daily life and in emergencies

'''Cons:'''
*Legendary fighting skills may make tantrums more fun
*Trainees don't work during training
*Trainees don't socialise during training (you may see this as an advantage, though)
*Trainees will choose training over performing civilian duties
'''Attributes trained:'''

Rapid increases of strength, agility, toughness, endurance, focus, intuition, kinesthetic sense, spatial sense and willpower.

====Gym ([[pump operator]])====
The main purpose of the Gym is keeping underemployed peasants from partying all the time. It merely consists of building a bunch of [[screw pump]]s connected to nothing in a room that's close to [[food]], [[bed]]s, and [[drink]]. After the pumps are built, order them to be pumped manually, then turn on [[Pump operator|pump operating]] for those dwarves that tend to be idle much of the time. Pump operating is a decent way to train endurance, benefits to other attributes are minimal.

'''Pros:'''
*Easy and cheap to set up;
*Requires no continuous oversight on your part.
*Fps-friendly: air-pumpers consume, produce and move nothing.
*Somewhat fast training; legendary in under a year (if other responsibilities like hauling are minimized).
*Very convenient; gyms can be placed anywhere in your fortress with no issues. 
*Marksdwarf squads may benefit from attribute development, since a well-managed squad of them will usually not spar. Pump operation doesn't consume bolts, either.
*If desired, you can arrange your pumps so they power one or more indoor [[waterfall]]s or other water-powered devices.
'''Cons:'''
*Generates nothing useful other than the increased attributes of the trainee.
*Increases attributes at a much slower rate than military training (and fewer attributes to boot).
*If you have any pumps around that critically NEED to remain in operation it can be a serious pain to keep the critical pumps operating (sadly, pumps cannot be [[Manager#Setting_workshop_profiles|profiled]]).
'''Attributes Trained:'''

Strength, Toughness, Endurance, Willpower, Kinesthetic Sense

====Boiler-room ([[furnace operator]])====
:''See also: [[Melt]]''
Boiler-room training can be performed by forging and melting items that do not incur a loss of metal in the process. This method is more of a direct training scheme for the various [[smith]]ing labors, furnace operator skill and attribute training are a side benefit.

'''Pros:'''
*Easy to set up.
*Requires little continuous oversight on your part.
*Somewhat fast training; dwarves reach legendary in two years.

'''Cons:'''
*Requires access to [[magma]].
*Generates nothing useful other than the increased skills and attributes of the trainee.
*May interfere with legitimate melting jobs (use of linked [[stockpile]]s, [[burrow]]s, and [[profile]]s can mitigate this).

'''Attributes Trained:'''

Strength, Toughness, Endurance, Analytical Ability, Kinesthetic Sense

====Swimming Pool ====
Adding a swimming pool allows your dwarves to rapidly boost their swimmer skill; unfortunately they will not do so voluntarily. A simple pit with 4/7 - 6/7 of water and a means of "encouraging" your dwarves to dive in are sufficient. Placing your swimming pool near/under a [[meeting hall]] will automatically train idle (and partying) dwarves. Minecart-aided swim training is a safer method, it is based on the feature, that a dwarf riding a minecart learns swimming while doing so. (See: [[Swimmer#Minecart_training|Minecart training]])

'''Pros:'''
*Cheap to set up
*Automates training of idle dwarves without interfering with actual work
*Provides a good set of physical [[attribute]]s likely to speed up fortress operation
*Swimming skill can occasionally save a dwarf's life
'''Cons:'''
*Generates no wealth
*[[gravity|Falling]] damage can be significant (of course, this trains medical staff too!).
*[[Flooding]] can be a problem, particular for overseers unfamiliar with Dwarf Fortress fluid mechanics
'''Attributes Trained:'''

Agility, Endurance, Strength, Willpower, Kinesthetic Sense, Spatial Sense

====Artillery proving ground ([[siege operator]])====
Mass-produce some catapults, line them up near a quarry, and fire away. Works well to dispose of stone from a gulag (see below). 
'''Pros:'''
*Trains a skill that's reasonably useful, and provides a place to put all the sub-par siege engine components your [[siege engineer]] will doubtlessly create if you're going for superior-quality engines.
*Harasses the wildlife, which is always fun and sometimes [[Fun]]. 
'''Cons:'''
*Very slow to train (2+ years for legendary).
*Fairly space-consuming to set up a well-designed and usable proving ground.
*Can be dangerous depending on the biome (especially when [[elephant]]s are present. If they get winged by a stray boulder, you can bet they're going to be coming straight at you).
*[[Siege operator]]s are civilians, and will run in fear when an enemy approaches them.
'''Attributes Trained:'''

Strength, Toughness, Endurance, Analytical Ability, Focus, Spatial Sense

====Internship MkII ([[manager]])====
Assign a new dwarf to manager, queue several hundred jobs, and rotate a replacement in as soon as he becomes legendary. For bonus points, queue jobs which need to be repeated anyway, like "Prepare Raw Fish" or "Mill Plants", or jobs for which there is no workshop, like "Make Wooden Bow" or "Make Soap".

'''Pros:'''
*Requires no extra infrastructure at all.
*You need a manager anyway!
*Mostly safe; a manager spends basically all his discretionary time snug in his office, or doing his other assigned jobs.
'''Cons:'''
*Only employs one dwarf at a time; not useful when you have 15-25 candidates for the reserves.
*No announcement when the current intern reaches Legendary status means you can lose time on rotation easily.
*Produces little to no useful attribute gains
'''Attributes Trained:'''

Analytical Ability, Memory, Focus

====Gulag ([[miner]])====
The gulag is basically a strip mine that is located far away from your main fortress (so you don't have to worry about accidentally screwing up your own building plans; if you are careful in planning, it may be placed closer to your fortress). Take a big square and start leveling it; it's really no more complicated than that. Since [[pick]]s can actually be used as weapons, it's worthwhile to give the reservists who will be working in the gulag picks made out of [[bronze]], or, if you are really living large, [[iron]] or even [[steel]]. Note that you will have to turn your usual mining corps (the civilian miners who are already experienced with mining) off or designate separate mining [[burrow]]s for this setup to work properly. It might be convenient to use a locked door to isolate the gulag from the main fortress, once a batch of trainees are inside. 
'''Pros:'''
*Soldiers can be equipped with picks from the military skill, and use the Miner skill in combat - militia squads of highly skilled miners can provide a decent defence from early threats
*Toting a pick for close-quarters support might make a legendary [[marksdwarf]] more useful, since the pathetic bludgeon damage of his [[wood]] and [[bone]] [[Weapon#Dwarf-manufactured Weapons|crossbows]] are less important.
*Can be quite useful for producing stones you might not have access to normally, or uncovering veins of precious metals.
*Levels quite fast in sand.
*Relatively little oversight from you.
*An overland hike to the gulag will fight [[cave adaptation]] in your military candidates.
*Can easily be transformed into a [[Caverns#Vegetation|underground tree farm]] on suitable maps, providing a safe and replenishable wood source.
*Mining trains all military attributes, so it's perfect for military training too

'''Cons:'''
*Juggling your real miners and your reservists when there's real work to be done on the fort can be a chore.
*Hard to keep dwarves in the gulag for too long; they'll inevitably get hungry, thirsty, and tired and start hiking back to the fortress proper. Could be solved by (temporary) [[burrow]].
*Can be dangerous, depending on the biome.
*Does require some amount of oversight from you, especially when your reservists start getting better at mining and run out of work more quickly.
*Surplus stone and mining in general are suspected to promote [[Maximizing_framerate|lag]].
*Can be trained easier and without space consumption as part of national defense training, when assigning picks as weapons.
'''Attributes Trained:'''

Strength, Toughness, Endurance, Willpower, Spatial Sense, Kinesthetic Sense

====Renovation ([[stone detailing]])====
Another convenient way to buff up your dwarves, assigning your reservists to mass [[stone detailing]] duty increases your fortress' architectural wealth and makes the place look nicer. While they may clutter the halls somewhat, it doesn't require any special allocation of [[food]], [[bed]]s or [[drink]]. Just turn on [[stone detailing]] for your reservists and mark up as much of the fortress as you like for renovation. If you have no particular area you want smoothed, you can alternate designating some open space between carving tracks and then smoothing them out. Be aware that carving tracks automatically sets those squares to be low traffic areas, so you may want to choose an out-of-the-way area that won't disrupt pathing for other activities. 
'''Pros:'''
*Even easier to set up; just assign your dwarves and an area and you're good to go.
*Increases your fortress' value and general happiness.
*Requires no continuous oversight on your part.
*Very safe, if you only assign areas inside the fortress.

'''Cons:'''
*Wealth overflow may bring too many [[immigrant]]s.
*Serious conflict with [[engraving]] assignments; trying to engrave with poorly trained engravers wastes a lot of wealth that essentially comes from nothing. To avoid this, have periods when you only designate stone smoothing, followed by periods where you only designate engraving.
*Careless designation of smoothing areas may have your dwarves trying to smooth walls too close to [[magma]], a [[river]], or an active [[minecart]] track.
'''Attributes Trained:'''

Agility, Creativity, Spatial Sense, Kinesthetic Sense

====Sweatshop ([[mason]])====
Make one or more [[mason's workshop]]s in an area with a bunch of junk stone you don't care about, or that you're actively looking to clear. Change the workshop settings to allow only your reservists to use it, then tell the workshop to churn out crafts, junk furniture, stone blocks, and trade goods that you can trade en-masse. Alternatively, forbid your reservists from working in your real mason's workshops, order lots of stone constructions built, and pray that your real masons stay too occupied with the workshops to intrude. Works well in conjunction with a gulag. Alternate ideas for sweatshops include a [[mechanic's workshop]], [[craftsdwarf's workshop]], [[Kiln|magma kiln]], or a [[Glass furnace|magma glass furnace]] to train [[mechanic]], [[Stone crafter|stonecrafter]], [[potter]] and [[glassmaker]] respectively. ''Note: Do NOT try this with the [[carpenter]] skill unless you have a large supply, or any other resource you don't have in near-limitless abundance. Sweatshops will consume huge amounts of their associated resources, and if you run out mid-way you have probably wasted your time. This includes [[coke]] or [[charcoal]] used in the normal (non-magma) [[glass furnace]].'' 
'''Pros:'''
*Quantitatively turns a profit. The inferior trade goods can be dumped on the next caravan for more useful commodities like bags, seeds, and logs. Logs are especially useful, since you'll inevitably stamp out lots of bins to support the trade good output.
*Mass-producing blocks makes your constructions higher value.
*Unlike many other training programs, Sweatshops train a skill that is very useful.

'''Cons:'''
*Slow to level.
*Hard to keep the reservists on task, since they'll need to do plenty of hauling to keep their workshop from becoming chokingly cluttered.
*Can be a logistical nightmare; making bins and organizing hauling for the finished goods can be insane if you're working from a gulag.
*Can be dangerous depending on the biome and location of your sweatshops.
*Note also that stone blocks cannot be made into furniture or stone crafts. This may or may not be an issue depending on where you're putting your gulag.
'''Attributes Trained:'''

Strength, Agility, Endurance, Creativity, Spatial Sense, Kinesthetic Sense

====Dwarf Powered Mill ([[grower]], [[cook]], [[miller]])====
Start off by creating a surplus of [[longland grass]], [[cave wheat]], and/or [[whip vine]] and some bags. Create multiple [[quern]] all close to the food stockpile which contains the millable plants. Next to this area make a [[kitchen]] assigned to an experienced cook. Enable milling for the dwarves you wish to cross-train and order the cook to make lavish meals. As long as your growers provide a steady supply of millable plants and your cook can empty out bags quick enough, the milling jobs will continue. 
'''Pros:'''
*Produces a lot of wealth as flour is a high value ingredient
*Produces high amounts of food
*Sustains the training of non cross-training dwarves such as the cook and growers

'''Cons:'''
*Requires a surplus of millable plants to ensure continuous milling, thus you may need to increase the number of plots/growers
*If you don't have enough bags and your cook decides to go on break you may end up having job cancellations for the millers
*Dedicated haulers will be required to keep all workshops clutter free
'''Attributes Trained:'''

Strength, Agility, Endurance, Kinesthetic Sense (grower and miller)

Agility, Analytical Ability, Creativity, Kinesthetic Sense (cook)

====Clear Cutting====
As long as wood hauling is turned off, dwarves will move from one tree to the next without stopping to bring the wood back. On a heavily forested map, this means that dedicated wood cutters can skill up quickly, though the total number of trees to chop has been drastically reduced from previous versions.

Of course, this training strategy isn't going to endear you with the [[elves]].

'''Pros:'''
*Works quickly
*Provides useful lumber to carpenters, charcoal makers, etc.
*Can cause problems with elves
'''Cons:'''
*Can cause problems with elves
*Map dependent
*Trees are limited, and regrow slowly
*Unless care is taken to only designate a small area for cutting, trainees and haulers can be spread out across the map while, making them vulnerable to creatures and ambushes.
'''Attributes Trained:'''

Strength, Agility, Endurance, Willpower, Spatial Sense, Kinesthetic Sense

====Survial Training([[herbalist]])====

Agility

====Dwarf Scouts ([[ambusher]], [[hunter]], [[marksdwarf]])====
Marksdwarves are an important part of any military. A bum rush of low level marksdwarves is good, but not as effective as an elite backup squad! Here is what you can do:
Draft a comfortable number of dwarves to hunting, give them all cheap crossbows. Your dwarves should hunt as usual. But you are really training an elite squad of assassins, that will one day hunt goblins instead of groundhogs.

'''Pros:'''
*Easy to start.
*Lots of meat, bones and leather around.
*Aforementioned bones can be recycled to make new bolts.

'''Cons:'''
*Doesn't work on some maps.
*Hunting is dangerous!
*Evil areas may result in the deer your dwarves bagged waking up and ripping your hunter's face off!
*Not as economically productive as some other methods.
'''Attributes Trained:'''

Agility, Focus, Spatial Sense, Kinesthetic Sense (ambusher)

====Art School ([[weaver]])====
Collecting spider [[web]]s is normally a slow way to train weaving, but that's because the aspiring weaver spends most of his time hiking out to the spiderweb and then back to the loom. If you manage to create a [[silk farming|convenient local source of webs]] near a loom, your weavers-in-training will rapidly gain experience. The abundant silk thread can then be woven by your more experienced weavers for clothing and trade.

'''Pros:'''
*Safe and easy to run
*Virtually inexhaustible
*Produces valuable resources (silk cloth)

'''Cons:'''
*Requires somewhat complex setup
*Weaving is a [[moodable]] skill--and not a particularly desirable one

'''Attributes Trained:'''

Agility, Creativity, Spatial Sense, Kinesthetic Sense



===Overview===
*Artillery training can give you some siege operators, which will be useful if you have ballistae.
*The internship only trains up one dwarf at a time. Your stocks could also lag behind if you are unlucky.
*The gulag requires planning, and your dwarves in the fortress proper may run all the way to the gulag to grab a stone for some crafts, a chair, etc. It does, however, train your dwarves in mining quickly, which is always a useful skill.
*Renovation is hands-free, but may bloat your fortress wealth too quickly.
*The sweatshop creates a large amount of goods, which can be traded away to keep traders happy. It also increases your wealth by quite a lot, which can be good or bad depending upon your situation. The goods are also difficult to manage.
*National self-defence training is easy to manage when set up and lets you give your civilians clothes and light armour to keep them safe. However, it can take valuable workers away from their job if the training is too frequent.

Note that the artillery training and internship don't influence potential [[strange mood]]s (you can give those dwarves dabbling in anything you want and that's how they'll get theirs), while the gulag, renovation, and sweatshop do.

{{Military FAQ}}

{{Category|Military}}
{{Category|Fortress defense}}