Dwarf Fortress Wiki - User contributions [en]

Bedroom design

2023-01-23T22:11:23Z

Tlupes: /* Minimalism */

{{migrated article}}
{{av}}
{{Quality|Unrated}}
There are many ways to design the layout of [[bedroom]]s. Simplicity, ease of designating, efficiency, and aesthetics are all important factors in designing dwarven housing. The ability to modify the design to enlarge, improve, or add rooms can be important as well. Proximity of the rooms to [[noise]] should also be considered.

As to size, all a dwarf needs to sleep is a 1-tile bed, anywhere. However, to be [[Thought|happy]], a dwarf wants their own room with a bed, and a chest and a cabinet to put stuff in. Dwarves consider it a bonus if the room is enclosed by 4 walls (or 3 and a door) for privacy. If you want to add some other item(s) that a dwarf [[preference|prefers]] to add to their happiness, that would require that much more space - usually no more than a tile or two. However, some [[noble]]s can get very [[Room#Quality|particular]], and their rooms need to be bigger to meet all their requirements.

The simplest approach resolving dwarven sleeping requirements is to have all your dwarves sleep in a large communal [[dormitory]]. The smallest ''bedroom design'' possible is a corridor with notched spaces for beds.

Players frequently want designs which maximize positive thought and minimize the path distance between a dwarf's food, drink, job and home. For these purposes, nothing holds a candle to the ease, simplicity, and efficiency of [[#The_multiply-overlapping_single_bedroom|overlapping bedrooms]] in a single large, carved-out area. In the current version, the main benefits of individualized rooms are for roleplaying purposes. Historically, room design was further complicated when the [[dwarven economy]] kicked in, and a wide range of "[[Room#Specific room quality grades|room qualities]]" were needed, and poor dwarves were kicked out of over-priced quarters (the dwarven economy is currently disabled). To this end, a number of solutions, some surprisingly elegant, have been produced.

Many of the designs shown here were taken from [http://www.bay12forums.com/smf/index.php?topic=16901.0 this forum post].

=Minimalism=

Sometimes, simpler is better... not always, but sometimes...

=== 1x1 bed only, no walls ===
[[Image:1x1 Bedroom Example.png|60px|right]]

By far the most minimal design is to take a bed, place it anywhere you want, then set it as a 1x1 room. This bed 'room' can be assigned to a dwarf early on, and will at least serve the bare minimum purpose of avoiding unhappy thoughts from the lack of a room. It will not, of course, leave the dwarves with any space to store any possessions at all. However, it requires the absolute minimum work to set up; all you need is existing empty space, preferably with no noise nearby, and a bed to place in it.

Alternatively if you are building compact merely to save space or improve framerate, a 1x1 bedroom on a smoothed, engraved floor can have quite a high room value.

Note that since beds do not block movement and simply having people moving nearby (or even directly ''over'' them) does not produce noise or disrupt sleeping dwarves in any way, you can place these 1x1 rooms in a solid block with no space between them; this makes it easy to smooth and engrave the floor for all of them at once. With a competent engraver and quality beds, this is often enough to raise the room value to the point where even this minimalist setup will produce happy thoughts; compared to a high-quality bed, the amount that un-engraved walls would add to a room's value is minimal anyway.

=== Communal dormitory ===
[[Image:dormitory Example.png|60px|right]]

The simplest form of dwarven housing. Stick a bunch of beds in a room, zone them in a [[dormitory]], and voilà, instant flophouse. On maps with no [[tree]]s, this is pretty much your only option for sleeping quarters before breaching a cavern or importing large amounts of wood. (Dwarves will sleep on the floor of the dormitory if no beds are available, which at least keeps them from sleeping in the wilderness.)

This setup only causes a single negative thought ("slept without a proper room recently"), although you miss out the benefit of the happy thoughts generated by personally-owned furniture. However, as long as you compensate by offering your dwarves high-quality [[food]] and [[alcohol]], an expansive [[dining room]], and other luxuries, your dwarves will remain happy enough to be productive throughout the life of a fortress. (You may still wish to give [[noble]]s their own rooms, however; they tend to [[mandate|get]] [[demand|upset]] when their [[Noble#Room Requirements Summary|requirements]] are not met)

More than one dormitory can be built in a fortress; if they do not own their own bedroom, dwarves will gravitate to a nearby empty bed when it is time for them to sleep.

Communal dormitories are more appealing now due to the presence of [[vampire]]s among fortress populations, as it increases the likelihood of the offending bloodsucker being caught.

Note that compared to the solid block of 1x1 bedrooms above, the only advantage to a communal dormitory is the ease with which it can be set up - even owning a 1x1 room generates happy thoughts (as opposed to the minor negative one from a dormitory) and take the exact same space. Therefore, if unhappy thoughts are a concern, you should designate the beds as rooms instead.

=== Plain square design ===
[[Image:3x3 example.png|180px|right]]
If it is 2×2, 3×3 or more, square designs are probably the first choice of many players. Easy to plan, easy to put in place, this kind of design is one of the best when the player values their playing time instead of the overall layout of their fortress. While square designs are easy to reproduce en masse, most are not optimized either for beauty or space efficiency, two aspects that other designs excel at.

=== Line design ===
[[Image:line_bedroom.png|right|thumb| '''Line design''', laid out (left) and finished (right)]]
Line designs have the advantage of being very space efficient and very adaptative. From 1×1 to 1×4 and longer, it can fit almost anywhere, can be upgraded later on as long as you have the space behind your first original line and do not need excessive corridor space for the bedroom access. Simply dig a few lines out of an access tunnel already in use in your fortress and voilà, you have new living quarters. This kind of minimalistic design was particularly useful when the economy kicked in, as it could be adapted in a flash to meet the needs of low-wage citizens.

===Decentralized living===
In larger fortresses, one of the bigger problems is traffic. Dwarves have a tendency to all get hungry, thirsty, and tired in waves, and a crowd of 50 of them storming your centralized food stockpiles, one big dining room, and dormitory tunnels can cause a lot of lost time while the hordes shuffle by each other. A good solution to this is decentralized architecture, incorporating most of the essentials of every day life into numerous smaller areas. This isn't to suggest that you shouldn't have a legendary dining hall set as a meeting area, capable of holding half your fortress at once. You definitely should! But decentralizing from that dining hall relieves a lot of congestion in the halls surrounding the main dining hall, and makes it easier for dwarves just to pass through.

[[image:Living.GIF|right]]
In this image, the access stairwell (blue fields in the center), spread out in all directions to a public dormitory and dining room for poorer dwarves on the left/right and to 3x3 private rooms on the top/bottom. The design allows for two small stockpiles of food (gray fields) to minimize the walk to a dining hall.

There are also built-in areas for impressive things like [[Main:statues|statues]] and [[Main:cages|cages]] (for zoos) to keep dwarves admiring your handiwork. The 3x3 rooms are easy to get up to decent or higher to keep your most useful dwarves happy as clams. They're also convenient for impromptu noble housing, since you can just knock out a wall between two rooms and convert one into a dining room for a whiny noble. You could even expand the corner rooms a bit more on both the X and Y axes to make four 3x3 rooms to give the noble a dining room, tomb, and office all in one area. This is especially useful for the mayor, who gets replaced every so often. When a new Mayor is elected, one can reassign all the trappings to the new mayor in one go. If you want an even more decentralized and calm traffic pattern, put tables and chairs in all the private rooms; dwarves will prefer to eat in their quarters. The walls between the doors leading to the dormitory and Dining Room allow for 2 entrances and 2 exits to each predictably higher-traffic room while leaving a pillar of rock for an engraving. The main corridor also allows you to branch off into 4 restraints per floor in a private 1x2 prison. Since it's flanked by an animal cage and a statue (or alternatively, 2 statues. This may be better because Statues block movement and it's effectively the same as surrounding the prisoner with walls). Additionally, in an area you want smoothed and engraved to begin with, it gives prisoners a leg upon their happiness immediately and -- once again -- prevents traffic jams from convicts being brought food and water in larger prisons.

Another option for maximizing traffic throughput is to put a 1x3 line of upward stairwells on one end of the blue field, and a 1x3 line of downward stairwells on the other. This simulates a 3-wide vertical corridor without the safety risks of up/down stairwells.

You may also, at your discretion, knock out the statues and cages near the stairwell to make the entire plan a little more compact (though you lose the easy prisons in this case). This plan can stretch on the x axis as much as you like, but note that the 1 wide corridors leading to individual rooms can get crowded if more than 10 dwarves are living along each one. Even with the given layout, though, one floor supports 26 private rooms and as many as 14 public beds. This works out quite nicely since one floor is enough to handle most immigrant waves, while existing floors' public beds can handle a decent amount of overflow. The public dormitory rooms can also be converted into prisons very easily (just put chains next to every bed) if you decide not to go with the main design.

=== High density single floor housing ===

[[Image:Housing_by_Marble_Dice.png|thumb|244px|This is the 61x61 housing plan]]

This fractal-inspired design combines space efficiency with wider access hallways to alleviate traffic jams. Stairs are placed in the middle, and the design can expand indefinitely. To decrease the size, remove the outermost perimeter hallway, and all connected bedrooms. To increase the size, use the picture as a guide and follow the same radial pattern.

{| class="wikitable" style="padding:"
|-
! style="text-align:left;" | Size
! style="text-align:left;" | Capacity
! style="text-align:left;" | Max walk distance from center
|-
| style="padding-right:26px;" | 29x29 tiles
| style="padding-right:26px;" | 48 dwarves
| style="padding-right:26px;" | 23 steps
|-
| style="padding-right:26px;" | 45x45 tiles
| style="padding-right:26px;" | 120 dwarves
| style="padding-right:26px;" | 39 steps
|-
| style="padding-right:26px;" | 61x61 tiles
| style="padding-right:26px;" | 224 dwarves
| style="padding-right:26px;" | 55 steps
|-
| style="padding-right:26px;" | 77x77 tiles
| style="padding-right:26px;" | 360 dwarves
| style="padding-right:26px;" | 71 steps
|}

 

=== The multiply-overlapping single bedroom ===

A variation on the dormitory can produce large numbers of cheap, high quality bedrooms, very easily. Start with a large room, perhaps 20 x 20 tiles, and put many beds in it. From each of those beds, create a bedroom that covers the entire room. Each of the rooms overlaps the other rooms, and therefore suffers a quality modifier, but the room is large enough that its size can dominate the quality calculation. The quality hit for overlapping rooms is only applied once; your room either overlaps or it does not. With any reasonable amount of beds, it is easier and cheaper to furnish the one room with high quality items (at a penalty) than it is to carve out and furnish dozens of rooms separately. In addition, side by side beds in an open room is by far the most efficient use of space and walking distance. A room this size with a couple hundred beds in it, and some combination of smoothing, engraving, or multiple pieces of cheap furniture, can be of any quality level that is desired, from modest to royal.

=== Staggered Doorless Rooms ===

Dwarves suffer no penalties for having other Dwarves travel through their bedrooms even when they are sleeping. They also don't require doors. Therefore, you can take advantage of diagonal pathing in room design for high-density, non-overlapping, multi-tile rooms.

The following diagram shows a 3x1 layout surrounding a 3x3 stairwell. The design can be repeated outwards as far as necessary.

<pre>
---.B.---.B.---
.B.---.B.---.B.
---.B.---.B.---
.B.---XXX---.B.
---.B.XXX.B.---
.B.---XXX---.B.
---.B.---.B.---
.B.---.B.---.B.
---.B.---.B.---
</pre>

Dwarves will navigate from the stairwell diagonally through rooms, while bedroom sizes can be applied at 3x3 (without the area leaking to adjoining rooms) allowing for some level of furnishing.

=High density, single floor, quick housing=

[[Image:Dwarf-bedroom-simple.jpg|thumb|250px|This is a 35x35 housing plan]]

This design is nice in that it is very quick to lay since using shift to move the cursor moves in steps of 11 tiles. It is also very easy to increase or decrease their value by adding or removing [[furniture]]. Each 1-tile wide walkway is shared by 10 dwarves reducing congestion and each room can fit a bed, a chest and a cabinet leaving 1 free space for any miscellaneous items such as a statue for legendary dwarves, the free space is in the back of the room for the reason that it allows you to place blocking items that cannot be moved over there without sealing your dwarves in/out.

=High density, multi-level=

Optimizing space, minimizing walking distance, these are good things... for some...

===Magical Multi-way Doors===

The main point of this design is that it squeezes six bedrooms in a space of 9x8 squares (including walls) by using two-way doors. It's meant to be built across several Z-levels, making it take up a minimal amount of practical space. It can be easily mirrored, although that requires a wider corridor (or the use of four bedrooms instead of six on the other side).

{{diagram|spaces=yes|\
Level -1 ¦ Level 0 ¦ Level 1
+-----+ ¦ +-----+ ¦ +-----+
¦..¦..¦ ¦ ¦..¦..¦ ¦ ¦..¦..¦
+-+.¦.+-+ ¦ +-+.¦.+-+ ¦ +-+.¦.+-+
¦.+D-D+.¦ ¦ ¦.+D-D+.¦ ¦ ¦.+D-D+.¦
¦..¦X¦..¦ ¦ ¦..¦X¦..¦ ¦ ¦..¦X¦..¦
¦---D---¦ ¦ ---+.+--- ¦ ¦---D---¦
¦...¦...¦ ¦ ......... ¦ ¦...¦...¦
+-------+ ¦ ¦ +-------+}}

'''Alternate layout:'''

This is a simpler (though slightly less compact) design using three-way doors.

{{diagram|spaces=yes|\
+---+---+
¦...¦...¦
+---+---D---+
¦...¦XXX¦...¦
+---D---+---+
¦...¦...¦
+---+---+}}

One apartment "unit" gives you 6 rooms using only 2 doors and it fits within a 13x7 space (including walls). Access to the apartments in the unit is through the 1-3 up/down stairwells in the center. This design can be expanded by repeating the same pattern one level down and/or by tiling together multiple units together on the same level.

Both designs mean that you have to build less doors per bedroom, which helps save time and materials.

===Sandwich===

A design to move bedrooms vertically spread across many unused Z levels easily. The rooms can be preferentially scaled up or down depending on needs. If space is reserved serves well for expansion of each bedroom as suitable.

The sandwich basically consists of a three tile wide hallway or wider. Up/Down Stairways are evenly distributed in increments which lead to one or more bedrooms as needed. [[Floor hatch]]es can be used between the individual bedrooms like vertical doors, but, unlike doors, owned floor hatches can generate happy [[thought]]s.

[http://www.bay12forums.com/smf/index.php?topic=118751.0 Recent science] has established that having any "holes" in a room's walls reduces the apparent [[room value]]; this design is therefore particularly well-suited to producing high-value rooms.

{{diagram|spaces=yes|\
Level -1 ¦ Level 0 ¦ Level 1
+-----------+ ¦ ¦ +-----------+
¦B.¦B.¦B.¦B.¦ ¦ ¦ ¦B.¦B.¦B.¦B.¦
¦..¦..¦..¦..¦ ¦ ------------- ¦ ¦..¦..¦..¦..¦
¦X.¦X.¦X.¦X.¦ ¦ .X..X..X..X.. ¦ ¦X.¦X.¦X.¦X.¦
¦--+--+--+--¦ ¦ ............. ¦ ¦--+--+--+--¦
¦X.¦X.¦X.¦X.¦ ¦ .X..X..X..X.. ¦ ¦X.¦X.¦X.¦X.¦
¦..¦..¦..¦..¦ ¦ ------------- ¦ ¦..¦..¦..¦..¦
¦B.¦B.¦B.¦B.¦ ¦ ¦ ¦B.¦B.¦B.¦B.¦
+-----------+ ¦ ¦ +-----------+}}

The bedroom design can be copied several times further up and down starting from Level 1 or -1 to exploit available space in neighbouring Z levels. The design is excellent as the space surrounding the hallway can be used for directly tying to the dining/meeting hall.

===6-room clusters===

[[File:ClusterBedrooms.png|thumb|350 pix|'''6-room clusters''' ''(click to enlarge)'']]
This one is quite dense. There are six bedroom clusters. They can be built close to each other.

There are 7 6-room clusters here. If 5 Z-Levels of this are built, that's 5*7*6=210, which is plenty for most any fortress.

=== Living Pods (Residential Flats) ===

This design is compact and allows for a large number of rooms. Each room has 3 tiles plus a door. To add to the complex build an apartment level one level above or below the lobby - the stairs allow direct access. The design can be stretched to make the rooms 3x2 or 3x3, or to allow more rooms per floor, depending on your preference. Though not as visually impressive as the fractal patterns it is very efficient in that it can allow for large numbers of dwarves to easily access the main hallway. The pods are very quick to deploy as the interior (mined out) width of the pods exactly equals one {{k|Shift}}+move of the cursor. Highlight a full square with a horizontal shift+move then a vertical. Then ''un''mark the 3 internal walls in both horizontal and vertical directions (each also 1 shift+move distance long), and finally mark in the four staircases. Sixteen bedrooms with extremely efficient pathing laid out in as many seconds.
{{diagram|spaces=yes|\
Upper/lower
Apartment Level: Lobby Level:
+-----------+ +-----------+..
¦..¦..¦..¦..¦ ¦..¦..¦..¦..¦.. O
¦.+-+.¦.+-+.¦ ¦.+-+.¦.+-+.¦.. u
¦-¦X¦-+-¦X¦-¦ ¦-¦X+---+X+-+.. t
¦.+-+.¦.+-+.¦ ¦.++..O........ e
¦..¦..¦..¦..¦ ¦..¦........... r
¦--+--+--+--¦ ¦--¦O...O+--+..
¦..¦..¦..¦..¦ ¦..¦.....¦..¦.. H
¦.+-+.¦.+-+.¦ ¦.++..O..++.¦.. a
¦-¦X¦-+-¦X¦-¦ ¦-¦X+---+X¦-¦.. l
¦.+-+.¦.+-+.¦ ¦.+-+.¦.+-+.¦.. l
¦..¦..¦..¦..¦ ¦..¦..¦..¦..¦..
+-----------+ +-----------+..}}

==== Pod variant ====

This is an example of varying the above to suit personal taste. Three significant changes have been made:

:1) 2 pairs of vertical access stairs feed upward, instead of one horizontal hallway.

:2) The entire design has been expanded (to 15x15, vs 13x13 above), but rooms have not been expanded to fill all available space - not yet. That will be done if/as need arises, and many of the 3-tile rooms can become 5- or 7-tile1, or two joined together to become 12-tile suites2.

:3) Allow for a central waterfall with drain system*.

<pre>
Upper Apartment Lobby Lower Apartment
Level(s*): Level: Level(s*):
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
¦..¦..¦ ¦..¦..¦ ¦..¦..¦ ¦..¦..¦ ¦..¦..¦ ¦..¦..¦
¦.+-+.¦ ¦.+-+.¦ ¦.+-+.¦ ¦.+-+.¦ ¦.+-+.¦ ¦.+-+.¦
¦-¦X¦-¦ ¦-¦X¦-¦ ¦-¦X¦-----¦X¦-¦ ¦-¦X¦-----¦X¦-¦
¦.+¦+.¦ ¦.+-+.¦ ¦.+¦+.OOO.+-+.¦ ¦.+¦+..¦..+-+.¦
¦..¦..¦ ¦..¦..¦ ¦..¦.......¦..¦ ¦..¦.+---+.¦..¦
+--+-------+--+ +--¦..###..¦--+ +--¦.¦~~~¦.¦--+
¦XX#~#XX¦ ¦<<#~#<<¦ ¦-¦~¦~¦-¦
+--+-------+--+ +--¦..###..¦--+ +--¦.¦~~~¦.¦--+
¦..¦..¦ ¦..¦..¦ ¦..¦.......¦..¦ ¦..¦.+---+.¦..¦
¦.+-+.¦ ¦.+-+.¦ ¦.+-+.OOO.+-+.¦ ¦.+-+..¦..+-+.¦
¦-¦X¦-¦ ¦-¦X¦-¦ ¦-¦X¦-----¦X¦-¦ ¦-¦X¦-----¦X¦-¦
¦.+-+.¦ ¦.+-+.¦ ¦.+-+.¦ ¦.+-+.¦ ¦.+-+.¦ ¦.+-+.¦
¦..¦..¦ ¦..¦..¦ ¦..¦..¦ ¦..¦..¦ ¦..¦..¦ ¦..¦..¦
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+}}
Legend:
X = up/down stair
< = up stair
~ = flowing water, in waterfall and drain
# = [[grate]] or floor [[bars]] over drain
¦ = solid block at base of waterfall
O = [[statue]]s (though a [[zoo]] or booze stockpiles could work as well)</pre>
Notes:
: 1) There is a central, vertical line of unused tiles, allowing adjacent rooms to be expanded to 5 tiles large.
: 2) Expanding out one more tile beyond the outer boundaries can create size 5-11 rooms, or size 19 if two are connected.
: 3) A size 15 room is ample for any noble, with the possible exception of a [[king|king/queen]].

