Dwarf Fortress Wiki - User contributions [en]

Minecart

2015-09-01T21:15:35Z

Kirig Stonebeard: Reordered "best materials for switching" (by best vs. alphabetical)

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

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

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

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

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

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

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

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

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

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

'''Weights of different carts'''

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

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

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

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

====Simple tracks====

'''Carved'''

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

'''Constructed'''

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

====Ramps====

'''Carved'''

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

'''Constructed'''

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

'''Examples of ramps'''

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

Carving track corners into ramps is rather unintuitive and complicated. Since engraving tracks always requires two tiles to connect in a straight line as input, you have to give two separate designations for a single job: a track bit from the ramp tile to the "below" direction and another one to the wall of the "upward" direction. If you wanted to change direction on a ramp from east to north:
{{diagram|spaces=yes|\
z +0 z +1
░░░░░ ░░░░░
░░░░░ ══╗░░
=▲░░ ░░▼░░
░░░░░ ░░░░░
}}
you would need to connect the ramp on z +0 both to the west and to the north by issuing two "carve track" commands, one selecting the ramp and the track tile to the west, and another connecting the ramp tile with the wall to the north. An engraver would then carve a NW track corner into the ramp, allowing carts to pass the corner correctly both going up and down. Such track corners are perfectly serviceable for guided carts, but moving down a route of several of them by pushed or ridden cart is problematic - ramps on corners behave very counter-intuitively, resulting in loss of speed when going down and diagonal movement when going up.

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

{{anchor|Tracks}}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Next, carve the track:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Now we've got everything set up:

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

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

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

=== Troubleshooting ===

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

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

'''Possible Causes:'''
* In basic terms, the game checks if there is a valid path for a cart along the rails to reach the next stop in the route, and whether a dwarf ''guiding'' a cart would be able to find a path to the destination without carrying the cart. This warning pops up if the cart can't find a valid path based upon guided carts.
** If your cart path relies upon advanced tricks like deliberate falling into pits or ignoring floor types, even a path designed entirely as you intended will still trigger the yellow warning. (But double-check to make sure it's fine...)
* The departure direction of the stop might be invalid. Edit the stop using {{k|Enter}} and press{{k|d}} until it is pointing in a valid direction.
* The track stop might not be built on top of a track. The track stop must be deconstructed to remedy this issue.
* Your track might not be built correctly. Make sure all connected tracks between destinations are not one-way tracks.
** This can be especially confusing with ramps. To carve a two-way track on a (natural) ramp, you must designate the ramp and one square beyond in the direction you want the track to go.
** Ramps '''must''' have a solid block on the side opposite to the track, or they will neither work nor be marked as "unusable". The solid block can be natural or constructed.
* The desired/kept items might not be configured correctly.

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

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

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

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

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

'''Possible Causes:'''
* This can be caused by using a Track Stop with autodumping enabled at a loading site. Every time a dwarf places an item into a cart resting on such a track stop, the item will be immediately dumped, causing unlimited, useless cart loading jobs. Autodumping Track Stops should never be used at a loading site.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

==== Impulse ramps ====
Carts can be given momentum without rollers or changing z-level through a phenomenon called "impulse ramps". A track ramp which is connected both to a wall and to a floor will ''always'' accelerate a cart towards the connected floor tile, no matter where the cart enters the tile from. This means carts can be accelerated as though dropping z-levels, even if the cart doesn't actually change z-level at all. If a track ramp faces three directions such as ╩, then two of those directions need to be facing walls for the cart to be accelerated towards the remaining direction.

Example of straight impulse acceleration:

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

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

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

Example of an impulse elevator:

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

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

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

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

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

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

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

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

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

=== Controlling traffic ===

==== Switching ====

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

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

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

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

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

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

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

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

==== Controlling Speed ====


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

Will derail at > 0.5 t/st:

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

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

O : wall/column.
}}

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

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

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

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

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

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

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

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

== Physics ==


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

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

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

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

=== Numbers behind the scene ===

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

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

Every tick the cart adjusts sub-tile position units by the amount of their velocity, as well as adjusts velocity depending on current tile (speed is reduced by the "friction" of the tile, or accelerated if going "down" a ramp). On flat (non-ramp) tiles, the cart will move to the next tile when the sub-tile position goes either above 100,000 or below 0, (or several tiles if velocity is over 100,000,) and 100,000 is either added or subtracted to sub-tile position to restart the count to the next tile change.

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

A push will teleport a cart to the beginning of the next tile (NOT the middle!) in one tick with 19990 speed (10 speed is lost due to track friction), while a roller will give a cart the roller's set speed, and it will start to accumulate regular track friction past the middle of the roller tile. Some track features will affect a minecart when it is past the middle of the previous tile: entering a ramp or a hole/drop will happen when the cart has left the middle of the previous tile, and the ramp will gain additional distance unit depending on the leftover units from the previous tile. When a cart leaves a ramp it will emerge after one tick in the middle of the next regular tile, so its entry coordinate is "50000-speed+friction". Rollers also affect the speed of minecart from the middle of the previous tile.

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

Water of depth 7/7 provides a friction of about 10000 per step, as does maximum-depth magma. This higher friction may not apply to very slow-moving carts.

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

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

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

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

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

Each non-ramp tile is functionally composed of a value between 0 and 100,000, with a "centered" cart sitting at the 50,000 point in all three directions. When a cart has velocity, it is added or subtracted from the current position every tick, and then a friction force is applied to the cart.

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

When carts move beyond the maximum or minimum value of a tile, they physically move a tile on the map, and start at the far end of the sub-tile position the next tile. (I.E., traveling West, a cart that starts a tick at 15,000 X sub-tile position and has an X velocity of -20,000 would move to -5000 X sub-tile position, which is out of bounds for that tile. As such, it will travel one tile West, and start the next tick at 95,000 X sub-tile position. It will also lose 10 velocity in that tick due to friction with the track if it is on a track, or 100 velocity if it is on regular ground, or no velocity if it is airborne.)

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

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

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

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

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

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

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

If the tile to the South is a wall at that point, it will be considered a collision with a wall that ''halts all motion''. If the tile is open, it will generate a diagonal track derailment that will send a cart flying until it strikes a wall, at which point it will not re-rail itself. In almost any circumstance, this is undesirable behavior.

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

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

Curves are applied "halfway through" a tile. If a cart is moving East, and approaches a North-East track at 20k velocity, and friction is eliminated for the purposes of a cleaner demonstration, then when it enters the tile at sub-tile point 0 X, and 50k Y at the start of a tick, it will then move 20k East (+X) the next tick, and be at 20k X sub-tile position, and 50k Y sub-tile position. Next tick, it is at 40k X sub-tile position, and 50k Y sub-tile position. The next tick would take it to 60k X, but that's past the halfway point, so it stops at 50k, turns (and thus loses 1k velocity, but translates the rest from X-velocity to Y-velocity) and travels another 10k. It is now at 50k X sub-tile position, and 60k Y sub-tile position. Next tick, it travels at 19k velocity North, and so moves to 50k X sub-tile position, and 79k Y sub-tile position. Then in two more turns, it leaves to the North.

In the case of diagonal motion due to having velocities in X and Y at the same time, it is critical that the direction the cart is heading in reaches that halfway point in a curve before the cart leaves the track off its sideways velocity direction. If it does so, all sideways velocity is lost, as forwards velocity ''overwrites'' sideways velocity in a curve. If, in that example in the paragraph above, the cart entered at 0 X sub-tile position with 20k X velocity, and 40k Y sub-tile position and -1k Y sub-tile position, it would take that "curve" (or rather, redirection of velocity) on the third turn, while it is at 38k Y sub-tile position to start with, and then move to 47k Y sub-tile position at the end of that tick. It would then move to 56k Y sub-tile position in the following turn, and take 3 turns, rather than just 2, to clear the tile.

But, most importantly, it would be centered in the X sub-tile position, and with the negligible difference of an extra tick, all sideways velocity could be safely ignored.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Falling carts accelerate similarly to the way that a ramp will accelerate a cart in a special z-only velocity that only applies to airborne carts. (Actually, acceleration due to gravity in freefall seems curiously slightly ''slower'' than ramp acceleration.) Ramp acceleration, while it logically should be partially z-directional, is only recorded as x- or y-directional, and there is no translation of z-directional velocity upon landing. Landing carts zero out their vertical velocity upon landing, even when landing on ramps, although carts that had horizontal momentum while falling preserve it.

This means a cart falling (from a hatch, thus with no horizontal speed) onto a track ramp is accelerated as if starting from the middle of the ramp - i.e. to the same speed, no matter how many Z-levels it was dropped, vertical velocity is negated. {{cite forum|144328/5701211}}

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

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

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

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

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

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

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

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

=== Corner Ramp Derail ===

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

This is caused by the fact that a cart, after turning the bend in the track halfway through the length of the tile, will still "accelerate down", which is now perpendicular to the movement of the cart, causing acceleration to occur in two directions. (Down corner ramps do not have this problem, as when they pass the halfway point, all perpendicular motion is added to forward motion, and after that curve, all downward acceleration is in the forward direction.)

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

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

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

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

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

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

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

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

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

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

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

Three successive ramps results in the highest attainable speeds.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[[ru:Minecart]]

v0.34:Minecart

2012-11-08T02:24:26Z

Kirig Stonebeard: returning deleted text to incomplete line

{{quality|Exceptional|21:37, 6 November 2012 (UTC)}}{{av}}{{Buggy}}
A '''minecart''' is a [[tool]] used mostly for [[hauling]]. It is made of [[wood]] at a [[carpenter's workshop]], or [[metal]] at a [[metalsmith's forge]]. Minecarts store up to five times as many items as [[wheelbarrow]]s and are quite a bit faster than hauling dwarves, but have the disadvantage of requiring a dedicated track network and a complex route setup. Minecart tracks also take up a lot of space, may be complicated to construct, and can be resource-intensive.

Just like wheelbarrows, minecarts are considered [[item]]s and are stored in a [[furniture]] [[stockpile]]. Despite their five times greater capacity, they are only one third larger than wheelbarrows and are identical in base [[item value|value]] when made from the same [[material]] (the value may differ due to the [[item quality]]). As items, [[thief|thieves]] or even mischievous animals can steal minecarts, even when moving on a track. If a minecart is moving fast enough, or if it has a rider, thieves will be unable to steal the minecarts.

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.

Since their introduction in version 0.34.08, a new [[hauling]] [[labor]] preference was added to all dwarves, called "Push/Haul Vehicles", turned on by default.

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

== Track ==
Tracks can be built in two ways:
*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 existant 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.
**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 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.)

*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 larger 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 (barring the [[Obsidian farming|creation of obsidian]]), and the only way to create one-way tracks. 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.

Every track, when complete, will designate the tile with a low-priority [[traffic|traffic order]]. This reduces the odds of dwarves walking into a high-speed minecart; however, it should be noted that pets and livestock ignore traffic orders. 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.

As constructions or tile features, [[door]]s and other furniture can be built on tracks. A [[door]] or [[floodgate]] can be turned on or off by a [[lever]], effectively controlling the flow of automated minecarts. This may be dangerous, however. 

[[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. It's also worth noting that bridges do not automatically have a low pathfinding traffic priority assigned to them, however.

== Hauling route ==
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 ===
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 at least one {{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.

=== Stop ===
Stops are designated by moving the cursor on top of the desired tile and pressing the {{k|s}} key afterwards. They can be removed with and nicknamed with the same hotkeys as routes. Stops can also be reordered with the {{k|p}}romote key. Without a definition, however, a stop is fairly useless: pressing the {{k|Enter}} key with a stop selected in the route menu opens its stop definition screen, from which departure conditions and stockpile links can be set up.

==== Stockpile links ====
By placing the cursor on top of a stockpile and using {{k|s}}, you can create stockpile links for a track stop. Links can also be redefined by selecting them, placing the cursor over a different stockpile, and pressing {{k|p}}.

==== 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).
# A departure direction (NSEW).
# 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 restricted stockpile and set to depart with any items.

== 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 along the track in a straight line until they either run off the tracks or encounter a turn. A minecart will continue straight at a T junction if possible but if it is not possible the track is treated as a dead end and may jump track. The cart's behavior also depends on the weight of its contents (including fluids and dwarves): heavily loaded carts are harder to accelerate and to stop, and gain more momentum when going downhill. 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.

When set to "Guide", minecarts seem to ignore all laws of physics. They:
*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:

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, if you attempt to "Push" from B to A or C, [[Fun|''the cart will go careening off of the tracks'']].

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

=== Track Jumping ===
If a minecart encounters the end of the track or a T junction where it can not continue straight it may jump off of the track if it is going fast enough. The minecart will now continue in a straight line until in encounters an obstacle, slows to a stop, or encounters another (properly aligned) Track. An escaped minecart will follow another track even if it is a corner.

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

=== Stacking ===
If a minecart lands on another minecart in exactly the perfect orientation and time, they may form a stack (effectively a pillar) of minecarts. This pillar, aside from the [[megaprojects]] uses possible, is also useful for [[trap design]] with minecarts as the weaponry.

The location of the upper minecarts, above what seems to be thin air, can be confusing. These minecarts generally need to be struck with another minecart to move out, or have their support removed. The latter option can be somewhat dangerous, however.

=== Danger ===
Minecarts are not without [[Fun|danger]]. 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, as dwarves guiding minecarts will ignore traffic restrictions, by [[pasture|pasturing]] domestic animals, and preventing the access of other creatures to the tracks.

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 used as weapons by imaginative players.

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

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

Track stops are not mandatory; in fact, their main use is in automated rail systems, to stop and hold extremely fast-moving minecarts or to dump contents mid-way without stopping. 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.

If a stockpile is built on the square that a track stop is set to dump to, it can act as a [[Exploit#Quantum_stockpiles|quantum stockpile]] and any items dumped from a minecart that match the storage settings of the stockpile will remain there and accumulate. Normally trackstops are built on top of existing track to operate on moving minecarts, but they can also be used without tracks to create [[Exploit#The_Minecart_Stop|automatic quantum stockpiles]] (see also [[#Example|route example]]).

Counter-intuitive to their construction method, track stops are considered [[building]]s and must be removed by {{k|q}} {{k|x}}.

=== Roller ===
A '''roller''' is a [[power]]ed [[machine component]] for the automated propulsion of minecarts. They are built with {{K|b}} {{K|M}} {{K|r}}, requiring a [[mechanic]], one or more [[mechanism]]s and a [[rope]]. 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, variable-direction, and variable-power, all traits that can be set at construction time; at the highest speed, a roller uses two units of power per tile it is long.

Rollers may be placed directly on ramps to help pull carts up Z levels. Currently rollers can only be placed on up or down ramps or open spaces if this results in being connected to existing powered components (gears, axles, or pumps). For that matter, rollers themselves transfer power along their sides but not from their front or back (the edges on the track) - the opposite of how horizontal [[axle]]s work. Care must be taken in [[glacier]]s and other extremely cold [[biome]]s, since rollers can be rendered inoperable when exposed to freezing [[temperature]]s.
The effects of floorless rollers on carts are not yet documented.

Because of their one-way nature, rollers are unsuitable for most two-way minecart tracks. However, a minecart set to be ''guided'' is not affected by rollers at all — this allows a one-way track to be used in both directions. In addition, rollers do not affect minecarts when disengaged: switching mechanisms (such as a [[pressure plate]] attached to powering [[gear assembly]]) can be used to create complex paths.

Rollers cannot be powered from above.

=== Switching ===


A rudimentary track switch can be constructed by building a T-junction as illustrated below.

B╥ B╥
║ ║
║ -> ║
║ ║
A╞════╚════╡C A╞════R════╡C

The 'R' is roller pushing from East 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'.

This switch has a disadvantage - it requires power. An alternative non-powered solution uses controlled derailment, or a connecting bridge.

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

If carts are moving too slowly to reliably derail at the corner, a retractable bridge may be used as a connector between A and C.
B╥
║
║
A╞════bbb════╡C
The bridge must overlap the corner so that it acts as if a T junction track when extended. When retracted, the corner reappears, so the slower carts will continue to B.

=== Controlling Speed ===


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

Will derail at > 0.5 m/s:

in ═╗->
out

Will not derail at > 0.5 m/s:

in ═╗O
|
v
out

O is wall.

This behavior can be used to build a "speed limiter", that will ensure that when a minecart exits it is traveling below derail speed:

OOOO
in ═╔═╗O
out ═╬═╝O
O╚S╝O
OOOOO

O is wall, S is a Track Stop set to High Friction or lower. If the minecart is traveling below derailment speed it will not be effected.

== Example ==

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

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

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

Next, carve the track:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Now we've got everything set up:

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

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

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

== Troubleshooting ==

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

'''Symptom:''' {{DFtext|! Set dir/connect track|6:1}} message appears to the right of one or more stops
 '''Possible Causes:'''
* The departure direction of the stop might be invalid. Edit the stop using {{k|Enter}} and press{{k|d}} until it is pointing in a valid direction.
* The track stop might not be built on top of a track. The track stop must be deconstructed to remedy this issue.
* Your track might not be built correctly. Make sure all connected tracks between destinations are not one-way tracks.
** This can be especially confusing with ramps. To carve a two-way track on a (natural) ramp, you must designate the ramp and one square beyond in the direction you want the track to go.
** Ramps '''must''' have a solid block on the side opposite to the track, or they will neither work nor be marked as "unusable". The solid block can be natural or constructed.
* The desired/kept items might not be configured correctly.

'''Symptom:''' The status '''0% V''' always appears to the right of one stop.
 '''Possible Causes:'''
* The stop may not be set to take from a stockpile. Edit the Stop using {{k|Enter}} and make sure you see a message like "Take from Stockpile #1".
* The take conditions must correspond with the contents of the stockpile.
* The track stop may be set to dump. A track stop set to dump cannot be filled. You must either set the stop to a time-based departure or deconstruct the track stop and rebuild it without dumping.
* Make sure the minecart itself has not been designated to be dumped (such as when using mass-dump).

== Capacity ==
Minecarts have five times the [[Weight|capacity]] of wheelbarrows, which is an enormous amount. A single minecart can carry 5 [[stone|boulder]]s, or 10 [[wood|log]]s, or 83 [[block]]s or [[bar]]s, 500 [[Kitchen|prepared meals]] or 2500 rolls of [[cloth]]. Calculating by the [[weight|item size]], one cart also should be able of carry 500 [[Trap_component#Spiked_ball|spiked balls]], 625 maces or 1250 [[Weapon#Native_weapons|spears]].{{verify}}

A glumprong minecart full with 5 pitchblende boulders weighs 3848Γ (the cart alone is 48Γ). 
A gold minecart is 772Γ, full of gold bars is 10398Γ. 
An platinum minecart weighs 856Γ. 
If slade minecarts were possible, they would weigh 8000Γ empty. 

[[Water]] and [[magma]] can also be loaded into minecarts by submerging them to a depth of at least 6/7, and dumped by a constructed track stop. Loading fluids onto minecarts can be difficult because their weight can slow the minecart down greatly. Curiously, filling a minecart with magma does not injure a dwarf ''riding'' it. A minecart will hold enough magma to increase the depth of a single tile by 2. This amount is listed as 833 units, which weigh 999Γ. An iron or steel cart filled with magma weighs 1313Γ. An adamantine one weighs 1007Γ.

The capacity in a minecart affects whether a [[pressure plate]] triggers or not, based on the pressure plate's setting.

== Bugs ==

*If you set up lots of routes and stops and then resize your screen, the list will scroll off-screen in the hauling menu. You can still navigate the list with keyboard commands, but cannot see the stop/route name. This will be fixed in the next release.
*A dwarf will drop its [[child|baby]], if it has one, when boarding a minecart set to be ridden.
*Tracks block wagon access to trade depots.{{bug|6040}}
** How to circumvent: bridges double as tracks.
*Dwarves cannot guide a minecart through an unlocked door unless another dwarf opens the door{{bug|6056}}

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

[[ru:Minecart]]

40d Talk:Weapon

2009-03-22T05:06:34Z

Kirig Stonebeard: /* Unusual materials */

Are the bows and blowguns melee or ranged? -- [[User:Bovinepro|Bovinepro]]

:Both. When they run out of ammo the dwarves will beat their enemies to death with their bows. The listed damage is for when that happens. --[[User:Ikkonoishi|Ikkonoishi]] 17:15, 4 November 2007 (EST)

----

What about damage done by artifact weapons? Is it x2 like masterwork items?

:The exact damage bonus granted by artifact weapons is unknown, though it's quite likely much higher than a masterwork, if the value is any indicator. It's difficult to determine the exact bonus, as it's not in the raws, Toady hasn't told us, and it's very difficult to gauge exactly how much damage a weapon is dealing due to how little is known about the combat calculations in general. --[[User:Hesitris|Hesitris]] 07:31, 18 November 2007 (EST)

== Conflicting Info? ==

Earlier on, we say that dwarves can't wield bows because they are too big. Down in the tables, the bow is listed as two handed and not unwieldable. Need to correct one or the other (I'm too lazy to verify that in the current version bows are still unwieldable.) --[[User:TheUbie|TheUbie]] 06:20, 28 November 2007 (EST)

:Well, a bow is two handed and unwieldable to dwarves, do you mean in adventure mode with humans/elves? I think most of this data is fortress mode specific. --Gotthard 18:15, 28 November 2007 (EST)

::I didn't write the article, so I don't know it's original intention, however there are other weapons that can be wielded 2 handed by humans and others in adventure mode, but are listed as unweildable by dwarves. Need to choose to make the table fortress specific, adventure mode specific, or add another col and make it specific to both. As it stands now, it doesn't make sense. --[[User:TheUbie|TheUbie]] 18:54, 29 November 2007 (EST)

:::I'm almost certain this is dwarf specific, because I had some goblin axemen siege my base, and one of them was wielding a great axe in one hand, and a shield (not even a *buckler*) in the other hand. I think I saw the same thing with a halberd, but a pike was multigrasped. Looks like goblins have a lot more options than our poor dwarves. --Gotthard 12:16, 30 November 2007 (EST)

== Pike ==

I been able to wield a bronze pike with an adventurer in 23a and it was quite deadly. This need to be verified. Maybe there is a strength requirement? --[[User:Eagle of Fire|Eagle of Fire]] 14:43, 28 November 2007 (EST)

== Whips and scourges ==

So, I'm guessing that you can't assign dwarves to use whips and scourges unless you've traded for one, right? And on the article for [[Scourge]] it says it's deadlier than a whip (which currently has no page)... Does that mean scourges are better in every way? What's worse? --[[User:Penguinofhonor|Penguinofhonor]] 21:03, 1 December 2007 (EST)

:Did you actually read the tables? It does 10 more damage, and is the same in everything else. Dwarves can't become lashers. There are no lasher option in the military settings... --[[User:Nitem4re|Nitem4re]] 14:13, 4 December 2007 (EST)

I have a complaint... Reading this wiki gave me the impression that whips and scourges were weak weapons and that it would require several for them to be noticeable. So it was that I came upon the idea of using a small number of scavenged and traded whips and scourges in weapon traps at the extremity of my fortress to weaken incoming attackers and to slow retreaters, hoping that if they got lucky and killed one it would probably bleed to death after safely leaving the trap. What I did not expect was rivers of blood, corpses piled 4 deep and exploding goblins. While I missed the event it would appear that a head travelled up one Z-level, west 8 X-levels and north 10 Y-levels, whilst a lower body travelled up 2 Z-levels, west 6 X-levels and south 2 Y-levels. I can only assume that they collapsed from the pain and were pulled into the mechanism...

My haulers are demanding an apology for the mess they need to clean up, perhaps a note could be made indicating that whips can be effective(and messy) despite their low damage values...

It is this sort of thing that makes me glad that the thoughts "horrified by an unfathomable scene of carnage" and "Saw something unnatural happen to a fellow living creature" have not yet been implemented...
[[User:RAM|RAM]] 04:56, 13 March 2009 (UTC)

:How many did you put in the traps? Even crappy weapons like whips will obliterate an enemy when you have a bunch of them all hitting simultaneously. --[[User:LegacyCWAL|LegacyCWAL]] 16:17, 13 March 2009 (UTC)

::Odd, I could have sworn that I liked to a movie of me examining the area, it is 3 1-deep rows of traps in a 3-wide corridor, the first row each have 1 low-quality bronze whip, second row each have 1 no-quality iron scourge and the third row each have 1 iron and 1 bismuth bronze whip, with one trap having an additional bronze whip. The mechanisms are good quality but it doesn't really seem to be alot to me, but I am new to DF...

::Here [http://www.mkv25.net/dfma/movie-1170-scarywhips] is the movie, I must say that this is very effective for stopping sieges, my goblins are unmodified, and they don't seem to have any trolls or beak dogs, but(if I recall correctly) in a recent siege this setup left me with 23 goblin corpses(and about 25 body parts) and only 3 traps clogged, with no goblins reaching any other defences(I think some made it through but ran back because of injuries and goblins dying behind them), funnily enough it was the single weapon traps that did most of the clogging...[[User:RAM|RAM]] 14:38, 16 March 2009 (UTC)

:::Hrm. Most of the goblins are unarmored wrestlers, and most of the rest are poorly-armored archers. By the time they got to the third row, they had taken multiple hits from gore-damage weapons (and one of the third row of traps had some really nasty ones in it). Whips and scourges don't do a lot of damage, but they do cause pain and bleeding. That doesn't matter too terribly much against heavily-armored soldiers who can shrug off a couple blows, but it doesn't take many hits like that to make a werestler bleed to death. And if the traps weren't clogging up much, most of the goblins would've taken a lot of hits, which with gore damage would really add up. I also see that several goblins made it to the stonefall traps. If it took that long to break them, then the odds are good that many made it past the traps, broke, and ran back across the traps for another go. With that many hits, even whips and scourges can overwhelm a metal-armored soldier. Long story short, it was pretty much an absolute best-case scenario for whips and scourges, making lots of attacks against poorly-armored targets ;) --[[User:LegacyCWAL|LegacyCWAL]] 16:14, 16 March 2009 (UTC)

== Unorthodox weapons ==

Is there any information on unorthodox weapons such as coins and loincloths? For instance, are the material and crafting value taken into account, and what is the base damage of the item? [[User:Patarak|Patarak]] 04:13, 13 February 2008 (EST)

:"Unortodox" weapons are not really weapons. However, since ''absolutly anything thrown is deadly in the curren fight code'', a lot of people use about anything in adventure mode. This is how coins became popular as a throwing weapon. Part because it's as deadly as anything else and very light which mean you can carry a lot around, part because it is a weapon used in other ascii or rogue like games. You could throw butterfly corpses and mud around and it would be just as deadly as coins. --[[User:Eagle of Fire|Eagle of Fire]] 17:52, 13 February 2008 (EST)

== Great axe ==

I'm not saying dwarves can wear it, but the dead goblin over there wore one, and even a shield too..if I can get 5 minutes of peace from this annoying little buggers i will try to let one of my dwarves wear it..--[[User:Koltom|Koltom]] 21:40, 3 March 2008 (EST)

:You're lucky. You get alot of goblins! I want some! Can you send some over?--[[User:CrazyMcfobo|CrazyMcfobo]] 18:16, 10 April 2008 (EDT

== Weapons ==

Clicking the links of some of the types of weapons redirects back to weapons. --[[User:Chrispy|Chrispy]] 21:07, 10 April 2008 (EDT)
:This is a feature called a redirect. If you want to then go ahead and create enough of an article that nobody reverts it back to a redirect. For a lot of weapons there isn't that much of a need for a seperate article, but the redirect will point someone back to a place they can find out what they need to know.[[User:GarrieIrons|GarrieIrons]] 00:21, 10 June 2008 (EDT)

== Trap components as weapons ==

"There are a few enormous weapons that no race can wield..." 
I beg to differ. In Adventure mode, at least in "Play Now", you can in fact pick these things up and hit people with them. I dunno if they come with lots of negatives for being a stupid weapon, but I know I've used an enormous wooden corkscrew to fight troglydites before. That, and a barrel of dwarven wine.
--[[User:Dadamh|Dadamh]] 11:19, 2 June 2008 (EDT)

:I know that adventurers can do things that shouldn't be possible. Other creatures are technically capable of doing those things, but their code won't ask them to do them. --[[User:Savok|Savok]] 12:51, 2 June 2008 (EDT)

::I'll say. In adventure mode, you can carry around and throw anvils at enemies. It does no more damage than sand and you'll have the speed of a glacier, but it's hilarious. I suspect, though, that improvised weapons are as effective as unarmed attacks. I'll have to check on that though. --[[User:Smartmo|Smartmo]] 15:45, 13 January 2009 (EST)

== Possible bug with long swords in 40d (not wieldable in two hands) ==

Today I traded for two wooden longswords and set two new recruits to use them for sparring.
The recruits continually go pick up the swords ("Pickup Equipment") and then instantly drop the weapon on the ground. It doesn't matter whether they are on duty or not, actually.

Is it possible this is a bug in 40d? Is it possible that oversized weapons that the article lists as being wieldable in two hands actually require a certain amount of strength attribute? Or is it that the article is just completely mistaken on long swords as being wieldable by dwarves using both hands? Any thoughts or input would be nice.
--[[User:Jpwrunyan|Jpwrunyan]] 01:02, 11 February 2009 (EST)

:If I recall, someone somewhere mentioned that setting a dwarf to use two weapons will permit them to hold two-handed weapons. I'm yet to confirm is this works, since I've not got any two-handed weapons available.--[[User:Quil|Quil]] 12:28, 11 February 2009 (EST)

::Ok, thanks. Stupidly, in a moment of frustration I abandoned the fortress. I will also try to confirm this again. If it's true, that info definately needs to be in the article...--[[User:Jpwrunyan|Jpwrunyan]] 00:35, 12 February 2009 (EST)

==Unusual materials==
I was hoping to make some wooden weapons for sparring, but I don't seem to be able to make anything but the enormous trap components and bolts out of wood. Am I missing something, or can dwarves only make bolts from wood, and other wooden weapons have to be traded for/looted?
Along the same lines, it'd be really nice to know more specifically what the "handful" of weapons are that can be made of other materials, and what materials each can be made from. If anyone can verify that info here I'll try and add it into the article. (I'll find out what I can, but have no access to obsidian atm). [[User:Kirig Stonebeard|Kirig Stonebeard]] 19:32, 18 March 2009 (UTC)

:That "handful" of weapons is just bolts (wood or bone), crossbows (wood or bone), and stone short swords (1 wood + 1 obsidian, just as deadly as steel). Anything else has to be imported. The good news is that you can make weapons out of silver, which is just as bad as wood when it comes to hurting things. It's expensive as hell, but sparring weapons are sparring weapons. --[[User:LegacyCWAL|LegacyCWAL]] 19:44, 18 March 2009 (UTC)

::Thanks Legacy, the way I was reading the article I was SURE there must be others and I was just missing something on how to manufacture them. It seems to me that list is short enough to be specific about, so I'll go ahead and edit it in (and probably steal your concise formatting) to make it clearer (unless someone objects).
::Thanks also for the tip on silver; I was planning to check the table right after I checked here. I do have some galena on my current map but it might be a while til I can reach it... since the elves are mostly bringing me useless junk and haven't appointed a liason, I might just go with copper weapons and iron/steel armor and cross my fingers.
::On the bright side though, they're bringing me plenty of tamed bears in case I decide to forge a few tricycles, sew a few fezs and start a circus! [[User:Kirig Stonebeard|Kirig Stonebeard]] 05:06, 22 March 2009 (UTC)

40d Talk:Weapon

2009-03-18T19:32:07Z

Kirig Stonebeard:

40d Talk:Organizer

2009-03-18T17:41:16Z

Kirig Stonebeard:

This circular reasoning is painful.. "The manager uses the Organizer skill" which links to "The organizer skill is used by the manager" [[User:Serjndestroy|Serjndestroy]] 11:46, 22 November 2007 (EST)

:That's not really circular reasoning exactly, since both go on to explain further. "A bicyclist is someone who uses a bicycle" and "A bicycle is what a bicyclist uses" are useless statements only because they don't offer extra information (2 wheeled, man-powered vehicle, etc.) It is admittedly a little redundant to word it the way it is, but it's handy in case someone knows what a manager does but forgets the skill he uses, or vice versa. [[User:Kirig Stonebeard|Kirig Stonebeard]] 17:41, 18 March 2009 (UTC)

Does a manager gain skill per task he validates? Or is it task times quantity?--[[User:Varsashi|Varsashi]] 19:26, 6 December 2007 (EST)
:Not sure on this one, but my Manager seems to take a lot longer to verify larger orders. It may be a fixed point gain per task validated, but the increasing legth of time to validate an order the bigger it is suggests it might be affected by quantity too (otherwise you could powerlevel you manager setting 30 1-unit orders instead of a single 30-unit one).
:—Preceding [[template:unsigned|unsigned]] comment added by [[User:TangoThree|TangoThree]] ([[User talk:TangoThree|talk]]•[[Special:Contributions/TangoThree|contribs]]) {{{2|}}}

== Skill Gain in v0.27.176.38c. ==

I have personally tested the skill gain in v0.27.176.38c. Work orders provide 10 skill points per item in the order. Therefore 30 one items and one 30 item gives the same amount of skill, 300.

Is the skill gained on completion of the validate order or on completion of the actual work order? --[[User:Drop11|Drop11]]

== workshop used for work orders ==

is there any way to make sure (for example) that the "make bone bolts" jobs always go to the same workshop next to the refuse storage area and the "make stone shortswords" always go to the same workshop near the outer perimeter (where the wood is coming from)? I have just started using the organizer and so far he's just giving me the shits by sending jobs to the "wrong workshop"... and by ignoring the fact that a crafters workshop set to be used only by my bone carver shouldn't really be taking orders for obsidian shortswords...[[User:GarrieIrons|GarrieIrons]] 06:55, 22 June 2008 (EDT)

:Fill the "wrong" workshops' queues with repeat jobs of the desired type and/or suspended jobs to keep unwanted jobs from being added.--[[User:Maximus|Maximus]] 14:04, 3 November 2008 (EST)

I believe when you use the manager the jobs are spread out amongst all the workshops of the correct type in order to complete the task with maximum efficiency (in ONE sense, that is). Assigning tasks to a specific workshop is what the "add new task" action on the workshop's {{key|Q}}uery menu is for. If you want to have your cake and skill up your Manager too, Maximus's suggestion is very effective, and shouldn't be too much extra work if your workshops aren't too many and/or spread all over the place. (Not that I know anyone who has that problem... *whistles*) [[User:Kirig Stonebeard|Kirig Stonebeard]] 17:41, 18 March 2009 (UTC)

40d Talk:Pet

2009-03-10T19:21:11Z

Kirig Stonebeard:

== Population control ==

Is there a reliable way to remove pets? On some of my fortresses, I wind up with 100+ pets and actually see a framerate hit because of it. I don't really care if their owners get an unhappy thought, they'll straighten out when they drink their masterwork beer. [[User:Ripheus|Ripheus]] 21:06, 3 March 2008 (EST)
:Non pet-passable door + death room might work. (A drawbridge would probably work nicely). Get the dorf to walk into the room (build something in there or draft them and station them there), wait for the pet, set door as tightly closed, get the dorf to leave the room, drop bridge. +Kitten tallow biscuits+. --[[User:Wabbiteh|Wabbiteh]] 06:21, 10 March 2008 (EDT)
::Death rooms are mandatory in fortresses requiring high fps. Best if you station them near main corridor with few backup corridors. It may be possible to trap pets by just door settings alone. Animals don't know that tightly-closed doors count as forbidden for them and will not include them in pathfinding calculations (they see free corridor, not closed door). They will stand before tightly closed door and won't find a better way. Forbidden doors count as obstacle and will be bypassed if possible. This may be used to create automatic death rooms (if they are controlled by pressure plates you may need absolutely no dwarven intervention). Also, you can't butcher cats killed by anything other than butcher, so no +Kitten Tallow Biscuit+ for you. --[[User:Someone-else|Someone-else]] 17:35, 9 May 2008 (EDT)
Worked and worked well, thank you sir. I prefer the spike trap, personally. [[User:Ripheus|Ripheus]] 22:55, 24 March 2008 (EDT)

==Controlling movement & pathing attempts==
I've been looking for a way to lock pets up and keep them from crowding my screen and putting themselves in danger (a river full of [[Carp]], [[Sturgeon]], [[Longnose_gar|Longnose Gar]] AND [[Sea_lamprey|Sea Lampreys]] is as deadly to careless pets as careless dwarves). Tightly-closed doors are largely ineffective, as the pets sit in front of them ready to spring out the moment a dwarf opens one (for example, to lock up another pet). I also suspect the constant pathing errors they generate thinking they can get through on their own (as Someone-else mentioned above) impact performance, though thankfully I don't have enough pets to be sure (yet). I've been working on a way to lock pets away such that they'll sit quietly not attempting to escape as soon as the opportunity presents itself, and it's proving a fairly complex task, since I'm trying to do this WITHOUT killing them. I'm wondering:
1) if info on how to do this, or for that matter detailed info on how to build a pet death-room, should be included in the article and
2) if anyone else has some insight on how the non-lethal method can/should be pulled off.
Once I get a workable system I'll post the info here, and can do a writeup on the article if people think it would be useful to have a "pet control" section. [[User:Kirig Stonebeard|Kirig Stonebeard]] 15:21, 10 March 2009 (EDT)

== Cost of ownership ==
On the z-animals menu, at least once the economy starts, non-cat pets have a price listed next to them. Is it possible to buy pets off owners? If so, how? (If not, why the monetary value?) --[[User:Squirrelloid|Squirrelloid]] 02:22, 29 April 2008 (EDT)
:If you mark stray pet as available it'll have price too. It's the price at which a dwarf can buy a pet, whether it's owned by other dwarf or is stray. That's what I think.--[[User:Dorten|Dorten]] 03:22, 29 April 2008 (EDT)
:I suspect this is the cost to the dwarf's own budget, maybe a one-time fee, maybe a periodic "rent" on the pet for its care (food, squeaky toys, etc.) Either way, the only purpose is to determine whether the dwarf can afford the pet and, if he can, to slightly reduce his ability to afford other things as a result of ownership. The price is only really relevant to strays, as you can't buy a pet that's already owned. [[User:Kirig Stonebeard|Kirig Stonebeard]] 15:21, 10 March 2009 (EDT)

== Pets in combat ==
Will a pet attack enemies attacking its owner? How does pets work for protection? Can a tame mule or whatever actually be any good in a fight?--[[User:Dwaref|Dwaref]] 22:33, 28 June 2008 (EDT)

:Firstly, I've never seen a horse attack anything. Some pets such as Dogs can indeed attack enemies, but they aren't that good at stopping Goblins or anything stronger. They're good at getting rid of pests though. --[[User:AlexFili|AlexFili]] 04:02, 24 July 2008 (EDT)

:: I've seen a horse attack and stun goblins, but only in self defence (counterattacks, I assume). I believe that the horse was a pet, probably of a woodcutter, as it was wandering around outside my fort at the time. Led those gobbos a merry chase, it did. --[[User:Raumkraut|Raumkraut]] 08:13, 24 July 2008 (EDT)

::: I'm hoping they do! I bought a tame black bear off some shady elves, and I'm hoping it'll get adopted soon; prefeably by a military dwarf, or at least one that spends a decent amount of time outside of Rissenpaddle's halls. Can't wait to see the look on those goblin's faces! --[[User:Eddie|Eddie]] 07:14, 26 July 2008 (EDT)

:My current fort's first goblin ambush was put down by two stray (untrained) dogs, a stray wardog, and a stray horse FOAL. They were hanging out in a meeting hall near my trapped entrance hallway and charged right in as soon as the gobbos entered (not waiting for them to trip more than a single cage trap, to my chagrin). I groaned but one dog killed 2 of the invaders without getting a scratch, and the other sustained only a couple minor injuries taking down a 3rd. I'm not sure how much the foal helped as he didn't end up getting a name/kill, but he was certainly involved, and had the bloody hooves to prove it. I'm pretty sure the wardog helped significantly but just didn't happen to land a killing blow.
:In any case, the answer's YES, animals will fight if presented with the enemy, and they can be very effective even untrained. They didn't pursue the 2 goblins that fled, interestingly (I was still happy to order double alpo/oats all around for valor, though *grin*) [[User:Kirig Stonebeard|Kirig Stonebeard]] 15:21, 10 March 2009 (EDT)

== Named and owned pet in cage ==
If you assign a kitten to a cage, it is possible for it to adopt a dwarf before it is put in the cage; I found a pet in my cat cage. --[[User:Bombcar|Bombcar]] 03:08, 19 October 2008 (EDT)
: Yep, it is quite possible. I've had it happen on a few occasions (much to my annoyance). --[[User:Toloran|Toloran]] 15:09, 2 November 2008 (EST)
:If it happens to you, just make sure to leave the cat in the cage. All the normal rules still apply (can't butcher, death causes unhappy thought, etc.) and once it's out it won't be possible to re-cage. It's possible because the cat claiming an owner doesn't interrupt the "cage animal" task, but you can't assign it to be caged AFTER the adoption takes place. [[User:Kirig Stonebeard|Kirig Stonebeard]] 15:21, 10 March 2009 (EDT)

==Pet Training==
Can you train pet dogs? In my fortress I had loads of dogs, but it is my first fort so I made all of them available and now they're pets. --[[User:Stinhad Limarezum|Stinhad Limarezum]] 07:44, 21 October 2008 (EDT)
:You can only train strays. Though assigned war/hunting dogs seem to act like pets in terms of making their owner happy and such. Don't worry about them being assigned, there will be puppies soon enough. [[User:HeWhoIsPale|HeWhoIsPale]] 08:32, 21 October 2008 (EDT)
==Non-preferred pets==
Do dwarfs take pets that aren't the creature they like for their [prefstring]? I have black bears, cougars, wolves, deer, and marmots, but non of my dwarves are claiming them as pets. They only seem to like cows, horses, and cats. [[User:HeWhoIsPale|HeWhoIsPale]] 08:32, 21 October 2008 (EDT)
:I've had the same problem, I think they only take prefstring pets :/ --[[User:Xonara|Xonara]] 21:00, 18 January 2009 (EST)
::Generally its prefstring, although common pets may be less bound by that. Also, cats adopt dwarves (not vice-versa), so whether the dwarf likes cats or not is completely irrelevant. What is relevant is whether the cat likes the dwarf - there are dwarves that cats will *not* adopt. Presumably this is based on personality somehow. --[[User:Squirrelloid|Squirrelloid]] 21:58, 18 January 2009 (EST)
:::According to [[Cat]] a dwarf "liking cats" IS relevant. The cats choose the owners but apparently are more likely to choose dwarves who have the cat prefstring. [[User:Kirig Stonebeard|Kirig Stonebeard]] 15:21, 10 March 2009 (EDT)

Pets

2009-03-08T05:44:09Z

Kirig Stonebeard: create; redirect to Pet

#REDIRECT [[Pet]]

40d Talk:Goblin

2009-03-06T08:42:05Z

Kirig Stonebeard: /* i think i need some help */

==== Thieves & cage traps ====
Not sure that Goblin (master) thieves /can/ evade traps. I've caught a bucketful in cage traps. Didn't know what to do with them, mind... [[User:Runspotrun|Runspotrun]] 09:23, 13 November 2007 (EST)

I've noticed that when i melt down Narrow Steel Equipment, all i get is Copper! can someone verify this as a bug or intentional? -- Bullion

:I would think that that would be a bug. [[User:Mindsnap|Mindsnap]] 18:42, 3 December 2007 (EST)

Does adding [CURIOUSBEAST_GUZZLER] actually semi-fix sieges? I thought that it didn't. [[User:Mindsnap|Mindsnap]] 18:42, 3 December 2007 (EST)

:Uh, surely this isn't a real tag? --[[User:Geofferic|Geofferic]] 17:15, 12 December 2007 (EST)
::It's used on gnomes, so that they can drink your booze if they find it. Strangely, it's also used on bears. Mindsnap, try <nowiki>[CURIOUSBEAST]</nowiki>. It's not anywhere in the default raws, but it's in the program text so it may be recognised. —[[User:0x517A5D|0x517A5D]] 17:38, 12 December 2007 (EST)

== Snatchers / pedophiles ==

Why not just leave it as <s>pedophiles</s> "snatchers"? I think it's funny. --[[User:Peristarkawan|Peristarkawan]] 13:55, 12 December 2007 (EST)

:Why not deal with it as "civilized" people? I mean have some sort of a voting with an argumented discussion on the talk page before a wiki admin say his final word. Those who reverted the change were at least stating something in the summary field. I myself don't think that this bit of humor is appropriate to this article and the user who did it again and again seems to be a vandal for me.--[[User:Another|Another]] 15:12, 12 December 2007 (EST)
::Whatever you do or say, pedophiles are no laughing matter. What's wrong with you [[User:Peristarkawan|Peristarkawan]]? >:( --[[User:Eagle of Fire|Eagle of Fire]] 15:28, 12 December 2007 (EST)
:::There are about 30 episodes of Family Guy that would beg to differ. However this turns out, please stop the edit war. --[[User:Peristarkawan|Peristarkawan]] 15:51, 12 December 2007 (EST)
::::I'm very confident that if it continue, it will result in the ban of [[User:Billdauterive|Billdauterive]]. --[[User:Eagle of Fire|Eagle of Fire]] 15:54, 12 December 2007 (EST)
:I support the word "snatcher" over "pedophile", for three reasons. First, it's more likely to be immediately understood by all wiki readers. Second, we're not talking same-species kiddy snatchers here - these are goblins, and goblins enslave and/or eat dwarf children. Third, why suggest nastiness and smut (as though dwarven kids ''a la carte'' wasn't horrid enough!) in a wiki without firm grounds? [[User:Fedor|Fedor]] 16:07, 12 December 2007 (EST)
::I wasn't suggesting removing the word "snatcher" at all. You've got to agree that it seems a bit peculiar that the snatchers ''only'' target children. Why is it that murderous carp are funny but pedophile goblins are sick? Seems like a double standard to me. --[[User:Peristarkawan|Peristarkawan]] 16:27, 12 December 2007 (EST)
:::Nothing strange at all about targetting only children. They're easier to catch, easier for goblins (who are no great size themselves) to carry, can't resist as well, are much more tender when cooked, and can be permanently enslaved more easily. There's just flat-out no reason to bother with any mention of pedophilia. --[[User:Fedor|Fedor]]
:::''Why is it that murderous carp are funny but pedophile <s>goblins</s> are sick?'': Because it's the truth. --[[User:Eagle of Fire|Eagle of Fire]] 16:42, 12 December 2007 (EST)
::::Meh. As long as it stays fantasy I don't have a problem with them. Much. I don't subscribe to the notion of thoughtcrime. It's the pederasts, who act on the urge, that are the criminals. —[[User:0x517A5D|0x517A5D]] 17:46, 12 December 2007 (EST)
:::::For the record, it's not just boys that get molested, girls do too. --Gotthard 17:52, 12 December 2007 (EST)
::::::Well, if I keep with the current "for the record" trend, I have to say that I would have no problem with having goblin pedophiles in game. It's a simulation afterall. Thing is, the current discussion is related to the article page, which is used in real life by humans and not dwarves. There is also no proof at all that goblin snatchers are pedophile, so not only it is a false entry but, as I said, since it's read by real life humans then the comment can also be considered offensive. Which is my case, I do find it offensive and there's no good reason to justify it. --[[User:Eagle of Fire|Eagle of Fire]] 18:10, 12 December 2007 (EST)

:::::: Certainly. I know that. Pederasty is the closest word we have, though. Statutory rape, while applicable, is a broader term. —[[User:0x517A5D|0x517A5D]] 18:46, 12 December 2007 (EST)

::::::The only reason I made the distinction is that girls are far more likely to suffer long term damage from sexual abuse. Pederasty refers only to males. Anyway, [[User:Eagle of Fire|Eagle of Fire]] I don't think the term should be in the article unless for some reason it is in the game. My 'for the record' comment was more off topic on the definition of the word than an attack. [[User:0x517A5D|0x517A5D]] and I seem to be on the same page anyway. --Gotthard 19:12, 12 December 2007 (EST)
:::::::A through search of the games strings turns up no occurances of '''pedo''', '''pede''', or '''rape'''. '''Sex''' occurs only in the word '''''sex'''tuplets'', and in the programming term ''RegisterClas'''sEx'''''. For what that's worth. I will add my personal opinion that I also think it doesn't belong in the article. —[[User:0x517A5D|0x517A5D]] 20:03, 12 December 2007 (EST)
::::::::To be fair, 'rape' is a word in the in-game goblin language, and often appears as a surname, or civilization name. I do agree that this oughtn't be in the article, though; I suspect that children are probably taken for eating, not raping. —[[User:Captain Epix|Captain Epix]] 22:51, 12 December 2007 (EST)
:::Besides, murderous carp aren't real to life the way pedophilia is. A large zombie fish attacking a mythological creature is a bit more abstract than the a pedophile (traditionally viewed as human) molesting a small child. Frankly, I like the lack of swearing and general offensiveness of the wiki, it's a nice change compared to most of the internet. Why spoil that for the ones that like it, for information that is unclear and doesn't help understanding the article? --Gotthard 17:50, 12 December 2007 (EST)
:A thought: assume, arguendo, that the children are stolen for such a purpose. This implies not only rape and statutory rape, but also sex outside one's species. (Not quite bestiality, but similar. We don't have a word for sex with a sapient that is not of one's own species.) And since there are many snatchers, this must be sanctioned by goblin society. How warped they must be! Comments? —[[User:0x517A5D|0x517A5D]] 18:54, 12 December 2007 (EST)
::''We don't have a word for sex with a sapient that is not of one's own species.'' Isn't that more or less what the word yiffing means? --[[User:Peristarkawan|Peristarkawan]] 19:19, 12 December 2007 (EST)
:::Point. Though I think it hasn't entered the mainstream. Another one: in the ''Ringworld'' series, there's the concept of 'rishathra', ceremonial inter-species (though all descended from homo erectus) sex for the purpose of sealing trade agreements and alliances. —[[User:0x517A5D|0x517A5D]] 19:53, 12 December 2007 (EST)
::::Mainstream? Crossbreeding would be a scientific term. --[[User:Digger|Digger]] 12:01, 25 February 2008 (EST)
'''I find it surprising that such a large debate has resulted [[User_talk:Billdauterive|from the actions of an obvious vandal.]]''' --[[User:Jackard|Jackard]] 20:04, 12 December 2007 (EST)
:Yeah, that comment's not scoring him any points. Although at least he appears to have stopped editing the page. --[[User:Peristarkawan|Peristarkawan]] 21:05, 12 December 2007 (EST)
:It's not like I like to talk about those things, but I thought it was important to have a discussion against the idea of having pedophilia added to a page when it's unneeded... Read above. --[[User:Eagle of Fire|Eagle of Fire]] 23:18, 12 December 2007 (EST)
::I don't believe there was a chance it ''would'' be added, discussion or no. At best it was a crude, immature attempt at humor. --[[User:Jackard|Jackard]] 06:17, 13 December 2007 (EST)
:::[[User:Peristarkawan|Peristarkawan]] started this discussion, and I've taken his first comment as a suggestion to consider it. It was enough for me. --[[User:Eagle of Fire|Eagle of Fire]] 22:04, 13 December 2007 (EST)

== Goblin Siege ==

it´s the year 1059 and I stillwaiting for a goblin siege. the kitnappers are comming since 2 years already...

I have the newest verison (0.27.169.33g)
so what´s wrong?
:Are you sure goblins have access to your fortress? You should be able to see that on the embark screen. If goblins used to raid you all the time (like me) and you don't see them at all since the new version (like me), goblin sieges might be broken again... (I'm very happy to have been able to play almost two years now without invasions... I now have almost double amount of dwarves and I can trade now!) --[[User:Eagle of Fire|Eagle of Fire]] 07:47, 27 December 2007 (EST)

::sorry. that waqs just a bad timing. (10 minutes later the goblins came. late but now they are here)
::bad luck ^^;
::by the way...since the first dig in the mountain I am waiting for the goblins (I have over 400 traps) and a bridge-system with fortifications...so it was a little bit boring without goblins. no matter >:D
::thank you for your help!
:::No problems... I've seen so many people complaining about the lack of gobling sieges since 33g that I was wondering myself if they were broken or not. They're supposed to attack you now instead of sitting on the edge of the map, can you confirm that? --[[User:Eagle of Fire|Eagle of Fire]] 08:42, 27 December 2007 (EST)

::::of course they do. but they came in where no connection was (okok...it was a bridge)
::::so I had to dig a new way...and yes they are very agressive! I wondered why the goblin force came exacly at the beginning of 1060...coincidence?
:::::Depends if you're playing a game from a fortress ported from lower versions like me or not. Hard to say when you're playing an old game and didn't start the fortress on a world generated on the same version. It could be anything that Toady ajusted and you're simply over a certain limit by far and it takes a while before they raid you again... From that point on, it's only speculation unless some specific corrolations can be made. --[[User:Eagle of Fire|Eagle of Fire]] 09:17, 27 December 2007 (EST)

::::::it´s an old version generated world.

== add smth about timing? ==

Goblins seem to prefer arriving with caravans. Comments? Any guesses on percentage distribution?

:I believe there's an event chance when something like caravan appears. Once i had a goblin squad spawn along with human caravan, after a reload, @same place&time it didn't happen. --[[User:Digger|Digger]] 12:05, 25 February 2008 (EST)
::things seem to like arriving in the middle of a season. that includes caravans, thieves, ambushes, and migrants. -[[User:Chariot|Chariot]] 02:45, 1 March 2008 (EST)

:::For me, goblins always show up with the elves so I dont need to worry about trading with them. --CrazyMcfobo

== Protection? ==

Ive noticed that there are 3 ways to dispose of goblins.

1. Make huge walls of cage traps to capture them and then proceed to drown them in your flooding chamber. This also prevents blood from getting on the goblins so the elves will trade for their items. (Thieves cannot be moved as they escape from cages as you take them out)

2. Make a choke point at the entrance of your base and fire your ballistas! Usually around 4 should do the trick if they are close together. When they come, call in all your dwarves, and arm your ballistas. Once they enter the choke point, have them fire at will and they will be disposed of.

3. Of course you can always set up zounds of stone-fall traps all over your map.

4. armies work to start, but goblin champions are quite excellent at striking down your armies through fortifications and platemail.

== Become friends with your fellow Goblin!==

Goblins are fun to kill. I like watching them suffer as a barrage of bolts rains down upon the. Sometimes I watch them drown with a kitten in there to see if it survives. I look forward to goblins and their trolls. Oh goblins! Come to me now!
--[[User:CrazyMcfobo|CrazyMcfobo]] 14:42, 10 April 2008 (EDT)
:Is there any way to speed up the goblin ambushes?--[[User:CrazyMcfobo|CrazyMcfobo]] 18:12, 10 April 2008 (EDT)
::Letting the kobolds/goblins steal from you makes them come with better gear I believe, but I am not sure about whether or not they come faster. --[[User:Wafl|Wafl]] 22:30, 16 April 2008 (EDT)

Should we add anything to the main article about the reports of friendly goblin caravans looking to trade with certain civilizations? "Darn friendly goblins! What am I going to use these traps for now?" --[[User:Jellyfishgreen|Jellyfishgreen]] 05:30, 13 January 2009 (EST)

== The goblin annoyance ==

These forces of vile darkness are invading me more than once a year. I barely have time to clean off the battle-field before the next force arrives. This has, of course supplied me with 40+ bins of valuable goblin clothing, as well as a ridiculous amount of iron from melting down their gear. I can defeat these forces easily enough with my 50+ crossbow dwarfs raining death down upon them, but really, enough is enough. Are these attacks ever going to cease or slow down a bit? --[[User:Wafl|Wafl]] 14:28, 11 April 2008 (EDT)

::Nope. In further versions, it will be possible to affect the world map, and other cities/towers/forts. I imagine that this will mean that at some point, a goblin civilization will run out of goblins, or you can take over their city. --[[User:Mirthmanor|Mirthmanor]] 20:33, 18 August 2008 (EDT)

== Snatcher message ==

When the game tells you "A kidnapper has made off with Baby (name)!" does that mean the child has been successfully taken off the map? Or just that it has been grabbed? I never noticed any other warning about the snatcher so I'm guessing it succesfully remained invisible...? The baby doesn't show up on the unit list, nor does the snatcher. [[User:Caradhras|Caradhras]] 21:47, 26 April 2008 (EDT)

: "made off" means he successfully left the map with the baby. [[User:Qwertyu|Qwertyu]] 06:34, 27 April 2008 (EDT)

===Releasing Caged Children===
I got a message "(Child) has canceled sleep: Caged", and (I'm pretty sure) I killed the snatcher before he managed to leave. How do I get the child back?
:if you drowned him your probably out of luck, otherwise have the child's cage built, or have him moved to another cage/restraint, then free him--[[User:Eerr|Eerr]] 15:47, 8 August 2008 (EDT)
===master thieves===
it appears i have a goblin master thief in my cage trap, perhaps they're not trap-immune unless stealthed?
:No thief is 100% immune to traps. They have a certain chance to avoid traps whether sneaking or revealed. Kobolds are a lot better at it than goblins, but even they aren't completely immune. --[[User:ThunderClaw|ThunderClaw]] 13:22, 7 November 2008 (EST)

::Theoretically that would mean you can even catch a demon... O_o --[[User:Maximus|Maximus]] 21:48, 7 November 2008 (EST)

::: You can catch ''anything'' with a cage trap. Demons (well in fact, I think they're immune to traps, but I'm not a Proficien Raw Reader), dragons, colossi, giant eagle, elephants, dwarves (well, when they're unconscious), titans, everything. And this, even with a wooden, or worse, a ''glass'' cage (more exactly, a terrarium). [[User:Timst|Timst]] 06:20, 8 November 2008 (EST)

::::Well, demons have [TRAPAVOID], unlike all those others. So do kobolds. Goblins don't have it, although goblin thieves seem to.--[[User:Maximus|Maximus]] 16:49, 8 November 2008 (EST)

===Fun Snatcher Facts===
It might be nice if goblin snatchers had their own page so there was someplace relevant to put this other than a talk page...

-If a Goblin Snatcher successfully makes it off the map with a child, you can find the exact square the child was snatched from by zooming to the child from the Relationship screen of a dwarf still present on the map (say, the parent). Basically, despite being removed from the (U)nit list, they can still be 'found' via the relationship list because they still retain friends/family/etc...

-Snatched children receive a happy thought from being grabbed, which you can see if you go to (v)iew from the relationship screen: "(S)he is happy to be free."

:I bet that thought is supposed to be for when you free them from the goblins, but what if it isn't? A dwarf's life is hard, usually spent serving nobles, and the slightest misstep gets you hammerized. Are we really the good guys? [[User:Rolan7|Rolan7]] 14:03, 27 February 2009 (EST)

--[[User:Squirrelloid|Squirrelloid]] 01:52, 2 December 2008 (EST)
:I changed the Snatcher redirect to [[Thief]] instead of [[Goblin]]. Snatchers are considered a type of thief. [[User:HeWhoIsPale|HeWhoIsPale]] 13:40, 2 December 2008 (EST)

== i think i need some help ==

so i settled riiight next to what i thought was a goblin settlement, as i have before, but the same thing happened that always does, its like there isnt anyone there-
i could see goblins, and humans but they werent moving or anything, i even sent my squad over, they didnt even notice the goblin the the square next to them.

what am I doing wrong?

:I noticed the same thing - starting on a goblin fort and all the goblins are FRIENDLY in the view unit screen. (40d) Anybody? --[[User:Kwieland|Kwieland]] 12:22, 18 February 2009 (EST)

::I would guess that they're friendly goblins. Depending on how worldgen goes, it's possible (though uncommon) for a dwarven civilization to be on good terms with a goblin civilization. When that happens and you choose to be a member of that dwarven civ upon embark, moving in next to goblins is no different than moving in next to humans or elves usually is. Goblins will even send trade caravans to friendly dwarven forts that are accessible. They're not really any different than the other races except that the values the worldgen uses for them make them MUCH more likely to be hostile than humans or elves. [[User:Kirig Stonebeard|Kirig Stonebeard]] 03:42, 6 March 2009 (EST)

40d Talk:Mule

2009-03-04T07:31:42Z

Kirig Stonebeard:

==In-game functions==
Given that the in-game function of animals is
#food
#breeding to become food

and that Mules are sterile... I take it they are a "snack on the hoof" as soon as you feel inclined to eat them?
There is no child-related info in the stats section and they ''are'' sterile in RL, just want to make sure before I start snacking down...
[[User:GarrieIrons|GarrieIrons]] 07:20, 13 February 2008 (EST)

: I'm now in my third year with a trio of Mules (1 male, 2 female) tethered idly in my breeding paddock, and so far they haven't seemed particularly interested in, or capable of, breeding. I've gone ahead and removed the apparently incorrect information from the article. That was 202 embarkation points I could've put toward more... frisky livestock! --[[User:Raumkraut|Raumkraut]] 21:41, 20 June 2008 (EDT)

:: Is this another example of DF evolution favoring creatures that shouldn't be allowed to live? [[User:Milskidasith|Milskidasith]] 23:00, 12 November 2008 (EST)

:Don't forget bonecarving, fat rendering, leather, and cannon fodder. But since all the available animals can be used these ways and require no upkeep, I'd argue that breeding stands head and shoulders above all other animal functions, since it increases production down the line. Even if a mule gives you more bang for your embark-buck on say bones or meat than X creature, its inability to breed makes it a less effective choice automatically. That could of course change if a future version requires that animals be fed or allows them to do work, but as it is currently I see no reason to buy a mule that isn't aesthetic (if you like mules for some reason). I've thus changed "little reason" to "no practical reason" for wanting them. [[User:Kirig Stonebeard|Kirig Stonebeard]] 02:31, 4 March 2009 (EST)

==Breeding horses and donkeys==
Could someone specifically verify that horses and donkeys won't mate in DF (as yet, at least)? I believe it, but it would be nice to have the kind of positive testimony Raumkraut offered above about mules breeding themselves. Anyone tried an experiment? I've got a mated horse/donkey pair from immigrants, I'll lock 'em up together and see what happens, but it might be a while before I'm confident about my data, so if you have experience, please post a note.
Since there's no better place to put this really, I just want to mention that I swapped the parental sexes. Apparently a horse father and donkey mother is pretty rare, and their offspring is called a "hinny". Thanks Wikipedia! [[User:Kirig Stonebeard|Kirig Stonebeard]] 02:31, 4 March 2009 (EST)

40d:Mule

2009-03-04T06:59:15Z

Kirig Stonebeard: correct male/female, change "little reason" to "no reason"

{{CreatureInfo|name=Mule|symbol=M|color=rgb(128, 128, 0)|bones=8|chunks=8|meat=8|fat=4|skulls=1|skin=Yes|biome= Common domestic}}

'''Mules''' are sterile hybrids of a [[donkey]] father and a [[horse]] mother in reality. In Dwarf Fortress they are indeed sterile, but cannot actually be bred from horses and donkeys, making them little more than a snack on the hoof. They are available for selection on the embark screen for most dwarven parties and cost 101 points.

You can also recieve a free mule as one of the two draft animals for your wagon, depending on what domesticated animals are used by your dwarven civiilization. Due to their infertility, there is no practical reason to purchase a mule over any other animal or foodstock.

{{Game_Data|[CREATURE:MULE]
[NAME:mule:mules:mule]
[TILE:'M'][COLOR:6:0:0]
[PETVALUE:200]
[PREFSTRING:stubborness]
[LARGE_ROAMING]
[COMMON_DOMESTIC][PACK_ANIMAL]
[BENIGN][MEANDERER][PET]
[BODY:QUADRUPED:TAIL:2EYES:2EARS:NOSE:2LUNGS:HEART:GUTS:ORGANS:THROAT:NECK:SPINE:BRAIN:MOUTH]
[BODYGLOSS:HOOF][NATURAL]
[SIZE:8]
[ATTACK:MAIN:BYTYPE:STANCE:kick:kicks:1:2:BLUDGEON][ATTACKFLAG_WITH]
[FAT:4]
[DIURNAL]
[STANDARD_FLESH]
[HOMEOTHERM:10068]
[LAYERING:100]
[SWIMS_INNATE][SWIM_SPEED:2500]
[TRADE_CAPACITY:2000]
}}
{{Creatures}}
[[Category:Animals]]

40d Talk:Captured creatures

2009-03-02T04:44:46Z

Kirig Stonebeard: /* STOP HIM!!! */

== Taming ==
It looks like animals that killed any "good" creatures (such as elves or humans) can't be tamed (will go rampart as soon as they are released from cages).
I've got my whole fortress sealed off, a dragon came, after being hit by few stone traps and killing whole elven caravan, it fell into a cage trap. I tamed him (I do have a Dungeon Master) but when I tried to chain him before the entrance he started to kill dwarfs as soon as he was released from cage. I'm 100% sure it didn't kill any dwarfs (only a war dog) before falling in to a trap, and I'm certain it killed at least one elf. I'm using 27.176.38c, not modded in any way. --[[User:Tomato|Tomato]] 02:58, 3 March 2008 (EST)

Just to clarify a little here, it doesnt seem that killing tame animals will trigger untamability, but if Tomato's experiences are anything to go by, watch out if other civilized entities have been slain. (I am reasonably sure that tame animals are ok, by an experimental process of de-stealthing a GCS by throwing a dog into its cave, taming it, and letting it wander around in my base for a month or so waiting for the death messages) --[[User:Kaypy|Kaypy]] 10:30, 21 May 2008 (EDT)
== magma ==
Initial questions: will cages melt and its inhabitants be killed if magma is released onto it and the cage is non-magma-resistant?
:Yes, I burnt a bunch of useless donkeys and kittens this way. [[User:Dangerous Beans|Dangerous Beans]] 12:32, 1 August 2008 (EDT)

== breed in cages?==
I've done the cages to massive herds idea, but it doesn't work. They'll give birth just fine while in the cage (and the babies *won't* be locked in the cage, btw) but I've gone three years without a birth until a couple seasons after I released them all to presumably breed again. If you ask me, the ideal herd would be contained in a pit that's had access walled off, since (I believe) pathfinding lag isn't a factor when it's a wall, not a locked door.

Yea, I'm feeling a bit lazy right now, or I'd have edited this stuff into the article myself. Feel free to add it in and remove this, assuming I haven't just ended up in some weird situation where they just happen to have been pregnant for 3 years... --[[User:N9103|Edward]] 22:56, 10 January 2008 (EST)
: I am not exactly sure, but i think both a cow and a dog have given birth inside a cage after being in there for more than a year. So i toned down the statement in the article.--[[User:Koltom|Koltom]] 10:02, 27 February 2008 (EST)

Actually, the babies born in cages thing is true, but it works this way: the baby is born in the cage but is not ''assigned'' in the cage. So when it's born, a dwarf will immediately rush to free it. (Tried this by building a cage behind forbidden doors and the baby remained in the cage.)

By the way, how do you put a timestamp behind your edit? This timestamp below I have manually typed in. --[[User:ShunterAlhena]] 09:12, 11 January 2008 (EST)

:use <nowiki>--~~~~</nowiki> or the button that looks like a signature ;) --[[User:N9103|Edward]] 08:04, 11 January 2008 (EST)

== STOP HIM!!! ==

How am I supposed to put a captured goblin in an arena without letting the little bastard go? [[User:Patarak|Patarak]] 00:05, 25 January 2008 (EST)
:A lever based enter/exit door for the arena so you can lock it, His combatent will probably have to be the one to let him go in that case. Or use a pit of some kind. --[[User:Shades|Shades]] 04:01, 25 January 2008 (EST)
My problem more lies with transporting the goblins from an animal stockpile to my arena/pit, which simply had the goblin released from his cage. [[User:Patarak|Patarak]] 04:32, 25 January 2008 (EST)
:Is there a problem with building a cage using the cage the gobbo's in? As for releasing... you do know levers work on cages too, right? --[[User:N9103|Edward]] 05:37, 25 January 2008 (EST)
Just to clarify, I have a problem transporting the goblin, not releasing him. When I attempted to move him, the goblin was released in the animal stockpile. I'm not sure how to specify build the cage that the goblin is using, but that would probably work, yes. [[User:Patarak|Patarak]] 05:52, 25 January 2008 (EST)
::You would {{k|b}}uild ca{{k|j}}e (yes its j to build a cage) [[User:Jikor|Jikor]] 06:51, 25 January 2008 (EST)

IIRC, in order to assign a creature to an existing cage, it first has to be taken out of the cage it's in and carried over to the new cage. However, the dwarf moving it in this way may suddenly realise they are carrying a dangerous 'thing' and drop it. This can be avoided by building the cage directly, which does not require taking the creature out. [[User:VengefulDonut|VengefulDonut]] 07:59, 25 January 2008 (EST)
:With the current (.38c) version I have noticed that transporting goblin soldiers is fine, the poor goblin just trails along and gets moved while goblin thieves will escape when tried to be moved. Perhaps it has something to do with sneaking vs not-sneaking. [[User:Yvain|Yvain]] 00:06, 10 April 2008 (EDT)
:I know for certian this behavior held in 0.23.130.23a. I imagine it probably hasn't changed since 0.27.169.33g. I tagged the article with 0.23.130.23a, so if someone knows better, please change it. [[User:VengefulDonut|VengefulDonut]] 08:09, 25 January 2008 (EST)
Whenever I build the cage, the dwarves just bring an empty one. I still haven't figured out a way to build exactly the cage the goblins are in. [[User:Patarak|Patarak]] 14:11, 25 January 2008 (EST)
:{{k|b}}uild menu -> ca{{k|j}}e [sic], then press e{{k|x}}pand list to see the indivudial cages with quality levels instead of a broader category list. Pick the one that's called "Goblin Cage(''materialname'')" and the dwarves will construct the cage with the gobbo still inside. Then link it up to a lever, station your executioner in a locked room with it, and yank the lever to start your pitfight. --[[User:TangoThree|TangoThree]] 10:23, 26 January 2008 (EST)
::No more reusable method? I mean, for next fight the cage has to be dismantled, then new cage built and connected to a lever. I could imagine "dumping" the goblin right onto the cage (set as cage trap?) on the arena (short pit/pond shaft right above) should work?
:::One method would be to {{k|b}}uild the cage on some kind of isolated platform that would force the combatant to run back across a grate or other pit trap, then pull a lever or whatever to drop them in. Puts whoever opens the cage at risk, though.
::::No "more reusable" method is really possible with a lever-triggered cage in the equation; opening a cage via lever is a one-time exercise, and a mechanic has to reset the lever and cage's mechanisms. If you wanted to avoid this I suppose you could have a dwarf remove the creature from its cage and dump it into the arena as outlined in the "injury tower" section, but it's probably not worth risking the creature escaping, IMO. Re-linking the cage and lever only takes a few seconds and your mechanic will re-use the mechanism anyway. [[User:Kirig Stonebeard|Kirig Stonebeard]] 23:44, 1 March 2009 (EST)

== RE: Arenas section ==

Is it actually possible to strip the weapons and armour off a captured creature as suggested here? --[[User:TangoThree|TangoThree]] 11:15, 26 January 2008 (EST)

: Yep, Check out the talk page for cages, under "Captured thieves" someone should probably integrate that info this article. --[[User:The Flying Febe|The Flying Febe]] 23:20, 3 February 2008 (EST)

== Sentry Animals? ==

Can tamed creatures be used as sentries? Or would I have to have a dwarf? 
--[[User:Lordmick134|Lordmick134]] 22:43, 30 March 2008 (EDT)

:Yes. Build a chain or rope and attach a tame creature to it, and it will have a good chance of spotting any nearby thieves or other sneaking creatures. I usually set up 2-3 chained critters in alcoves along my entry halls for that purpose. --[[User:Janus|Janus]] 02:55, 31 March 2008 (EDT)

::Can caged animals see ambushers farther away than the 8 tiles adjacent to them? I figure they probably don't (in which case they're still plenty useful anyways), but it'd make it a lot easier to cover large areas if I don't have to put a cage every third tile. [[User:LegacyCWAL|LegacyCWAL]] 20:08, 7 June 2008 (EDT)

No. The best way is to set up some high-traffic areas, and make sure all your valuables are indoors and that any potential ambushers have to get past your security. For example;
:xxx
:xOx
:xxx

If you put your roped animal in the middle they will have access to all 8 tiles around them with very little chance of an enemy bypassing it. --[[User:AlexFili|AlexFili]] 04:09, 9 June 2008 (EDT)

:I was afraid of that. Ambushers getting into the fortress isn't a problem because I've already done what you describe (and racked up a hell of a kill count in the process =P ). I was just hoping for a better way to help keep ambushers away from stuff like road-builders and caravans that my Corridor of Doom can't protect. --[[User:LegacyCWAL|LegacyCWAL]] 13:45, 9 June 2008 (EDT)

== Animal Training Labor ==

The article said only a dwarf with Animal Training activated will release animals. I had a dwarf releasing and caging animals with no labors active, except pump operating. Using 38c. --[[User:Strangething|Strangething]] 15:31, 14 June 2008 (EDT)

:I don't know where it says that, so I'll leave it to you to fix it. You're correct; the article is wrong. --[[User:Savok|Savok]] 15:48, 14 June 2008 (EDT)

::I already fixed it --[[User:Strangething|Strangething]] 20:31, 15 June 2008 (EDT)

== Capturing friends ==

Does anyone know of a way to capture friendly entities? Elves would be awesome but I was thinking more like my own dwarves, without makind them go berserk (I'm also trying to figure out whether or not it counts as lowering population, and if not what happens if you sell them?). --[[User:MagicGuigz|MagicGuigz]] 20:00, 7 October 2008 (EDT)

:I think that making them go to sleep on a cage trap (such as by locking them in a 1x1 room with said trap in it) will do it.[[User:LegacyCWAL|LegacyCWAL]] 20:58, 7 October 2008 (EDT)

:: Ah yes probably, didn't think of that...thanks! Maybe we should include it if it's veryfied? There's lots of fun to be had with captured dwarves and humans/elves I think. --[[User:MagicGuigz|MagicGuigz]] 21:31, 7 October 2008 (EDT)

:: It was pretty hard but I managed to catch one! The trick is to dig a 3-4 z-levels hole with a hatch over it (or bridge, etc), and have a cage at the bottom. Draft someone and make him stand there while someone pulls the lever. 2 dead dwarves (and the one in the cage gravely wounded I suspect) but it was worth it. The 1x1 room thing didn't work, as they tended to starve before they actually fainted...or maybe I didn't wait long enough? More testing to come and then maybe I can include that in the article. --[[User:MagicGuigz|MagicGuigz]] 22:24, 9 October 2008 (EDT)

:: The dwarf was automatically released and helped by others... I guess the only way to keep dwarves locked is to make them go berserk...

== Slavery? ==

Is it possible to sell caged entities? I once tried to sell a caged Goblin (Pedogob, I think it was) to Dwarven Merchants, and the Goblin was released from its cage when the cage was set down in the Depot. Did I do something wrong, or is it just not possible? --[[User:Nekojin|Nekojin]]

: Bug #41 (or was it 40?). Sometimes (not always) a dwarf will take only the cage without its content to the depot. --[[User:MagicGuigz|MagicGuigz]] 11:02, 19 October 2008 (EDT)

== "This can be avoided by building the cage the animal is in" ==

Caveat — When an animal is captured via a cage trap and then assigned to an existing cage, the dwarf moving the animal will tend to let it go. This can be avoided by building the cage the animal is in.v0.27.176.38c

Can we get some clarification on the last sentence? [[User:SwallowedSpear|SwallowedSpear]] 18:56, 11 January 2009 (EST)

:In DF, building an object can (and often does) refer to placing it as a building. EG: "I have 20 limonite tables for my dining hall, but I didn't build them yet". Does that clear it up? [[User:VengefulDonut|VengefulDonut]] 19:18, 11 January 2009 (EST)

::Well, does it mean that if, say, a goblin gets caught in a *Lead cage*, you should "build" that same *Lead Cage* where you want it to go? [[User:SwallowedSpear|SwallowedSpear]] 19:49, 12 January 2009 (EST)

:::Yes. --[[User:N9103|Edward]] 21:07, 12 January 2009 (EST)

== Jailbreak ==

I had caught goblins in my traps over the years. I put all the cages in a big room because I didn't know what else to do with them ... then during the second siege of my fortress I caught a GOBLIN MACE LORD! 
I read the arena section and put him in there with a giant jaguar. Locked the door and pulled the lever.. the mace lord literally tore the giant jaguar apart and began walking in a circle inside of the room.. I don't get it. 
I thought that he could at least try to free his captured brethren. That way an army of 7 would form and even though they were mostly thieves a simple locked rock door shouldn't be able to hold a MACE LORD and his 6 followers captive now would it? Am I the only one who thinks this would be a welcome change? --[[User:Aspgren|Aspgren]] 05:25, 7 Feb 2009 (CET)

:Toady actually reads the suggestions in the DF forums. If you have an idea and an interest in seeing it happen, here is not the best place to put it. [[User:VengefulDonut|VengefulDonut]] 00:26, 7 February 2009 (EST)

== Injury Shaft ==

Is it only me or does the instructions to build sound confusing? I'm having a hard time deciphering it. --[[User:Myroc|Myroc]] 08:05, 14 February 2009 (EST)
:Hopefully this will help =) [[User:LegacyCWAL|LegacyCWAL]] 12:17, 14 February 2009 (EST)

== Goblin-raised dwarfs ==

So, my fort has a lot of cage traps. I've been just chucking captured goblin invaders down through the baracks roof to give the rookies some combat experience, but last time the fort got attacked, there were some dwarfs among them. So, now I have three captured dwarves in cages. Unfortunately, I cannot 'pit' them into the baracks. I have tried building cages and 'unassigning' the invader-dwarves from the cages, but nothing happens when I do so. When I tried to use a lever to free them, someone came and dismantled the cage. How does one free one's long-lost children so they can get a face-full of crossbow? [[User:Dogun|Dogun]] 20:56, 22 February 2009 (EST)

40d Talk:Cleaning

2009-02-26T14:06:27Z

Kirig Stonebeard:

I see no indication that any of this is true in 40c. No blood, vomit, water, bolts, or ammunition (even not-forbidden) has been cleaned up in my fortress, and every dwarf has had Cleaning toggled on by default from the beginning. Is this old data? --[[User:Sev|Sev]] 14:05, 2 September 2008 (EDT)
:At least the cleaning of blood and used bolts I can verify for 40d. So probably its still true for vomit and water, too. --[[User:Doub|Doub]] 04:30, 11 October 2008 (EDT)
::I just watched one of my dwarves clean up used bolts (in 40d) [[User:Edenicholas|Edenicholas]] 15:02, 11 October 2008 (EDT)
:::I've added verify tags to water and vomit. I've also done ammunition since no one's mentioned it specifically. Anyone who's seen their dwarves clean these, please just remove the verify tag and leave a note here. [[User:Kirig Stonebeard|Kirig Stonebeard]] 09:06, 26 February 2009 (EST)

40d:Cleaning

2009-02-26T14:04:13Z

Kirig Stonebeard: add verify tags to unconfirmed substances

Cleaning is a [[labor]] that allows your dwarves to take cleaning [[skill|job]]s.

Cleaning jobs remove [[blood|blood, ichor]], [[vomit]]{{verify}}, [[water]]{{verify}}, used [[bolt]]s and [[siege engine|ammunition]]{{verify}} from the floor and walls of your fortress. Cleaning will not move [[corpse]]s, body parts, or dead [[vermin]]; those tasks require the [[hauling|refuse hauling]] labor. Cleaning has no effect on [[miasma]], which will naturally dissipate over time.

Dwarves will only clean [[subterranean]] areas of the fortress, as [[above ground]] areas will clean automatically at the turn of every season.

A dwarf who decides to clean will stand on the space to be cleaned for a moment, and that tile and all adjacent tiles will be cleaned.

While cleaning must be activated in the labor preferences, it does not raise any skill, nor does cleaning rely on any skill to determine the speed or effectiveness with which it is done.

[[Category:Jobs]]

40d Talk:Vomit

2009-02-26T13:54:05Z

Kirig Stonebeard:

Perhaps this page should be merged with and redirect to a general contaminants page? - [[User:Mzbundifund|Mzbundifund]] 23:52, 21 November 2007 (CST)

I agree--vomit isn't big enough to have its own page. [[User:Midna|Midna]] 13:44, 6 May 2008 (EDT)

== Mood penalty? ==

Is there any sort of mood penalty associated with vomit? I can't imagine dwarves like trodding through the stuff...
:Nope they're quite content to wade through the stuff.--[[User:Richards|Richards]] 20:48, 15 May 2008 (EDT)
::Eww. --[[User:Borgin|Borgin]] 23:47, 15 May 2008 (CST)
:::From what I read on [[thought]] page vomit can only help after it's created. Dwarves can drink vomit, though it obviously makes them unhappy. I wish DF had true fluid mechanics, not only water and magma. Vomit pump would be incredibly awesome. --[[User:Someone-else|Someone-else]] 21:30, 22 July 2008 (EDT)
::::"Help"? If I understand [[Thought]] correctly "was forced to drink vomit lately" is a negative thought. However, I'm not sure it's actually ''possible'' (at least in the current version). [[User:Kirig Stonebeard|Kirig Stonebeard]] 08:54, 26 February 2009 (EST)

You're making me devise a wicked plan that involves a vomitorium enforced sun room that creates a vomit pool, which I can then pump... I'll have to wait for the fluid mechanics but.. it'll happen --[[User:Loganis|Loganis]] 01:00, 5 December 2008 (EST)

:I believe vomit is not a liquid but a "covering", like mud, so that won't work.--[[User:Maximus|Maximus]] 12:03, 5 December 2008 (EST)
::It would work if vomit were made a fluid as Someone-else suggested, but AFAIK there's no reason to think Toady plans to institute this. It would be... interesting, though. I'll sign the petition if it includes blood! [[User:Kirig Stonebeard|Kirig Stonebeard]] 08:54, 26 February 2009 (EST)

== Cleaning? ==

Will dwarves with the Cleaning job clear up puddles of vomit, or does it just go away over time?
:I'm pretty sure they don't. They certainly don't clean it off of themselves either! Eventually most of my fortress seems to end up vomit-covered, especially babies. Actually babies end up worse as their parents tend to drop them in the mud whilst vomiting and if there's been a siege recently and the reason for everyone coming out is because of the lootables on the floor there tends to be a healthy amount of blood too, just in case vomit and mud stains weren't enough. --[[User:Krythorne|Krythorne]]
::It seems to disappear from the floor at the beginning of each season. --[[User:Tachyon|Tachyon]]
:Cleaning indicates that vomit will be cleaned, but only if it's inside (it's left to disappear at the end of the season if it's outdoors). That could use verifying though. [[User:Kirig Stonebeard|Kirig Stonebeard]] 08:54, 26 February 2009 (EST)

==Escaping cave adaptation==
Once it has set in, is there any way to cure cave adaptation? Because I have dwarves building up a large tower, and they keep vomiting. It's annoying, and it's not good for the mental state of the fort. --[[User:Cypress|Cypress]] 17:45, 26 August 2008 (EDT)
:See [[Cave adaptation]] for info on getting it, curing it, and preventing it. [[User:Kirig Stonebeard|Kirig Stonebeard]] 08:54, 26 February 2009 (EST)

==Any effect?==
It would seem vomit doesn't have negative thought penalties, but does it have ANY negative effects (or positive, for that matter)? There's a "was forced to drink vomit lately" negative thought built into the game as mentioned above, but AFAIK it's not actually possible to drink the stuff. Are there any negatives that ''are'' instituted? If not it makes the Cleaning labor seem like kind of a waste to me (except for aesthetic purposes). [[User:Kirig Stonebeard|Kirig Stonebeard]] 08:54, 26 February 2009 (EST)

40d Talk:Blood

2009-02-26T13:52:41Z

Kirig Stonebeard:

The spreading mud/blood issue is fixed as of 0.27.169.33f. Toady One has disabled mud/blood spreading for the time being.

:Did it spread like infinite water?--[[User:CrazyMcfobo|CrazyMcfobo]] 19:36, 13 April 2008 (EDT)

:: afaik, the blood/mud became fresh any time anything stepped in it, so if it got into a major hallway or a chokepoint, it covered your whole fortress... [[User:Twiggie|Twiggie]] 16:24, 19 April 2008 (EDT)

Since all my goblin gear is in brackets like (this), I assume that indicates something covered in blood? I know elves don't buy bloodied items, but does it otherwise affect the price? And does blood eventually wear off? Hopefully some important tidbits to add to the page. [[User:Bryan Derksen|Bryan Derksen]] 19:22, 6 May 2008 (EDT)

objects in (brackets) mean that they were imported or produced off site. 
As far as I know, the only way to check blood is to open the full detail page. 

--[[User:Lordmick134|Lordmick134]] 19:47, 6 May 2008 (EDT)

:(edit conflict)
:No, parenthesized items are ones created by people other than yours -- they don't count in your "created wealth". You can see blood by viewing description in the stock menu, inventory or otherwise: for instance an axe will show "Contents: goblin blood covering". Blood seems to last a long time still, not sure if it ever goes away. All my cats are covered in blood, vomit, and ichor spatters. Ick. [[User:Anydwarf|Anydwarf]] 19:50, 6 May 2008 (EDT)

how do you clean it/disable it? – [[template:unsigned|unsigned]] comment by [[User:Seaneat|Seaneat]]

: Get rid of it? Hell, I want MORE of it! Any way one can keep blood from being cleaned up by dwarves with the cleaning job? The sacrificial pit in my temple must run red! --[[User:Eddie|Eddie]] 00:38, 21 October 2008 (EDT)

::More to the point, is there any REASON to get rid of it? Does having blood staining your walls (or clothes, or skin, or pets...) have any negative effect? I haven't seen anywhere that it does, nor vomit. Makes the Cleaning labor seem like a waste of time to me, other than for aesthetic purposes. [[User:Kirig Stonebeard|Kirig Stonebeard]] 08:52, 26 February 2009 (EST)

40d Talk:Design strategies

2009-02-24T05:46:10Z

Kirig Stonebeard: /* Radial Design */

Perhaps these explanations of how the various mining commands work should go under a Mining article. "Design strategies" seems like it would be more about layouts for kitchens and pump systems and whatnot. --[[User:BahamutZERO|BahamutZERO]] 19:43, 30 October 2007 (EDT)
: I have inadvetently written an article on [[Digging]] which complements the work on this page. I suggest they be reviewed and relevant parts merged. This page will have a use in future for players to post their designs. I agree with '''BahamutZERO''' that this isn't the place to talk about Mining. --[[User:Markavian|Markavian]] 22:41, 31 October 2007 (EDT)

== Flooded Entrance ==

I'd like to see some sample shots of that Flooded Entrance setup. It's my understanding that the screw pump only pulls water up, not pump it down. Maybe he meant a floodgate for dropping the water down a level. --[[User:Vinic|Vinic]] 16:27, 2 November 2007 (EDT)

:I think what he had was two rooms--one is the actual entrance way, sealed by doors--that have pumps on the level above, dumping thier output into a channel that leads into the room they aren't pumping from.--[[User:Draco18s|Draco18s]] 16:43, 2 November 2007 (EDT)

::Sorry if I was ambiguous in my wording. Hopefully the accompanying screenshot removes any confusion in how it works. --[[User:Lucid|Lucid]] 11:38, 3 November 2007 (EDT)

The idea is good but what I saw on those screenshots had immediately looked flawed to me. Even back when siege AI was broken trolls wandered to my experimental flood-the-sigers device (ironically) and quickly destroyed both the screw pump and the windmill. I am sure that they will also try to break any accessible axles and gears. So you should modify the design to keep all building destroyers (ideally including flying ones but not necessary as dragons are really rare and demons are avoidable) from leaving you with a permanently flooded entrance. The problem can be even worse with lava.--[[User:Another|Another]] 17:59, 16 December 2007 (EST)

== Choice of location ==

I think we should get some information up here on selecting a ''proper'' site to start digging your fortress. Sort of a list of ideal criteria to look for on the actual map after you've arrived, taking into account things like elevation, natural rock formations, water and magma, and accessibility. Sort of a guide to the ultimate defense, I suppose. --[[User:Xazak|Xazak]] 14:47, 3 November 2007 (EDT)

:Seconded. That would be indeed useful. --[[User:UltimaPhantom|UltimaPhantom]] 13:43, 8 November 2007 (EST)

==Defense Designs==
I think we should have separate page for defense schemes such as the new trap designs using machines and wall patterns and such. [[User:Jikor|Jikor]] 06:29, 9 November 2007 (EST)

== Nifty designs? ==

Not sure if this is right page, but I'd love a step-by-step about building arenas. [[User:Runspotrun|Runspotrun]] 09:24, 13 November 2007 (EST)

== Workshop layout ==

Why are the inputs placed so far off the hallway in the "Wio" design? Wouldn't it make more sense to have a 'ladder' layout where each rail was a hallway and each rung was "iWo", so that haulers had easy access to both piles? Or better yet, a hallway with input stockpiles below the workshops, and another with output stockpiles above the workshops? I think the layout presented is pretty inefficient given the new 3rd axis.

== This page is strange to edit ==
If you edit a section of the page, it totally screws up the formatting of the entire page. I think it might have to do with the code and pre tags. [[User:Julius|Julius]] 14:21, 13 November 2007 (EST)
:I stripped out the code and pre tags and replaced them with leading spaces to preserve fixed width formatting.[[User:Julius|Julius]] 14:34, 13 November 2007 (EST)

== Access to Trade Depot ==

I thought it would be a good idea to have a seperate three-tile wide entrance to have the trade depot underground, behind defences, with a single tile wide access from a store-room for finished goods.

HOWEVER: If the drawbridge blocking the three-wide entrance is raised: the human merchant wagons bypass my settlement!

Maybe, closed drawbridges need to be included as accessable in the pathfinding algorithm?

Yes, my "Access to depot" screen is ''totally different'' with the drawbridge up vs down. It should be the same though.[[User:GarrieIrons|GarrieIrons]] 07:14, 8 February 2008 (EST)

==Radial Design==
I've been using a radial design that works superb. The entire fortress is designed around a principle somewhat similar to that presented in the 'Moody Dwarves' section on the main page. With a single staircase running up and down the entire fortress, which everything is connected around.

The floors alternate workshop/storage. On workshop floors the diagonals immediate to the main stairway are mined out a couple spaces to make room for the first workshops; around those I start mining in straight lines and start a grid pattern. Storage floors I leave the wall of stone around the staircase with only one or two walls mined out for access and put doors there; everything around this is mined out. First floor is usually farm workshops, kennel, barracks, and dining. On the ground level I start by mining into a cave, clear out space for a trade depot, and mine out one spot where I build a single downward staircase; here the entire fortress starts. It works great and is very efficient, though it takes a while to get setup right.

For defense I prefer to locate the starting digging point up high and build a bridge to an inaccessible area of cliff. The bridge is retracted as invaders stream across it. Again, it takes a while to get started because you have to build a huge bridge, but worth it. The sole entrance to your fortress is also a single down stairway (unless you have backdoors or additional stairways), making it somewhat easy to defend here too.

I'm still a noob, so I'm sure people can add to this, but of my several fortresses the one I went with this design on has been my favorite and I think best operating establishment.

Below you can see a piece from around the central staircase, to see how the design should start. Notice that it is pretty modular, you can have two workshops pushed together, or you can separate them all, and you have a couple options on how you set up your entrances, connecting two workshops with one door, or leaving them with separate entrances. Up to you. Notice the initial diagonal terminates at a workshop, and starts the grid pattern.
W= workshop
D= door
┼= path
`= wall
{{qd|cols=18
|`|W|W|W|`|.|`|`|`|`|`|.|`|W|W|W|`|`
|`|W|W|W|`|.|`|`|`|`|`|.|`|W|W|W|`|`
|`|W|W|W|`|.|`|W|W|W|`|.|`|W|W|W|`|`
|`|`|`|`|┼|.|`|W|W|W|`|.|┼|`|`|`|`|`
|.|.|.|.|.|.|`|W|W|W|`|.|.|.|.|.|.|.
|`|`|`|`|`|`|┼|`|`|`|┼|`|`|`|┼|`|`|`
|W|W|W|W|W|W|`|.|`|.|`|W|W|W|`|W|W|W
|W|W|W|W|W|W|`|`|X|`|`|W|W|W|`|W|W|W}}
{{qd|cols=18
|W|W|W|W|W|W|`|.|`|.|`|W|W|W|`|W|W|W
|`|`|`|`|`|`|┼|`|`|`|┼|`|`|`|┼|`|`|`
|.|.|.|.|.|.|`|W|W|W|`|.|.|.|.|.|.|.
|`|`|`|`|┼|.|`|W|W|W|`|.|┼|`|`|`|`|`
|`|W|W|W|`|.|`|W|W|W|`|.|`|W|W|W|`|`
|`|W|W|W|`|.|`|`|`|`|`|.|`|W|W|W|`|`
|`|W|W|W|`|.|┼|W|W|W|┼|.|`|W|W|W|`|`
|`|`|`|`|`|.|`|W|W|W|`|.|`|`|`|`|`|`}}
{{qd|cols=18
|`|`|`|`|`|.|`|W|W|W|`|.|`|`|`|`|`|`
|`|`|`|`|`|.|`|`|`|`|`|.|`|`|`|`|`|`}}

[[User:Omnirizon|Omnirizon]] 23:59, 28 February 2008 (EST)

-----

I started using this design, but ran into a small problem: For some reason, even with all four diagonals leading into the room, they're unable to build a workshop though. I've so far only tried a mason's workshop since I'm interested in getting rid of all my excess stone by turning it into blocks for roads and walls (I want to have smooth roads and walls), and no matter which square I stick it in, they say that they "Cannot reach the work site" once they begin building. [http://img.photobucket.com/albums/v478/urth/workshop.png] There's a link to a picture of the layout thus far. The workshop is in the bottom square, and when completed would only block out access from the top-right corner, still allowing traffic via the top-left corner. It even says they cannot reach the site if I stick it in the far north square, where both current entrances would remain intact. Why is it doing this? --[[User:Urthdigger|Urthdigger]] 04:44, 11 October 2008 (EDT)

:I haven't tried this setup myself and I don't know why it didn't work for you, but solving it ought to be rather easy simply by not extending the diagonals beyond the initial hallways, like so:
<code>
█WWW█.█████.█WWW██ 
█WWW█.█████.█WWW██ 
█WWW█.█WWW█.█WWW██ 
██▓██.█WWW█.██▓███ 
......█WWW█....... 
██████▓███▓█▓███▓█ 
WWWWWW█.█.█WWW█WWW 
WWWWWW██X██WWW█WWW 
WWWWWW█.█.█WWW█WWW 
████▓█▓███▓███████ 
......█WWW█....... 
██▓██.█WWW█.██▓███ 
█WWW█.█WWW█.█WWW██ 
█WWW█.██▓██.█WWW██ 
█WWW█.█WWW█.█WWW██ 
█████.█WWW█.██████ 
█████.█WWW█.██████ 
█████.█████.██████</code>

You'd get an unsmoothable section of workshop wall, but it's better than nothing. It'd also allow you to incorporate a door if you were adapting the design a bit. [[User:Kirig Stonebeard|Kirig Stonebeard]] 00:46, 24 February 2009 (EST)

== Beware: Traffic Problems ==

I think that one of the biggest mistakes new fortress designers make is not leaving enough space for traffic. If you build a fortress that is too compact/tight, you'll begin to see problems when you have 80+ dwarves all running around. This will be especially problematic in fortresses that use single width hallways. I'd suggest using 4-wide for main arteries, 3-wide for secondary roads, and 2-wide at minimum for anything other than a work/access tunnel.

== Gairabad's shameless self-promotion ==

I added a bunch of stuff to my [[User:Gairabad|user page]] on workshop layout design. In my humble opinion, it blows all the existing designs on this page right out of the water. You're welcome to incorporate it if you like. [[User:Gairabad|Gairabad]] 21:17, 28 November 2008 (EST)

== Cave Adaptation ==

Not sure why, but when I follow the intructions on this section the stairway ends up listed as 'inside' and 'light'. As I understand it, unless it says outside it won't work.

I noticed that the instructions as listed say to replace the channeled area with flooring, that may be a missunderstanding there. This is in response to the person talking about things being inside anyway. I will try to give it a try soon and see what I get. Anyway, on to my actual comment. The posting mentions that telling dwarves to stay inside forbids them from using the stairs, a possible way arround this is to make sure that the exit has a door of some sort (since it is suggested to build a wall at the top level anyway) and then when you tell all dwarves to stay inside, lock the door, then tell them they can go outside again. [[User:Burlingk|Burlingk]] 23:39, 10 February 2009 (EST)

40d Talk:Design strategies

2009-02-24T04:51:50Z

Kirig Stonebeard: /* Radial Design */

Perhaps these explanations of how the various mining commands work should go under a Mining article. "Design strategies" seems like it would be more about layouts for kitchens and pump systems and whatnot. --[[User:BahamutZERO|BahamutZERO]] 19:43, 30 October 2007 (EDT)
: I have inadvetently written an article on [[Digging]] which complements the work on this page. I suggest they be reviewed and relevant parts merged. This page will have a use in future for players to post their designs. I agree with '''BahamutZERO''' that this isn't the place to talk about Mining. --[[User:Markavian|Markavian]] 22:41, 31 October 2007 (EDT)

== Flooded Entrance ==

I'd like to see some sample shots of that Flooded Entrance setup. It's my understanding that the screw pump only pulls water up, not pump it down. Maybe he meant a floodgate for dropping the water down a level. --[[User:Vinic|Vinic]] 16:27, 2 November 2007 (EDT)

:I think what he had was two rooms--one is the actual entrance way, sealed by doors--that have pumps on the level above, dumping thier output into a channel that leads into the room they aren't pumping from.--[[User:Draco18s|Draco18s]] 16:43, 2 November 2007 (EDT)

::Sorry if I was ambiguous in my wording. Hopefully the accompanying screenshot removes any confusion in how it works. --[[User:Lucid|Lucid]] 11:38, 3 November 2007 (EDT)

The idea is good but what I saw on those screenshots had immediately looked flawed to me. Even back when siege AI was broken trolls wandered to my experimental flood-the-sigers device (ironically) and quickly destroyed both the screw pump and the windmill. I am sure that they will also try to break any accessible axles and gears. So you should modify the design to keep all building destroyers (ideally including flying ones but not necessary as dragons are really rare and demons are avoidable) from leaving you with a permanently flooded entrance. The problem can be even worse with lava.--[[User:Another|Another]] 17:59, 16 December 2007 (EST)

== Choice of location ==

I think we should get some information up here on selecting a ''proper'' site to start digging your fortress. Sort of a list of ideal criteria to look for on the actual map after you've arrived, taking into account things like elevation, natural rock formations, water and magma, and accessibility. Sort of a guide to the ultimate defense, I suppose. --[[User:Xazak|Xazak]] 14:47, 3 November 2007 (EDT)

:Seconded. That would be indeed useful. --[[User:UltimaPhantom|UltimaPhantom]] 13:43, 8 November 2007 (EST)

==Defense Designs==
I think we should have separate page for defense schemes such as the new trap designs using machines and wall patterns and such. [[User:Jikor|Jikor]] 06:29, 9 November 2007 (EST)

== Nifty designs? ==

Not sure if this is right page, but I'd love a step-by-step about building arenas. [[User:Runspotrun|Runspotrun]] 09:24, 13 November 2007 (EST)

== Workshop layout ==

Why are the inputs placed so far off the hallway in the "Wio" design? Wouldn't it make more sense to have a 'ladder' layout where each rail was a hallway and each rung was "iWo", so that haulers had easy access to both piles? Or better yet, a hallway with input stockpiles below the workshops, and another with output stockpiles above the workshops? I think the layout presented is pretty inefficient given the new 3rd axis.

== This page is strange to edit ==
If you edit a section of the page, it totally screws up the formatting of the entire page. I think it might have to do with the code and pre tags. [[User:Julius|Julius]] 14:21, 13 November 2007 (EST)
:I stripped out the code and pre tags and replaced them with leading spaces to preserve fixed width formatting.[[User:Julius|Julius]] 14:34, 13 November 2007 (EST)

== Access to Trade Depot ==

I thought it would be a good idea to have a seperate three-tile wide entrance to have the trade depot underground, behind defences, with a single tile wide access from a store-room for finished goods.

HOWEVER: If the drawbridge blocking the three-wide entrance is raised: the human merchant wagons bypass my settlement!

Maybe, closed drawbridges need to be included as accessable in the pathfinding algorithm?

Yes, my "Access to depot" screen is ''totally different'' with the drawbridge up vs down. It should be the same though.[[User:GarrieIrons|GarrieIrons]] 07:14, 8 February 2008 (EST)

==Radial Design==
I've been using a radial design that works superb. The entire fortress is designed around a principle somewhat similar to that presented in the 'Moody Dwarves' section on the main page. With a single staircase running up and down the entire fortress, which everything is connected around.

The floors alternate workshop/storage. On workshop floors the diagonals immediate to the main stairway are mined out a couple spaces to make room for the first workshops; around those I start mining in straight lines and start a grid pattern. Storage floors I leave the wall of stone around the staircase with only one or two walls mined out for access and put doors there; everything around this is mined out. First floor is usually farm workshops, kennel, barracks, and dining. On the ground level I start by mining into a cave, clear out space for a trade depot, and mine out one spot where I build a single downward staircase; here the entire fortress starts. It works great and is very efficient, though it takes a while to get setup right.

For defense I prefer to locate the starting digging point up high and build a bridge to an inaccessible area of cliff. The bridge is retracted as invaders stream across it. Again, it takes a while to get started because you have to build a huge bridge, but worth it. The sole entrance to your fortress is also a single down stairway (unless you have backdoors or additional stairways), making it somewhat easy to defend here too.

I'm still a noob, so I'm sure people can add to this, but of my several fortresses the one I went with this design on has been my favorite and I think best operating establishment.

Below you can see a piece from around the central staircase, to see how the design should start. Notice that it is pretty modular, you can have two workshops pushed together, or you can separate them all, and you have a couple options on how you set up your entrances, connecting two workshops with one door, or leaving them with separate entrances. Up to you. Notice the initial diagonal terminates at a workshop, and starts the grid pattern.
W= workshop
D= door
┼= path
`= wall
{{qd|cols=18
|`|W|W|W|`|.|`|`|`|`|`|.|`|W|W|W|`|`
|`|W|W|W|`|.|`|`|`|`|`|.|`|W|W|W|`|`
|`|W|W|W|`|.|`|W|W|W|`|.|`|W|W|W|`|`
|`|`|`|`|┼|.|`|W|W|W|`|.|┼|`|`|`|`|`
|.|.|.|.|.|.|`|W|W|W|`|.|.|.|.|.|.|.
|`|`|`|`|`|`|┼|`|`|`|┼|`|`|`|┼|`|`|`
|W|W|W|W|W|W|`|.|`|.|`|W|W|W|`|W|W|W
|W|W|W|W|W|W|`|`|X|`|`|W|W|W|`|W|W|W}}
{{qd|cols=18
|W|W|W|W|W|W|`|.|`|.|`|W|W|W|`|W|W|W
|`|`|`|`|`|`|┼|`|`|`|┼|`|`|`|┼|`|`|`
|.|.|.|.|.|.|`|W|W|W|`|.|.|.|.|.|.|.
|`|`|`|`|┼|.|`|W|W|W|`|.|┼|`|`|`|`|`
|`|W|W|W|`|.|`|W|W|W|`|.|`|W|W|W|`|`
|`|W|W|W|`|.|`|`|`|`|`|.|`|W|W|W|`|`
|`|W|W|W|`|.|┼|W|W|W|┼|.|`|W|W|W|`|`
|`|`|`|`|`|.|`|W|W|W|`|.|`|`|`|`|`|`}}
{{qd|cols=18
|`|`|`|`|`|.|`|W|W|W|`|.|`|`|`|`|`|`
|`|`|`|`|`|.|`|`|`|`|`|.|`|`|`|`|`|`}}

[[User:Omnirizon|Omnirizon]] 23:59, 28 February 2008 (EST)

-----

I started using this design, but ran into a small problem: For some reason, even with all four diagonals leading into the room, they're unable to build a workshop though. I've so far only tried a mason's workshop since I'm interested in getting rid of all my excess stone by turning it into blocks for roads and walls (I want to have smooth roads and walls), and no matter which square I stick it in, they say that they "Cannot reach the work site" once they begin building. [http://img.photobucket.com/albums/v478/urth/workshop.png] There's a link to a picture of the layout thus far. The workshop is in the bottom square, and when completed would only block out access from the top-right corner, still allowing traffic via the top-left corner. It even says they cannot reach the site if I stick it in the far north square, where both current entrances would remain intact. Why is it doing this? --[[User:Urthdigger|Urthdigger]] 04:44, 11 October 2008 (EDT)

:I haven't tried this setup myself and I don't know why it didn't work for you, but solving it ought to be rather easy simply by not extending the diagonals beyond the initial hallways, like so:
<code>
█WWW█.█████.█WWW██ 
█WWW█.█████.█WWW██ 
█WWW█.█WWW█.█WWW██ 
██▓██.█WWW█.██▓███ 
......█WWW█....... 
██████▓███▓█▓███▓█ 
WWWWWW█.█.█WWW█WWW 
WWWWWW██X██WWW█WWW 
WWWWWW█.█.█WWW█WWW 
████▓█▓███▓███████ 
......█WWW█....... 
██▓██.█WWW█.██▓███ 
█WWW█.█WWW█.█WWW██ 
█WWW█.██▓██.█WWW██ 
█WWW█.█WWW█.█WWW██ 
█████.█WWW█.██████ 
█████.█WWW█.██████ 
█████.█████.██████</code>

== Beware: Traffic Problems ==

I think that one of the biggest mistakes new fortress designers make is not leaving enough space for traffic. If you build a fortress that is too compact/tight, you'll begin to see problems when you have 80+ dwarves all running around. This will be especially problematic in fortresses that use single width hallways. I'd suggest using 4-wide for main arteries, 3-wide for secondary roads, and 2-wide at minimum for anything other than a work/access tunnel.

== Gairabad's shameless self-promotion ==

I added a bunch of stuff to my [[User:Gairabad|user page]] on workshop layout design. In my humble opinion, it blows all the existing designs on this page right out of the water. You're welcome to incorporate it if you like. [[User:Gairabad|Gairabad]] 21:17, 28 November 2008 (EST)

== Cave Adaptation ==

Not sure why, but when I follow the intructions on this section the stairway ends up listed as 'inside' and 'light'. As I understand it, unless it says outside it won't work.

I noticed that the instructions as listed say to replace the channeled area with flooring, that may be a missunderstanding there. This is in response to the person talking about things being inside anyway. I will try to give it a try soon and see what I get. Anyway, on to my actual comment. The posting mentions that telling dwarves to stay inside forbids them from using the stairs, a possible way arround this is to make sure that the exit has a door of some sort (since it is suggested to build a wall at the top level anyway) and then when you tell all dwarves to stay inside, lock the door, then tell them they can go outside again. [[User:Burlingk|Burlingk]] 23:39, 10 February 2009 (EST)