:<nowiki>*</nowiki> The floor plan for the waterfall/drain system may vary from floor to floor, and by personal taste. Eventually it can be routed off and out one side, and the full interior area of all levels below that reserved for apartments.

''(Note - It's easy to [[flood]] an area with a waterfall such as this - be sure you are familiar with the technique before risking an entire dormitory (or the lower parts, at least) on it.)''

=== Greek Cross design===
[[image:VaniverGreek48.png|right|thumb| 48 room design]]
Minimizing walking distances requires good use of vertical space. This plan is simple, scalable, and only takes up a few floors - 6 if you have 32 per floor, 4 if you have 48. The maximum walking distance should be less than 20 (walking up/down stairs counts as one distance.).[[image:VaniverGreek32.png|center|thumb| 32 room design]]
A Quickfort blueprint for the 32 tile Greek Cross design is available [http://www.mediafire.com/download/yfeoeo0qj38vw24/Greek_Cross_Design_Blueprint.zip here]

=== Shaft design ===

[[Image:Shaft_bedroom_design.gif|thumb|Shaft bedroom design with a few possible variations.]]

The Shaft design allows various options for entry direction and central "shaft" use. The central shaft may be altered to create dining rooms and offices for minor nobles, "deluxe" bedrooms, hospital beds, or simply more bedrooms. The design can easily accommodate several different room sizes while maintaining efficiency. However, the design utilizes Z-levels for efficiency, and you must build several levels of Shaft designs to accommodate a fully grown fortress.

The Shaft design can fit 20 2x2 rooms, or 30 1x1 rooms.

=== Tileable shaft design ===

The tileable shaft design is a further expansion of the general shaft design above, coming in somewhere between the simple geometric designs and the vastly more complex fractal designs. These are designs that can be symmetrically tiled, that means concatenated in all six directions and are thus suited both for manual design as well as macro-automation. They allow the user to extend the same pattern over very large areas and to easily extend the available space per room up to a given size by tearing down just a few walls. Additionally, they can be suited for bedrooms as well as work and storage.[[Image:tileable_shaft_big.png|thumb|Tileable shaft design with a few possible variations.]]

The downsides are that they're not especially optimized for walking distance or large hallways, and the necessity of the main access shaft on the z-level (stairs) having to be in the central-most tile (marked red in the examples) to allow z-level stacking.

=== Modified Windmill Villas ===

This is the most efficient method I have seen, and it keeps the central staircase as well.

(Calculations use 8 levels)
*Dwarfs per level = 28
*Levels needed for 200 = 7.1
*Max distance (including Z) = 15
*Average distance = 10.2
*Average distance per level = 5.4

[[Image:Modified_Windmill_Villas.png|Modified windmill villas]]

=== Squarified Tri-way Doors ===

Four "tri-way doors" patterns adjacent to each other, squarified with 4 normal rooms and 2 noble rooms.

This results in 30 bedrooms in a 21x15 rectangular space (counting all walls, including external ones). Can be repeated multiple z-levels, accessed from a lobby hallway.

{{diagram|spaces=yes|\
+-------+---+---+---+
¦.....DX¦...¦...¦...¦
+---+---+---D-+-+-+D¦
¦...¦...¦...¦X¦...¦X¦
+---D-+-+-+-+-D---+D¦
¦...¦X¦...¦...¦...¦.¦
+-+-+-D---+---+---+.¦
¦.¦...¦...¦...¦...¦.¦
¦.+---+---+---D-+-+-+
¦.¦...¦...¦...¦X¦...¦
¦D+---D-+-+-+-+-D---+
¦X¦...¦X¦...¦...¦...¦
¦D+-+-+-D---+---+---+
¦...¦...¦...¦XD.....¦
+---+---+---+-------+}}

=== Large Squarified Tri-way Doors ===

By playing with the basic building block of the above design, and a 25x25 space, you can get this elegant square and symmetrical design:

{{diagram|spaces=yes|\
╔═╦═╦═══╦═╦═╦═╦═╦═══╦═╦═╗
║ +X+ ║ ║ ║ ║ ║ +X+ ║
║ ╠═╬═╦═╣ ║ ║ ║ ╠═╦═╬═╣ ║
║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║
╠═╣ ║ ║ ╠═+═╬═+═╣ ║ ║ ╠═╣
║ ║ ║ ║ ║X║ ║ ║X║ ║ ║ ║ ║
║ ╠═+═╬═+═╣ ║ ╠═+═╬═+═╣ ║
║ ║X║ ║ ║ ║ ║ ║ ║ ║ ║X║ ║
╠═+═╣ ║ ║ ╠═╩═╣ ║ ║ ╠═+═╣
║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║
║ ║ ╠═╩═╬═╣ ╔═╩═╬═╩═╣ ║ ║
║ ║ ║ ║X+ ║ ║ ║ ║ ║
╠═╬═╬═══+═╩═╬═╦═+═══╬═╬═╣
║ ║ ║ ║ ║ +X║ ║ ║ ║
║ ║ ╠═╦═╬═╦═╝ ╠═╬═╦═╣ ║ ║
║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║
╠═+═╣ ║ ║ ╠═╦═╣ ║ ║ ╠═+═╣
║ ║X║ ║ ║ ║ ║ ║ ║ ║ ║X║ ║
║ ╠═+═╬═+═╣ ║ ╠═+═╬═+═╣ ║
║ ║ ║ ║ ║X║ ║ ║X║ ║ ║ ║ ║
╠═╣ ║ ║ ╠═+═╬═+═╣ ║ ║ ╠═╣
║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║
║ ╠═╬═╩═╣ ║ ║ ║ ╠═╩═╬═╣ ║
║ +X+ ║ ║ ║ ║ ║ +X+ ║
╚═╩═╩═══╩═╩═╩═╩═╩═══╩═╩═╝}}

This is the most space-efficient design when aiming for bedrooms with exactly three tiles of space which are accessible without crossing another bedroom. It uses only 9 tiles per bedroom overall, an amazing feat, since the mathematical minimum for the problem given is 8 tiles per bedroom! Such bedroom allocations are not in any way required, however: normal citizens are perfectly happy with an [[#The_multiply-overlapping_single_bedroom|overlapping bedroom]] in a large hall packed to capacity with beds.

=Repeating patterns & fractals=

Art for art's sake... and if it's functional, so much the better...

=== Blossom ===
[[Image:blossom.png|300px]]

Not truly fractal, but inspired by other fractals with a more aesthetic appeal. A slightly stripped down quickfort version of this is available [http://www.mediafire.com/view/?wx3g4373422u02r here].

=== Tessellated Apartments ===

[[File:Tessellatedrooms.jpg]]

Access can be from above and/or below by the stairs, or a hallway can be run into the dining room level by removing the bedroom at one of the cardinal points. This design can be repeated as far as desired in the X, Y, and Z directions.

===Noble Hive Pods===

A geometric pattern for Noble housing trying for interesting aesthetics and high mobility. The basic tiling pattern is shown on the left; one possible way to join them, involving surrounding corridors and a central staircase and a jillion doors, on the right.

[[File:Noblehive.png]]

=== Fractal designs ===

Betting on design beauty and on geometrical symmetry first, fractal designs can also be, at the same time, very space and walk efficient. They however require a lot of time and space both to plan and execute and are most likely out of reach of all but the most serious players. On the other hand, most of the designs displayed below would be avoided by the most serious players, due to their lack of serious Z-level access and incongruity with almost any general access plan. Most players however agree that they are the most incredible of all the designs around, if not for the sheer challenge of successfully executing something as complex, as for the extra touch it gives to the fortress as a whole once it is done.

[[image:Raynard_square_delight1.png]] [[image:Raynard1.png]]

[[image:Raynard_whirlpool_housing.png]]

[[image:Hactar1_3_branch_tree.png]] [[image:Hactar1_Mandelbrot_Tree.png]]

[[Image:SavokisLeaf08a032.png]]

[[image:Andrelius_Windmill_Villas.png]]

[[image:4bh0r53n_h-fractal.jpg]]

More fractal bedroom designs based upon the H-Tree (pictured above) can be found at [[User:Tenebrous|this user page]].

===Fractal modified for 3d===
This was created by palin88 from [http://www.bay12forums.com/smf/index.php?topic=17784.msg17413 Bay12Games forum] in order to make a three-dimensional version of Raynard's Fractal Design.

[[File:Palin88_Bedroom_Design.png]]

===Animated design===

Tall towers of designs are more efficient to designate, but can be visually boring and hard for you to orient which z-level you are currently on when zoomed in. You can 'animate' any tower based patterns by rotating around a central staircase. The rooms become less uniform in shape, but as you move z-levels it produces a more eye-catching animation that can also help with keeping oriented.

===Hallway with office===

+---------+╤¦ ¦b+---------+
¦B¦B¦B¦B¦B¦╥¦ ¦r¦B¦B¦B¦B¦B¦
¦k¦k¦k¦k¦k¦H¦ ¦H¦k¦k¦k¦k¦k¦
¦c¦c¦c¦c¦c¦ ¦c¦c¦c¦c¦c¦
¦D¦D¦D¦D¦D¦ ¦D¦D¦D¦D¦D¦
X
¦D¦D¦D¦D¦D¦ ¦D¦D¦D¦D¦D¦
¦c¦c¦c¦c¦c¦ ¦c¦c¦c¦c¦c¦
¦k¦k¦k¦k¦k¦H¦ ¦H¦k¦k¦k¦k¦k¦
¦B¦B¦B¦B¦B¦╥¦ ¦╥¦B¦B¦B¦B¦B¦
+---------+╤¦ ¦╤+---------+

Legend: 
B: Bed 
D: Door 
X: Staircase 
╥: Chair 
╤: Table 
c: Chest or Bag 
k: Cabinet 

An interesting design made to consume less space but still look pretty. It can be repeated infinitely, or at least as far as your embark square goes. One may also decide to use the stairwells as noble offices or rooms, or put the staircase somewhere else and put a well where the staircase would be.

{{Buildings}}
{{Category|Design}}

File:3x3 example.png

2023-01-23T22:05:05Z

Tlupes: example of 3x3 bedrooms

== Summary ==
example of 3x3 bedrooms
== Licensing ==
{{Non-free Dwarf Fortress Screenshot}}

File:Dormitory Example.png

2023-01-23T22:02:44Z

Tlupes: dormitory example

== Summary ==
dormitory example
== Licensing ==
{{Non-free Dwarf Fortress Screenshot}}

File:1x1 Bedroom Example.png

2023-01-23T22:00:15Z

Tlupes: Example of a bunch of 1x1 bedrooms

== Summary ==
Example of a bunch of 1x1 bedrooms
== Licensing ==
{{Non-free Dwarf Fortress Screenshot}}

Table

2023-01-23T21:52:45Z

Tlupes: Add premium graphics image

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

{{V50_furniture
|graphic=[[File:Table_Premium.png]]
|name=Table
|tile=╤
|wood=y
|stonecarve=y
|metal=y
|glass=y
|rooms=
* [[dining room|Dining Room]]
* [[meeting hall|Meeting Hall]]
}}

A '''table''' is a piece of [[furniture]] necessary for [[dwarf|dwarves]] to eat [[food]] in comfort. A table is also needed to define a [[dining room]] and serve as an operating surface in a [[hospital]]. Tables are also part of [[traction bench]]es. Dwarves dislike eating at a [[chair]] without a table and can't share their table or chair with others.

Tables can be made from a wide variety of materials, including [[wood]], [[stone]], [[metal]], and [[glass]].

Dwarves primarily use tables to eat [[food]], avoiding the negative [[thought]] for eating without a proper table. Since dwarves first try to sit down and only then check whether there's a table to put their food on, the proper placement of chairs is more important for proper dining. Tables without an adjacent chair will simply not be used for eating; if two tables are adjacent to a single chair, one will go unused. Chairs without adjacent tables, however, will cause unhappy thoughts whenever dwarves sit on them to eat, and a single table with two adjacent chairs can also lead to unhappy thoughts if two dwarves sit on the chairs: only one can put their food on the table, the other will have to eat from their lap and will complain about crowded tables.

An unassigned [[dining room]] designated from a table will be used by any dwarves without an assigned dining room, resulting in positive [[thought]]s scaled to the [[Room#Quality|quality]] of the dining room. Creating a high-value dining room is one of the easiest ways to give your dwarves a happy thought. Note, however, that dwarves with a table (or chair) in their [[quarters]] may opt to eat there instead, so it is generally best to only install tables in your nobles' quarters.

In a [[hospital]] zone, tables are used during [[surgery]] as an operating surface.

Tables are also used as an input, along with [[mechanism]] and [[rope]]s, at the [[Mechanic's workshop]] to make a [[traction bench]]. The quality of each component is not reflected in the quality of the traction bench, and only the material of the table is used as the material for the bench.

Tables can be created from one [[wood]] log at a [[Carpenter's workshop]], one [[stone]] at a [[Mason's workshop]], one bag of [[sand]] at a [[Glass furnace]] or three metal [[bar]]s at a [[Metalsmith's forge]].

{{Buildings}}
{{Category|Furniture}}

File:Table Premium.png

2023-01-23T21:52:19Z

Tlupes: Premium graphics of a table

== Summary ==
Premium graphics of a table
== Licensing ==
{{Non-free Dwarf Fortress Screenshot}}

Memorial

2023-01-23T21:49:43Z

Tlupes: Add premium graphics image

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

{{Merge|Slab|date=November 2017}}

{{V50_furniture
|graphic=[[File:Memorial_Premium.png]]
|name=Memorial
|tile=∩
|stone=n
|metal=n
|glass=n
|slabv50=y
|rooms=
* [[memorial hall|Memorial Hall]]
}}'''Memorials''' are buildings which can be built from the {{k|b}}uild menu under {{k|Alt}}+{{k|s}}. To create one, you first need to order a blank [[slab]] at a [[stoneworker's workshop]] ({{k|a}}, {{k|Alt}}+{{k|s}}), then order an [[engraver]] to make the unengraved slab into a memorial at a [[stoneworker's workshop]] ({{k|a}}, {{k|Alt}}+{{k|s}}). When placing the memorial (listed under 'slab' in the build menu), hitting 'x' on the materials menu will expand the list and let you pick which specific memorial you want. Once engraved, they can be built as an alternative to [[coffin]]s - failure to memorialize or entomb a deceased dwarf may lead to [[ghost|unexpected consequences]]. If you're having trouble finding which slab you want to place, use {{k|x}} to expand the list and find named or blank slabs.

You can create a [[memorial hall]] from a memorial's {{k|q}}uery menu. Memorial halls appear to serve as additional [[meeting hall]]s: free dwarves will congregate in the area and receive happy [[thought]]s from the decorations.

Oddly, it is also possible to engrave memorials to [[goblin|invaders]], [[forgotten beast]]s, and even ''merchant [[wagon]]s'' (not just the merchants, but the wagon itself!). This can be used to create trophy halls full of goblin skeletons and weapons, or to memorialize a deceased warrior's [[kill list]] inside of his tomb.

Memorials work inconsistently for merchants' escorts--some deceased caravan guards are not included in the list of potential memorial subjects. This behavior is presumably a bug, but you can avoid problems by placing dead caravan guards into coffins whenever possible.

[[File:City of London Cemetery collapsed grave slab ledger stone 2.jpg|thumb|370px|center|A collapsed memorial in London.]]
{{Buildings}}
{{Category|Furniture}}

File:Memorial Premium.png

2023-01-23T21:49:18Z

Tlupes: Premium graphics of a memorial

== Summary ==
Premium graphics of a memorial
== Licensing ==
{{Non-free Dwarf Fortress Screenshot}}

File:Slab Premium.png

2023-01-23T21:48:47Z

Tlupes: Tlupes uploaded a new version of File:Slab Premium.png

== Summary ==
Premium graphics for a slab and engraved slab
== Licensing ==
{{Non-free Dwarf Fortress Screenshot}}

Slab

2023-01-23T21:47:33Z

Tlupes: Add premium graphics image

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

{{V50_furniture
|graphic=[[File:Slab_Premium.png]]
|name=Slab
|tile=∩
|stonecarve=y
|metal=n
|glass=n
|rooms=
* [[Memorial hall]]
}}

'''Slabs''' are buildings which serve primarily to commemorate the dead. Unlike [[coffin]]s, slabs do not require any body part of the deceased to function, allowing you to prevent the appearance of [[ghost]]s of dwarves whose bodies are no longer recoverable. Engraved slab [[memorial]]s are usually made for your fort's citizens, but can be made in remembrance of any historical figure which dies on your lands. If a ghost has appeared in a fortress, but a slab commemorating that deceased individual has been placed somewhere, the ghost's spirit will be calmed and disappear. When this happens, the following message appears: 
{{DFtext|Urist McGhost, Ghostly Cheesemaker has been put to rest.|5:1}}

A slab must first be constructed at a [[stoneworker's workshop]] ({{k|Alt}}+{{k|s}}lab) from a single [[stone]], and can then be turned into a [[memorial]] at a [[stoneworker's workshop]] (same workshop) by an [[engraver]] (using {{k|Alt}}+{{k|s}}:Engrave memorial slab). After it has been engraved, the slab may be built from the {{k|b}}uilding menu under {{k|Alt}}+{{k|s}}. In order to prevent placing slabs which have not yet been engraved, make sure to e{{k|x}}pand the list when selecting which slab should be placed.

You can use an engraved slab to create a [[memorial hall]] from the slab's {{k|q}} menu. This is functionally identical to a [[sculpture garden]]. Engraved slabs can be read in fortress mode using {{k|t|Enter|v}}, revealing information on the arrival and death of the creature. If the subject slew any important figures or fortress dwarves, this may also be noted on the slab. If you're not sure how a dwarf or creature died, engraving a slab in their memory may reveal the killer.

Slabs, whether blank or engraved, can also be built solely to increase a [[room]]'s [[value]]. They aren't terribly valuable, but don't block movement.

{{minorspoiler}}

[[Artifact]] slabs can be found in [[vault]]s throughout the world. Although extremely well-guarded, your dwarves can perform raid [[mission]]s to capture them and bring them back to your fortress.

== Adventurer mode ==
In [[adventurer mode]], slabs are occasionally used as signs. They also appear in two particularly interesting places. If you manage to infiltrate or conquer a [[necromancer]]'s [[Tower (necromancy)|tower]], you may find an engraved slab which contains the secrets of life and death. To read this, you need to pick it up with {{k|g}}, enter advanced interaction menu with {{k|Shift}}+{{k|I}}, select the slab, select {{k|a}} to read it, and voila! You can now raise the dead too. Basic [[reader|reading]] [[skill]]s are required to do this, so make sure to start your adventurer with some reading skill.

A slab is also found in the bottom of sealed [[vault]]s, which contains a different kind of secret. See the [[Vault]] article for further details.

{{Buildings}}
{{Category|Furniture}}

File:Slab Premium.png

2023-01-23T21:45:47Z

Tlupes: Premium graphics for a slab and engraved slab

== Summary ==
Premium graphics for a slab and engraved slab
== Licensing ==
{{Non-free Dwarf Fortress Screenshot}}

Throne

2023-01-23T21:39:44Z

Tlupes: Add premium graphics image

{{migrated article}}
{{av}}
{{Quality|Unrated}}
{{V50_furniture
|graphic=[[File:Chair_Premium.png]]
|name=Throne
|tile=╥
|wood=y
|stonecarve=y
|metal=y
|glass=y
|rooms=
* [[Office]]
}}
{{For/see|throne room|[[Office]]}}

A '''throne''' or '''chair''' is a piece of [[furniture]] that dwarves use in their daily routines once built as a '''seat''' (the generic term). A throne can be made from [[stone]] at a [[stoneworker's workshop]] with [[stone carver]], 3 [[metal|metal bars]] at a [[forge]] with [[blacksmithing]], [[glass]] at a [[glass furnace]] with [[glassmaking]], or from [[wood]] at a [[carpenter's workshop]] by a dwarf with the [[carpentry]] [[labor]] (where it's listed as a "chair"). The material has no effect on its functionality; all thrones work the same. Note that for an equal skill level, wood chairs are produced faster than rock thrones{{verify}}, though different [[material]]s have different final base [[Value#Material_multipliers|value]] multipliers.

The {{k|b}}uild menu option {{k|f}}urniture chai{{k|r}} will allow you to place any throne/chair as a "seat", but only [[inside|indoors]].

Seats, like [[table]]s, are an obvious part of [[dining room]]s -- Dining at a seat in a high-quality dining hall will give an (additional) happy [[thought]]. If a dwarf wants to eat, they will look for a free seat. If they don't find one, or one without a free table next to it, they will have an unhappy thought. Dwarves do not share tables; a dwarf sitting at a seat will have exclusive use of the table next to it. Having enough seats and tables and placing them in an unambiguous 1:1 pattern avoids these bad thoughts. Seats are also used to create [[office]]s (and throne rooms, essentially the same thing) for [[nobles]].
[[File:throne_preview.png|thumb|220px|center|Some call it the "pompous placement".]]
{{Translation
| dwarven = kalur
| elvish = toneri
| goblin = zongosp
| human = sathrel
}}

{{Buildings}}
{{Category|Furniture}}

File:Chair Premium.png

2023-01-23T21:39:07Z

Tlupes: A wooden chair

== Summary ==
A wooden chair
== Licensing ==
{{Non-free Dwarf Fortress Screenshot}}

Restraint

2023-01-23T21:35:45Z

Tlupes: Add premium graphics image

{{Quality|Unrated}}
{{av}}
{{V50_furniture
|graphic=[[File:Restraints_Premium.png]]
|name=Restraint
|tile=§|col=7:0:0
|metalcraft=y
|cloth=y
|leather=n
|rooms=
* [[Jail]]
* [[Zoo]]
}}[[File:restraints_preview.png|thumb|300px|right|"Alright, now don't go anywhere!"]]'''Restraints''' can be built from [[chain]]s or [[rope]]s, using the keys {{k|b}} + {{k|r}} + {{k|h}}. They can be used to tie up guard non-[[pet]] [[animals]], prisoners, criminals or livestock. Also of note is that after you do tie up a individual they are not shown as such if you decide to tie up another at another chain/rope. Currently as of 50.05 they are not listed with the chained up icon. Its recommended as a workaround to rename the animal with chained in the name. So "War Dog" can be renamed "Chained War Dog" and will be listed as "Stray Chained War Dog"(Game automatically puts the Stray if the animal does not have a name). They are listed with a chain icon in the list when assigning animals to a pasture so this is probably just a quirk of the UI.

A restraint is (technically) a 1-tile large [[building]], a chain or rope which is used to restrain a [[dog]], [[dwarf]] or other [[creature]] to a certain very limited area of movement. Unlike a [[cage]], a restraint can only hold one creature, and the creature can move within a range of one tile from the location of the restraint itself, including up and down if [[stairs]] or slopes are in this area. This gives them, at most, a 3×3×3 cube of movement, limited as normal by [[wall]]s, [[door]]s etc. Restraints do not block movement, including movement of [[wagon]]s. While an animal is assigned to it the same as with a cage, dwarves can and will only be assigned from within the justice system inside a [[dungeon]] zone.

Restraints can be used to keep a war dog or other animal near areas where you need constant vigilance and defense. Chained animals placed near the entrance to your fort will spot [[kobold]] thieves that can bypass [[trap]]s and other passive defenses, pausing the game and [[announcement|announcing]] their presence. A pair of animals, placed opposite each other against the walls of a 3-wide corridor (so they cannot have more than 1 tile between them), are guaranteed to spot any [[thief]] that tries to enter, and (if combative) will similarly engage any hostile creature. But assigning a pasture for the guard animal is more resource efficient way to guard specific areas. This also allows the animal to walk away on its own if there ever is an alert that forces everybody to a certain area.

Restraints can also be useful in the [[meat industry]], since animals on restraints can [[meat industry#Breeding|breed]], unlike animals in cages. Chained animals are also available for [[animal trainer|training]] (when the appropriate [[zone]] has been designated around the chain). This can be particularly important for dangerous creatures that are only partially [[tame]]. Dwarves will also feed animals on restraints if they get hungry, making them an effective way to keep grazing animals alive during sieges.

Restraints are also very useful in weaponizing otherwise untrainable creatures that you've managed to capture in a cage trap. Hostile creatures on restraints will no longer be aggressive to dwarves, which means [[semi-megabeast]]s, [[megabeast]]s, and even [[forgotten beast]]s can be chained up where a guard is needed as these will still draw aggression from invaders and [[undead]], and will fight back when possible (within range of being restrained). Beware though, as forgotten beasts with special attacks like deadly dust may still use it liberally even if chained, and this can be harmful to dwarves. Restrained building destroyers may destroy nearby buildings, so they should be located a safe distance from anything destructible (including other restraints).

Currently, due to a bug, a restrained animal will keep the restraint on their upper body if it's deconstructed while the animal is still restrained. This can be used to "equip" your beasts with decorations, such as spiked chain collars or lavish ropes, but has no in-game effect. Similarly, if you move a caged were-creature in its non-were form to a chain, and then de-assign it that chain, it will immediately recage itself rather then be set free. Its unclear if the cage is duplicated when this happens or if the prisoner has the cage as an item.

If a creature falls down from a ledge while restrained, it will not be left hanging. Instead, it will be released from the restraint and keep falling.

== Bugs ==
*Wild animals assigned to a restraint may be immediately re-caged by another dwarf.{{bug|7664}}

{{buildings}}

{{Category|Justice}}

File:Restraints Premium.png

2023-01-23T21:35:11Z

Tlupes: Premium graphics of a chain and rope restraint

== Summary ==
Premium graphics of a chain and rope restraint
== Licensing ==
{{Non-free Dwarf Fortress Screenshot}}

Display furniture

2023-01-23T17:37:00Z

Tlupes: Add premium graphics image

{{migrated article}}
{{Quality|Unrated}}
{{av}}
{{V50_furniture
|graphic=[[File:Pedestal_Premium.png]]
|name=Pedestal
|tile=ï
|wood=y
|stonecarve=y
|glass=y
|metalcraft=y
|rooms=
[[Museum]]}}
{{V50_furniture
|graphic=[[File:Display_Case_Premium.png]]
|name=Display case
|tile=π |col=0:6:0
|wood=y
|rooms=
[[Museum]]}}

A piece of '''display [[furniture]]''' can be used to display other items. There are two available types of display furniture, pedestals and display cases.

Pedestals are created from [[wood]], [[stone]], [[glass]], or [[metal]] at a [[carpenter's workshop]], [[stoneworker's workshop]], [[glass furnace]], or [[forge]], respectively; while wood, stone, and glass only require 1 material to craft, metal requires 2 bars. Being tools, they are listed at a forge under "Other Objects" rather than "Furniture", and a metal pedestal is made using [[metalcrafting]], not [[blacksmithing]].

Display cases are created from a [[log]] and a [[window]] at a [[carpenter's workshop]]. The window used to create the display case does not affect it in any way; a ☼display case☼ made with a ☼crystal glass window☼ is worth as much as a ☼display case☼ made with a -green glass window-, and the window used is not mentioned in any context.

Other than the above mentioned creation processes, their visual appearances and the fact that display cases are twice as large as pedestals (and thus twice as heavy as a pedestal made out of the same material), pedestals and display furniture are completely identical, their behavior determined entirely by the [[DF2014:Tool token#TOOL_USE|DISPLAY_OBJECT]] tool use.

In the {{k|b}}uilding menu, they are listed in display {{k|F}}urniture. Once built, display furniture can be examined with {{k|q}} and the display item(s) can be selected with {{k|d}}. The selection menu displays a list of all categories of items that can be displayed on the furniture. Highlighting one of the categories lists the items of that type that are available, and highlighting an item shows its description and location at the bottom of the screen. Pressing {{k|Enter}} designates an item to be put on it, which will be done by [[Hauling#Item_hauling|item haulers]]. A [[museum]] can be created from built display furniture using {{k|q|r}}.

Dwarves will admire both the display furniture and the item on display, giving them happy thoughts. A dwarf must stand in or pass through the actual tile containing the display furniture in order to admire it; they cannot do so from a distance. This unfortunately leaves your artifacts on display vulnerable to sticky-fingered [[Villain|villains]]. If the only objective is to increase the value of a location, however (for example, to instantly turn a meeting place into a grand guildhall), the object can be locked away, such as by vertical grates or bars.

Display furniture are [[stockpile]]d as furniture, under "Other Large Tools".

In [[adventurer mode]], pedestals can be found in many generated sites, sometimes alongside display cases. It is possible to place an item on a pedestal by standing next to (or on) it and {{k|p}}utting the item onto the pedestal. Likewise, it is possible to remove an item from a pedestal by standing on the same tile as it and {{k|g}}etting it. These actions will be seen by NPCs as, respectively placing or taking the item from the site, though they only care if the item is an [[artifact]].
<gallery mode=packed widths=300px heights=300px>
File:Room 232 of the Louvre display case 4-P7160410.JPG|Room 232 of the Louvre.
File:pedestal_preview.png|Can hold - not one - but ''three'' containers of alcohol.
</gallery>
{{Gamedata|title=Pedestal raws|{{raw|DF2014:item_tool.txt|ITEM_TOOL|ITEM_TOOL_PEDESTAL}}}}
{{Gamedata|title=Display case raws|{{raw|DF2014:item_tool.txt|ITEM_TOOL|ITEM_TOOL_DISPLAY_CASE}}}}
{{Buildings}}
{{Category|Furniture}}

File:Display Case Premium.png

2023-01-23T17:36:33Z

Tlupes: Premium graphics of a display case

== Summary ==
Premium graphics of a display case
== Licensing ==
{{Non-free Dwarf Fortress Screenshot}}

File:Pedestal Premium.png

2023-01-23T17:35:47Z

Tlupes: Premium graphics pedestal

== Summary ==
Premium graphics pedestal
== Licensing ==
{{Non-free Dwarf Fortress Screenshot}}

Coffin

2023-01-23T17:04:25Z

Tlupes:

{{migrated article}}
{{Quality|Unrated}}{{av}}
{{V50_furniture
|graphic=[[File:Coffin_Premium.png]]
|name=Coffin
|tile=0
|wood=y
|stonecarve=y
|metal=y
|glass=y
|rooms=
* [[Tomb]]
}}
[[Image:Catacombs.png|thumb|right|Every respectable dwarven fortress has a developed (and occupied) catacombs system.]]
'''Burial receptacles''' are [[container]]s for deceased dwarves and their [[pet]]s, that are used to store their [[corpse]]s, and other [[remains]]. Somewhat confusingly, they have different names depending on the materials used to craft them, but, thankfully, they all function identically, and all are placed with the Burial Receptacle ({{k|n}}) option via the [[building|build]] menu. This article uses the term "coffin" to describe any burial receptacle, for reasons of brevity.

{| border="1" cellpadding="2" class="wikitable"
|-
! Name
! Materials used
|-
| Coffin
| Stone, Glass
|-
| Casket
| Wood
|-
| Sarcophagus
| Metal
|}

==Usage==
After a coffin is created by the appropriate crafter, it must be built (as furniture) to be used. This is done with the {{k|b}}-{{k|f}}-{{k|x}} keys. In order for the coffin to be used for burials, it needs to be part of a [[tomb]] zone. The zone can then be used to configure if citizens (default) and/or pets are allowed to be buried there. It can also be designated for a specific citizen once they die. A coffin has been assigned when the message, ''"This is the resting place of __________"'', is displayed; viewing the contents of the coffin by clicking on it will show if the assignee has been successfully interred.

Enabling one of the burial options for citizens/pets will cause the coffin to be automatically assigned to the next creature/pet in the burial queue. Creatures are added to the burial queue when the game notifies you that the creature is dead. (An announcement that they are missing is not sufficient. If the body is in an out-of-the-way place, station a squad in your military next to the corpse and wait for the announcement that the body has been found before expecting the corpse to be buried.) The burial queue is the only way to bury pets, caravan guards, and other visitors.

To bury a specific citizen in a particular coffin, assign the coffin's [[tomb]] to the citizen in question. Tombs can be retroactively assigned to dead citizens and residents, allowing the assignee to skip the auto-burial queue. Unfortunately, non-residents cannot be assigned tombs. To get a non-resident into a particular coffin, make sure that no other coffins are available for burial and that the selected creature is next in line for burial. If said creature has already been buried, simply deconstruct the old coffin and that creature will be first in line for a new one. (Deconstructing a coffin will not destroy the remains inside.)

Coffins do not prevent [[reanimation]], though permanent burial may still be possible if the deceased was thoughtful enough to provide one or more non-reanimatable body parts (e.g. teeth).

[[File:rustic_coffin.jpg|thumb|290px|center|"Be sure to bury my favorite alcohol with me."]]

==Advantages==
It is not required to bury the dead; the player may instead engrave [[slab]]s and build [[memorial]]s. One can even simply haul dwarven remains to a corpse [[stockpile]], throw them into [[magma]], or leave them to rot where they fell, though these things have several serious consequences. A dwarf viewing the unburied body of any sentient species will receive a horrified thought. [[Friend]]s and [[relationship|relatives]] of the deceased will receive [[thought|unhappy thoughts]] if their loved ones remain unburied, especially if they decay (or [[magma|burn]]) away, and [[miasma]] will be generated if corpses rot inside the fortress. Particularly troubled souls may decide to [[ghost|come back for revenge]].

==Bugs==
*Dwarves insist on assigning a coffin, even when there are no remains left to bury. This can prevent you from burying the recently deceased until all the long lost caravanners have empty coffins of their own.
*Dwarves fail to bury remains of werecreatures{{bug|5431}} and reanimated corpses.{{bug|10396}}

{{D for Dwarf}}
It is said among [[Dwarf|dwarves]] that the only two constants in life are [[death]] and [[Tax collector|taxes]]. However, taxes were removed, giving [[Necromancer|some dwarves]] hope for an [[Intelligent undead|escape]] from the other.
{{buildings}}

File:Coffin Premium.png

2023-01-23T17:03:57Z

Tlupes: Premium graphics of coffin, both empty and occupied

== Summary ==
Premium graphics of coffin, both empty and occupied
== Licensing ==
{{Non-free Dwarf Fortress Screenshot}}

File:Cage Premium.png

2023-01-23T17:03:10Z

Tlupes: Tlupes reverted File:Cage Premium.png to an old version

== Summary ==
Premium graphics of a cage. Wood, metal, and glass
== Licensing ==
{{Non-free Dwarf Fortress Screenshot}}

File:Cage Premium.png

2023-01-23T17:00:08Z

Tlupes: Tlupes uploaded a new version of File:Cage Premium.png

== Summary ==
Premium graphics of a cage. Wood, metal, and glass
== Licensing ==
{{Non-free Dwarf Fortress Screenshot}}

Cage

2023-01-23T16:54:11Z

Tlupes: Add premium graphics image

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

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

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

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

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

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

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

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

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

===Creature containment===

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

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

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

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

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

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

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

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

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

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

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

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

==== Trading contained creatures ====

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

===Prisons===

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

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

===Remotely opening cages===

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

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

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

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

===Cages and fluids===

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

{{buildings}}

==Bugs==

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

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

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

File:Cage Premium.png

2023-01-23T16:53:41Z

Tlupes: Tlupes uploaded a new version of File:Cage Premium.png

== Summary ==
Premium graphics of a cage. Wood, metal, and glass
== Licensing ==
{{Non-free Dwarf Fortress Screenshot}}

File:Cage Premium.png

2023-01-23T16:52:19Z

Tlupes: Premium graphics of a cage. Wood, metal, and glass

== Summary ==
Premium graphics of a cage. Wood, metal, and glass
== Licensing ==
{{Non-free Dwarf Fortress Screenshot}}

Cabinet

2023-01-23T16:50:24Z

Tlupes: Add premium graphics image

{{migrated article}}
{{Quality|Unrated}}
{{av}}
{{V50_furniture|name=Cabinet
|graphic=[[File:Cabinet_Premium.png]]
|tile=π
|wood=y
|stonecarve=y
|metal=y
|glass=y
|rooms=
* [[Barracks]]
}}
'''Cabinets''' are a type of [[furniture]] used for storing [[clothes]]. They are a common requirement for [[noble]]s and they are also good for increasing the [[Room#Increasing_room_value|value]] of a [[room]]. A cabinet can hold close to 20 pieces of clothing. Cabinets do not block movement; dwarves and other creatures are able to walk through tiles with cabinets.

If a dwarf does not own a cabinet in their bedroom, they will leave their clothing on the floor.

Cabinets can be made from [[wood]], [[stone]], [[glass]], and all ordinary types of [[metal]] except [[pig iron]] and [[bismuth]].
[[File:Barberini Cabinet MET DP106703.jpg|thumb|280px|center|Barberini Cabinet. Probably [[human]] made. Definitely not [[elf]] made.]]
==See also==
* [[Container]]

{{buildings}}

File:Cabinet Premium.png

2023-01-23T16:50:04Z

Tlupes: Premium graphics of a cabinet, rock and metal

== Summary ==
Premium graphics of a cabinet, rock and metal
== Licensing ==
{{Non-free Dwarf Fortress Screenshot}}

File:Bucket Premium.png

2023-01-23T16:45:42Z

Tlupes: Premium graphics image of a bucket

== Summary ==
Premium graphics image of a bucket
== Licensing ==
{{Non-free Dwarf Fortress Screenshot}}

Container

2023-01-23T16:44:40Z

Tlupes: Add premium graphics image

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

{{V50_furniture|name=Container
|graphic=[[File:Chest_Premium.png]]
|tile=Æ
|wood=y
|stonecarve=y
|metal=y
|glass=y
|cloth=n
|leather=n
|rooms=
* [[Barracks]]
* [[Hospital]]
* [[Library]]
* [[Tavern]]
* [[Temple]]
}}
{{Translation| dwarven = etost | elvish = thale | goblin = ustêx | human = puti}}
:''This article is about buildable containers, for all types of containers see: [[storage]]''.

'''Containers''' is a general term used for various types of similar [[item]]s which are used for [[storage]]. Containers are named differently depending on what they are made of (see table, below), but they all fill the same function. They are a common requirement for [[noble]]s, and they are also good for increasing the [[room value|value]] of a [[room]]. Each different type of container holds a varying number of items. Dwarves may walk through tiles with containers.

If a dwarf does not own a container in their bedroom, they will leave any possessions on the floor. Containers are also used in [[barracks]] to store [[squad]] equipment, [[tavern|taverns]] and [[temple|temples]] to store musical instruments (and mugs for [[tavern keeper]]s), and [[library|libraries]] to store blank writing materials such as [[quire]]s. Note that a [[bookcase]] is needed for ''written'' [[book|materials]].

Containers are listed under "tools" in some menus.

;Container names by material type:
{| class = "wikitable unsortable"
! Name !! Material !! Required materials
|-
|'''Box'''
|[[Glass]]
| 1 bag of sand (+ pearlash if crafting clear glass), or 1 uncut rock crystal gem
|-
|'''Coffer'''
|[[Stone]]
| 1 rock
|-
|'''Chest'''
|[[Wood]], [[Metal]]
| 1 log or 3 bars of metal
|}

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

{{buildings}}

File:Chest Premium.png

2023-01-23T16:44:10Z

Tlupes: Premium graphics chest

== Summary ==
Premium graphics chest
== Licensing ==
{{Non-free Dwarf Fortress Screenshot}}

Animal trap

2023-01-23T16:41:55Z

Tlupes: Add premium graphics image

{{Quality|Unrated}}
{{av}}
{{V50_furniture
|graphic=[[File:Animal_Trap_Premium.png]]
|name = Animal trap
|tile = ⌂
|col = 6:0:0
|wood = yes
|metal = yes
|labors=
* [[Trapping]] 
* [[Trapping]]
}}

[[File:TrappedRat 4448.jpg|thumb|220px|Trapped like a r- Well... Yeah...]]An '''animal trap''' is [[furniture]] used to catch live [[vermin]]. They are created at a [[carpenter's workshop]] with 1 log, or a [[metalsmith's forge]] (in the Furniture menu) with 1 bar, by a dwarf with the [[trapping]] labor enabled. An animal trap can be made from [[wood]] or [[metal]]. Animal traps are unrelated to other [[trap]]s. To capture [[creature]]-sized animals, a [[cage]] is required.

Like cages, animal traps are stored in an animal [[stockpile]]. To set the pile to accept only empty traps, go to its '''Custom''' settings and click '''None''' in the top left to block all items, then click "'''Empty animal traps'''" in the animals tab.

==Use==
To catch vermin on land, order the task "'''Capture a Live Land Animal'''" from a [[kennel]] or [[butcher's shop]]. A trapper will grab an available animal trap and begin to pursue and capture wild vermin from there. This can cause the dwarves to only pursue certain vermin i.e. [[cave spider]]s if those are the only vermin near the stockpile. Or, to [[captured live fish|catch vermin in water]], order the task "Capture a Live Fish" from a [[fishery]]. A [[fisherdwarf]] will then take a trap and capture an aquatic vermin from a [[activity zone#Fishing zone|fishing zone]] (that has available fish to catch). You may want to put the task on high priority. so that fisherdwarves will prioritize the task over regular fishing.

Animal traps can also be built adjacent to any walkable tile using {{Menu icon|b|r|t|sep=-}} or '''[[building|build]]'''-"'''Cages/Restraints'''"-"'''Animal trap'''". After the trap is placed, it must be baited with [[fish]] or [[meat]] (the "large gem" option is useless at the moment). Click on a placed trap to select its bait type, or set it to not be baited. When a bait is selected, trapper will automatically go and bait the trap (you cannot remove the bait afterwards). In Classic graphics, a baited animal trap flashes between the trap and bait symbols, while Premium requires you to click on the trap to view its contents. When it successfully captures (or fails to capture) a vermin, the game will make an [[announcement]] showing a cage trap icon in Premium and {{DFtext|cd}} in Classic. A trap with caught vermin will automatically be slated for removal, and subsequently be hauled back to a stockpile.

Make sure to build the trap in an area with available vermin, otherwise the trap will be unable to capture anything. If the bait is left for too long, it will begin to [[rot]], and the building must be removed to prevent [[miasma]].

The main advantage of building an animal trap over using a kennel or butcher's shop is the ability to specify the location or [[biome]]. It also allows trappers to perform other tasks while the trap is set up. The disadvantage is that built traps require bait to function, and you cannot set baited traps underwater to capture aquatic vermin (although it is possible to place the animal traps on the surface of the water as long as it is adjacent to an walkable tile).

When a vermin is caught, the trap containing the vermin will be brought to an animal stockpile which accepts vermin of that type by a dwarf with the animal [[hauling]] labor enabled. A caught vermin is treated as if it were an item. Marking it for dumping will send it to a nearby [[garbage dump]], and once dumped, it will disappear back to the wild. Caught vermin are viewable in the animal '''Citizens''' {{Menu icon|u}}-'''Pets/Livestock''' tab. To tame one, go to a kennel and select '''Tame a small animal'''. A dwarf with [[animal training]] enabled will take a trap containing an untamed vermin to the kennel and train it with raw meat or fish (although none is actually consumed). After taming it, a dwarf will haul the animal trap containing the now-tamed vermin back to an animal stockpile. unless assigned to a constructed [[cage|cage or aquarium]].

Any captured vermin will remain in the animal trap permanently unless it is assigned to an installed [[cage|cage or aquarium]] (thus freeing the trap for reuse). Unfortunately, vermin cannot be assigned to a [[pasture]], so a mechanized cage is required to release them into the game world (e.g. for a [[Silk_farming#Cave_spider_silk_farm|cave spider silk farm]]). For [[hateable]] vermin, it is recommended to have any installed cages in a faraway place, to reduce the chance of passing dwarves getting unhappy [[thought]]s.

Vermin with {{token|GNAWER|c}} can break free from wooden animal traps. This does not destroy the trap. The game makes an announcement whenever this happens; if it occurs too often, you are better off getting rid of wooden traps and replacing them with metal ones.

==Success chance==
There is a chance that a baited animal trap may be robbed, and the trap will need to be rebaited by a trapper. The [[item quality]] affects the success chance of catching a vermin. To compare, a normal trap has a 50% chance of failing, while masterwork traps will never fail.

{| class="wikitable"
! Quality !! Success chance
|-
| (none) || 50%
|-
| -Well-crafted- || 60%
|-
| +Finely-crafted+ || 75%
|-
| *Superior quality* || 85%
|-
| ≡Exceptional≡ || 95%
|-
| ☼Masterful☼ || 100%
|}

==See also==
* [[Terrarium]] and aquarium – used to put vermin on display. Aquariums are required in order to store aquatic vermin, otherwise they will die.

{{Translation
| dwarven = emär ïggal
| elvish = fela abola
| goblin = slulasp stoslo
| human = dik losric
}}

{{buildings}}

File:Animal Trap Premium.png

2023-01-23T16:41:32Z

Tlupes: Premium graphics animal trap, empty and occupied.

== Summary ==
Premium graphics animal trap, empty and occupied.
== Licensing ==
{{Non-free Dwarf Fortress Screenshot}}

Weapon rack

2023-01-23T16:36:49Z

Tlupes: Remove migrated article warning

{{Quality|Unrated}}
{{V50_furniture|name=Weapon Rack
|graphic=[[File:Weapon_Rack_Premium.png]]
|tile=√
|wood=y
|stonecarve=y
|metal=y
|glass=y
|rooms=
* [[Barracks]]
}}
{{av}}

'''Weapon racks''' ({{k|b}}-{{k|y}}-{{k|r}}) are a type of [[furniture]] which can be used to create a [[barracks]] or to appease a [[noble]]'s demand or raise the [[value]] of a [[room]]

When used in a barracks designed for Individual Equipment storage, dwarves will prefer to store their weapons on the racks instead of stockpiles. Doing so in concert with [[armor stand]]s allows you to create centralized armories for your military.
[[File:Daisho-p1000661.jpg|thumb|300px|center|A samurai-related weapon rack.]]

{{buildings}}

Weapon rack

2023-01-23T16:36:32Z

Tlupes: Fix hotkey

{{migrated article}}
{{Quality|Unrated}}
{{V50_furniture|name=Weapon Rack
|graphic=[[File:Weapon_Rack_Premium.png]]
|tile=√
|wood=y
|stonecarve=y
|metal=y
|glass=y
|rooms=
* [[Barracks]]
}}
{{av}}

'''Weapon racks''' ({{k|b}}-{{k|y}}-{{k|r}}) are a type of [[furniture]] which can be used to create a [[barracks]] or to appease a [[noble]]'s demand or raise the [[value]] of a [[room]]

When used in a barracks designed for Individual Equipment storage, dwarves will prefer to store their weapons on the racks instead of stockpiles. Doing so in concert with [[armor stand]]s allows you to create centralized armories for your military.
[[File:Daisho-p1000661.jpg|thumb|300px|center|A samurai-related weapon rack.]]

{{buildings}}

Weapon rack

2023-01-23T16:35:13Z

Tlupes:

{{migrated article}}
{{Quality|Unrated}}
{{V50_furniture|name=Weapon Rack
|graphic=[[File:Weapon_Rack_Premium.png]]
|tile=√
|wood=y
|stonecarve=y
|metal=y
|glass=y
|rooms=
* [[Barracks]]
}}
{{av}}

'''Weapon racks''' ({{k|b}}-{{k|r}}) are a type of [[furniture]] which can be used to create a [[barracks]] or to appease a [[noble]]'s demand or raise the [[value]] of a [[room]]

When used in a barracks designed for Individual Equipment storage, dwarves will prefer to store their weapons on the racks instead of stockpiles. Doing so in concert with [[armor stand]]s allows you to create centralized armories for your military.
[[File:Daisho-p1000661.jpg|thumb|300px|center|A samurai-related weapon rack.]]

{{buildings}}

File:Weapon Rack Premium.png

2023-01-23T16:34:17Z

Tlupes: premium version sprite of a weapon rack both empty and full

== Summary ==
premium version sprite of a weapon rack both empty and full
== Licensing ==
{{Non-free Dwarf Fortress Screenshot}}

Weapon rack

2023-01-23T16:28:13Z

Tlupes: Removing bug, as the issue appears to be resolved in the most recent version of Dwarf Fortress

{{migrated article}}
{{Quality|Unrated}}
{{furniture|name=Weapon Rack
|tile=√
|wood=y
|stonecarve=y
|metal=y
|glass=y
|rooms=
* [[Barracks]]
}}
{{av}}

'''Weapon racks''' ({{k|b}}-{{k|r}}) are a type of [[furniture]] which can be used to create a [[barracks]] or to appease a [[noble]]'s demand or raise the [[value]] of a [[room]]

When used in a barracks designed for Individual Equipment storage, dwarves will prefer to store their weapons on the racks instead of stockpiles. Doing so in concert with [[armor stand]]s allows you to create centralized armories for your military.
[[File:Daisho-p1000661.jpg|thumb|300px|center|A samurai-related weapon rack.]]

{{buildings}}

Minecart

2023-01-01T19:53:56Z

Tlupes: /* Step-by-step tutorial */

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

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

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

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

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

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

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

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

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

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

'''Weights of different carts'''

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

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

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

{{anchor|Tracks}}

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

====Simple tracks====

'''Carved'''

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

'''Constructed'''

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

====Ramps====

'''Carved'''

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

'''Constructed'''

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

'''Examples of ramps'''

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Next, carve the track:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

=== Troubleshooting ===

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Example of straight impulse acceleration:

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

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

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

Examples of impulse elevators:

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

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

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

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

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

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

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

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

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

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

=== Controlling traffic ===

==== Switching ====

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

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

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

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

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

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

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

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

==== Controlling Speed ====


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

Will derail at > 0.5 t/st:

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

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

O : wall/column.
}}

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

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

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

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

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

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

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

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

== Physics ==


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

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

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

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

=== Numbers behind the scenes ===

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

=== Corner Ramp Derail ===

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

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

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

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

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

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

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

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

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

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

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

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

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

Three successive ramps results in the highest attainable speeds.

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

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

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

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

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

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

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

== Simple Example Layouts ==

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

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

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

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

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

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

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

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

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

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

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

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

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

[[ru:Minecart]]

File:Minecart-example-13-v50.03.png

2023-01-01T19:52:49Z

Tlupes:

== Licensing ==
{{Non-free Dwarf Fortress Screenshot}}

File:Minecart-example-12-v50.03.png

2023-01-01T19:51:13Z

Tlupes:

== Licensing ==
{{Non-free Dwarf Fortress Screenshot}}

Minecart

2023-01-01T19:43:57Z

Tlupes: /* Step-by-step tutorial */

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

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

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

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

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

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

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

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

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

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

'''Weights of different carts'''

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

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

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

{{anchor|Tracks}}

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

====Simple tracks====

'''Carved'''

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

'''Constructed'''

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

====Ramps====

'''Carved'''

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

'''Constructed'''

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

'''Examples of ramps'''

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Next, carve the track:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

=== Troubleshooting ===

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Example of straight impulse acceleration:

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

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

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

Examples of impulse elevators:

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

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

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

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

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

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

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

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

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

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

=== Controlling traffic ===

==== Switching ====

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

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

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

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

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

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

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

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

==== Controlling Speed ====


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

Will derail at > 0.5 t/st:

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

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

O : wall/column.
}}

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

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

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

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

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

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

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

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

== Physics ==


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

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

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

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

=== Numbers behind the scenes ===

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

=== Corner Ramp Derail ===

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

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

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

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

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

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

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

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

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

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

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

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

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

Three successive ramps results in the highest attainable speeds.

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

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

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

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

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

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

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

== Simple Example Layouts ==

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

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

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

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

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

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

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

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

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

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

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

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

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

[[ru:Minecart]]

File:Minecart-example-11.2-v50.03.png

2023-01-01T19:41:58Z

Tlupes:

== Licensing ==
{{Non-free Dwarf Fortress Screenshot}}

File:Minecart-example-11.1-v50.03.png

2023-01-01T19:37:08Z

Tlupes:

== Licensing ==
{{Non-free Dwarf Fortress Screenshot}}

File:Minecart-example-11-v50.03.png

2023-01-01T19:32:28Z

Tlupes:

== Licensing ==
{{Non-free Dwarf Fortress Screenshot}}

File:Minecart-example-10-v50.03.png

2023-01-01T19:22:49Z

Tlupes:

== Licensing ==
{{Non-free Dwarf Fortress Screenshot}}

File:Minecart-example-9-v50.03.png

2023-01-01T19:20:57Z

Tlupes:

== Licensing ==
{{Non-free Dwarf Fortress Screenshot}}

File:Minecart-example-7-v50.03.png

2023-01-01T19:20:42Z

Tlupes:

== Licensing ==
{{Non-free Dwarf Fortress Screenshot}}

File:Minecart-example-8-v50.03.png

2023-01-01T19:17:12Z

Tlupes:

== Licensing ==
{{Non-free Dwarf Fortress Screenshot}}

File:Minecart-example-6-v50.03.png

2023-01-01T19:13:06Z

Tlupes:

== Licensing ==
{{Non-free Dwarf Fortress Screenshot}}

File:Minecart-example-5-v50.03.png

2023-01-01T19:10:48Z

Tlupes:

== Licensing ==
{{Non-free Dwarf Fortress Screenshot}}