Dwarf Fortress Wiki - User contributions [en]

Slavery

2026-10-04T00:45:11Z

Silverwing235: /* Child enslavement */

{{Quality|Unrated}}
[[Image:necromancer_experiment_slave.png|300px|thumb|right|A [[necromancer]] [[experiment]] with the slave "profession".]]

This article describes slavery only as represented by the game mechanics, world generation and fictional setting of ''Dwarf Fortress''.

=Overview=
Slavery is not a major gameplay mechanic in ''Dwarf Fortress'', but the concept occurs in several parts of the game. [[Legends|Historical]] figures can become enslaved during [[world generation]], and slavery can also occur through several distinct game mechanics.
The game represents several forms of enslavement, including:
* Child enslavement — [[Goblin]] snatchers abduct [[children]], who may subsequently become slaves.
* Forced domestication — Goblins can enslave [[Troll]]s and use them as mounts, haulers or war animals.
* War slavery — [[Civilization]]s can enslave defeated enemies and bring them back to their settlements.
* Undead servitude — [[Undead]] creatures raised by [[necromancer]]s can be regarded as being under the control of their creator.
* Slaves of Armok — The game's subtitle; '''Slaves to Armok: God of Blood Chapter II: Dwarf Fortress''', uses slavery as part of the game's fictional terminology.

=Civilizational attitudes=
Slavery is also represented in the game's ethics system, which determines how different civilizations regard the practice.

The vanilla civilization definitions specify the following [[Ethic|ethical attitudes]] toward slavery:
{| class="wikitable"
!Civilization!!Attitude toward slavery
|-
|[[Human]]s||Acceptable
|-
|[[Goblin]]s||Viewed as a personal matter
|-
|[[Elf|Elves]]||Punishable by exile
|-
|[[Dwarf|Dwarves]]||Capital punishment1
|-
|[[Kobold]]s||Unthinkable
|-
|[[Animal person|Subterranean animal peoples]]||Unthinkable
|}
These attitudes primarily determine how a civilization reacts to slavery as an ethical issue. They should not be confused with the separate mechanics through which slavery actually occurs.

Notes:
#Despite being defined by the entity token [[Ethic#PUNISH_CAPITAL|PUNISH_CAPITAL]], as far as Dwarven [[Justice#Punishments|justice]] is concerned, capital punishment is not an intentional death penalty (though it is often an [[Hammerer|unintentional]] one). Dwarf society regards this punishment as 8 months in prison or fifty hammer strikes, falling just short of the greater than fifty hammer strikes needed for a punishment to be specifically considered an execution.

=Slavery in world generation=
During world generation, [[historical figure]]s can become enslaved. In mechanical terms, enslavement is closely related to imprisonment: an enslaved historical figure can potentially escape.

Slavery is unlikely to have a direct impact on the game when playing in [[Adventurer mode|adventure]] or [[Dwarf fortress mode|fortress mode]], where it is most likely to be seen in descriptions of historical events. Specific examples of how slavery is represented or implemented by the game can be seen in:
*A civilization's ethics.
*The various text [[String_dump/raw|strings]] used by the game in [[language]]s, [[speech]] and descriptions.
*Two explicit [[unit type token]]s.

Examples of possible references:
* "the end of the former enslavement of"
* "escaped from the slavery of"
* "escaped from the slavery of" / "escaped from the prisons of"
* "was enslaved by" / "was imprisoned by"
* "the enslavement" / "the imprisonment"
* "as a former slave of" / "as a former prisoner of"

=Child enslavement=
Goblins are particularly associated with the abduction of [[children]]. Goblin snatchers can enter settlements and abduct children, who can become part of the goblin civilization, rather than remaining members of their original civilization.
Children can potentially be recovered through a citizen recovery mission, while adventurers can also encounter and rescue captives through quests.
See:
* [[Thief#Goblin_snatchers|Goblin snatchers]]
* [[Mission|Missions]]
* [[Quest|Quests]]

= Troll enslavement / forced domestication / sentient livestock=
[[Goblin|Goblins]] can also enslave [[Troll|Trolls]]. This is mechanically different from human-style war slavery. The Troll is treated as an animal-like creature under goblin control and can be used for purposes such as:
* carrying loads;
* pulling;
* riding;
* combat.
This creates a distinction between sapient creatures that are treated as animals and ordinary domesticated animals.
This form of enslavement is particularly relevant to modding, because the {{token|ANIMAL|entity}} token can cause a creature to be treated mechanically as an animal, even when the creature is otherwise sapient.
The relevant distinction is between:
* a creature being part of the civilization's main race;
* a creature being defined as an animal or special animal caste;
* a creature being treated as a pet;
* a creature being used as a mount, puller or hauler.
This can produce a situation in which a creature is biologically or culturally sapient but is mechanically handled as livestock or a domesticated animal.

=War slavery=

Civilizations can enslave defeated enemies and take them back to their settlements. This can be described as spoils-of-war slavery or war enslavement.

The ethics value for slavery also affects whether a civilization is willing to accept caged sapient creatures from merchants.

Higher or lower ethical values appear to have relatively limited mechanical consequences, beyond determining whether the civilization permits slavery at all. The ethical value therefore primarily establishes the civilization's attitude toward the practice rather than providing a detailed slavery simulation.

=Undead servitude=
[[Necromancer|Necromancers]] can raise dead creatures as [[Undead]]. The resulting undead are generally under the control of the necromancer who created them.
This can be interpreted as another form of forced servitude, although the game does not necessarily classify undead as slaves in the same mechanical sense as enslaved historical figures.

=Modding Slavery=
There is no dedicated `SLAVE` creature mechanic in ''Dwarf Fortress''. A [[Modding|mod]] can simulate slavery through the use of [[Entity token#Animal definitions|ANIMAL entity tokens]], and referencing a creature with specific [[creature token]]s such as {{token|PACK_ANIMAL}} and {{token|PET}}. There are three main approaches, all of which rely on the creature in question being explicitly defined per-civlization (entity).
{| class="wikitable"
|+ Modding approaches
|-
! Method !! Description !! Can be embarked with !! Can be traded !! Has slave-population in worldgen !! Can be trained !! Can have labours !! Can have a specific interaction !! Can have specific traits !! Can have a pet value !! Slave can be married to non-slave and have kids || Graphic modding needed
|-
| Existing creature as ANIMAL || Use ANIMAL tokens within an entity to define an existing creature itself. || Yes || Yes || Yes || If non-speaking || If [CAN_LEARN]| No || No || Yes || Yes || No
|-
| Special caste as ANIMAL || Add a special caste to an existing creature and use ANIMAL_CASTE_TOKEN to define it within an entity. || Yes for the special caste, but not the main race || both || No || If non-speaking || If [CAN_LEARN] || Only for the special caste || Only for the special caste ||Yes, both || Yes || Yes
|-
| Creature copy as ANIMAL|| Create a copy of the original creature and define the copy using ANIMAL entity tokens. || Yes for the special creature, but not for the main race || both || Yes || If non-speaking || If [CAN_LEARN] || Only for the special creature || Only for the special creature || Yes, both || No || Yes
|}
* Can be embarked with: creatures can be selected as livestock animals
* Can be traded: can be selected in the trade agreement
* Can have a specific interaction: an interaction specifically for this slave-creature can be defined
* Can have specific traits: tokens as desired can be assigned to the slave-creature.

The choice depends on the desired behaviour. A special caste is useful when the enslaved version should remain closely connected to the original creature — i.e. if dwarves should be able to enslave other dwarves. A separate creature provides more freedom when the enslaved version needs substantially different properties — i.e. if there is a specific "House Elf" creature that is expected to always be enslaved.

==Sapience and Assigning Tasks==
You can assign tasks to a creature with ANIMAL entity tokens if they have the creature tokens {{token|CAN_LEARN}} and {{token|CAN_SPEAK}}.

The CAN_LEARN tag will also mean that the game classes a creature as sapient, which comes with certain limitations on how they can be treated and interacted with. For instance, sapient creatures cannot normally be milked or butchered. Either token will allow a creature to have [[Personality value|values]] and [[Personality goal|goals]].

For a more detailed and philosophical analysis on the topic of sapience, within the context of ''Dwarf Fortress'', see [[Person]].

==How to make them show up==
For creatures that do not naturally spawn, you need {{token|ANIMAL_ALWAYS_PRESENT|entity}}, otherwise, the civ only has them available if they somehow domesticated them. You need {{token|ANIMAL_ALWAYS_PET|entity}} to make them selectable for embark.

==Other notes about [ANIMAL] sapients==
* They can be assigned a (bed)room
* They can be assigned positions like tavern keeper or priest, but never any of the noble positions
* They cannot be assigned a pond or pit and cannot be tied to a rope
* They cannot be assigned to a trainer
* If an ANIMAL-sapient is brought by the merchants, they will come clothed and the merchants will charge extra for the clothing.
* Their thoughts can be viewed in full detail.
* They can be expelled. They do not seem to form any relationships at all.
* If they cannot speak, they are listed as livestock, but cannot be assigned labours, so they can be assigned labours if they are able to speak.
* If they cannot speak, they are trainable
Whether they will petition for citizenship has yet to be verified.
* If you catch a hostile creature in a war, they cannot be pacified. They can, however, be sold to traders.
* If you attack a site that is inhabited by a sapient creature that is defined as an animal by your civilization, you cannot capture them as livestock.

==Example==
A modder who wants dwarves to have an enslaved caste can add a special `SLAVE` caste to the dwarf creature, making use of the appropriate creature tags detailed above. Setting its population ratio to `0` prevents enslaved dwarves from appearing as a separate natural population, while still allowing the caste to be used for individual enslaved dwarves.

For elves or other races, a separate copy of the creature can instead be used as the enslaved version. This provides more control over its properties, but the game treats it as a different creature.

{| class="wikitable floatright" style="text-align:center;"
|"Slave" in other '''[[Language|Languages]]''' [[File:Story tell indicator.png|20px]]
{| style="text-align:left;"
! '''[[Dwarven language|Dwarven]]''': noth
|-
! '''[[Elven language|Elven]]''': urepe
|-
! '''[[Goblin language|Goblin]]''': smanges
|-
! '''[[Human language|Human]]''': cubnor
|}
|}

{| style="text-align:left;"
{{#if:{{{english|}}}|
{{!}}-
! '''[[wikipedia:English language|English]]''':
{{!}} {{{english}}}
}}
|-
{{#if:{{{dwarven|}}}|
{{!}}-
! '''[[Dwarven language|Dwarven]]''':
{{!}} {{{dwarven}}}
}}
|-
{{#if:{{{elvish|}}}|
{{!}}-
! '''[[Elven language|Elven]]''':
{{!}} {{{elvish}}}
}}
|-
{{#if:{{{goblin|}}}|
{{!}}-
! '''[[Goblin language|Goblin]]''':
{{!}} {{{goblin}}}
}}
|-
{{#if:{{{human|}}}|
{{!}}-
! '''[[Human language|Human]]''':
{{!}} {{{human}}}
}}
|}

{{Category|Entities}}
{{Category|Game mechanics}}
{{Category|Legends mode}}
{{Category|Lore}}
{{Category|Modding}}

Slavery

2026-10-04T00:44:14Z

Silverwing235: /* Slavery in world generation */ this isn't another grammatical screw-up, is it? at least, I hope not

{{Quality|Unrated}}
[[Image:necromancer_experiment_slave.png|300px|thumb|right|A [[necromancer]] [[experiment]] with the slave "profession".]]

This article describes slavery only as represented by the game mechanics, world generation and fictional setting of ''Dwarf Fortress''.

=Overview=
Slavery is not a major gameplay mechanic in ''Dwarf Fortress'', but the concept occurs in several parts of the game. [[Legends|Historical]] figures can become enslaved during [[world generation]], and slavery can also occur through several distinct game mechanics.
The game represents several forms of enslavement, including:
* Child enslavement — [[Goblin]] snatchers abduct [[children]], who may subsequently become slaves.
* Forced domestication — Goblins can enslave [[Troll]]s and use them as mounts, haulers or war animals.
* War slavery — [[Civilization]]s can enslave defeated enemies and bring them back to their settlements.
* Undead servitude — [[Undead]] creatures raised by [[necromancer]]s can be regarded as being under the control of their creator.
* Slaves of Armok — The game's subtitle; '''Slaves to Armok: God of Blood Chapter II: Dwarf Fortress''', uses slavery as part of the game's fictional terminology.

=Civilizational attitudes=
Slavery is also represented in the game's ethics system, which determines how different civilizations regard the practice.

The vanilla civilization definitions specify the following [[Ethic|ethical attitudes]] toward slavery:
{| class="wikitable"
!Civilization!!Attitude toward slavery
|-
|[[Human]]s||Acceptable
|-
|[[Goblin]]s||Viewed as a personal matter
|-
|[[Elf|Elves]]||Punishable by exile
|-
|[[Dwarf|Dwarves]]||Capital punishment1
|-
|[[Kobold]]s||Unthinkable
|-
|[[Animal person|Subterranean animal peoples]]||Unthinkable
|}
These attitudes primarily determine how a civilization reacts to slavery as an ethical issue. They should not be confused with the separate mechanics through which slavery actually occurs.

Notes:
#Despite being defined by the entity token [[Ethic#PUNISH_CAPITAL|PUNISH_CAPITAL]], as far as Dwarven [[Justice#Punishments|justice]] is concerned, capital punishment is not an intentional death penalty (though it is often an [[Hammerer|unintentional]] one). Dwarf society regards this punishment as 8 months in prison or fifty hammer strikes, falling just short of the greater than fifty hammer strikes needed for a punishment to be specifically considered an execution.

=Slavery in world generation=
During world generation, [[historical figure]]s can become enslaved. In mechanical terms, enslavement is closely related to imprisonment: an enslaved historical figure can potentially escape.

Slavery is unlikely to have a direct impact on the game when playing in [[Adventurer mode|adventure]] or [[Dwarf fortress mode|fortress mode]], where it is most likely to be seen in descriptions of historical events. Specific examples of how slavery is represented or implemented by the game can be seen in:
*A civilization's ethics.
*The various text [[String_dump/raw|strings]] used by the game in [[language]]s, [[speech]] and descriptions.
*Two explicit [[unit type token]]s.

Examples of possible references:
* "the end of the former enslavement of"
* "escaped from the slavery of"
* "escaped from the slavery of" / "escaped from the prisons of"
* "was enslaved by" / "was imprisoned by"
* "the enslavement" / "the imprisonment"
* "as a former slave of" / "as a former prisoner of"

=Child enslavement=
Goblins are particularly associated with the abduction of [[children]]. Goblin snatchers can enter settlements and abduct children. Abducted children can become part of the goblin civilization, rather than remaining members of their original civilization.
Children can potentially be recovered through a citizen recovery mission, while adventurers can also encounter and rescue captives through quests.
See:
* [[Thief#Goblin_snatchers|Goblin snatchers]]
* [[Mission|Missions]]
* [[Quest|Quests]]

= Troll enslavement / forced domestication / sentient livestock=
[[Goblin|Goblins]] can also enslave [[Troll|Trolls]]. This is mechanically different from human-style war slavery. The Troll is treated as an animal-like creature under goblin control and can be used for purposes such as:
* carrying loads;
* pulling;
* riding;
* combat.
This creates a distinction between sapient creatures that are treated as animals and ordinary domesticated animals.
This form of enslavement is particularly relevant to modding, because the {{token|ANIMAL|entity}} token can cause a creature to be treated mechanically as an animal, even when the creature is otherwise sapient.
The relevant distinction is between:
* a creature being part of the civilization's main race;
* a creature being defined as an animal or special animal caste;
* a creature being treated as a pet;
* a creature being used as a mount, puller or hauler.
This can produce a situation in which a creature is biologically or culturally sapient but is mechanically handled as livestock or a domesticated animal.

=War slavery=

Civilizations can enslave defeated enemies and take them back to their settlements. This can be described as spoils-of-war slavery or war enslavement.

The ethics value for slavery also affects whether a civilization is willing to accept caged sapient creatures from merchants.

Higher or lower ethical values appear to have relatively limited mechanical consequences, beyond determining whether the civilization permits slavery at all. The ethical value therefore primarily establishes the civilization's attitude toward the practice rather than providing a detailed slavery simulation.

=Undead servitude=
[[Necromancer|Necromancers]] can raise dead creatures as [[Undead]]. The resulting undead are generally under the control of the necromancer who created them.
This can be interpreted as another form of forced servitude, although the game does not necessarily classify undead as slaves in the same mechanical sense as enslaved historical figures.

=Modding Slavery=
There is no dedicated `SLAVE` creature mechanic in ''Dwarf Fortress''. A [[Modding|mod]] can simulate slavery through the use of [[Entity token#Animal definitions|ANIMAL entity tokens]], and referencing a creature with specific [[creature token]]s such as {{token|PACK_ANIMAL}} and {{token|PET}}. There are three main approaches, all of which rely on the creature in question being explicitly defined per-civlization (entity).
{| class="wikitable"
|+ Modding approaches
|-
! Method !! Description !! Can be embarked with !! Can be traded !! Has slave-population in worldgen !! Can be trained !! Can have labours !! Can have a specific interaction !! Can have specific traits !! Can have a pet value !! Slave can be married to non-slave and have kids || Graphic modding needed
|-
| Existing creature as ANIMAL || Use ANIMAL tokens within an entity to define an existing creature itself. || Yes || Yes || Yes || If non-speaking || If [CAN_LEARN]| No || No || Yes || Yes || No
|-
| Special caste as ANIMAL || Add a special caste to an existing creature and use ANIMAL_CASTE_TOKEN to define it within an entity. || Yes for the special caste, but not the main race || both || No || If non-speaking || If [CAN_LEARN] || Only for the special caste || Only for the special caste ||Yes, both || Yes || Yes
|-
| Creature copy as ANIMAL|| Create a copy of the original creature and define the copy using ANIMAL entity tokens. || Yes for the special creature, but not for the main race || both || Yes || If non-speaking || If [CAN_LEARN] || Only for the special creature || Only for the special creature || Yes, both || No || Yes
|}
* Can be embarked with: creatures can be selected as livestock animals
* Can be traded: can be selected in the trade agreement
* Can have a specific interaction: an interaction specifically for this slave-creature can be defined
* Can have specific traits: tokens as desired can be assigned to the slave-creature.

The choice depends on the desired behaviour. A special caste is useful when the enslaved version should remain closely connected to the original creature — i.e. if dwarves should be able to enslave other dwarves. A separate creature provides more freedom when the enslaved version needs substantially different properties — i.e. if there is a specific "House Elf" creature that is expected to always be enslaved.

==Sapience and Assigning Tasks==
You can assign tasks to a creature with ANIMAL entity tokens if they have the creature tokens {{token|CAN_LEARN}} and {{token|CAN_SPEAK}}.

The CAN_LEARN tag will also mean that the game classes a creature as sapient, which comes with certain limitations on how they can be treated and interacted with. For instance, sapient creatures cannot normally be milked or butchered. Either token will allow a creature to have [[Personality value|values]] and [[Personality goal|goals]].

For a more detailed and philosophical analysis on the topic of sapience, within the context of ''Dwarf Fortress'', see [[Person]].

==How to make them show up==
For creatures that do not naturally spawn, you need {{token|ANIMAL_ALWAYS_PRESENT|entity}}, otherwise, the civ only has them available if they somehow domesticated them. You need {{token|ANIMAL_ALWAYS_PET|entity}} to make them selectable for embark.

==Other notes about [ANIMAL] sapients==
* They can be assigned a (bed)room
* They can be assigned positions like tavern keeper or priest, but never any of the noble positions
* They cannot be assigned a pond or pit and cannot be tied to a rope
* They cannot be assigned to a trainer
* If an ANIMAL-sapient is brought by the merchants, they will come clothed and the merchants will charge extra for the clothing.
* Their thoughts can be viewed in full detail.
* They can be expelled. They do not seem to form any relationships at all.
* If they cannot speak, they are listed as livestock, but cannot be assigned labours, so they can be assigned labours if they are able to speak.
* If they cannot speak, they are trainable
Whether they will petition for citizenship has yet to be verified.
* If you catch a hostile creature in a war, they cannot be pacified. They can, however, be sold to traders.
* If you attack a site that is inhabited by a sapient creature that is defined as an animal by your civilization, you cannot capture them as livestock.

==Example==
A modder who wants dwarves to have an enslaved caste can add a special `SLAVE` caste to the dwarf creature, making use of the appropriate creature tags detailed above. Setting its population ratio to `0` prevents enslaved dwarves from appearing as a separate natural population, while still allowing the caste to be used for individual enslaved dwarves.

For elves or other races, a separate copy of the creature can instead be used as the enslaved version. This provides more control over its properties, but the game treats it as a different creature.

{| class="wikitable floatright" style="text-align:center;"
|"Slave" in other '''[[Language|Languages]]''' [[File:Story tell indicator.png|20px]]
{| style="text-align:left;"
! '''[[Dwarven language|Dwarven]]''': noth
|-
! '''[[Elven language|Elven]]''': urepe
|-
! '''[[Goblin language|Goblin]]''': smanges
|-
! '''[[Human language|Human]]''': cubnor
|}
|}

{| style="text-align:left;"
{{#if:{{{english|}}}|
{{!}}-
! '''[[wikipedia:English language|English]]''':
{{!}} {{{english}}}
}}
|-
{{#if:{{{dwarven|}}}|
{{!}}-
! '''[[Dwarven language|Dwarven]]''':
{{!}} {{{dwarven}}}
}}
|-
{{#if:{{{elvish|}}}|
{{!}}-
! '''[[Elven language|Elven]]''':
{{!}} {{{elvish}}}
}}
|-
{{#if:{{{goblin|}}}|
{{!}}-
! '''[[Goblin language|Goblin]]''':
{{!}} {{{goblin}}}
}}
|-
{{#if:{{{human|}}}|
{{!}}-
! '''[[Human language|Human]]''':
{{!}} {{{human}}}
}}
|}

{{Category|Entities}}
{{Category|Game mechanics}}
{{Category|Legends mode}}
{{Category|Lore}}
{{Category|Modding}}

Missing features

2026-10-03T21:59:34Z

Silverwing235: minorly reorganize

<div id="test" style="margin-right:10px;">[[File:missing_features_preview.png|right]]</div>This page lists the '''missing features''' of DF version 50, which were present in 0.47. Some of those don't have an alternative yet and are not implemented, which is what this list is about. This list is a work in progress as many discussions are scattered between multiple platforms and new issues are being discovered daily. Some of these were removed due to time constraints and are intended to be brought back in the future. {{cite forum|169696.msg8442542#msg8442542}}

==Missing gameplay features==
*[[Worldgen]] cannot be aborted once it has reached the desired history length.

====In [[Fortress Mode]]:====
*Multipurpose [[zones]] can't be created, and the type of a zone can't be changed after its creation.
*Locations can't be disbanded once they have been created. [[DFHack]] fixes this.
*Workshops can't be restricted to a certain skill level or labor ([[DF2014:Manager#Workshop_profiles|Workshop profiles]]). [[DFHack]] fixes this.
*Labor priorities are not available (aside from prioritizing certain tiles when [[mining]] or [[smoothing]]). [[DFHack]] fixes this.
*Single-tile [[stair]]s cannot be built, and the type of stairs (down, up, up/down) cannot be selected when building. [[DFHack]] fixes this.
*No mass designation of buildings to mark them as to be removed. [[DFHack]] fixes this.
*No mass removal of building foundations (as in the foundations which are created after placing a building). [[DFHack]] fixes this.
*Burrows are only designatable on a layer-by-layer basis. Painting over multiple layers only saves the one you first clicked. [[DFHack]] fixes this.
*Specific mechanisms aren't selectable when linking levers to objects, you need to forbid every other mechanism through the stock screen to have the autoselect choose the one you want. [[DFHack]] fixes this.
*[[Civilian alert]]s are not available. [[DFHack]] fixes this.
*Characters cited among your dwarves' relationships cannot be examined if they're not on the map (i.e. [[deity|gods]]).
*Can't mass bury dwarves in the same room in multiple coffins. (can't select a coffin to be used for burial, that functionality has been moved to a tomb zone requiring multiple tombs for multiple dwarves). [[DFHack]] fixes this.

====In [[Adventure Mode]]:====
*[[Camp]]s cannot be built, nor can [[site]]s be founded.

====In [[Legends]] Mode:====
*The map cannot be viewed. This also leaves Civilizations without icons.
*[[DF2014:Legends#Exporting_World_information|Legends export]] can only produce the XML file, not any of the other files it used to.

==Missing UI features==
*Logs aren't accessible after closing them. There is no combat log available when clicking a creature. [[DFHack]] fixes this.
*No [[health screen]] with an overview of dwarf and livestock health.
*[[Notes]] cannot be created. As an alternative, most buildings, zones, and stockpiles can be renamed. [[DFHack]] fixes this.
*There is no UI to visualize [[trade depot]] accessibility. [[DFHack]] fixes this.
*[[Building]] menu doesn’t show the number of buildings are built; no other way to see this information.

==Missing [[modding]] features==
*[[Raw file]]s of already created worlds cannot be edited.

==Other missing features==
*[[World painter]] is absent.
*[[DF2014:Technical_tricks#Video_Card_Options|PRINT_MODE:TEXT]] is no longer an option.

==Reintroduced features==
* [[Arena mode]] was reintroduced in [[Release information/50.06|50.06]].
* Exporting [[Legends]] content as XML was reintroduced in [[Release information/50.08|50.08]]
* [[Adventure mode]] was reintroduced in [[Release information/51.02|51.02]].
[[Category:Game]]
[[Category:Release information]]
[[ru:Missing features]]

Slavery

2026-10-03T18:33:30Z

Silverwing235: /* Civilizational attitudes */

This article describes slavery only as represented by the game mechanics, world generation and fictional setting of ''Dwarf Fortress''.

=Overview=
Slavery is not a major gameplay mechanic in ''Dwarf Fortress'', but the concept occurs in several parts of the game. [[Legends|Historical]] figures can become enslaved during [[world generation]], and slavery can also occur through several distinct game mechanics.
The game represents several forms of enslavement, including:
* Child enslavement — [[Goblin]] snatchers abduct [[children]], who may subsequently become slaves.
* Forced domestication — Goblins can enslave [[Troll]]s and use them as mounts, haulers or war animals.
* War slavery — [[Civilization]]s can enslave defeated enemies and bring them back to their settlements.
* Undead servitude — [[Undead]] creatures raised by [[necromancer]]s can be regarded as being under the control of their creator.
* Slaves of Armok — The game's subtitle; '''Slaves to Armok: God of Blood Chapter II: Dwarf Fortress''', uses slavery as part of the game's fictional terminology.

=Civilizational attitudes=
Slavery is also represented in the game's ethics system, which determines how different civilizations regard the practice.

The vanilla civilization definitions specify the following [[Ethic|ethical attitudes]] toward slavery:
{| class="wikitable"
!Civilization!!Attitude toward slavery
|-
|[[Human]]s||Acceptable
|-
|[[Goblin]]s||Viewed as a personal matter
|-
|[[Elf|Elves]]||Punishable by exile
|-
|[[Dwarf|Dwarves]]||Capital punishment1
|-
|[[Kobold]]s||Unthinkable
|-
|[[Animal person|Subterranean animal peoples]]||Unthinkable
|}
These attitudes primarily determine how a civilization reacts to slavery as an ethical issue. They should not be confused with the separate mechanics through which slavery actually occurs.

Notes:
#Despite being defined by the entity token [[Ethic#PUNISH_CAPITAL|PUNISH_CAPITAL]], as far as Dwarven [[Justice#Punishments|justice]] is concerned, capital punishment is not an intentional death penalty (though it is often an [[Hammerer|unintentional]] one). Dwarf society regards this punishment as 8 months in prison or fifty hammer strikes, falling just short of the greater than fifty hammer strikes needed for a punishment to be specifically considered an execution.

=Slavery in world generation=
During world generation, [[historical figure]]s can become enslaved. In mechanical terms, enslavement is closely related to imprisonment: an enslaved historical figure can potentially escape.

Slavery is unlikely to have a direct impact on the game when playing in [[Adventurer mode|adventure]] or [[Dwarf fortress mode|fortress mode]], where it is most likely to be seen in descriptions of historical events. Specific examples of how slavery is represented or implemented by the game can be seen in:
*A civilizations' ethics.
*The various text [[String_dump/raw|strings]] used by the game in [[language]]s, [[speech]] and descriptions.
*Two explicit [[unit type token]]s.

Examples of possible references:
* "the end of the former enslavement of"
* "escaped from the slavery of"
* "escaped from the slavery of" / "escaped from the prisons of"
* "was enslaved by" / "was imprisoned by"
* "the enslavement" / "the imprisonment"
* "as a former slave of" / "as a former prisoner of"

=Child enslavement=
Goblins are particularly associated with the abduction of [[children]]. Goblin snatchers can enter settlements and abduct children. Abducted children can become part of the goblin civilization, rather than remaining members of their original civilization.
Children can potentially be recovered through a citizen recovery mission, while adventurers can also encounter and rescue captives through quests.
See:
* [[Thief#Goblin_snatchers|Goblin snatchers]]
* [[Mission|Missions]]
* [[Quest|Quests]]

= Troll enslavement / forced domestication / sentient livestock=
[[Goblin|Goblins]] can also enslave [[Troll|Trolls]]. This is mechanically different from human-style war slavery. The Troll is treated as an animal-like creature under goblin control and can be used for purposes such as:
* carrying loads;
* pulling;
* riding;
* combat.
This creates a distinction between sapient creatures that are treated as animals and ordinary domesticated animals.
This form of enslavement is particularly relevant to modding, because the {{token|ANIMAL|entity}} token can cause a creature to be treated mechanically as an animal, even when the creature is otherwise sapient.
The relevant distinction is between:
* a creature being part of the civilization's main race;
* a creature being defined as an animal or special animal caste;
* a creature being treated as a pet;
* a creature being used as a mount, puller or hauler.
This can produce a situation in which a creature is biologically or culturally sapient but is mechanically handled as livestock or a domesticated animal.

=War slavery=

Civilizations can enslave defeated enemies and take them back to their settlements. This can be described as spoils-of-war slavery or war enslavement.

The ethics value for slavery also affects whether a civilization is willing to accept caged sapient creatures from merchants.

Higher or lower ethical values appear to have relatively limited mechanical consequences, beyond determining whether the civilization permits slavery at all. The ethical value therefore primarily establishes the civilization's attitude toward the practice rather than providing a detailed slavery simulation.

=Undead servitude=
[[Necromancer|Necromancers]] can raise dead creatures as [[Undead]]. The resulting undead are generally under the control of the necromancer who created them.
This can be interpreted as another form of forced servitude, although the game does not necessarily classify undead as slaves in the same mechanical sense as enslaved historical figures.

=Modding Slavery=
There is no dedicated `SLAVE` creature mechanic in ''Dwarf Fortress''. A [[Modding|mod]] can simulate slavery through the use of [[Entity token#Animal definitions|ANIMAL entity tokens]], and referencing a creature with specific [[creature token]]s such as {{token|PACK_ANIMAL}} and {{token|PET}}. There are three main approaches, all of which rely on the creature in question being explicitly defined per-civlization (entity).
{| class="wikitable"
|+ Modding approaches
|-
! Method !! Description !! Can be embarked with !! Can be traded !! Has slave-population in worldgen !! Can be trained !! Can have labours !! Can have a specific interaction !! Can have specific traits !! Can have a pet value !! Slave can be married to non-slave and have kids || Graphic modding needed
|-
| Existing creature as ANIMAL || Use ANIMAL tokens within an entity to define an existing creature itself. || Yes || Yes || Yes || If non-speaking || If [CAN_LEARN]| No || No || Yes || Yes || No
|-
| Special caste as ANIMAL || Add a special caste to an existing creature and use ANIMAL_CASTE_TOKEN to define it within an entity. || Yes for the special caste, but not the main race || both || No || If non-speaking || If [CAN_LEARN] || Only for the special caste || Only for the special caste ||Yes, both || Yes || Yes
|-
| Creature copy as ANIMAL|| Create a copy of the original creature and define the copy using ANIMAL entity tokens. || Yes for the special creature, but not for the main race || both || Yes || If non-speaking || If [CAN_LEARN] || Only for the special creature || Only for the special creature || Yes, both || No || Yes
|}
* Can be embarked with: creatures can be selected as livestock animals
* Can be traded: can be selected in the trade agreement
* Can have a specific interaction: an interaction specifically for this slave-creature can be defined
* Can have specific traits: tokens as desired can be assigned to the slave-creature.

The choice depends on the desired behaviour. A special caste is useful when the enslaved version should remain closely connected to the original creature — i.e. if dwarves should be able to enslave other dwarves. A separate creature provides more freedom when the enslaved version needs substantially different properties — i.e. if there is a specific "House Elf" creature that is expected to always be enslaved.

==Sapience and Assigning Tasks==
You can assign tasks to a creature with ANIMAL entity tokens if they have the creature tokens {{token|CAN_LEARN}} and {{token|CAN_SPEAK}}.

The CAN_LEARN tag will also mean that the game classes a creature as sapient, which comes with certain limitations on how they can be treated and interacted with. For instance, sapient creatures cannot normally be milked or butchered. Either token will allow a creature to have [[Personality value|values]] and [[Personality goal|goals]].

For a more detailed and philosophical analysis on the topic of sapience, within the context of ''Dwarf Fortress'', see [[Person]].

==How to make them show up==
For creatures that do not naturally spawn, you need {{token|ANIMAL_ALWAYS_PRESENT|entity}}, otherwise, the civ only has them available if they somehow domesticated them. You need {{token|ANIMAL_ALWAYS_PET|entity}} to make them selectable for embark.

==Other notes about [ANIMAL] sapients==
* They can be assigned a (bed)room
* They can be assigned positions like tavern keeper or priest, but never any of the noble positions
* They cannot be assigned a pond or pit and cannot be tied to a rope
* They cannot be assigned to a trainer
* If an ANIMAL-sapient is brought by the merchants, they will come clothed and the merchants will charge extra for the clothing.
* Their thoughts can be viewed in full detail.
* They can be expelled. They do not seem to form any relationships at all.
* If they cannot speak, they are listed as livestock, but cannot be assigned labours, so they can be assigned labours if they are able to speak.
* If they cannot speak, they are trainable
Whether they will petition for citizenship has yet to be verified.
* If you catch a hostile creature in a war, they cannot be pacified. They can, however, be sold to traders.
* If you attack a site that is inhabited by a sapient creature that is defined as an animal by your civilization, you cannot capture them as livestock.

==Example==
A modder who wants dwarves to have an enslaved caste can add a special `SLAVE` caste to the dwarf creature, making use of the appropriate creature tags detailed above. Setting its population ratio to `0` prevents enslaved dwarves from appearing as a separate natural population, while still allowing the caste to be used for individual enslaved dwarves.

For elves or other races, a separate copy of the creature can instead be used as the enslaved version. This provides more control over its properties, but the game treats it as a different creature.

Slavery

2026-10-03T17:32:10Z

Silverwing235: /* Civilizational attitudes */ fix a bit of sentence fragment-y disconnection

This article describes slavery only as represented by the game mechanics, world generation and fictional setting of ''Dwarf Fortress''.

=Overview=
Slavery is not a major gameplay mechanic in ''Dwarf Fortress'', but the concept occurs in several parts of the game. [[Legends|Historical]] figures can become enslaved during [[world generation]], and slavery can also occur through several distinct game mechanics.
The game represents several forms of enslavement, including:
* Child enslavement — [[Goblin]] snatchers abduct [[children]], who may subsequently become slaves.
* Forced domestication — Goblins can enslave [[Troll]]s and use them as mounts, haulers or war animals.
* War slavery — [[Civilization]]s can enslave defeated enemies and bring them back to their settlements.
* Undead servitude — [[Undead]] creatures raised by [[necromancer]]s can be regarded as being under the control of their creator.
* Slaves of Armok — The game's subtitle; '''Slaves to Armok: God of Blood Chapter II: Dwarf Fortress''', uses slavery as part of the game's fictional terminology.

=Civilizational attitudes=
Slavery is also represented in the game's ethics system, which determines how different civilizations regard the practice.

The vanilla civilization definitions specify the following [[Ethic|ethical attitudes]] toward slavery:
{| class="wikitable"
!Civilization!!Attitude toward slavery
|-
|[[Human]]s||Acceptable
|-
|[[Goblin]]s||Viewed as a personal matter
|-
|[[Elf|Elves]]||Punishable by exile
|-
|[[Dwarf|Dwarves]]||Punishable by death
|-
|[[Kobold]]s||Unthinkable
|-
|[[Animal person|Subterranean animal peoples]]||Unthinkable
|}
These attitudes primarily determine how a civilization reacts to slavery as an ethical issue. They should not be confused with the separate mechanics through which slavery actually occurs.

=Slavery in world generation=
During world generation, [[historical figure]]s can become enslaved. In mechanical terms, enslavement is closely related to imprisonment: an enslaved historical figure can potentially escape.

Slavery is unlikely to have a direct impact on the game when playing in [[Adventurer mode|adventure]] or [[Dwarf fortress mode|fortress mode]], where it is most likely to be seen in descriptions of historical events. Specific examples of how slavery is represented or implemented by the game can be seen in:
*A civilizations' ethics.
*The various [[String_dump/raw|strings]] used by the game in [[language]]s, [[speech]] and descriptive texts.
*Two explicit [[unit type token]]s.

Examples of possible references:
* "the end of the former enslavement of"
* "escaped from the slavery of"
* "escaped from the slavery of" / "escaped from the prisons of"
* "was enslaved by" / "was imprisoned by"
* "the enslavement" / "the imprisonment"
* "as a former slave of" / "as a former prisoner of"

=Child enslavement=
Goblins are particularly associated with the abduction of [[children]]. Goblin snatchers can enter settlements and abduct children. Abducted children can become part of the goblin civilization, rather than remaining members of their original civilization.
Children can potentially be recovered through a citizen recovery mission, while adventurers can also encounter and rescue captives through quests.
See:
* [[Thief#Goblin_snatchers|Goblin snatchers]]
* [[Mission|Missions]]
* [[Quest|Quests]]

= Troll enslavement / forced domestication / sentient livestock=
[[Goblin|Goblins]] can also enslave [[Troll|Trolls]]. This is mechanically different from human-style war slavery. The Troll is treated as an animal-like creature under goblin control and can be used for purposes such as:
* carrying loads;
* pulling;
* riding;
* combat.
This creates a distinction between sapient creatures that are treated as animals and ordinary domesticated animals.
This form of enslavement is particularly relevant to modding, because the {{token|ANIMAL|entity}} token can cause a creature to be treated mechanically as an animal, even when the creature is otherwise sapient.
The relevant distinction is between:
* a creature being part of the civilization's main race;
* a creature being defined as an animal or special animal caste;
* a creature being treated as a pet;
* a creature being used as a mount, puller or hauler.
This can produce a situation in which a creature is biologically or culturally sapient but is mechanically handled as livestock or a domesticated animal.

=War slavery=

Civilizations can enslave defeated enemies and take them back to their settlements. This can be described as spoils-of-war slavery or war enslavement.

The ethics value for slavery also affects whether a civilization is willing to accept caged sapient creatures from merchants.

Higher or lower ethical values appear to have relatively limited mechanical consequences, beyond determining whether the civilization permits slavery at all. The ethical value therefore primarily establishes the civilization's attitude toward the practice rather than providing a detailed slavery simulation.

=Undead servitude=
[[Necromancer|Necromancers]] can raise dead creatures as [[Undead]]. The resulting undead are generally under the control of the necromancer who created them.
This can be interpreted as another form of forced servitude, although the game does not necessarily classify undead as slaves in the same mechanical sense as enslaved historical figures.

=Modding Slavery=
There is no dedicated `SLAVE` creature mechanic in ''Dwarf Fortress''. A [[Modding|mod]] can simulate slavery through the use of [[Entity token#Animal definitions|ANIMAL entity tokens]], and referencing a creature with specific [[creature token]]s such as {{token|PACK_ANIMAL}} and {{token|PET}}. There are three main approaches, all of which rely on the creature in question being explicitly defined per-civlization (entity).
{| class="wikitable"
|+ Modding approaches
|-
! Method !! Description !! Can be embarked with !! Can be traded !! Has slave-population in worldgen !! Can be trained !! Can have labours !! Can have a specific interaction !! Can have specific traits !! Can have a pet value !! Slave can be married to non-slave and have kids || Graphic modding needed
|-
| Existing creature as ANIMAL || Use ANIMAL tokens within an entity to define an existing creature itself. || Yes || Yes || Yes || If non-speaking || If [CAN_LEARN]| No || No || Yes || Yes || No
|-
| Special caste as ANIMAL || Add a special caste to an existing creature and use ANIMAL_CASTE_TOKEN to define it within an entity. || Yes for the special caste, but not the main race || both || No || If non-speaking || If [CAN_LEARN] || Only for the special caste || Only for the special caste ||Yes, both || Yes || Yes
|-
| Creature copy as ANIMAL|| Create a copy of the original creature and define the copy using ANIMAL entity tokens. || Yes for the special creature, but not for the main race || both || Yes || If non-speaking || If [CAN_LEARN] || Only for the special creature || Only for the special creature || Yes, both || No || Yes
|}
* Can be embarked with: creatures can be selected as livestock animals
* Can be traded: can be selected in the trade agreement
* Can have a specific interaction: an interaction specifically for this slave-creature can be defined
* Can have specific traits: tokens as desired can be assigned to the slave-creature.

The choice depends on the desired behaviour. A special caste is useful when the enslaved version should remain closely connected to the original creature — i.e. if dwarves should be able to enslave other dwarves. A separate creature provides more freedom when the enslaved version needs substantially different properties — i.e. if there is a specific "House Elf" creature that is expected to always be enslaved.

==Sapience and Assigning Tasks==
You can assign tasks to a creature with ANIMAL entity tokens if they have the creature tokens {{token|CAN_LEARN}} and {{token|CAN_SPEAK}}.

The CAN_LEARN tag will also mean that the game classes a creature as sapient, which comes with certain limitations on how they can be treated and interacted with. For instance, sapient creatures cannot normally be milked or butchered. Either token will allow a creature to have [[Personality value|values]] and [[Personality goal|goals]].

For a more detailed and philosophical analysis on the topic of sapience, within the context of ''Dwarf Fortress'', see [[Person]].

==How to make them show up==
For creatures that do not naturally spawn, you need {{token|ANIMAL_ALWAYS_PRESENT|entity}}, otherwise, the civ only has them available if they somehow domesticated them. You need {{token|ANIMAL_ALWAYS_PET|entity}} to make them selectable for embark.

==Other notes about [ANIMAL] sapients==
* They can be assigned a (bed)room
* They can be assigned positions like tavern keeper or priest, but never any of the noble positions
* They cannot be assigned a pond or pit and cannot be tied to a rope
* They cannot be assigned to a trainer
* If an ANIMAL-sapient is brought by the merchants, they will come clothed and the merchants will charge extra for the clothing.
* Their thoughts can be viewed in full detail.
* They can be expelled. They do not seem to form any relationships at all.
* If they cannot speak, they are listed as livestock, but cannot be assigned labours, so they can be assigned labours if they are able to speak.
* If they cannot speak, they are trainable
Whether they will petition for citizenship has yet to be verified.
* If you catch a hostile creature in a war, they cannot be pacified. They can, however, be sold to traders.
* If you attack a site that is inhabited by a sapient creature that is defined as an animal by your civilization, you cannot capture them as livestock.

==Example==
A modder who wants dwarves to have an enslaved caste can add a special `SLAVE` caste to the dwarf creature, making use of the appropriate creature tags detailed above. Setting its population ratio to `0` prevents enslaved dwarves from appearing as a separate natural population, while still allowing the caste to be used for individual enslaved dwarves.

For elves or other races, a separate copy of the creature can instead be used as the enslaved version. This provides more control over its properties, but the game treats it as a different creature.

Slavery

2026-10-03T13:46:19Z

Silverwing235: /* Modding Slavery */ some inconsistent case use around here

This article describes slavery only as represented by the game mechanics, world generation and fictional setting of ''Dwarf Fortress''.

=Overview=
Slavery is not a major gameplay mechanic in ''Dwarf Fortress'', but the concept occurs in several parts of the game. [[Legends|Historical]] figures can become enslaved during [[world generation]], and slavery can also occur through several distinct game mechanics.
The game represents several forms of enslavement, including:
* Child enslavement — [[Goblin]] snatchers abduct [[children]], who may subsequently become slaves.
* Forced domestication — Goblins can enslave [[Troll]]s and use them as mounts, haulers or war animals.
* War slavery — [[Civilization]]s can enslave defeated enemies and bring them back to their settlements.
* Undead servitude — [[Undead]] creatures raised by [[necromancer]]s can be regarded as being under the control of their creator.
* Slaves of Armok — The game's subtitle; '''Slaves to Armok: God of Blood Chapter II: Dwarf Fortress''', uses slavery as part of the game's fictional terminology.

=Civilizational attitudes=
Slavery is also represented in the game's ethics system, which determines how different civilizations regard the practice.

Civilizations have different [[Ethic|ethical attitudes]] toward slavery.
{| class="wikitable"
!Civilization!!Attitude toward slavery
|-
|Humans||Acceptable
|-
|Goblins||Personal Matter
|-
|Elves||Opposed; perpetrators may be punished with exile
|-
|Dwarves||Capital punishment (''technically also opposed, but with [[Justice#Punishments|considerably more force]]'')
|}
These attitudes primarily determine how a civilization reacts to slavery as an ethical issue. They should not be confused with the separate mechanics through which slavery actually occurs.

=Slavery in world generation=
During world generation, [[historical figure]]s can become enslaved. In mechanical terms, enslavement is closely related to imprisonment: an enslaved historical figure can potentially escape.

Slavery is unlikely to have a direct impact on the game when playing in [[Adventurer mode|adventure]] or [[Dwarf fortress mode|fortress mode]], where it is most likely to be seen in descriptions of historical events. Specific examples of how slavery is represented or implemented by the game can be seen in:
*A civilizations' ethics.
*The various [[String_dump/raw|strings]] used by the game in [[language]]s, [[speech]] and descriptive texts.
*Two explicit [[unit type token]]s.

Examples of possible references:
* "the end of the former enslavement of"
* "escaped from the slavery of"
* "escaped from the slavery of" / "escaped from the prisons of"
* "was enslaved by" / "was imprisoned by"
* "the enslavement" / "the imprisonment"
* "as a former slave of" / "as a former prisoner of"

=Child enslavement=
Goblins are particularly associated with the abduction of [[children]]. Goblin snatchers can enter settlements and abduct children. Abducted children can become part of the goblin civilization, rather than remaining members of their original civilization.
Children can potentially be recovered through a citizen recovery mission, while adventurers can also encounter and rescue captives through quests.
See:
* [[Thief#Goblin_snatchers|Goblin snatchers]]
* [[Mission|Missions]]
* [[Quest|Quests]]

= Troll enslavement / forced domestication / sentient livestock=
[[Goblin|Goblins]] can also enslave [[Troll|Trolls]]. This is mechanically different from human-style war slavery. The Troll is treated as an animal-like creature under goblin control and can be used for purposes such as:
* carrying loads;
* pulling;
* riding;
* combat.
This creates a distinction between sapient creatures that are treated as animals and ordinary domesticated animals.
This form of enslavement is particularly relevant to modding, because the {{token|ANIMAL|entity}} token can cause a creature to be treated mechanically as an animal, even when the creature is otherwise sapient.
The relevant distinction is between:
* a creature being part of the civilization's main race;
* a creature being defined as an animal or special animal caste;
* a creature being treated as a pet;
* a creature being used as a mount, puller or hauler.
This can produce a situation in which a creature is biologically or culturally sapient but is mechanically handled as livestock or a domesticated animal.

=War slavery=

Civilizations can enslave defeated enemies and take them back to their settlements. This can be described as spoils-of-war slavery or war enslavement.

The ethics value for slavery also affects whether a civilization is willing to accept caged sapient creatures from merchants.

Higher or lower ethical values appear to have relatively limited mechanical consequences, beyond determining whether the civilization permits slavery at all. The ethical value therefore primarily establishes the civilization's attitude toward the practice rather than providing a detailed slavery simulation.

=Undead servitude=
[[Necromancer|Necromancers]] can raise dead creatures as [[Undead]]. The resulting undead are generally under the control of the necromancer who created them.
This can be interpreted as another form of forced servitude, although the game does not necessarily classify undead as slaves in the same mechanical sense as enslaved historical figures.

=Modding Slavery=
There is no dedicated `SLAVE` creature mechanic in ''Dwarf Fortress''. A [[Modding|mod]] can simulate slavery through the use of [[Entity token#Animal definitions|ANIMAL entity tokens]], and referencing a creature with specific [[creature token]]s such as {{token|PACK_ANIMAL}} and {{token|PET}}. There are three main approaches, all of which rely on the creature in question being explicitly defined per-civlization (entity).
{| class="wikitable"
|+ Modding approaches
|-
! Method !! Description !! Can be embarked with !! Can be traded !! Has slave-population in worldgen !! Can be trained !! Can have labours !! Can have a specific interaction !! Can have specific traits !! Can have a pet value !! Slave can be married to non-slave and have kids || Graphic modding needed
|-
| Existing creature as ANIMAL || Use ANIMAL tokens within an entity to define an existing creature itself. || Yes || Yes || Yes || If non-speaking || If [CAN_LEARN]| No || No || Yes || Yes || No
|-
| Special caste as ANIMAL || Add a special caste to an existing creature and use ANIMAL_CASTE_TOKEN to define it within an entity. || Yes for the special caste, but not the main race || both || No || If non-speaking || If [CAN_LEARN] || Only for the special caste || Only for the special caste ||Yes, both || Yes || Yes
|-
| Creature copy as ANIMAL|| Create a copy of the original creature and define the copy using ANIMAL entity tokens. || Yes for the special creature, but not for the main race || both || Yes || If non-speaking || If [CAN_LEARN] || Only for the special creature || Only for the special creature || Yes, both || No || Yes
|}
* Can be embarked with: creatures can be selected as livestock animals
* Can be traded: can be selected in the trade agreement
* Can have a specific interaction: an interaction specifically for this slave-creature can be defined
* Can have specific traits: tokens as desired can be assigned to the slave-creature.

The choice depends on the desired behaviour. A special caste is useful when the enslaved version should remain closely connected to the original creature — i.e. if dwarves should be able to enslave other dwarves. A separate creature provides more freedom when the enslaved version needs substantially different properties — i.e. if there is a specific "House Elf" creature that is expected to always be enslaved.

==Sapience and Assigning Tasks==
You can assign tasks to a creature with ANIMAL entity tokens if they have the creature tokens {{token|CAN_LEARN}} and {{token|CAN_SPEAK}}.

The CAN_LEARN tag will also mean that the game classes a creature as sapient, which comes with certain limitations on how they can be treated and interacted with. For instance, sapient creatures cannot normally be milked or butchered. Either token will allow a creature to have [[Personality value|values]] and [[Personality goal|goals]].

For a more detailed and philosophical analysis on the topic of sapience, within the context of ''Dwarf Fortress'', see [[Person]].

==How to make them show up==
For creatures that do not naturally spawn, you need {{token|ANIMAL_ALWAYS_PRESENT|entity}}, otherwise, the civ only has them available if they somehow domesticated them. You need {{token|ANIMAL_ALWAYS_PET|entity}} to make them selectable for embark.

==Other notes about [ANIMAL] sapients==
* They can be assigned a (bed)room
* They can be assigned positions like tavern keeper or priest, but never any of the noble positions
* They cannot be assigned a pond or pit and cannot be tied to a rope
* They cannot be assigned to a trainer
* If an ANIMAL-sapient is brought by the merchants, they will come clothed and the merchants will charge extra for the clothing.
* Their thoughts can be viewed in full detail.
* They can be expelled. They do not seem to form any relationships at all.
* If they cannot speak, they are listed as livestock, but cannot be assigned labours, so they can be assigned labours if they are able to speak.
* If they cannot speak, they are trainable
Whether they will petition for citizenship has yet to be verified.
* If you catch a hostile creature in a war, they cannot be pacified. They can, however, be sold to traders.
* If you attack a site that is inhabited by a sapient creature that is defined as an animal by your civilization, you cannot capture them as livestock.

==Example==
A modder who wants dwarves to have an enslaved caste can add a special `SLAVE` caste to the dwarf creature, making use of the appropriate creature tags detailed above. Setting its population ratio to `0` prevents enslaved dwarves from appearing as a separate natural population, while still allowing the caste to be used for individual enslaved dwarves.

For elves or other races, a separate copy of the creature can instead be used as the enslaved version. This provides more control over its properties, but the game treats it as a different creature.

Slavery

2026-10-03T13:34:54Z

Silverwing235:

This article describes slavery only as represented by the game mechanics, world generation and fictional setting of ''Dwarf Fortress''.

=Overview=
Slavery is not a major gameplay mechanic in ''Dwarf Fortress'', but the concept occurs in several parts of the game. [[Legends|Historical]] figures can become enslaved during [[world generation]], and slavery can also occur through several distinct game mechanics.
The game represents several forms of enslavement, including:
* Child enslavement — [[Goblin]] snatchers abduct [[children]], who may subsequently become slaves.
* Forced domestication — Goblins can enslave [[Troll]]s and use them as mounts, haulers or war animals.
* War slavery — [[Civilization]]s can enslave defeated enemies and bring them back to their settlements.
* Undead servitude — [[Undead]] creatures raised by [[necromancer]]s can be regarded as being under the control of their creator.
* Slaves of Armok — The game's subtitle; '''Slaves to Armok: God of Blood Chapter II: Dwarf Fortress''', uses slavery as part of the game's fictional terminology.

=Civilizational attitudes=
Slavery is also represented in the game's ethics system, which determines how different civilizations regard the practice.

Civilizations have different [[Ethic|ethical attitudes]] toward slavery.
{| class="wikitable"
!Civilization!!Attitude toward slavery
|-
|Humans||Acceptable
|-
|Goblins||Personal Matter
|-
|Elves||Opposed; perpetrators may be punished with exile
|-
|Dwarves||Capital punishment (''technically also opposed, but with [[Justice#Punishments|considerably more force]]'')
|}
These attitudes primarily determine how a civilization reacts to slavery as an ethical issue. They should not be confused with the separate mechanics through which slavery actually occurs.

=Slavery in world generation=
During world generation, [[historical figure]]s can become enslaved. In mechanical terms, enslavement is closely related to imprisonment: an enslaved historical figure can potentially escape.

Slavery is unlikely to have a direct impact on the game when playing in [[Adventurer mode|adventure]] or [[Dwarf fortress mode|fortress mode]], where it is most likely to be seen in descriptions of historical events. Specific examples of how slavery is represented or implemented by the game can be seen in:
*A civilizations' ethics.
*The various [[String_dump/raw|strings]] used by the game in [[language]]s, [[speech]] and descriptive texts.
*Two explicit [[unit type token]]s.

Examples of possible references:
* "the end of the former enslavement of"
* "escaped from the slavery of"
* "escaped from the slavery of" / "escaped from the prisons of"
* "was enslaved by" / "was imprisoned by"
* "the enslavement" / "the imprisonment"
* "as a former slave of" / "as a former prisoner of"

=Child enslavement=
Goblins are particularly associated with the abduction of [[children]]. Goblin snatchers can enter settlements and abduct children. Abducted children can become part of the goblin civilization, rather than remaining members of their original civilization.
Children can potentially be recovered through a citizen recovery mission, while adventurers can also encounter and rescue captives through quests.
See:
* [[Thief#Goblin_snatchers|Goblin snatchers]]
* [[Mission|Missions]]
* [[Quest|Quests]]

= Troll enslavement / forced domestication / sentient livestock=
[[Goblin|Goblins]] can also enslave [[Troll|Trolls]]. This is mechanically different from human-style war slavery. The Troll is treated as an animal-like creature under goblin control and can be used for purposes such as:
* carrying loads;
* pulling;
* riding;
* combat.
This creates a distinction between sapient creatures that are treated as animals and ordinary domesticated animals.
This form of enslavement is particularly relevant to modding, because the {{token|ANIMAL|entity}} token can cause a creature to be treated mechanically as an animal, even when the creature is otherwise sapient.
The relevant distinction is between:
* a creature being part of the civilization's main race;
* a creature being defined as an animal or special animal caste;
* a creature being treated as a pet;
* a creature being used as a mount, puller or hauler.
This can produce a situation in which a creature is biologically or culturally sapient but is mechanically handled as livestock or a domesticated animal.

=War slavery=

Civilizations can enslave defeated enemies and take them back to their settlements. This can be described as spoils-of-war slavery or war enslavement.

The ethics value for slavery also affects whether a civilization is willing to accept caged sapient creatures from merchants.

Higher or lower ethical values appear to have relatively limited mechanical consequences, beyond determining whether the civilization permits slavery at all. The ethical value therefore primarily establishes the civilization's attitude toward the practice rather than providing a detailed slavery simulation.

=Undead servitude=
[[Necromancer|Necromancers]] can raise dead creatures as [[Undead]]. The resulting undead are generally under the control of the necromancer who created them.
This can be interpreted as another form of forced servitude, although the game does not necessarily classify undead as slaves in the same mechanical sense as enslaved historical figures.

=Modding Slavery=
There is no dedicated `SLAVE` creature mechanic in ''Dwarf Fortress''. A [[Modding|mod]] can simulate slavery through the use of [[Entity token#Animal definitions|ANIMAL entity tokens]], and referencing a creature with specific [[creature token]]s such as {{token|PACK_ANIMAL}} and {{token|PET}}. There are three main approaches, all of which rely on the creature in question being explicitly defined per-civlization (entity).
{| class="wikitable"
|+ Modding approaches
|-
! Method !! Description !! Can be embarked with !! Can be traded !! Has slave-population in worldgen !! Can be trained !! Can have labours !! Can have a specific interaction !! Can have specific traits !! Can have a pet value !! Slave can be married to non-slave and have kids || Graphic modding needed
|-
| Existing creature as ANIMAL || Use ANIMAL tokens within an entity to define an existing creature itself. || yes || yes || yes || If non-speaking || If [CAN_LEARN]| No || No || yes || yes || no
|-
| Special caste as ANIMAL || Add a special caste to an existing creature and use ANIMAL_CASTE_TOKEN to define it within an entity. || Yes for the special caste, but not the main race || both || No || If non-speaking || If can_learn || Only for the special caste || Only for the special caste ||Yes, both || yes || yes
|-
| Creature copy as ANIMAL|| Create a copy of the original creature and define the copy using ANIMAL entity tokens. || Yes for the special creature, but not for the main race || both || Yes || If non-speaking || If can_learn || Only for the special creature || Only for the special creature || Yes, both || no || yes
|}
* Can be embarked with: creatures can be selected as livestock animals
* Can be traded: can be selected in the trade agreement
* Can have a specific interaction: an interaction specific for this slave-creature can be defined
* Can have specific traits: tokens as desired can be assigned to the slave-creature.

The choice depends on the desired behaviour. A special caste is useful when the enslaved version should remain closely connected to the original creature — i.e. if Dwarves should be able to enslave other Dwarves. A separate creature provides more freedom when the enslaved version needs substantially different properties — i.e. if there is a specific "House Elf" creature that is expected to always be enslaved.

==Sapience and Assigning Tasks==
You can assign tasks to a creature with ANIMAL entity tokens if they have the creature tokens {{token|CAN_LEARN}} and {{token|CAN_SPEAK}}.

The CAN_LEARN tag will also mean that the game classes a creature as sapient, which comes with certain limitations on how they can be treated and interacted with. For instance, sapient creatures cannot normally be milked or butchered. Either token will allow a creature to have [[Personality value|values]] and [[Personality goal|goals]].

For a more detailed and philosophical analysis on the topic of sapience, within the context of ''Dwarf Fortress'', see [[Person]].

==How to make them show up==
For creatures that do not naturally spawn, you need {{token|ANIMAL_ALWAYS_PRESENT|entity}}, otherwise, the civ only has them available if they somehow domesticated them. You need {{token|ANIMAL_ALWAYS_PET|entity}} to make them selectable for embark.

==Other notes about [ANIMAL] sapients==
* They can be assigned a (bed)room
* They can be assigned positions like tavern keeper or priest, but never any of the noble positions
* They cannot be assigned a pond or pit and cannot be tied to a rope
* They cannot be assigned to a trainer
* If an ANIMAL-sapient is brought by the merchants, they will come clothed and the merchants will charge extra for the clothing.
* Their thoughts can be viewed in full detail.
* They can be expelled. They do not seem to form any relationships at all.
* If they cannot speak, they are listed as livestock, but cannot be assigned labours, so they can be assigned labours if they are able to speak.
* If they cannot speak, they are trainable
Whether they will petition for citizenship has yet to be verified.
* If you catch a hostile creature in a war, they cannot be pacified. They can, however, be sold to traders.
* If you attack a site that is inhabited by a sapient creature that is defined as an animal by your civilization, you cannot capture them as livestock.

==Example==
A modder who wants dwarves to have an enslaved caste can add a special `SLAVE` caste to the dwarf creature, making use of the appropriate creature tags detailed above. Setting its population ratio to `0` prevents enslaved dwarves from appearing as a separate natural population, while still allowing the caste to be used for individual enslaved dwarves.

For elves or other races, a separate copy of the creature can instead be used as the enslaved version. This provides more control over its properties, but the game treats it as a different creature.

Slavery

2026-10-03T11:30:11Z

Silverwing235: silly grammar by OPC's mother tongue, for some reason - program vs programmer? Nevertheless, fix.

This article describes slavery only as represented by the game mechanics, world generation and fictional setting of ''Dwarf Fortress''.

=Overview=
Slavery is not a major gameplay mechanic in ''Dwarf Fortress'', but the concept occurs in several parts of the game. [[Legends|Historical]] figures can become enslaved during [[world generation]], and slavery can also occur through several distinct game mechanics.
The game represents several forms of enslavement, including:
* Child enslavement — [[Goblin]] snatchers abduct [[children]], who may subsequently become slaves.
* Forced domestication — Goblins can enslave [[Troll]]s and use them as mounts, haulers or war animals.
* War slavery — [[Civilization]]s can enslave defeated enemies and bring them back to their settlements.
* Undead servitude — [[Undead]] creatures raised by [[necromancer]]s can be regarded as being under the control of their creator.
* Slaves of Armok — The game's subtitle; '''Slaves to Armok: God of Blood Chapter II: Dwarf Fortress''', uses slavery as part of the game's fictional terminology.

=Civilizational attitudes=
Slavery is also represented in the game's ethics system, which determines how different civilizations regard the practice.

Civilizations have different [[Ethic|ethical attitudes]] toward slavery.
{| class="wikitable"
!Civilization!!Attitude toward slavery
|-
|Humans||Acceptable
|-
|Goblins||Personal Matter
|-
|Elves||Opposed; perpetrators may be punished with exile
|-
|Dwarves||Capital punishment (''technically also opposed, but with [[Justice#Punishments|considerably more force]]'')
|}
These attitudes primarily determine how a civilization reacts to slavery as an ethical issue. They should not be confused with the separate mechanics through which slavery actually occurs.

=Slavery in world generation=
During world generation, [[historical figure]]s can become enslaved. In mechanical terms, enslavement is closely related to imprisonment: an enslaved historical figure can potentially escape.

Slavery is unlikely to have a direct impact on the game when playing in [[Adventurer mode|adventure]] or [[Dwarf fortress mode|fortress mode]], where it is most likely to be seen in descriptions of historical events. Specific examples of how slavery is represented or implemented by the game can be seen in:
*A civilizations' ethics.
*The various [[String_dump/raw|strings]] used by the game in [[language]]s, [[speech]] and descriptive texts.
*Two explicit [[unit type token]]s.

Examples of possible references:
* "the end of the former enslavement of"
* "escaped from the slavery of"
* "escaped from the slavery of" / "escaped from the prisons of"
* "was enslaved by" / "was imprisoned by"
* "the enslavement" / "the imprisonment"
* "as a former slave of" / "as a former prisoner of"

=Child enslavement=
Goblins are particularly associated with the abduction of [[children]]. Goblin snatchers can enter settlements and abduct children. Abducted children can become part of the goblin civilization, rather than remaining members of their original civilization.
Children can potentially be recovered through a citizen recovery mission, while adventurers can also encounter and rescue captives through quests.
See:
* [[Thief#Goblin_snatchers|Goblin snatchers]]
* [[Mission|Missions]]
* [[Quest|Quests]]

= Troll enslavement / forced domestication / sentient livestock=
[[Goblin|Goblins]] can also enslave [[Troll|Trolls]]. This is mechanically different from human-style war slavery. The Troll is treated as an animal-like creature under goblin control and can be used for purposes such as:
* carrying loads;
* pulling;
* riding;
* combat.
This creates a distinction between sapient creatures that are treated as animals and ordinary domesticated animals.
This form of enslavement is particularly relevant to modding, because the {{token|ANIMAL|entity}} token can cause a creature to be treated mechanically as an animal, even when the creature is otherwise sapient.
The relevant distinction is between:
* a creature being part of the civilization's main race;
* a creature being defined as an animal or special animal caste;
* a creature being treated as a pet;
* a creature being used as a mount, puller or hauler.
This can produce a situation in which a creature is biologically or culturally sapient but is mechanically handled as livestock or a domesticated animal.

=War slavery=

Civilizations can enslave defeated enemies and take them back to their settlements. This can be described as spoils-of-war slavery or war enslavement.

The ethics value for slavery also affects whether a civilization is willing to accept caged sapient creatures from merchants.

Higher or lower ethical values appear to have relatively limited mechanical consequences, beyond determining whether the civilization permits slavery at all. The ethical value therefore primarily establishes the civilization's attitude toward the practice rather than providing a detailed slavery simulation.

=Undead servitude=
[[Necromancer|Necromancers]] can raise dead creatures as [[Undead]]. The resulting undead are generally under the control of the necromancer who created them.
This can be interpreted as another form of forced servitude, although the game does not necessarily classify undead as slaves in the same mechanical sense as enslaved historical figures.

=Modding Slavery=
There is no dedicated `SLAVE` creature mechanic in ''Dwarf Fortress''. A [[Modding|mod]] can simulate slavery through the use of [[Entity token#Animal definitions|ANIMAL entity tokens]], and referencing a creature with specific [[creature token]]s such as {{token|PACK_ANIMAL}} and {{token|PET}}. There are three main approaches, all of which rely on the creature in question being explicitly defined per-civlization (entity).
{| class="wikitable"
|+ Modding approaches
|-
! Method !! Description !! Can be embarked with !! Can be traded !! Has slave-population in worldgen !! Can be trained !! Can have labours !! Can have a specific interaction !! Can have specific traits !! Can have a pet value !! Slave can be married to non-slave and have kids || Graphic modding needed
|-
| Existing creature as ANIMAL || Use ANIMAL tokens within an entity to define an existing creature itself. || yes || yes || yes || If non-speaking || If [CAN_LEARN]| No || No || yes || yes || no
|-
| Special caste as ANIMAL || Add a special caste to an existing creature and use ANIMAL_CASTE_TOKEN to define it within an entity. || Yes for the special caste, but not the main race || both || No || If non-speaking || If can_learn || Only for the special caste || Only for the special caste ||Yes, both || yes || yes
|-
| Creature copy as ANIMAL|| Create a copy of the original creature and define the copy using ANIMAL entity tokens. || Yes for the special creature, but not for the main race || both || Yes || If non-speaking || If can_learn || Only for the special creature || Only for the special creature || Yes, both || no || yes
|}
* Can be embarked with: creatures can be selected as livestock animals
* Can be traded: can be selected in the trade agreement
* Can have a specific interaction: an interaction specific for this slave-creature can be defined
* Can have specific traits: tokens as desired can be assigned to the slave-creature.

The choice depends on the desired behaviour. A special caste is useful when the enslaved version should remain closely connected to the original creature — i.e. if Dwarves should be able to enslave other Dwarves. A separate creature provides more freedom when the enslaved version needs substantially different properties — i.e. if there is a specific "House Elf" creature that is expected to always be enslaved.

==Sapience and Assigning tasks==
You can assign tasks to a creature with ANIMAL entity tokens if they have the creature tokens {{token|CAN_LEARN}} and {{token|CAN_SPEAK}}.

The CAN_LEARN tag will also mean that the game classes a creature as sapient, which comes with certain limitations on how they can be treated and interacted with. For instance, sapient creatures cannot normally be milked or butchered. Either token will allow a creature to have [[Personality value|values]] and [[Personality goal|goals]].

For a more detailed and philosophical analysis on the topic of sapience, within the context of ''Dwarf Fortress'', see [[Person]].

==How to make them show up==
For creatures that do not naturally spawn, you need {{token|ANIMAL_ALWAYS_PRESENT|entity}}, otherwise, the civ only has them available if they somehow domesticated them. You need {{token|ANIMAL_ALWAYS_PET|entity}} to make them selectable for embark.

==Other notes about [ANIMAL] sapients==
* They can be assigned a (bed)room
* They can be assigned positions like tavern keeper or priest, but never any of the noble positions
* They cannot be assigned a pond or pit and cannot be tied to a rope
* They cannot be assigned to a trainer
* If an ANIMAL-sapient is brought by the merchants, they will come clothed and the merchants will charge extra for the clothing.
* Their thoughts can be viewed in full detail.
* They can be expelled. They do not seem to form any relationships at all.
* If they cannot speak, they are listed as livestock, but cannot be assigned labours, so they can be assigned labours if they are able to speak.
* If they cannot speak, they are trainable
Whether they will petition for citizenship has yet to be verified.
* If you catch a hostile creature in a war, they cannot be pacified. They can, however, be sold to traders.
* If you attack a site that is inhabited by a sapient creature that is defined as an animal by your civilization, you cannot capture them as livestock.

==Example==
A modder who wants dwarves to have an enslaved caste can add a special `SLAVE` caste to the dwarf creature, making use of the appropriate creature tags detailed above. Setting its population ratio to `0` prevents enslaved dwarves from appearing as a separate natural population, while still allowing the caste to be used for individual enslaved dwarves.

For elves or other races, a separate copy of the creature can instead be used as the enslaved version. This provides more control over its properties, but the game treats it as a different creature.

Slavery

2026-10-03T10:59:26Z

Silverwing235: /* Child enslavement */ organize

This article describes slavery only as represented by the game mechanics, world generation and fictional setting of ''Dwarf Fortress''.

=Overview=
Slavery is not a major gameplay mechanic in ''Dwarf Fortress'', but the concept occurs in several parts of the game. [[Legends|Historical]] figures can become enslaved during [[world generation]], and slavery can also occur through several distinct game mechanics.
The game represents several forms of enslavement, including:
* Child enslavement — [[Goblin]] snatchers abduct [[children]], who may subsequently become slaves.
* Forced domestication — Goblins can enslave [[Troll]]s and use them as mounts, haulers or war animals.
* War slavery — [[Civilization]]s can enslave defeated enemies and bring them back to their settlements.
* Undead servitude — [[Undead]] creatures raised by [[necromancer]]s can be regarded as being under the control of their creator.
* Slaves of Armok — The game's subtitle; '''Slaves to Armok: God of Blood Chapter II: Dwarf Fortress''', uses slavery as part of the game's fictional terminology.

=Civilizational attitudes=
Slavery is also represented in the game's ethics system, which determines how different civilizations regard the practice.

Civilizations have different [[Ethic|ethical attitudes]] toward slavery.
{| class="wikitable"
!Civilization!!Attitude toward slavery
|-
|Humans||Acceptable
|-
|Goblins||Personal Matter
|-
|Elves||Opposed; perpetrators may be punished with exile
|-
|Dwarves||Capital punishment (''technically also opposed, but with [[Justice#Punishments|considerably more force]]'')
|}
These attitudes primarily determine how a civilization reacts to slavery as an ethical issue. They should not be confused with the separate mechanics through which slavery actually occurs.

=Slavery in world generation=
During world generation, [[historical figure]]s can become enslaved. In mechanical terms, enslavement is closely related to imprisonment: an enslaved historical figure can potentially escape.

Slavery is unlikely to have a direct impact on the game when playing in [[Adventurer mode|adventure]] or [[Dwarf fortress mode|fortress mode]], where it is most likely to be seen in descriptions of historical events. Specific examples of how slavery is represented or implemented by the game can be seen in:
*A civilizations' ethics.
*The various [[String_dump/raw|strings]] used by the game in [[language]]s, [[speech]] and descriptive texts.
*Two explicit [[unit type token]]s.

Examples of possible references:
* "the end of the former enslavement of"
* "escaped from the slavery of"
* "escaped from the slavery of" / "escaped from the prisons of"
* "was enslaved by" / "was imprisoned by"
* "the enslavement" / "the imprisonment"
* "as a former slave of" / "as a former prisoner of"

=Child enslavement=
Goblins are particularly associated with the abduction of [[children]]. Goblin snatchers can enter settlements and abduct children. Abducted children can become part of the goblin civilization, rather than remaining members of their original civilization.
Children can potentially be recovered through a citizen recovery mission, while adventurers can also encounter and rescue captives through quests.
See:
* [[Thief#Goblin_snatchers|Goblin snatchers]]
* [[Mission|Missions]]
* [[Quest|Quests]]

= Troll enslavement / forced domestication / sentient livestock=
[[Goblin|Goblins]] can also enslave [[Troll|Trolls]]. This is mechanically different from human-style war slavery. The Troll is treated as an animal-like creature under goblin control and can be used for purposes such as:
* carrying loads;
* pulling;
* riding;
* combat.
This creates a distinction between sapient creatures that are treated as animals and ordinary domesticated animals.
This form of enslavement is particularly relevant to modding, because the {{token|ANIMAL|entity}} token can cause a creature to be treated mechanically as an animal, even when the creature is otherwise sapient.
The relevant distinction is between:
* a creature being part of the civilization's main race;
* a creature being defined as an animal or special animal caste;
* a creature being treated as a pet;
* a creature being used as a mount, puller or hauler.
This can produce a situation in which a creature is biologically or culturally sapient but is mechanically handled as livestock or a domesticated animal.

=War slavery=

Civilizations can enslave defeated enemies and take them back to their settlements. This can be described as spoils-of-war slavery or war enslavement.

The ethics value for slavery also affects whether a civilization is willing to accept caged sapient creatures from merchants.

Higher or lower ethical values appear to have relatively limited mechanical consequences, beyond determining whether the civilization permits slavery at all. The ethical value therefore primarily establishes the civilization's attitude toward the practice rather than providing a detailed slavery simulation.

=Undead servitude=
[[Necromancer|Necromancers]] can raise dead creatures as [[Undead]]. The resulting undead are generally under the control of the necromancer who created them.
This can be interpreted as another form of forced servitude, although the game does not necessarily classify undead as slaves in the same mechanical sense as enslaved historical figures.

=Modding Slavery=
There is no dedicated `SLAVE` creature mechanic in ''Dwarf Fortress''. A [[Modding|mod]] can simulate slavery through the use of [[Entity token#Animal definitions|ANIMAL entity tokens]], and referencing a creature with specific [[creature token]]s such as {{token|PACK_ANIMAL}} and {{token|PET}}. There are three main approaches, all of which rely on the creature in question being explicitly defined per-civlization (entity).
{| class="wikitable"
|+ Modding approaches
|-
! Method !! Description !! Can be embarked with !! Can be traded !! Has slave-population in world-gen !! Can be trained !! Can have labours !! Can have a specific interaction !! Can have specific traits !! Can have a pet-value !! Slave can be married to non slave and have kids || Graphic modding needed
|-
| Existing creature as ANIMAL || Use ANIMAL tokens within an entity to define an existing creature itself. || yes || yes || yes || If non-speaking || If [CAN_LEARN]| No || No || yes || yes || no
|-
| Special caste as ANIMAL || Add a special caste to an existing creature and use ANIMAL_CASTE_TOKEN to define it within an entity. || Yes for the special caste, but not the main race || both || No || If non-speaking || If can_learn || Only for the special caste || Only for the special caste ||Yes, both || yes || yes
|-
| Creature copy as ANIMAL|| Create a copy of the original creature and define the copy using ANIMAL entity tokens. || Yes for the special creature, but not for the main race || both || Yes || If non-speaking || If can_learn || Only for the special creature || Only for the special creature || Yes, both || no || yes
|}
* Can be embarked with: creatures can be selected as livestock animals
* Can be traded: can be selected in the trade agreement
* Can have a specific interaction: an interaction specific for this slave-creature can be defined
* Can have specific traits: tokens as desired can be assigned to the slave-creature.

The choice depends on the desired behaviour. A special caste is useful when the enslaved version should remain closely connected to the original creature — i.e. if Dwarves should be able to enslave other Dwarves. A separate creature provides more freedom when the enslaved version needs substantially different properties — i.e. if there is a specific "House Elf" creature that is expected to always be enslaved.

==Sapience and Assigning tasks==
You can assign tasks to a creature with ANIMAL entity tokens if they have the creature tokens {{token|CAN_LEARN}} and {{token|CAN_SPEAK}}.

The CAN_LEARN tag will also mean that the game classes a creature as sapient, which comes with certain limitations on how they can be treated and interacted with. For instance, sapient creatures cannot normally be milked or butchered. Either token will allow a creature to have [[Personality value|values]] and [[Personality goal|goals]].

For a more detailed and philosophical analysis on the topic of sapience, within the context of ''Dwarf Fortress'', see [[Person]].

==How to make them show up==
For creatures that do not naturally spawn, you need {{token|ANIMAL_ALWAYS_PRESENT|entity}}, otherwise, the civ only has them available if they somehow domesticated them. You need {{token|ANIMAL_ALWAYS_PET|entity}} to make them selectable for embark.

==Other notes about [ANIMAL] sapients==
* They can be assigned a (bed)room
* They can be assigned positions like tavern keeper or priest, but never any of the noble positions
* They cannot be assigned a pond or pit and cannot be tied to a rope
* They cannot be assigned to a trainer
* If an ANIMAL-sapient is brought by the merchants, they will come clothed and the merchants will charge extra for the clothing.
* Their thoughts can be viewed in full detail.
* They can be expelled. They do not seem to form any relationships at all.
* If they cannot speak, they are listed as livestock, but cannot be assigned labours, so they can be assigned labours if they are able to speak.
* If they cannot speak, they are trainable
Whether they will petition for citizenship has yet to be verified.
* If you catch a hostile creature in a war, they cannot be pacified. They can, however, be sold to traders.
* If you attack a site that is inhabited by a sapient creature that is defined as an animal by your civilization, you cannot capture them as livestock.

==Example==
A mod that wants dwarves to have an enslaved caste can add a special `SLAVE` caste to the dwarf creature, making use of the appropriate creature tags detailed above. Setting its population ratio to `0` prevents enslaved dwarves from appearing as a separate natural population, while still allowing the caste to be used for individual enslaved dwarves.

For elves or other races, a separate copy of the creature can instead be used as the enslaved version. This provides more control over its properties, but the game treats it as a different creature.

Slavery

2026-10-03T10:52:07Z

Silverwing235: /* Slavery in world generation */ this would seem to have been OPC's (original page creator's) intended link

This article describes slavery only as represented by the game mechanics, world generation and fictional setting of ''Dwarf Fortress''.

=Overview=
Slavery is not a major gameplay mechanic in ''Dwarf Fortress'', but the concept occurs in several parts of the game. [[Legends|Historical]] figures can become enslaved during [[world generation]], and slavery can also occur through several distinct game mechanics.
The game represents several forms of enslavement, including:
* Child enslavement — [[Goblin]] snatchers abduct [[children]], who may subsequently become slaves.
* Forced domestication — Goblins can enslave [[Troll]]s and use them as mounts, haulers or war animals.
* War slavery — [[Civilization]]s can enslave defeated enemies and bring them back to their settlements.
* Undead servitude — [[Undead]] creatures raised by [[necromancer]]s can be regarded as being under the control of their creator.
* Slaves of Armok — The game's subtitle; '''Slaves to Armok: God of Blood Chapter II: Dwarf Fortress''', uses slavery as part of the game's fictional terminology.

=Civilizational attitudes=
Slavery is also represented in the game's ethics system, which determines how different civilizations regard the practice.

Civilizations have different [[Ethic|ethical attitudes]] toward slavery.
{| class="wikitable"
!Civilization!!Attitude toward slavery
|-
|Humans||Acceptable
|-
|Goblins||Personal Matter
|-
|Elves||Opposed; perpetrators may be punished with exile
|-
|Dwarves||Capital punishment (''technically also opposed, but with [[Justice#Punishments|considerably more force]]'')
|}
These attitudes primarily determine how a civilization reacts to slavery as an ethical issue. They should not be confused with the separate mechanics through which slavery actually occurs.

=Slavery in world generation=
During world generation, [[historical figure]]s can become enslaved. In mechanical terms, enslavement is closely related to imprisonment: an enslaved historical figure can potentially escape.

Slavery is unlikely to have a direct impact on the game when playing in [[Adventurer mode|adventure]] or [[Dwarf fortress mode|fortress mode]], where it is most likely to be seen in descriptions of historical events. Specific examples of how slavery is represented or implemented by the game can be seen in:
*A civilizations' ethics.
*The various [[String_dump/raw|strings]] used by the game in [[language]]s, [[speech]] and descriptive texts.
*Two explicit [[unit type token]]s.

Examples of possible references:
* "the end of the former enslavement of"
* "escaped from the slavery of"
* "escaped from the slavery of" / "escaped from the prisons of"
* "was enslaved by" / "was imprisoned by"
* "the enslavement" / "the imprisonment"
* "as a former slave of" / "as a former prisoner of"

=Child enslavement=
Goblins are particularly associated with the abduction of [[children]]. Goblin snatchers can enter settlements and abduct children.
See: [[Thief#Goblin_snatchers|Goblin snatchers]]

Abducted children can become part of the goblin civilization rather than remaining members of their original civilization.

Children can potentially be recovered through a citizen recovery mission. Adventurers can also encounter and rescue captives through quests.
See:
* [[Mission|Missions]]
* [[Quest|Quests]]

= Troll enslavement / forced domestication / sentient livestock=
[[Goblin|Goblins]] can also enslave [[Troll|Trolls]]. This is mechanically different from human-style war slavery. The Troll is treated as an animal-like creature under goblin control and can be used for purposes such as:
* carrying loads;
* pulling;
* riding;
* combat.
This creates a distinction between sapient creatures that are treated as animals and ordinary domesticated animals.
This form of enslavement is particularly relevant to modding, because the {{token|ANIMAL|entity}} token can cause a creature to be treated mechanically as an animal, even when the creature is otherwise sapient.
The relevant distinction is between:
* a creature being part of the civilization's main race;
* a creature being defined as an animal or special animal caste;
* a creature being treated as a pet;
* a creature being used as a mount, puller or hauler.
This can produce a situation in which a creature is biologically or culturally sapient but is mechanically handled as livestock or a domesticated animal.

=War slavery=

Civilizations can enslave defeated enemies and take them back to their settlements. This can be described as spoils-of-war slavery or war enslavement.

The ethics value for slavery also affects whether a civilization is willing to accept caged sapient creatures from merchants.

Higher or lower ethical values appear to have relatively limited mechanical consequences, beyond determining whether the civilization permits slavery at all. The ethical value therefore primarily establishes the civilization's attitude toward the practice rather than providing a detailed slavery simulation.

=Undead servitude=
[[Necromancer|Necromancers]] can raise dead creatures as [[Undead]]. The resulting undead are generally under the control of the necromancer who created them.
This can be interpreted as another form of forced servitude, although the game does not necessarily classify undead as slaves in the same mechanical sense as enslaved historical figures.

=Modding Slavery=
There is no dedicated `SLAVE` creature mechanic in ''Dwarf Fortress''. A [[Modding|mod]] can simulate slavery through the use of [[Entity token#Animal definitions|ANIMAL entity tokens]], and referencing a creature with specific [[creature token]]s such as {{token|PACK_ANIMAL}} and {{token|PET}}. There are three main approaches, all of which rely on the creature in question being explicitly defined per-civlization (entity).
{| class="wikitable"
|+ Modding approaches
|-
! Method !! Description !! Can be embarked with !! Can be traded !! Has slave-population in world-gen !! Can be trained !! Can have labours !! Can have a specific interaction !! Can have specific traits !! Can have a pet-value !! Slave can be married to non slave and have kids || Graphic modding needed
|-
| Existing creature as ANIMAL || Use ANIMAL tokens within an entity to define an existing creature itself. || yes || yes || yes || If non-speaking || If [CAN_LEARN]| No || No || yes || yes || no
|-
| Special caste as ANIMAL || Add a special caste to an existing creature and use ANIMAL_CASTE_TOKEN to define it within an entity. || Yes for the special caste, but not the main race || both || No || If non-speaking || If can_learn || Only for the special caste || Only for the special caste ||Yes, both || yes || yes
|-
| Creature copy as ANIMAL|| Create a copy of the original creature and define the copy using ANIMAL entity tokens. || Yes for the special creature, but not for the main race || both || Yes || If non-speaking || If can_learn || Only for the special creature || Only for the special creature || Yes, both || no || yes
|}
* Can be embarked with: creatures can be selected as livestock animals
* Can be traded: can be selected in the trade agreement
* Can have a specific interaction: an interaction specific for this slave-creature can be defined
* Can have specific traits: tokens as desired can be assigned to the slave-creature.

The choice depends on the desired behaviour. A special caste is useful when the enslaved version should remain closely connected to the original creature — i.e. if Dwarves should be able to enslave other Dwarves. A separate creature provides more freedom when the enslaved version needs substantially different properties — i.e. if there is a specific "House Elf" creature that is expected to always be enslaved.

==Sapience and Assigning tasks==
You can assign tasks to a creature with ANIMAL entity tokens if they have the creature tokens {{token|CAN_LEARN}} and {{token|CAN_SPEAK}}.

The CAN_LEARN tag will also mean that the game classes a creature as sapient, which comes with certain limitations on how they can be treated and interacted with. For instance, sapient creatures cannot normally be milked or butchered. Either token will allow a creature to have [[Personality value|values]] and [[Personality goal|goals]].

For a more detailed and philosophical analysis on the topic of sapience, within the context of ''Dwarf Fortress'', see [[Person]].

==How to make them show up==
For creatures that do not naturally spawn, you need {{token|ANIMAL_ALWAYS_PRESENT|entity}}, otherwise, the civ only has them available if they somehow domesticated them. You need {{token|ANIMAL_ALWAYS_PET|entity}} to make them selectable for embark.

==Other notes about [ANIMAL] sapients==
* They can be assigned a (bed)room
* They can be assigned positions like tavern keeper or priest, but never any of the noble positions
* They cannot be assigned a pond or pit and cannot be tied to a rope
* They cannot be assigned to a trainer
* If an ANIMAL-sapient is brought by the merchants, they will come clothed and the merchants will charge extra for the clothing.
* Their thoughts can be viewed in full detail.
* They can be expelled. They do not seem to form any relationships at all.
* If they cannot speak, they are listed as livestock, but cannot be assigned labours, so they can be assigned labours if they are able to speak.
* If they cannot speak, they are trainable
Whether they will petition for citizenship has yet to be verified.
* If you catch a hostile creature in a war, they cannot be pacified. They can, however, be sold to traders.
* If you attack a site that is inhabited by a sapient creature that is defined as an animal by your civilization, you cannot capture them as livestock.

==Example==
A mod that wants dwarves to have an enslaved caste can add a special `SLAVE` caste to the dwarf creature, making use of the appropriate creature tags detailed above. Setting its population ratio to `0` prevents enslaved dwarves from appearing as a separate natural population, while still allowing the caste to be used for individual enslaved dwarves.

For elves or other races, a separate copy of the creature can instead be used as the enslaved version. This provides more control over its properties, but the game treats it as a different creature.

Justice

2026-10-03T10:39:49Z

Silverwing235: /* Punishments */ fix an unfortunate case of unserious writing, in context

{{Quality|Exceptional}}
{{av}}
[[File:dwarf_justice.png|thumb|When you forget the Baron's demands for 3 flutes. ''Art by MK01'']]

The '''justice''' system is present to punish criminals. Justice is administered by a [[sheriff]] or [[captain of the guard]], and is used to deal with criminal acts committed in the fortress by citizens or [[visitor]]s; for example, dwarves disobeying their betters, breaking furniture, starting fights, etc.

== Screen ==
[[File:Opening Justice Menu.png|thumb|Click scales icon or press j on the keyboard.]]
To get to the justice screen, click the Justice menu button or press {{k|j}}
=== Open cases tab ===
The Open cases tab has a list of the open cases on the left from oldest to most recent. On the right, details about the selected case are provided, including the injured party (if applicable), the case status ({{DFtext|Unsolved.|3:1}}), and the witnesses who reported the crime. There are two buttons which allow the player to [[Justice#Interrogation|interrogate]] or [[Justice#Punishments|convict]] a creature.

=== Closed cases tab ===
The Closed cases tab, similarly to the open cases tab, has a list of the closed cases on the left from oldest to most recent, with details on the right. However, there are no buttons, and the case status is described as {{DFtext|Convicted: Urist McDidntMakeFlutes, Craftsdwarf.|5:1}}

=== Cold cases tab ===
The Cold cases tab is the same as the open cases tab, but only includes cases older than one year.

=== Fortress guard tab ===
The Fortress guard tab contains information on the [[fortress guard]] if it exists. At the top is shown the total number of combined [[Cage|cages]] plus [[Restraint|restraints]] in the [[dungeon]] out of the number requested by the fortress guard (approximately one tenth the population). Note that [[Chain|chains]] includes both ropes and chains.

The rest of the tab is a list of members of the fortress guard, including the cases assigned to each member.

=== Convicts tab ===
The Convicts tab consists of a list on the left of everybody who has been convicted of a crime. On the right, pending sentence(s) for the selected creature are displayed, along with all the crimes they have ever been convicted of.

=== Intelligence tab ===
The Intelligence tab shows information gathered about hostile [[Intrigue|plots]] via [[Justice#Interrogation|interrogation]].

== Crimes ==
[[File:Justice screen.png|thumb|In-game screenshot]]

* '''Violation of Production Order''' - failing to produce items [[mandate]]d by a [[noble]].
* '''Violation of Export Prohibition''' - selling items to a caravan which a [[noble]] forbade the export of.
* '''Violation of Job Order''' - failing to complete [[guild]] jobs [[mandate]]d by the [[mayor]]
* '''Conspiracy to Slow Labor''' - deliberately slowing down the workflow of the fortress by delaying jobs (currently does not happen)
* '''Murder''' - killing a fellow dwarf or tame [[animal]]; alternatively, being caught [[vampire|sucking blood]] out of another dwarf.
* '''Disorderly Conduct''' - attacking another dwarf during a [[tantrum]].
* '''Building destruction''' -- destroying a [[building]] during a [[tantrum]].
* '''Vandalism''' - toppling [[furniture]] during a [[tantrum]].
* '''Theft''' - a dwarf stole an [[artifact]].
* '''Robbery''' - ''(exact deed is unknown)''
* '''Blood-drinking''' - being caught sucking blood out of another dwarf. not in use
* '''Embezzlement''' - ''(exact deed is unknown)''
* '''Attempted murder''' - ''(exact deed is unknown)''
* '''Kidnapping''' - ''(exact deed is unknown)''
* '''Attempted kidnapping''' - ''(exact deed is unknown)''
* '''Attempted theft''' - ''(exact deed is unknown)''
* '''Treason''' - ''(exact deed is unknown)''
* '''Espionage''' - an [[agent]] infiltrated your fortress as a [[visitor]], as part of a larger plot (for example, to steal an [[artifact]], or to corrupt a [[noble]]).
* '''Bribery''' - ''(exact deed is unknown)''

If a [[vampire]] is caught feeding on another dwarf, even if the victim survives, it is still considered a murder. The vampire will typically make a false report, to try to frame another dwarf. Witnesses will also sometimes make false reports to try and frame dwarves they have [[grudge]]s against.

In some cases, the player has to convict a criminal or suspect, in others, criminals are convicted without player input. In case of mandate infractions, the player is generally not asked for input, while murderers must be convicted by the player. Practically anybody can be blamed for a murder, including tame animals and long-dead persons. However, the populace will feel [[Thought#Justice|affronted]] at particularly nonsensical convictions.

"Violating an export ban" happens when a banned item is sold to a merchant and a merchant leaves the map with it. In this case, the criminal is NOT the trader who authorized the sale, but the hapless hauler who brought the good to the trade depot. It can happen when a noble decides to ban an export '''after''' you've already traded away a relevant item. Yeah, that's lame, but one way to mitigate it is to not perform trades unless there is an active mandate, and then obey it. You'll have a lower risk of the noble making a NEW mandate between the time that the merchants arrive and depart if one is already in place. If you've sold an item that subsequently becomes banned, but the merchants haven't left yet, you can also eat your pride and pay to buy it back.

If your dwarves start throwing [[tantrum]]s, then you'll see the harsher crimes, as they let off steam by throwing items around, breaking furniture, toppling doors, and punching fellow dwarves who are just trying to clean up the mess - instead of punches, sometimes, they may use the weapons they're carrying. Suddenly, keeping those axe lords happy seems a bit more high priority, eh?

Dwarves and others are also variously tempted by e.g. the opportunity to embezzle or accept bribes using the power of their positions. If their personality and values aren't up to the challenge, they may eventually fall to temptation and undertake corrupt activities in an ongoing fashion, which will make them a target for both law enforcement and blackmail.

== Interrogation ==
[[File:Investigation.png|thumb|Crime investigation at work. Do note that you might not be able to interview the deceased.]]

Dwarves and friendly visitors can also be interrogated as the suspects of crimes, in which case they are escorted by the Captain of the Guard to their office and questioned. If the interrogation is successful (which is determined by the Captain's various [[Social_skill|social skills]] against the target's) the target will confess what they know, whether that is a crime they themselves have committed or their membership of a particular scheming or other villainous organisation, and possibly the names of other members of said organisations; the results are detailed in a [[report]] and the target is listed in the Actors tab of the justice menu.
Interrogating an innocent dwarf does not have any negative effects, so if you're unsure of a culprit, you could interrogate the entire fort without any repercussions other than lost work time.

You can (and probably should) investigate all new arrivals (immigrants and visitors), as some of them may be there to commit a crime (espionage, theft, etc) or may be under a false name that is guilty of another crime. To do so, there needs to be at least one Open case in the Justice > Open cases menu. You can click "Interrogate" and then scroll down to the target of investigation. This may result in newly reported crimes in the Open cases tab, and it will result in new data in the Intelligence tab.

== Punishments ==
Dwarves who commit crimes can receive punishments if a [[sheriff]] has been assigned.

In increasing order of severity (at least, that's what the dwarves think):
# Beating by a [[fortress guard]] (more dangerous than it sounds, see below)
# Imprisonment for a period of time.
# Hammering by the [[Hammerer]].

The punishment for a crime, or series of crimes, will be issued by the [[sheriff]], or by a member of the [[fortress guard]]. If the crime calls for imprisonment, then the guard will try to put the prisoner in [[jail]]; if no jails are available, the guard will "downgrade" the punishment to a beating, giving the criminal a happy thought for getting a reduced punishment and the injured party (i.e. the dwarf injured by the criminal, if one exists) an unhappy thought for justice not being properly served. If the crime calls for hammer strikes, then the hammerer will attach the prisoner to a restraint before carrying out the sentence; if no justice restraints are available, the punishment will be downgraded to a beating. All punishments will give the criminal an unhappy thought (and the guard/Hammerer a happy thought).

Note that it is usually not a good idea to train your guards to physical perfection, if you want your dwarves to survive beatings:
Punches to the head have a very high fatality rate, possibly due to a bug {{bug|2907}}. Therefore it is wise to ensure that any criminals scheduled for beating are fitted with a metal helm as quickly as possible (if you want them to live). Even without headstrikes, beatings can easily result in broken bones or organ damage, making prison sentences a less risky option.

Punishments are performed sequentially; a criminal who has been sentenced to jail time ''and'' a hammering will not be hammered until the entire jail term has been served.

If the criminal is a [[visitor]], it is entirely possible for them to run away from your fortress before punishment is delivered.

The level of punishment is determined by the civilisation's [[ethics]].
* PUNISH_SERIOUS will result in either a beating or a month in prison.
* PUNISH_CAPITAL will result in either 8 months in prison or 50 hammerstrikes.

Any punishment of 50 or more hammerstrikes is considered an "execution" and will serve to deter future [[immigration]].

== Cages and chains ==
Designate a new dungeon by going to {{k|z}}ones, select Dungeon, and then highlight the area of your future dungeon/prison. Once designated, the {{k|j}}ustice > Fortress guard screen will show you how many jail cells are available in the dungeon.

Jails can be made out of either cages or chains, and each has its own advantages and disadvantages.

Chains:
* Pro - prisoners can still walk to adjacent tiles to eat, drink, sleep, and admire furniture, keeping them happy
* Con - prisoners throwing [[tantrum]]s can break their chains and attack anybody nearby (including the haulers refilling their food/drink stockpiles)

Cages:
* Pro - unhappy prisoners cannot do any damage to themselves or others
* Con - prisoners require other citizens to give them food and water, or they will die

== Happiness management ==
A dwarf or other creature that is carelessly tied up in a dank dungeon is subject to several unhappy thoughts. Most can be avoided or offset with some care:

Putting food and booze stockpiles right next to the chain allows for happy thoughts from both instead of having to drink water when (if) someone finally brings some. Don't forget that all civilized dwarves like using a mug/goblet.
Decorating your jail with numerous valuable engravings and furniture is helpful too. This includes the chain itself -- prisoners will be happier being shackled with a shiny [[diamond]]-[[decoration|encrusted]] [[gold]] chain than tied up with a boring old [[pig tail]] rope. Finally, with a bed and a table next to a chair all within a square of the chain itself, negative thoughts approach zero. You can even add a beautiful water well and a soap stockpile so the dwarf can bathe and drink water if necessary. The entire jail can double as a temple; Many a dwarf came happier out of prison than they were before because finally they have time to pray.

== Backlog ==
Dwarven justice has no statute of limitations, so if you've delayed appointing the "executive" nobility for some time, there might be a long list of delinquents and open sentences pending. The law will swiftly proceed to chaining up all delinquents and, once all chains are occupied, beating up any remaining free "criminals". Therefore, beatings are avoided only by constructing restraints first, and possibly way more than recommended.

== Exemption ==
Creatures are exempt from the justice system if they are any of the following:

* Dead
* [[Insane]]
* In a [[strange mood]]
* A [[child]] or a [[baby]]
* Non-humanoid (animals are exempt)
* A local position holder with {{token|PUNISHMENT_EXEMPTION|po}}

{{D for Dwarf}}
[[File:Courtroom.png|thumb|A typical (not really) dwarven court.]]
In the Dwarven justice system, the Dwarves are oppressed by two separate yet equally obstinate nobles: the sheriff, who investigates crimes, and the hammerer, who beats the living %#(* out of the offenders. These are their stories.

"Thank the [[deity|gods]] I only got assigned a long-term jail time followed by a hammering. My partner in crime was assigned to a guard beating, poor bastard's head got pulped after one punch." -Urist Mc. Murderhobo.

{{Translation| dwarven = imketh | elvish = leÿa | goblin = aka | human = takru}}

{{V50 menus}}
{{Category|Interface}}
{{Category|Fortress mode}}
{{Category|Justice}}
[[ru:Justice]]

Slavery

2026-10-03T10:32:00Z

Silverwing235: /* Other notes about [ANIMAL] sapients */ and more

This article describes slavery only as represented by the game mechanics, world generation and fictional setting of ''Dwarf Fortress''.

=Overview=
Slavery is not a major gameplay mechanic in ''Dwarf Fortress'', but the concept occurs in several parts of the game. [[Legends|Historical]] figures can become enslaved during [[world generation]], and slavery can also occur through several distinct game mechanics.
The game represents several forms of enslavement, including:
* Child enslavement — [[Goblin]] snatchers abduct [[children]], who may subsequently become slaves.
* Forced domestication — Goblins can enslave [[Troll]]s and use them as mounts, haulers or war animals.
* War slavery — [[Civilization]]s can enslave defeated enemies and bring them back to their settlements.
* Undead servitude — [[Undead]] creatures raised by [[necromancer]]s can be regarded as being under the control of their creator.
* Slaves of Armok — The game's subtitle; '''Slaves to Armok: God of Blood Chapter II: Dwarf Fortress''', uses slavery as part of the game's fictional terminology.

=Civilizational attitudes=
Slavery is also represented in the game's ethics system, which determines how different civilizations regard the practice.

Civilizations have different [[Ethic|ethical attitudes]] toward slavery.
{| class="wikitable"
!Civilization!!Attitude toward slavery
|-
|Humans||Acceptable
|-
|Goblins||Personal Matter
|-
|Elves||Opposed; perpetrators may be punished with exile
|-
|Dwarves||Capital punishment (''technically also opposed, but with [[Justice#Punishments|considerably more force]]'')
|}
These attitudes primarily determine how a civilization reacts to slavery as an ethical issue. They should not be confused with the separate mechanics through which slavery actually occurs.

=Slavery in world generation=
During world generation, historical figures can become enslaved. In mechanical terms, enslavement is closely related to imprisonment: an enslaved historical figure can potentially escape.

Slavery is unlikely to have a direct impact on the game when playing in [[Adventurer mode|adventure]] or [[Dwarf fortress mode|fortress mode]], where it is most likely to be seen in descriptions of historical events. Specific examples of how slavery is represented or implemented by the game can be seen in:
*A civilizations' ethics.
*The various [[String_dump/raw|strings]] used by the game in [[language]]s, [[speech]] and descriptive texts.
*Two explicit [[unit type token]]s.

Examples of possible references:
* "the end of the former enslavement of"
* "escaped from the slavery of"
* "escaped from the slavery of" / "escaped from the prisons of"
* "was enslaved by" / "was imprisoned by"
* "the enslavement" / "the imprisonment"
* "as a former slave of" / "as a former prisoner of"

=Child enslavement=
Goblins are particularly associated with the abduction of [[children]]. Goblin snatchers can enter settlements and abduct children.
See: [[Thief#Goblin_snatchers|Goblin snatchers]]

Abducted children can become part of the goblin civilization rather than remaining members of their original civilization.

Children can potentially be recovered through a citizen recovery mission. Adventurers can also encounter and rescue captives through quests.
See:
* [[Mission|Missions]]
* [[Quest|Quests]]

= Troll enslavement / forced domestication / sentient livestock=
[[Goblin|Goblins]] can also enslave [[Troll|Trolls]]. This is mechanically different from human-style war slavery. The Troll is treated as an animal-like creature under goblin control and can be used for purposes such as:
* carrying loads;
* pulling;
* riding;
* combat.
This creates a distinction between sapient creatures that are treated as animals and ordinary domesticated animals.
This form of enslavement is particularly relevant to modding, because the {{token|ANIMAL|entity}} token can cause a creature to be treated mechanically as an animal, even when the creature is otherwise sapient.
The relevant distinction is between:
* a creature being part of the civilization's main race;
* a creature being defined as an animal or special animal caste;
* a creature being treated as a pet;
* a creature being used as a mount, puller or hauler.
This can produce a situation in which a creature is biologically or culturally sapient but is mechanically handled as livestock or a domesticated animal.

=War slavery=

Civilizations can enslave defeated enemies and take them back to their settlements. This can be described as spoils-of-war slavery or war enslavement.

The ethics value for slavery also affects whether a civilization is willing to accept caged sapient creatures from merchants.

Higher or lower ethical values appear to have relatively limited mechanical consequences, beyond determining whether the civilization permits slavery at all. The ethical value therefore primarily establishes the civilization's attitude toward the practice rather than providing a detailed slavery simulation.

=Undead servitude=
[[Necromancer|Necromancers]] can raise dead creatures as [[Undead]]. The resulting undead are generally under the control of the necromancer who created them.
This can be interpreted as another form of forced servitude, although the game does not necessarily classify undead as slaves in the same mechanical sense as enslaved historical figures.

=Modding Slavery=
There is no dedicated `SLAVE` creature mechanic in ''Dwarf Fortress''. A [[Modding|mod]] can simulate slavery through the use of [[Entity token#Animal definitions|ANIMAL entity tokens]], and referencing a creature with specific [[creature token]]s such as {{token|PACK_ANIMAL}} and {{token|PET}}. There are three main approaches, all of which rely on the creature in question being explicitly defined per-civlization (entity).
{| class="wikitable"
|+ Modding approaches
|-
! Method !! Description !! Can be embarked with !! Can be traded !! Has slave-population in world-gen !! Can be trained !! Can have labours !! Can have a specific interaction !! Can have specific traits !! Can have a pet-value !! Slave can be married to non slave and have kids || Graphic modding needed
|-
| Existing creature as ANIMAL || Use ANIMAL tokens within an entity to define an existing creature itself. || yes || yes || yes || If non-speaking || If [CAN_LEARN]| No || No || yes || yes || no
|-
| Special caste as ANIMAL || Add a special caste to an existing creature and use ANIMAL_CASTE_TOKEN to define it within an entity. || Yes for the special caste, but not the main race || both || No || If non-speaking || If can_learn || Only for the special caste || Only for the special caste ||Yes, both || yes || yes
|-
| Creature copy as ANIMAL|| Create a copy of the original creature and define the copy using ANIMAL entity tokens. || Yes for the special creature, but not for the main race || both || Yes || If non-speaking || If can_learn || Only for the special creature || Only for the special creature || Yes, both || no || yes
|}
* Can be embarked with: creatures can be selected as livestock animals
* Can be traded: can be selected in the trade agreement
* Can have a specific interaction: an interaction specific for this slave-creature can be defined
* Can have specific traits: tokens as desired can be assigned to the slave-creature.

The choice depends on the desired behaviour. A special caste is useful when the enslaved version should remain closely connected to the original creature — i.e. if Dwarves should be able to enslave other Dwarves. A separate creature provides more freedom when the enslaved version needs substantially different properties — i.e. if there is a specific "House Elf" creature that is expected to always be enslaved.

==Sapience and Assigning tasks==
You can assign tasks to a creature with ANIMAL entity tokens if they have the creature tokens {{token|CAN_LEARN}} and {{token|CAN_SPEAK}}.

The CAN_LEARN tag will also mean that the game classes a creature as sapient, which comes with certain limitations on how they can be treated and interacted with. For instance, sapient creatures cannot normally be milked or butchered. Either token will allow a creature to have [[Personality value|values]] and [[Personality goal|goals]].

For a more detailed and philosophical analysis on the topic of sapience, within the context of ''Dwarf Fortress'', see [[Person]].

==How to make them show up==
For creatures that do not naturally spawn, you need {{token|ANIMAL_ALWAYS_PRESENT|entity}}, otherwise, the civ only has them available if they somehow domesticated them. You need {{token|ANIMAL_ALWAYS_PET|entity}} to make them selectable for embark.

==Other notes about [ANIMAL] sapients==
* They can be assigned a (bed)room
* They can be assigned positions like tavern keeper or priest, but never any of the noble positions
* They cannot be assigned a pond or pit and cannot be tied to a rope
* They cannot be assigned to a trainer
* If an ANIMAL-sapient is brought by the merchants, they will come clothed and the merchants will charge extra for the clothing.
* Their thoughts can be viewed in full detail.
* They can be expelled. They do not seem to form any relationships at all.
* If they cannot speak, they are listed as livestock, but cannot be assigned labours, so they can be assigned labours if they are able to speak.
* If they cannot speak, they are trainable
Whether they will petition for citizenship has yet to be verified.
* If you catch a hostile creature in a war, they cannot be pacified. They can, however, be sold to traders.
* If you attack a site that is inhabited by a sapient creature that is defined as an animal by your civilization, you cannot capture them as livestock.

==Example==
A mod that wants dwarves to have an enslaved caste can add a special `SLAVE` caste to the dwarf creature, making use of the appropriate creature tags detailed above. Setting its population ratio to `0` prevents enslaved dwarves from appearing as a separate natural population, while still allowing the caste to be used for individual enslaved dwarves.

For elves or other races, a separate copy of the creature can instead be used as the enslaved version. This provides more control over its properties, but the game treats it as a different creature.

Slavery

2026-10-03T10:30:39Z

Silverwing235: /* How to make them show up */ Grammar problems

This article describes slavery only as represented by the game mechanics, world generation and fictional setting of ''Dwarf Fortress''.

=Overview=
Slavery is not a major gameplay mechanic in ''Dwarf Fortress'', but the concept occurs in several parts of the game. [[Legends|Historical]] figures can become enslaved during [[world generation]], and slavery can also occur through several distinct game mechanics.
The game represents several forms of enslavement, including:
* Child enslavement — [[Goblin]] snatchers abduct [[children]], who may subsequently become slaves.
* Forced domestication — Goblins can enslave [[Troll]]s and use them as mounts, haulers or war animals.
* War slavery — [[Civilization]]s can enslave defeated enemies and bring them back to their settlements.
* Undead servitude — [[Undead]] creatures raised by [[necromancer]]s can be regarded as being under the control of their creator.
* Slaves of Armok — The game's subtitle; '''Slaves to Armok: God of Blood Chapter II: Dwarf Fortress''', uses slavery as part of the game's fictional terminology.

=Civilizational attitudes=
Slavery is also represented in the game's ethics system, which determines how different civilizations regard the practice.

Civilizations have different [[Ethic|ethical attitudes]] toward slavery.
{| class="wikitable"
!Civilization!!Attitude toward slavery
|-
|Humans||Acceptable
|-
|Goblins||Personal Matter
|-
|Elves||Opposed; perpetrators may be punished with exile
|-
|Dwarves||Capital punishment (''technically also opposed, but with [[Justice#Punishments|considerably more force]]'')
|}
These attitudes primarily determine how a civilization reacts to slavery as an ethical issue. They should not be confused with the separate mechanics through which slavery actually occurs.

=Slavery in world generation=
During world generation, historical figures can become enslaved. In mechanical terms, enslavement is closely related to imprisonment: an enslaved historical figure can potentially escape.

Slavery is unlikely to have a direct impact on the game when playing in [[Adventurer mode|adventure]] or [[Dwarf fortress mode|fortress mode]], where it is most likely to be seen in descriptions of historical events. Specific examples of how slavery is represented or implemented by the game can be seen in:
*A civilizations' ethics.
*The various [[String_dump/raw|strings]] used by the game in [[language]]s, [[speech]] and descriptive texts.
*Two explicit [[unit type token]]s.

Examples of possible references:
* "the end of the former enslavement of"
* "escaped from the slavery of"
* "escaped from the slavery of" / "escaped from the prisons of"
* "was enslaved by" / "was imprisoned by"
* "the enslavement" / "the imprisonment"
* "as a former slave of" / "as a former prisoner of"

=Child enslavement=
Goblins are particularly associated with the abduction of [[children]]. Goblin snatchers can enter settlements and abduct children.
See: [[Thief#Goblin_snatchers|Goblin snatchers]]

Abducted children can become part of the goblin civilization rather than remaining members of their original civilization.

Children can potentially be recovered through a citizen recovery mission. Adventurers can also encounter and rescue captives through quests.
See:
* [[Mission|Missions]]
* [[Quest|Quests]]

= Troll enslavement / forced domestication / sentient livestock=
[[Goblin|Goblins]] can also enslave [[Troll|Trolls]]. This is mechanically different from human-style war slavery. The Troll is treated as an animal-like creature under goblin control and can be used for purposes such as:
* carrying loads;
* pulling;
* riding;
* combat.
This creates a distinction between sapient creatures that are treated as animals and ordinary domesticated animals.
This form of enslavement is particularly relevant to modding, because the {{token|ANIMAL|entity}} token can cause a creature to be treated mechanically as an animal, even when the creature is otherwise sapient.
The relevant distinction is between:
* a creature being part of the civilization's main race;
* a creature being defined as an animal or special animal caste;
* a creature being treated as a pet;
* a creature being used as a mount, puller or hauler.
This can produce a situation in which a creature is biologically or culturally sapient but is mechanically handled as livestock or a domesticated animal.

=War slavery=

Civilizations can enslave defeated enemies and take them back to their settlements. This can be described as spoils-of-war slavery or war enslavement.

The ethics value for slavery also affects whether a civilization is willing to accept caged sapient creatures from merchants.

Higher or lower ethical values appear to have relatively limited mechanical consequences, beyond determining whether the civilization permits slavery at all. The ethical value therefore primarily establishes the civilization's attitude toward the practice rather than providing a detailed slavery simulation.

=Undead servitude=
[[Necromancer|Necromancers]] can raise dead creatures as [[Undead]]. The resulting undead are generally under the control of the necromancer who created them.
This can be interpreted as another form of forced servitude, although the game does not necessarily classify undead as slaves in the same mechanical sense as enslaved historical figures.

=Modding Slavery=
There is no dedicated `SLAVE` creature mechanic in ''Dwarf Fortress''. A [[Modding|mod]] can simulate slavery through the use of [[Entity token#Animal definitions|ANIMAL entity tokens]], and referencing a creature with specific [[creature token]]s such as {{token|PACK_ANIMAL}} and {{token|PET}}. There are three main approaches, all of which rely on the creature in question being explicitly defined per-civlization (entity).
{| class="wikitable"
|+ Modding approaches
|-
! Method !! Description !! Can be embarked with !! Can be traded !! Has slave-population in world-gen !! Can be trained !! Can have labours !! Can have a specific interaction !! Can have specific traits !! Can have a pet-value !! Slave can be married to non slave and have kids || Graphic modding needed
|-
| Existing creature as ANIMAL || Use ANIMAL tokens within an entity to define an existing creature itself. || yes || yes || yes || If non-speaking || If [CAN_LEARN]| No || No || yes || yes || no
|-
| Special caste as ANIMAL || Add a special caste to an existing creature and use ANIMAL_CASTE_TOKEN to define it within an entity. || Yes for the special caste, but not the main race || both || No || If non-speaking || If can_learn || Only for the special caste || Only for the special caste ||Yes, both || yes || yes
|-
| Creature copy as ANIMAL|| Create a copy of the original creature and define the copy using ANIMAL entity tokens. || Yes for the special creature, but not for the main race || both || Yes || If non-speaking || If can_learn || Only for the special creature || Only for the special creature || Yes, both || no || yes
|}
* Can be embarked with: creatures can be selected as livestock animals
* Can be traded: can be selected in the trade agreement
* Can have a specific interaction: an interaction specific for this slave-creature can be defined
* Can have specific traits: tokens as desired can be assigned to the slave-creature.

The choice depends on the desired behaviour. A special caste is useful when the enslaved version should remain closely connected to the original creature — i.e. if Dwarves should be able to enslave other Dwarves. A separate creature provides more freedom when the enslaved version needs substantially different properties — i.e. if there is a specific "House Elf" creature that is expected to always be enslaved.

==Sapience and Assigning tasks==
You can assign tasks to a creature with ANIMAL entity tokens if they have the creature tokens {{token|CAN_LEARN}} and {{token|CAN_SPEAK}}.

The CAN_LEARN tag will also mean that the game classes a creature as sapient, which comes with certain limitations on how they can be treated and interacted with. For instance, sapient creatures cannot normally be milked or butchered. Either token will allow a creature to have [[Personality value|values]] and [[Personality goal|goals]].

For a more detailed and philosophical analysis on the topic of sapience, within the context of ''Dwarf Fortress'', see [[Person]].

==How to make them show up==
For creatures that do not naturally spawn, you need {{token|ANIMAL_ALWAYS_PRESENT|entity}}, otherwise, the civ only has them available if they somehow domesticated them. You need {{token|ANIMAL_ALWAYS_PET|entity}} to make them selectable for embark.

==Other notes about [ANIMAL] sapients==
* They can be assigned a (bed)room
* They can be assigned positions like tavern keeper or priest, but never any of the noble positions
* They cannot be assigned a pond or pit and cannot be tied to a rope
* They cannot be assigned to a trainer
* If an ANIMAL-sapient is brought by the merchants, they will come clothed and the merchants will charge extra for the clothing.
* Their thoughts can be viewed in full detail.
* They can be expelled. They do not seem to make any relationships at all.
* If they cannot speak, they are listed as livestock, but cannot be assigned labours, so they can be assigned labours if they are able to speak.
* If they cannot speak, they are trainable
Whether they will petition for citizenship has yet to be verified.
* If you catch a hostile creature in a war, they cannot be pacified. They can, however, be sold to traders.
* If you attack a site that is inhabited by a sapient creature that is defined as an animal by your civilization, you cannot capture them as livestock.

==Example==
A mod that wants dwarves to have an enslaved caste can add a special `SLAVE` caste to the dwarf creature, making use of the appropriate creature tags detailed above. Setting its population ratio to `0` prevents enslaved dwarves from appearing as a separate natural population, while still allowing the caste to be used for individual enslaved dwarves.

For elves or other races, a separate copy of the creature can instead be used as the enslaved version. This provides more control over its properties, but the game treats it as a different creature.

Slavery

2026-10-03T10:26:00Z

Silverwing235: /* Sapience and Assigning tasks */ grammar: run-on sentence

This article describes slavery only as represented by the game mechanics, world generation and fictional setting of ''Dwarf Fortress''.

=Overview=
Slavery is not a major gameplay mechanic in ''Dwarf Fortress'', but the concept occurs in several parts of the game. [[Legends|Historical]] figures can become enslaved during [[world generation]], and slavery can also occur through several distinct game mechanics.
The game represents several forms of enslavement, including:
* Child enslavement — [[Goblin]] snatchers abduct [[children]], who may subsequently become slaves.
* Forced domestication — Goblins can enslave [[Troll]]s and use them as mounts, haulers or war animals.
* War slavery — [[Civilization]]s can enslave defeated enemies and bring them back to their settlements.
* Undead servitude — [[Undead]] creatures raised by [[necromancer]]s can be regarded as being under the control of their creator.
* Slaves of Armok — The game's subtitle; '''Slaves to Armok: God of Blood Chapter II: Dwarf Fortress''', uses slavery as part of the game's fictional terminology.

=Civilizational attitudes=
Slavery is also represented in the game's ethics system, which determines how different civilizations regard the practice.

Civilizations have different [[Ethic|ethical attitudes]] toward slavery.
{| class="wikitable"
!Civilization!!Attitude toward slavery
|-
|Humans||Acceptable
|-
|Goblins||Personal Matter
|-
|Elves||Opposed; perpetrators may be punished with exile
|-
|Dwarves||Capital punishment (''technically also opposed, but with [[Justice#Punishments|considerably more force]]'')
|}
These attitudes primarily determine how a civilization reacts to slavery as an ethical issue. They should not be confused with the separate mechanics through which slavery actually occurs.

=Slavery in world generation=
During world generation, historical figures can become enslaved. In mechanical terms, enslavement is closely related to imprisonment: an enslaved historical figure can potentially escape.

Slavery is unlikely to have a direct impact on the game when playing in [[Adventurer mode|adventure]] or [[Dwarf fortress mode|fortress mode]], where it is most likely to be seen in descriptions of historical events. Specific examples of how slavery is represented or implemented by the game can be seen in:
*A civilizations' ethics.
*The various [[String_dump/raw|strings]] used by the game in [[language]]s, [[speech]] and descriptive texts.
*Two explicit [[unit type token]]s.

Examples of possible references:
* "the end of the former enslavement of"
* "escaped from the slavery of"
* "escaped from the slavery of" / "escaped from the prisons of"
* "was enslaved by" / "was imprisoned by"
* "the enslavement" / "the imprisonment"
* "as a former slave of" / "as a former prisoner of"

=Child enslavement=
Goblins are particularly associated with the abduction of [[children]]. Goblin snatchers can enter settlements and abduct children.
See: [[Thief#Goblin_snatchers|Goblin snatchers]]

Abducted children can become part of the goblin civilization rather than remaining members of their original civilization.

Children can potentially be recovered through a citizen recovery mission. Adventurers can also encounter and rescue captives through quests.
See:
* [[Mission|Missions]]
* [[Quest|Quests]]

= Troll enslavement / forced domestication / sentient livestock=
[[Goblin|Goblins]] can also enslave [[Troll|Trolls]]. This is mechanically different from human-style war slavery. The Troll is treated as an animal-like creature under goblin control and can be used for purposes such as:
* carrying loads;
* pulling;
* riding;
* combat.
This creates a distinction between sapient creatures that are treated as animals and ordinary domesticated animals.
This form of enslavement is particularly relevant to modding, because the {{token|ANIMAL|entity}} token can cause a creature to be treated mechanically as an animal, even when the creature is otherwise sapient.
The relevant distinction is between:
* a creature being part of the civilization's main race;
* a creature being defined as an animal or special animal caste;
* a creature being treated as a pet;
* a creature being used as a mount, puller or hauler.
This can produce a situation in which a creature is biologically or culturally sapient but is mechanically handled as livestock or a domesticated animal.

=War slavery=

Civilizations can enslave defeated enemies and take them back to their settlements. This can be described as spoils-of-war slavery or war enslavement.

The ethics value for slavery also affects whether a civilization is willing to accept caged sapient creatures from merchants.

Higher or lower ethical values appear to have relatively limited mechanical consequences, beyond determining whether the civilization permits slavery at all. The ethical value therefore primarily establishes the civilization's attitude toward the practice rather than providing a detailed slavery simulation.

=Undead servitude=
[[Necromancer|Necromancers]] can raise dead creatures as [[Undead]]. The resulting undead are generally under the control of the necromancer who created them.
This can be interpreted as another form of forced servitude, although the game does not necessarily classify undead as slaves in the same mechanical sense as enslaved historical figures.

=Modding Slavery=
There is no dedicated `SLAVE` creature mechanic in ''Dwarf Fortress''. A [[Modding|mod]] can simulate slavery through the use of [[Entity token#Animal definitions|ANIMAL entity tokens]], and referencing a creature with specific [[creature token]]s such as {{token|PACK_ANIMAL}} and {{token|PET}}. There are three main approaches, all of which rely on the creature in question being explicitly defined per-civlization (entity).
{| class="wikitable"
|+ Modding approaches
|-
! Method !! Description !! Can be embarked with !! Can be traded !! Has slave-population in world-gen !! Can be trained !! Can have labours !! Can have a specific interaction !! Can have specific traits !! Can have a pet-value !! Slave can be married to non slave and have kids || Graphic modding needed
|-
| Existing creature as ANIMAL || Use ANIMAL tokens within an entity to define an existing creature itself. || yes || yes || yes || If non-speaking || If [CAN_LEARN]| No || No || yes || yes || no
|-
| Special caste as ANIMAL || Add a special caste to an existing creature and use ANIMAL_CASTE_TOKEN to define it within an entity. || Yes for the special caste, but not the main race || both || No || If non-speaking || If can_learn || Only for the special caste || Only for the special caste ||Yes, both || yes || yes
|-
| Creature copy as ANIMAL|| Create a copy of the original creature and define the copy using ANIMAL entity tokens. || Yes for the special creature, but not for the main race || both || Yes || If non-speaking || If can_learn || Only for the special creature || Only for the special creature || Yes, both || no || yes
|}
* Can be embarked with: creatures can be selected as livestock animals
* Can be traded: can be selected in the trade agreement
* Can have a specific interaction: an interaction specific for this slave-creature can be defined
* Can have specific traits: tokens as desired can be assigned to the slave-creature.

The choice depends on the desired behaviour. A special caste is useful when the enslaved version should remain closely connected to the original creature — i.e. if Dwarves should be able to enslave other Dwarves. A separate creature provides more freedom when the enslaved version needs substantially different properties — i.e. if there is a specific "House Elf" creature that is expected to always be enslaved.

==Sapience and Assigning tasks==
You can assign tasks to a creature with ANIMAL entity tokens if they have the creature tokens {{token|CAN_LEARN}} and {{token|CAN_SPEAK}}.

The CAN_LEARN tag will also mean that the game classes a creature as sapient, which comes with certain limitations on how they can be treated and interacted with. For instance, sapient creatures cannot normally be milked or butchered. Either token will allow a creature to have [[Personality value|values]] and [[Personality goal|goals]].

For a more detailed and philosophical analysis on the topic of sapience, within the context of ''Dwarf Fortress'', see [[Person]].

==How to make them show up==
* For creatures that do not naturally spawn, you need {{token|ANIMAL_ALWAYS_PRESENT|entity}}. otherwise the civ has them only available if they somehow domesticated them
* you need {{token|ANIMAL_ALWAYS_PET|entity}} to make them selectable for embark.

==Other notes about [ANIMAL] sapients==
* They can be assigned a (bed)room
* They can be assigned positions like tavern keeper or priest, but never any of the noble positions
* They cannot be assigned a pond or pit and cannot be tied to a rope
* They cannot be assigned to a trainer
* If an ANIMAL-sapient is brought by the merchants, they will come clothed and the merchants will charge extra for the clothing.
* Their thoughts can be viewed in full detail.
* They can be expelled. They do not seem to make any relationships at all.
* If they cannot speak, they are listed as livestock, but cannot be assigned labours, so they can be assigned labours if they are able to speak.
* If they cannot speak, they are trainable
Whether they will petition for citizenship has yet to be verified.
* If you catch a hostile creature in a war, they cannot be pacified. They can, however, be sold to traders.
* If you attack a site that is inhabited by a sapient creature that is defined as an animal by your civilization, you cannot capture them as livestock.

==Example==
A mod that wants dwarves to have an enslaved caste can add a special `SLAVE` caste to the dwarf creature, making use of the appropriate creature tags detailed above. Setting its population ratio to `0` prevents enslaved dwarves from appearing as a separate natural population, while still allowing the caste to be used for individual enslaved dwarves.

For elves or other races, a separate copy of the creature can instead be used as the enslaved version. This provides more control over its properties, but the game treats it as a different creature.

Slavery

2026-10-02T21:05:50Z

Silverwing235: /* Civilizational attitudes */ scratch-scratch, scribble-scribble

This article describes slavery only as represented by the game mechanics, world generation and fictional setting of ''Dwarf Fortress''.

=Overview=
Slavery is not a major gameplay mechanic in ''Dwarf Fortress'', but the concept occurs in several parts of the game. Historical figures can become enslaved during world generation, and slavery can also occur through several distinct game mechanics.
The game represents several forms of enslavement, including:
* Child enslavement — Goblin snatchers abduct children, who may subsequently become slaves.
* Forced domestication — Goblins can enslave [[Trolls]] and use them as mounts, haulers or war animals.
* War slavery — Civilizations can enslave defeated enemies and bring them back to their settlements.
* Undead servitude — Undead creatures raised by necromancers can be regarded as being under the control of their creator.
* Slaves of Armok — The game's subtitle; '''Slaves to Armok: God of Blood Chapter II: Dwarf Fortress''', uses slavery as part of the game's fictional terminology.
Slavery is also represented in the game's ethics system, which determines how different civilizations regard the practice.

=Civilizational attitudes=
Civilizations have different [[Ethic|ethical attitudes]] toward slavery.
{| class="wikitable"
!Civilization!!Attitude toward slavery
|-
|Humans||Acceptable
|-
|Goblins||Personal Matter
|-
|Elves||Opposed; perpetrators may be punished with exile
|-
|Dwarves||Capital punishment (''technically also opposed, but with considerably more force'')
|}
These attitudes primarily determine how a civilization reacts to slavery as an ethical issue. They should not be confused with the separate mechanics through which slavery actually occurs.

=Slavery in world generation=
During world generation, historical figures can become enslaved. In mechanical terms, enslavement is closely related to imprisonment: an enslaved historical figure can potentially escape.
Relevant game definitions and tokens can be found in:
[[Unit_type_token]]
or
[[String_dump/raw]]

There are references to slavery like:

* "the end of the former enslavement of"
* "escaped from the slavery of"
* "escaped from the slavery of" / "escaped from the prisons of"
* "was enslaved by" / "was imprisoned by"
* "the enslavement" / "the imprisonment"
* "as a former slave of" / "as a former prisoner of"

=Child enslavement=
Goblins are particularly associated with the abduction of children. Goblin snatchers can enter settlements and abduct children.
See: [[Thief#Goblin_snatchers|Goblin snatchers]]

Abducted children can become part of the goblin civilization rather than remaining members of their original civilization.

Children can potentially be recovered through a citizen recovery mission. Adventurers can also encounter and rescue captives through quests.
See:
* [[Mission|Missions]]
* [[Quest|Quests]]

= Troll enslavement / forced domestication / sentient livestock=
[[Goblin|Goblins]] can also enslave [[Troll|Trolls]]. This is mechanically different from human-style war slavery. The Troll is treated as an animal-like creature under goblin control and can be used for purposes such as:
* carrying loads;
* pulling;
* riding;
* combat.
This creates a distinction between sapient creatures that are treated as animals and ordinary domesticated animals.
This form of enslavement is particularly relevant to modding, because the [[Entity_token#ANIMAL|ANIMAL]] token can cause a creature to be treated mechanically as an animal, even when the creature is otherwise sapient.
The relevant distinction is between:
* a creature being part of the civilization's main race;
* a creature being defined as an animal or special animal caste;
* a creature being treated as a pet;
* a creature being used as a mount, puller or hauler.
This can produce a situation in which a creature is biologically or culturally sapient but is mechanically handled as livestock or a domesticated animal.

=War slavery=

Civilizations can enslave defeated enemies and take them back to their settlements. This can be described as spoils-of-war slavery or war enslavement.

The ethics value for slavery also affects whether a civilization is willing to accept caged sapient creatures from merchants.

Higher or lower ethical values appear to have relatively limited mechanical consequences, beyond determining whether the civilization permits slavery at all. The ethical value therefore primarily establishes the civilization's attitude toward the practice rather than providing a detailed slavery simulation.

=Undead servitude=
[[Necromancer|Necromancers]] can raise dead creatures as [[Undead]]. The resulting undead are generally under the control of the necromancer who created them.
This can be interpreted as another form of forced servitude, although the game does not necessarily classify undead as slaves in the same mechanical sense as enslaved historical figures.

=Modding Slavery=
There is no dedicated `SLAVE` creature mechanic in ''Dwarf Fortress''. A mod can simulate slavery by defining the enslaved creature as an `ANIMAL` and also as PET. There are three main approaches.
{| class="wikitable"
|+ Modding approaches
|-
! Method !! Description !! Can be embarked with !! Can be traded !! Has slave-population in world-gen !! Can be trained !! Can have labours !! Can have a specific interaction !! Can have specific traits !! Can have a pet-value !! Slave can be married to non slave and have kids || Graphic modding needed
|-
| Existing creature as ANIMAL || Define an existing creature itself as an ANIMAL.|| yes || yes || yes || If non-speaking || If [CAN_LEARN]| No || No || yes || yes || no
|-
| Special caste as ANIMAL || Add a special caste to an existing creature and define that caste as an ANIMAL || Yes for the special caste, but not the main race || both || No || If non-speaking || If can_learn || Only for the special caste || Only for the special caste ||Yes, both || yes || yes
|-
| Creature copy as ANIMAL|| Create a copy of the original creature and define the copy as an ANIMAL. || Yes for the special creature, but not for the main race || both || Yes || If non-speaking || If can_learn || Only for the special creature || Only for the special creature || Yes, both || no || yes
|}
* Can be embarked with: creatures can be selected as livestock animals
* Can be traded: can be selected in the trade agreement
* Can have a specific interaction: an interaction specific for this slave-creature can be defined
* Can have specific traits: tokens as desired can be assigned to the slave-creature.

The choice depends on the desired behaviour. A special caste is useful when the enslaved version should remain closely connected to the original creature. A separate creature provides more freedom when the enslaved version needs substantially different properties.

==Assigning tasks==
* You can assign them tasks if they are [CAN_LEARN] and [CAN_SPEAK].

==How to make them show up==
* For creatures that do not naturally spawn, you need [ANIMAL_ALWAYS_PRESENT]. otherwise the civ has them only available if they somehow domesticated them
* you need [ANIMAL_ALWAYS_PET] to make them selectable for embark.

==Other notes about [ANIMAL] sapients==
* It can be assigned a (bed)room
* It can be assigned positions like tavern keeper or priest, but never any of the noble positions
* It cannot be assigned a pond or pit and cannot be tied to a rope
* It cannot be assigned to a trainer
* If an ANIMAL-sapient is brought by the merchants, it will come clothed and the merchants will charge extra for the clothing.
* Its thoughts can be viewed in full detail.
* It can be expelled. It does not seem to make any relationships at all.
* If they cannot speak, they are listed as livestock, but cannot be assigned labours, so they can be assigned labours if they are able to speak.
* If they cannot speak, they are trainable
Further testing is required to determine if it will petition for citizenship.
* If you catch a hostile creature in a war, it cannot be pacified. It can, however, be sold to traders.
* If you attack a site that is inhabited by the creature that you have defined as animal, you, unfortunately, cannot capture them as livestock.

==Example==
A mod that wants dwarves to have an enslaved caste can add a special `ANIMAL` caste to the dwarf creature. Setting its population ratio to `0` prevents enslaved dwarves from appearing as a separate natural population, while still allowing the caste to be used for individual enslaved dwarves.

For elves or other races, a separate copy of the creature can instead be used as the enslaved version. This provides more control over its properties, but the game treats it as a different creature.

Slavery

2026-10-02T20:58:13Z

Silverwing235: /* Troll enslavement / forced domestication / sentient livestock */

This article describes slavery only as represented by the game mechanics, world generation and fictional setting of ''Dwarf Fortress''.

=Overview=
Slavery is not a major gameplay mechanic in ''Dwarf Fortress'', but the concept occurs in several parts of the game. Historical figures can become enslaved during world generation, and slavery can also occur through several distinct game mechanics.
The game represents several forms of enslavement, including:
* Child enslavement — Goblin snatchers abduct children, who may subsequently become slaves.
* Forced domestication — Goblins can enslave [[Trolls]] and use them as mounts, haulers or war animals.
* War slavery — Civilizations can enslave defeated enemies and bring them back to their settlements.
* Undead servitude — Undead creatures raised by necromancers can be regarded as being under the control of their creator.
* Slaves of Armok — The game's subtitle; '''Slaves to Armok: God of Blood Chapter II: Dwarf Fortress''', uses slavery as part of the game's fictional terminology.
Slavery is also represented in the game's ethics system, which determines how different civilizations regard the practice.

=Civilizational attitudes=
Civilizations have different [[Ethic|ethical attitudes]] toward slavery.
{| class="wikitable"
!Civilization!!Attitude toward slavery
|-
|Humans||Acceptable
|-
|Goblins||Personal Matter
|-
|Elves||Opposed; perpetrators may be punished with exile
|-
|Dwarves||Capital punishment
|}
These attitudes primarily determine how a civilization reacts to slavery as an ethical issue. They should not be confused with the separate mechanics through which slavery actually occurs.

=Slavery in world generation=
During world generation, historical figures can become enslaved. In mechanical terms, enslavement is closely related to imprisonment: an enslaved historical figure can potentially escape.
Relevant game definitions and tokens can be found in:
[[Unit_type_token]]
or
[[String_dump/raw]]

There are references to slavery like:

* "the end of the former enslavement of"
* "escaped from the slavery of"
* "escaped from the slavery of" / "escaped from the prisons of"
* "was enslaved by" / "was imprisoned by"
* "the enslavement" / "the imprisonment"
* "as a former slave of" / "as a former prisoner of"

=Child enslavement=
Goblins are particularly associated with the abduction of children. Goblin snatchers can enter settlements and abduct children.
See: [[Thief#Goblin_snatchers|Goblin snatchers]]

Abducted children can become part of the goblin civilization rather than remaining members of their original civilization.

Children can potentially be recovered through a citizen recovery mission. Adventurers can also encounter and rescue captives through quests.
See:
* [[Mission|Missions]]
* [[Quest|Quests]]

= Troll enslavement / forced domestication / sentient livestock=
[[Goblin|Goblins]] can also enslave [[Troll|Trolls]]. This is mechanically different from human-style war slavery. The Troll is treated as an animal-like creature under goblin control and can be used for purposes such as:
* carrying loads;
* pulling;
* riding;
* combat.
This creates a distinction between sapient creatures that are treated as animals and ordinary domesticated animals.
This form of enslavement is particularly relevant to modding, because the [[Entity_token#ANIMAL|ANIMAL]] token can cause a creature to be treated mechanically as an animal, even when the creature is otherwise sapient.
The relevant distinction is between:
* a creature being part of the civilization's main race;
* a creature being defined as an animal or special animal caste;
* a creature being treated as a pet;
* a creature being used as a mount, puller or hauler.
This can produce a situation in which a creature is biologically or culturally sapient but is mechanically handled as livestock or a domesticated animal.

=War slavery=

Civilizations can enslave defeated enemies and take them back to their settlements. This can be described as spoils-of-war slavery or war enslavement.

The ethics value for slavery also affects whether a civilization is willing to accept caged sapient creatures from merchants.

Higher or lower ethical values appear to have relatively limited mechanical consequences, beyond determining whether the civilization permits slavery at all. The ethical value therefore primarily establishes the civilization's attitude toward the practice rather than providing a detailed slavery simulation.

=Undead servitude=
[[Necromancer|Necromancers]] can raise dead creatures as [[Undead]]. The resulting undead are generally under the control of the necromancer who created them.
This can be interpreted as another form of forced servitude, although the game does not necessarily classify undead as slaves in the same mechanical sense as enslaved historical figures.

=Modding Slavery=
There is no dedicated `SLAVE` creature mechanic in ''Dwarf Fortress''. A mod can simulate slavery by defining the enslaved creature as an `ANIMAL` and also as PET. There are three main approaches.
{| class="wikitable"
|+ Modding approaches
|-
! Method !! Description !! Can be embarked with !! Can be traded !! Has slave-population in world-gen !! Can be trained !! Can have labours !! Can have a specific interaction !! Can have specific traits !! Can have a pet-value !! Slave can be married to non slave and have kids || Graphic modding needed
|-
| Existing creature as ANIMAL || Define an existing creature itself as an ANIMAL.|| yes || yes || yes || If non-speaking || If [CAN_LEARN]| No || No || yes || yes || no
|-
| Special caste as ANIMAL || Add a special caste to an existing creature and define that caste as an ANIMAL || Yes for the special caste, but not the main race || both || No || If non-speaking || If can_learn || Only for the special caste || Only for the special caste ||Yes, both || yes || yes
|-
| Creature copy as ANIMAL|| Create a copy of the original creature and define the copy as an ANIMAL. || Yes for the special creature, but not for the main race || both || Yes || If non-speaking || If can_learn || Only for the special creature || Only for the special creature || Yes, both || no || yes
|}
* Can be embarked with: creatures can be selected as livestock animals
* Can be traded: can be selected in the trade agreement
* Can have a specific interaction: an interaction specific for this slave-creature can be defined
* Can have specific traits: tokens as desired can be assigned to the slave-creature.

The choice depends on the desired behaviour. A special caste is useful when the enslaved version should remain closely connected to the original creature. A separate creature provides more freedom when the enslaved version needs substantially different properties.

==Assigning tasks==
* You can assign them tasks if they are [CAN_LEARN] and [CAN_SPEAK].

==How to make them show up==
* For creatures that do not naturally spawn, you need [ANIMAL_ALWAYS_PRESENT]. otherwise the civ has them only available if they somehow domesticated them
* you need [ANIMAL_ALWAYS_PET] to make them selectable for embark.

==Other notes about [ANIMAL] sapients==
* It can be assigned a (bed)room
* It can be assigned positions like tavern keeper or priest, but never any of the noble positions
* It cannot be assigned a pond or pit and cannot be tied to a rope
* It cannot be assigned to a trainer
* If an ANIMAL-sapient is brought by the merchants, it will come clothed and the merchants will charge extra for the clothing.
* Its thoughts can be viewed in full detail.
* It can be expelled. It does not seem to make any relationships at all.
* If they cannot speak, they are listed as livestock, but cannot be assigned labours, so they can be assigned labours if they are able to speak.
* If they cannot speak, they are trainable
Further testing is required to determine if it will petition for citizenship.
* If you catch a hostile creature in a war, it cannot be pacified. It can, however, be sold to traders.
* If you attack a site that is inhabited by the creature that you have defined as animal, you, unfortunately, cannot capture them as livestock.

==Example==
A mod that wants dwarves to have an enslaved caste can add a special `ANIMAL` caste to the dwarf creature. Setting its population ratio to `0` prevents enslaved dwarves from appearing as a separate natural population, while still allowing the caste to be used for individual enslaved dwarves.

For elves or other races, a separate copy of the creature can instead be used as the enslaved version. This provides more control over its properties, but the game treats it as a different creature.

Slavery

2026-10-02T20:51:43Z

Silverwing235: /* Slavery in world generation */

This article describes slavery only as represented by the game mechanics, world generation and fictional setting of ''Dwarf Fortress''.

=Overview=
Slavery is not a major gameplay mechanic in ''Dwarf Fortress'', but the concept occurs in several parts of the game. Historical figures can become enslaved during world generation, and slavery can also occur through several distinct game mechanics.
The game represents several forms of enslavement, including:
* Child enslavement — Goblin snatchers abduct children, who may subsequently become slaves.
* Forced domestication — Goblins can enslave [[Trolls]] and use them as mounts, haulers or war animals.
* War slavery — Civilizations can enslave defeated enemies and bring them back to their settlements.
* Undead servitude — Undead creatures raised by necromancers can be regarded as being under the control of their creator.
* Slaves of Armok — The game's subtitle; '''Slaves to Armok: God of Blood Chapter II: Dwarf Fortress''', uses slavery as part of the game's fictional terminology.
Slavery is also represented in the game's ethics system, which determines how different civilizations regard the practice.

=Civilizational attitudes=
Civilizations have different [[Ethic|ethical attitudes]] toward slavery.
{| class="wikitable"
|Civilization||Attitude toward slavery
|-
|Humans||Acceptable
|-
|Goblins||Personal Matter
|-
|Elves||Opposed; perpetrators may be punished with exile
|-
|Dwarves||Capital punishment
|}
These attitudes primarily determine how a civilization reacts to slavery as an ethical issue. They should not be confused with the separate mechanics through which slavery actually occurs.

=Slavery in world generation=
During world generation, historical figures can become enslaved. In mechanical terms, enslavement is closely related to imprisonment: an enslaved historical figure can potentially escape.
Relevant game definitions and tokens can be found in:
[[Unit_type_token]]
or
[[String_dump/raw]]

There are references to slavery like:

* "the end of the former enslavement of"
* "escaped from the slavery of"
* "escaped from the slavery of" / "escaped from the prisons of"
* "was enslaved by" / "was imprisoned by"
* "the enslavement" / "the imprisonment"
* "as a former slave of" / "as a former prisoner of"

=Child enslavement=
Goblins are particularly associated with the abduction of children. Goblin snatchers can enter settlements and abduct children.
See: [[Thief#Goblin_snatchers|Goblin snatchers]]

Abducted children can become part of the goblin civilization rather than remaining members of their original civilization.

Children can potentially be recovered through a citizen recovery mission. Adventurers can also encounter and rescue captives through quests.
See:
* [[Mission|Missions]]
* [[Quest|Quests]]

= Troll enslavement / forced domestication / sentient livestock=
[[Goblin|Goblins]] can also enslave [[Troll|Trolls]]. This is mechanically different from human-style war slavery. The Troll is treated as an animal-like creature under goblin control and can be used for purposes such as:
* carrying loads;
* pulling;
* riding;
* combat.
This creates a distinction between sapient creatures that are treated as animals and ordinary domesticated animals.
This form of enslavement is particularly relevant to modding because the [[Entity_Token#ANIMAL]] token can cause a creature to be treated mechanically as an animal, even when the creature is otherwise sapient.
The relevant distinction is between:
* a creature being part of the civilization's main race;
* a creature being defined as an animal or special animal caste;
* a creature being treated as a pet;
* a creature being used as a mount, puller or hauler.
This can produce a situation in which a creature is biologically or culturally sapient but is mechanically handled as livestock or a domesticated animal.

=War slavery=

Civilizations can enslave defeated enemies and take them back to their settlements. This can be described as spoils-of-war slavery or war enslavement.

The ethics value for slavery also affects whether a civilization is willing to accept caged sapient creatures from merchants.

Higher or lower ethical values appear to have relatively limited mechanical consequences, beyond determining whether the civilization permits slavery at all. The ethical value therefore primarily establishes the civilization's attitude toward the practice rather than providing a detailed slavery simulation.

=Undead servitude=
[[Necromancer|Necromancers]] can raise dead creatures as [[Undead]]. The resulting undead are generally under the control of the necromancer who created them.
This can be interpreted as another form of forced servitude, although the game does not necessarily classify undead as slaves in the same mechanical sense as enslaved historical figures.

=Modding Slavery=
There is no dedicated `SLAVE` creature mechanic in ''Dwarf Fortress''. A mod can simulate slavery by defining the enslaved creature as an `ANIMAL` and also as PET. There are three main approaches.
{| class="wikitable"
|+ Modding approaches
|-
! Method !! Description !! Can be embarked with !! Can be traded !! Has slave-population in world-gen !! Can be trained !! Can have labours !! Can have a specific interaction !! Can have specific traits !! Can have a pet-value !! Slave can be married to non slave and have kids || Graphic modding needed
|-
| Existing creature as ANIMAL || Define an existing creature itself as an ANIMAL.|| yes || yes || yes || If non-speaking || If [CAN_LEARN]| No || No || yes || yes || no
|-
| Special caste as ANIMAL || Add a special caste to an existing creature and define that caste as an ANIMAL || Yes for the special caste, but not the main race || both || No || If non-speaking || If can_learn || Only for the special caste || Only for the special caste ||Yes, both || yes || yes
|-
| Creature copy as ANIMAL|| Create a copy of the original creature and define the copy as an ANIMAL. || Yes for the special creature, but not for the main race || both || Yes || If non-speaking || If can_learn || Only for the special creature || Only for the special creature || Yes, both || no || yes
|}
* Can be embarked with: creatures can be selected as livestock animals
* Can be traded: can be selected in the trade agreement
* Can have a specific interaction: an interaction specific for this slave-creature can be defined
* Can have specific traits: tokens as desired can be assigned to the slave-creature.

The choice depends on the desired behaviour. A special caste is useful when the enslaved version should remain closely connected to the original creature. A separate creature provides more freedom when the enslaved version needs substantially different properties.

==Assigning tasks==
* You can assign them tasks if they are [CAN_LEARN] and [CAN_SPEAK].

==How to make them show up==
* For creatures that do not naturally spawn, you need [ANIMAL_ALWAYS_PRESENT]. otherwise the civ has them only available if they somehow domesticated them
* you need [ANIMAL_ALWAYS_PET] to make them selectable for embark.

==Other notes about [ANIMAL] sapients==
* It can be assigned a (bed)room
* It can be assigned positions like tavern keeper or priest, but never any of the noble positions
* It cannot be assigned a pond or pit and cannot be tied to a rope
* It cannot be assigned to a trainer
* If an ANIMAL-sapient is brought by the merchants, it will come clothed and the merchants will charge extra for the clothing.
* Its thoughts can be viewed in full detail.
* It can be expelled. It does not seem to make any relationships at all.
* If they cannot speak, they are listed as livestock, but cannot be assigned labours, so they can be assigned labours if they are able to speak.
* If they cannot speak, they are trainable
Further testing is required to determine if it will petition for citizenship.
* If you catch a hostile creature in a war, it cannot be pacified. It can, however, be sold to traders.
* If you attack a site that is inhabited by the creature that you have defined as animal, you, unfortunately, cannot capture them as livestock.

==Example==
A mod that wants dwarves to have an enslaved caste can add a special `ANIMAL` caste to the dwarf creature. Setting its population ratio to `0` prevents enslaved dwarves from appearing as a separate natural population, while still allowing the caste to be used for individual enslaved dwarves.

For elves or other races, a separate copy of the creature can instead be used as the enslaved version. This provides more control over its properties, but the game treats it as a different creature.

Slavery

2026-10-02T10:50:50Z

Silverwing235: bungled formatting,etc

This article describes slavery as represented by the game mechanics and world generation of ''Dwarf Fortress''. It does not endorse slavery or the treatment of sentient beings as property.

=Overview=
Slavery is not a major gameplay mechanic in ''Dwarf Fortress'', but the concept occurs in several parts of the game. Historical figures can become enslaved during world generation, and slavery can also occur through several distinct game mechanics.
The game represents several forms of enslavement, including:
* Child enslavement — Goblin snatchers abduct children, who may subsequently become slaves.
* Forced domestication — Goblins can enslave [[Trolls]] and use them as mounts, haulers or war animals.
* War slavery — Civilizations can enslave defeated enemies and bring them back to their settlements.
* Undead servitude — Undead creatures raised by necromancers can be regarded as being under the control of their creator.
* Slaves of Armok — The game's subtitle; '''Slaves to Armok: God of Blood Chapter II: Dwarf Fortress''', uses slavery as part of the game's fictional terminology.
Slavery is also represented in the game's ethics system, which determines how different civilizations regard the practice.

=Civilizational attitudes=
Civilizations have different [[Ethic|ethical attitudes]] toward slavery.
{| class="wikitable"
|Civilization||Attitude toward slavery
|-
|Humans||Acceptable
|-
|Goblins||Personal Matter
|-
|Elves||Opposed; perpetrators may be punished with exile
|-
|Dwarves||Capital punishment
|}
These attitudes primarily determine how a civilization reacts to slavery as an ethical issue. They should not be confused with the separate mechanics through which slavery actually occurs.

=Slavery in world generation=
During world generation, historical figures can become enslaved. In mechanical terms, enslavement is closely related to imprisonment: an enslaved historical figure can potentially escape.
Relevant game definitions and tokens can be found in:
[[https://dwarffortresswiki.org/index.php/Unit_type_token]]
[[https://dwarffortresswiki.org/index.php/String_dump/raw]]

There are references to slavery like:

* "the end of the former enslavement of"
* "escaped from the slavery of"
* "escaped from the slavery of" / "escaped from the prisons of"
* "was enslaved by" / "was imprisoned by"
* "the enslavement" / "the imprisonment"
* "as a former slave of" / "as a former prisoner of"

=Child enslavement=
Goblins are particularly associated with the abduction of children. Goblin snatchers can enter settlements and abduct children.
See: [[Thief#Goblin_snatchers|Goblin snatchers]]

Abducted children can become part of the goblin civilization rather than remaining members of their original civilization.

Children can potentially be recovered through a citizen recovery mission. Adventurers can also encounter and rescue captives through quests.
See:
* [[Mission|Missions]]
* [[Quest|Quests]]

= Troll enslavement / forced domestication / sentient livestock=
[[Goblin|Goblins]] can also enslave [[Troll|Trolls]]. This is mechanically different from human-style war slavery. The Troll is treated as an animal-like creature under goblin control and can be used for purposes such as:
* carrying loads;
* pulling;
* riding;
* combat.
This creates a distinction between sapient creatures that are treated as animals and ordinary domesticated animals.
This form of enslavement is particularly relevant to modding because the [[Entity_Token#ANIMAL]] token can cause a creature to be treated mechanically as an animal, even when the creature is otherwise sapient.
The relevant distinction is between:
* a creature being part of the civilization's main race;
* a creature being defined as an animal or special animal caste;
* a creature being treated as a pet;
* a creature being used as a mount, puller or hauler.
This can produce a situation in which a creature is biologically or culturally sapient but is mechanically handled as livestock or a domesticated animal.

=War slavery=

Civilizations can enslave defeated enemies and take them back to their settlements. This can be described as spoils-of-war slavery or war enslavement.

The ethics value for slavery also affects whether a civilization is willing to accept caged sapient creatures from merchants.

Higher or lower ethical values appear to have relatively limited mechanical consequences, beyond determining whether the civilization permits slavery at all. The ethical value therefore primarily establishes the civilization's attitude toward the practice rather than providing a detailed slavery simulation.

=Undead servitude=
[[Necromancer|Necromancers]] can raise dead creatures as [[Undead]]. The resulting undead are generally under the control of the necromancer who created them.
This can be interpreted as another form of forced servitude, although the game does not necessarily classify undead as slaves in the same mechanical sense as enslaved historical figures.

=Modding Slavery=
There is no dedicated `SLAVE` creature mechanic in ''Dwarf Fortress''. A mod can simulate slavery by defining the enslaved creature as an `ANIMAL` and also as PET. There are three main approaches.
{| class="wikitable"
|+ Modding approaches
|-
! Method !! Description !! Can be embarked with !! Can be traded !! Has slave-population in world-gen !! Can be trained !! Can have labours !! Can have a specific interaction !! Can have specific traits !! Can have a pet-value !! Slave can be married to non slave and have kids || Graphic modding needed
|-
| Existing creature as ANIMAL || Define an existing creature itself as an ANIMAL.|| yes || yes || yes || If non-speaking || If [CAN_LEARN]| No || No || yes || yes || no
|-
| Special caste as ANIMAL || Add a special caste to an existing creature and define that caste as an ANIMAL || Yes for the special caste, but not the main race || both || No || If non-speaking || If can_learn || Only for the special caste || Only for the special caste ||Yes, both || yes || yes
|-
| Creature copy as ANIMAL|| Create a copy of the original creature and define the copy as an ANIMAL. || Yes for the special creature, but not for the main race || both || Yes || If non-speaking || If can_learn || Only for the special creature || Only for the special creature || Yes, both || no || yes
|}
* Can be embarked with: creatures can be selected as livestock animals
* Can be traded: can be selected in the trade agreement
* Can have a specific interaction: an interaction specific for this slave-creature can be defined
* Can have specific traits: tokens as desired can be assigned to the slave-creature.

The choice depends on the desired behaviour. A special caste is useful when the enslaved version should remain closely connected to the original creature. A separate creature provides more freedom when the enslaved version needs substantially different properties.

==Assigning tasks==
* You can assign them tasks if they are [CAN_LEARN] and [CAN_SPEAK].

==How to make them show up==
* For creatures that do not naturally spawn, you need [ANIMAL_ALWAYS_PRESENT]. otherwise the civ has them only available if they somehow domesticated them
* you need [ANIMAL_ALWAYS_PET] to make them selectable for embark.

==Other notes about [ANIMAL] sapients==
* It can be assigned a (bed)room
* It can be assigned positions like tavern keeper or priest, but never any of the noble positions
* It cannot be assigned a pond or pit and cannot be tied to a rope
* It cannot be assigned to a trainer
* If an ANIMAL-sapient is brought by the merchants, it will come clothed and the merchants will charge extra for the clothing.
* Its thoughts can be viewed in full detail.
* It can be expelled. It does not seem to make any relationships at all.
* If they cannot speak, they are listed as livestock, but cannot be assigned labours, so they can be assigned labours if they are able to speak.
* If they cannot speak, they are trainable
Further testing is required to determine if it will petition for citizenship.
* If you catch a hostile creature in a war, it cannot be pacified. It can, however, be sold to traders.
* If you attack a site that is inhabited by the creature that you have defined as animal, you, unfortunately, cannot capture them as livestock.

==Example==
A mod that wants dwarves to have an enslaved caste can add a special `ANIMAL` caste to the dwarf creature. Setting its population ratio to `0` prevents enslaved dwarves from appearing as a separate natural population, while still allowing the caste to be used for individual enslaved dwarves.

For elves or other races, a separate copy of the creature can instead be used as the enslaved version. This provides more control over its properties, but the game treats it as a different creature.

Slavery

2026-10-02T09:44:28Z

Silverwing235: /* Assigning tasks */

This article describes slavery as represented by the game mechanics and world generation of ''Dwarf Fortress''. It does not endorse slavery or the treatment of sentient beings as property.

=Overview=
Slavery is not a major gameplay mechanic in ''Dwarf Fortress'', but the concept occurs in several parts of the game. Historical figures can become enslaved during world generation, and slavery can also occur through several distinct game mechanics.
The game represents several forms of enslavement, including:
* Child enslavement — Goblin snatchers abduct children, who may subsequently become slaves.
* Forced domestication — Goblins can enslave [[Trolls]] and use them as mounts, haulers or war animals.
* War slavery — Civilizations can enslave defeated enemies and bring them back to their settlements.
* Undead servitude — Undead creatures raised by necromancers can be regarded as being under the control of their creator.
* Slaves of Armok — The game's subtitle, Slaves to Armok: God of Blood Chapter II: Dwarf Fortress, uses slavery as part of the game's fictional terminology.
Slavery is also represented in the game's ethics system, which determines how different civilizations regard the practice.

=Civilizational attitudes=
Civilizations have different [[Ethic|ethical attitudes]] toward slavery.
{| class="wikitable"
|Civilization||Attitude toward slavery
|-
|Humans||Acceptable
|-
|Goblins||Personal Matter
|-
|Elves||Opposed; perpetrators may be punished with exile
|-
|Dwarves||Capital punishment
|}
These attitudes primarily determine how a civilization reacts to slavery as an ethical issue. They should not be confused with the separate mechanics through which slavery actually occurs.

=Slavery in world generation=
During world generation, historical figures can become enslaved. In mechanical terms, enslavement is closely related to imprisonment: an enslaved historical figure can potentially escape.
Relevant game definitions and tokens can be found in:
[[https://dwarffortresswiki.org/index.php/Unit_type_token]]
[[https://dwarffortresswiki.org/index.php/String_dump/raw]]

There are references to slavery like:

* "the end of the former enslavement of"
* "escaped from the slavery of"
* "escaped from the slavery of" / "escaped from the prisons of"
* "was enslaved by" / "was imprisoned by"
* "the enslavement" / "the imprisonment"
* "as a former slave of" / "as a former prisoner of"

=Child enslavement=
Goblins are particularly associated with the abduction of children. Goblin snatchers can enter settlements and abduct children.
See: [[Thief#Goblin_snatchers|Goblin snatchers]]

Abducted children can become part of the goblin civilization rather than remaining members of their original civilization.

Children can potentially be recovered through a citizen recovery mission. Adventurers can also encounter and rescue captives through quests.
See:
* [[Mission|Missions]]
* [[Quest|Quests]]

= Troll enslavement / forced domestication / sentient livestock=
[[Goblin|Goblins]] can also enslave [[Troll|Trolls]]. This is mechanically different from human-style war slavery. The Troll is treated as an animal-like creature under goblin control and can be used for purposes such as:
* carrying loads;
* pulling;
* riding;
* combat.
This creates a distinction between sapient creatures that are treated as animals and ordinary domesticated animals.
This form of enslavement is particularly relevant to modding because the [[Entity_Token#ANIMAL]] token can cause a creature to be treated mechanically as an animal, even when the creature is otherwise sapient.
The relevant distinction is between:
* a creature being part of the civilization's main race;
* a creature being defined as an animal or special animal caste;
* a creature being treated as a pet;
* a creature being used as a mount, puller or hauler.
This can produce a situation in which a creature is biologically or culturally sapient but is mechanically handled as livestock or a domesticated animal.

=War slavery=

Civilizations can enslave defeated enemies and take them back to their settlements. This can be described as spoils-of-war slavery or war enslavement.

The ethics value for slavery also affects whether a civilization is willing to accept caged sapient creatures from merchants.

Higher or lower ethical values appear to have relatively limited mechanical consequences, beyond determining whether the civilization permits slavery at all. The ethical value therefore primarily establishes the civilization's attitude toward the practice rather than providing a detailed slavery simulation.

=Undead servitude=
[[Necromancer|Necromancers]] can raise dead creatures as [[Undead]]. The resulting undead are generally under the control of the necromancer who created them.
This can be interpreted as another form of forced servitude, although the game does not necessarily classify undead as slaves in the same mechanical sense as enslaved historical figures.

=Modding Slavery=
There is no dedicated `SLAVE` creature mechanic in *Dwarf Fortress*. A mod can simulate slavery by defining the enslaved creature as an `ANIMAL` and also as PET. There are three main approaches.
{| class="wikitable"
|+ Modding approaches
|-
! Method !! Description !! Can be embarked with !! Can be traded !! Has slave-population in world-gen !! Can be trained !! Can have labours !! Can have a specific interaction !! Can have specific traits !! Can have a pet-value !! Slave can be married to non slave and have kids || Graphic modding needed
|-
| Existing creature as ANIMAL || Define a existing creature itself as an ANIMAL.|| yes || yes || yes || If non-speaking || If can_learn || No || No || yes || yes || no
|-
| Special caste as ANIMAL || Add a special caste to an existing creature and define that caste as an ANIMAL || Yes for the special caste, but not the main race || both || No || If non-speaking || If can_learn || Only for the special caste || Only for the special caste ||Yes, both || yes || yes
|-
| Creature copy as ANIMAL|| Create a copy of the original creature and define the copy as an ANIMAL. || Yes for the special creature, but not for the main race || both || Yes || If non-speaking || If can_learn || Only for the special creature || Only for the special creature || Yes, both || no || yes
|}
* Can be embarked with: creatures can be selected as livestock animals
* Can be traded: can be selected in the trade agreement
* Can have a specific interaction: an interaction specific for this slave-creature can be defined
* Can have specific traits: tokens as desired can be assigned to the slave-creature.

The choice depends on the desired behaviour. A special caste is useful when the enslaved version should remain closely connected to the original creature. A separate creature provides more freedom when the enslaved version needs substantially different properties.

==Assigning tasks==
* You can assign them tasks if they are [CAN_LEARN] and [CAN_SPEAK].

==How to make them show up==
* for creatures that do not naturally spawn, you need [ANIMAL_ALWAYS_PRESENT]. otherwise the civ has them only available if they somehow domesticated them
* you need [ANIMAL_ALWAYS_PET] to make them selectable for embark.

==Other notes about [ANIMAL] sapients==
* It can be assigned a (bed)room
* It can be assigned position like tavern keeper or priest
* It can never be assigned for any of the noble positions
* It cannot be assigned a pond or pit and cannot be tied to a rope
* It cannot be assigned to a trainer
* If an ANIMAL-sapient is brought by the merchants, it will come clothed and the merchants will charge extra for the clothing.
* Its thoughts can be viewed in full detail.
* It can be expelled. It does not seem to make any relationships at all.
* If they cannot speak, they are listed as livestock, but cannot be assigned labours, so they can be assigned labours if they are able to speak.
* If they cannot speak, they are trainable
Further testing is required to determine if it will petition for citizenship.
* If you catch a hostile creature in a war, it cannot be pacified. It can, however, be sold to traders.
* If you attack a site that is inhabited by the creature that you have defined as animal, you, unfortunately, cannot capture them as livestock.

==Example==
A mod that wants dwarves to have an enslaved caste can add a special `ANIMAL` caste to the dwarf creature. Setting its population ratio to `0` prevents enslaved dwarves from appearing as a separate natural population, while still allowing the caste to be used for individual enslaved dwarves.

For elves or other races, a separate copy of the creature can instead be used as the enslaved version. This provides more control over its properties, but the game treats it as a different creature.

Slavery

2026-10-02T09:43:43Z

Silverwing235: /* Other notes about ANIMAL-sapients */

This article describes slavery as represented by the game mechanics and world generation of ''Dwarf Fortress''. It does not endorse slavery or the treatment of sentient beings as property.

=Overview=
Slavery is not a major gameplay mechanic in ''Dwarf Fortress'', but the concept occurs in several parts of the game. Historical figures can become enslaved during world generation, and slavery can also occur through several distinct game mechanics.
The game represents several forms of enslavement, including:
* Child enslavement — Goblin snatchers abduct children, who may subsequently become slaves.
* Forced domestication — Goblins can enslave [[Trolls]] and use them as mounts, haulers or war animals.
* War slavery — Civilizations can enslave defeated enemies and bring them back to their settlements.
* Undead servitude — Undead creatures raised by necromancers can be regarded as being under the control of their creator.
* Slaves of Armok — The game's subtitle, Slaves to Armok: God of Blood Chapter II: Dwarf Fortress, uses slavery as part of the game's fictional terminology.
Slavery is also represented in the game's ethics system, which determines how different civilizations regard the practice.

=Civilizational attitudes=
Civilizations have different [[Ethic|ethical attitudes]] toward slavery.
{| class="wikitable"
|Civilization||Attitude toward slavery
|-
|Humans||Acceptable
|-
|Goblins||Personal Matter
|-
|Elves||Opposed; perpetrators may be punished with exile
|-
|Dwarves||Capital punishment
|}
These attitudes primarily determine how a civilization reacts to slavery as an ethical issue. They should not be confused with the separate mechanics through which slavery actually occurs.

=Slavery in world generation=
During world generation, historical figures can become enslaved. In mechanical terms, enslavement is closely related to imprisonment: an enslaved historical figure can potentially escape.
Relevant game definitions and tokens can be found in:
[[https://dwarffortresswiki.org/index.php/Unit_type_token]]
[[https://dwarffortresswiki.org/index.php/String_dump/raw]]

There are references to slavery like:

* "the end of the former enslavement of"
* "escaped from the slavery of"
* "escaped from the slavery of" / "escaped from the prisons of"
* "was enslaved by" / "was imprisoned by"
* "the enslavement" / "the imprisonment"
* "as a former slave of" / "as a former prisoner of"

=Child enslavement=
Goblins are particularly associated with the abduction of children. Goblin snatchers can enter settlements and abduct children.
See: [[Thief#Goblin_snatchers|Goblin snatchers]]

Abducted children can become part of the goblin civilization rather than remaining members of their original civilization.

Children can potentially be recovered through a citizen recovery mission. Adventurers can also encounter and rescue captives through quests.
See:
* [[Mission|Missions]]
* [[Quest|Quests]]

= Troll enslavement / forced domestication / sentient livestock=
[[Goblin|Goblins]] can also enslave [[Troll|Trolls]]. This is mechanically different from human-style war slavery. The Troll is treated as an animal-like creature under goblin control and can be used for purposes such as:
* carrying loads;
* pulling;
* riding;
* combat.
This creates a distinction between sapient creatures that are treated as animals and ordinary domesticated animals.
This form of enslavement is particularly relevant to modding because the [[Entity_Token#ANIMAL]] token can cause a creature to be treated mechanically as an animal, even when the creature is otherwise sapient.
The relevant distinction is between:
* a creature being part of the civilization's main race;
* a creature being defined as an animal or special animal caste;
* a creature being treated as a pet;
* a creature being used as a mount, puller or hauler.
This can produce a situation in which a creature is biologically or culturally sapient but is mechanically handled as livestock or a domesticated animal.

=War slavery=

Civilizations can enslave defeated enemies and take them back to their settlements. This can be described as spoils-of-war slavery or war enslavement.

The ethics value for slavery also affects whether a civilization is willing to accept caged sapient creatures from merchants.

Higher or lower ethical values appear to have relatively limited mechanical consequences, beyond determining whether the civilization permits slavery at all. The ethical value therefore primarily establishes the civilization's attitude toward the practice rather than providing a detailed slavery simulation.

=Undead servitude=
[[Necromancer|Necromancers]] can raise dead creatures as [[Undead]]. The resulting undead are generally under the control of the necromancer who created them.
This can be interpreted as another form of forced servitude, although the game does not necessarily classify undead as slaves in the same mechanical sense as enslaved historical figures.

=Modding Slavery=
There is no dedicated `SLAVE` creature mechanic in *Dwarf Fortress*. A mod can simulate slavery by defining the enslaved creature as an `ANIMAL` and also as PET. There are three main approaches.
{| class="wikitable"
|+ Modding approaches
|-
! Method !! Description !! Can be embarked with !! Can be traded !! Has slave-population in world-gen !! Can be trained !! Can have labours !! Can have a specific interaction !! Can have specific traits !! Can have a pet-value !! Slave can be married to non slave and have kids || Graphic modding needed
|-
| Existing creature as ANIMAL || Define a existing creature itself as an ANIMAL.|| yes || yes || yes || If non-speaking || If can_learn || No || No || yes || yes || no
|-
| Special caste as ANIMAL || Add a special caste to an existing creature and define that caste as an ANIMAL || Yes for the special caste, but not the main race || both || No || If non-speaking || If can_learn || Only for the special caste || Only for the special caste ||Yes, both || yes || yes
|-
| Creature copy as ANIMAL|| Create a copy of the original creature and define the copy as an ANIMAL. || Yes for the special creature, but not for the main race || both || Yes || If non-speaking || If can_learn || Only for the special creature || Only for the special creature || Yes, both || no || yes
|}
* Can be embarked with: creatures can be selected as livestock animals
* Can be traded: can be selected in the trade agreement
* Can have a specific interaction: an interaction specific for this slave-creature can be defined
* Can have specific traits: tokens as desired can be assigned to the slave-creature.

The choice depends on the desired behaviour. A special caste is useful when the enslaved version should remain closely connected to the original creature. A separate creature provides more freedom when the enslaved version needs substantially different properties.

==Assigning tasks==
* You can assign them tasks if they are CAN_LEARN and CAN_SPEAK

==How to make them show up==
* for creatures that do not naturally spawn, you need [ANIMAL_ALWAYS_PRESENT]. otherwise the civ has them only available if they somehow domesticated them
* you need [ANIMAL_ALWAYS_PET] to make them selectable for embark.

==Other notes about [ANIMAL] sapients==
* It can be assigned a (bed)room
* It can be assigned position like tavern keeper or priest
* It can never be assigned for any of the noble positions
* It cannot be assigned a pond or pit and cannot be tied to a rope
* It cannot be assigned to a trainer
* If an ANIMAL-sapient is brought by the merchants, it will come clothed and the merchants will charge extra for the clothing.
* Its thoughts can be viewed in full detail.
* It can be expelled. It does not seem to make any relationships at all.
* If they cannot speak, they are listed as livestock, but cannot be assigned labours, so they can be assigned labours if they are able to speak.
* If they cannot speak, they are trainable
Further testing is required to determine if it will petition for citizenship.
* If you catch a hostile creature in a war, it cannot be pacified. It can, however, be sold to traders.
* If you attack a site that is inhabited by the creature that you have defined as animal, you, unfortunately, cannot capture them as livestock.

==Example==
A mod that wants dwarves to have an enslaved caste can add a special `ANIMAL` caste to the dwarf creature. Setting its population ratio to `0` prevents enslaved dwarves from appearing as a separate natural population, while still allowing the caste to be used for individual enslaved dwarves.

For elves or other races, a separate copy of the creature can instead be used as the enslaved version. This provides more control over its properties, but the game treats it as a different creature.

Slavery

2026-10-02T09:36:24Z

Silverwing235:

This article describes slavery as represented by the game mechanics and world generation of ''Dwarf Fortress''. It does not endorse slavery or the treatment of sentient beings as property.

=Overview=
Slavery is not a major gameplay mechanic in ''Dwarf Fortress'', but the concept occurs in several parts of the game. Historical figures can become enslaved during world generation, and slavery can also occur through several distinct game mechanics.
The game represents several forms of enslavement, including:
* Child enslavement — Goblin snatchers abduct children, who may subsequently become slaves.
* Forced domestication — Goblins can enslave [[Trolls]] and use them as mounts, haulers or war animals.
* War slavery — Civilizations can enslave defeated enemies and bring them back to their settlements.
* Undead servitude — Undead creatures raised by necromancers can be regarded as being under the control of their creator.
* Slaves of Armok — The game's subtitle, Slaves to Armok: God of Blood Chapter II: Dwarf Fortress, uses slavery as part of the game's fictional terminology.
Slavery is also represented in the game's ethics system, which determines how different civilizations regard the practice.

=Civilizational attitudes=
Civilizations have different [[Ethic|ethical attitudes]] toward slavery.
{| class="wikitable"
|Civilization||Attitude toward slavery
|-
|Humans||Acceptable
|-
|Goblins||Personal Matter
|-
|Elves||Opposed; perpetrators may be punished with exile
|-
|Dwarves||Capital punishment
|}
These attitudes primarily determine how a civilization reacts to slavery as an ethical issue. They should not be confused with the separate mechanics through which slavery actually occurs.

=Slavery in world generation=
During world generation, historical figures can become enslaved. In mechanical terms, enslavement is closely related to imprisonment: an enslaved historical figure can potentially escape.
Relevant game definitions and tokens can be found in:
[[https://dwarffortresswiki.org/index.php/Unit_type_token]]
[[https://dwarffortresswiki.org/index.php/String_dump/raw]]

There are references to slavery like:

* "the end of the former enslavement of"
* "escaped from the slavery of"
* "escaped from the slavery of" / "escaped from the prisons of"
* "was enslaved by" / "was imprisoned by"
* "the enslavement" / "the imprisonment"
* "as a former slave of" / "as a former prisoner of"

=Child enslavement=
Goblins are particularly associated with the abduction of children. Goblin snatchers can enter settlements and abduct children.
See: [[Thief#Goblin_snatchers|Goblin snatchers]]

Abducted children can become part of the goblin civilization rather than remaining members of their original civilization.

Children can potentially be recovered through a citizen recovery mission. Adventurers can also encounter and rescue captives through quests.
See:
* [[Mission|Missions]]
* [[Quest|Quests]]

= Troll enslavement / forced domestication / sentient livestock=
[[Goblin|Goblins]] can also enslave [[Troll|Trolls]]. This is mechanically different from human-style war slavery. The Troll is treated as an animal-like creature under goblin control and can be used for purposes such as:
* carrying loads;
* pulling;
* riding;
* combat.
This creates a distinction between sapient creatures that are treated as animals and ordinary domesticated animals.
This form of enslavement is particularly relevant to modding because the [[Entity_Token#ANIMAL]] token can cause a creature to be treated mechanically as an animal, even when the creature is otherwise sapient.
The relevant distinction is between:
* a creature being part of the civilization's main race;
* a creature being defined as an animal or special animal caste;
* a creature being treated as a pet;
* a creature being used as a mount, puller or hauler.
This can produce a situation in which a creature is biologically or culturally sapient but is mechanically handled as livestock or a domesticated animal.

=War slavery=

Civilizations can enslave defeated enemies and take them back to their settlements. This can be described as spoils-of-war slavery or war enslavement.

The ethics value for slavery also affects whether a civilization is willing to accept caged sapient creatures from merchants.

Higher or lower ethical values appear to have relatively limited mechanical consequences, beyond determining whether the civilization permits slavery at all. The ethical value therefore primarily establishes the civilization's attitude toward the practice rather than providing a detailed slavery simulation.

=Undead servitude=
[[Necromancer|Necromancers]] can raise dead creatures as [[Undead]]. The resulting undead are generally under the control of the necromancer who created them.
This can be interpreted as another form of forced servitude, although the game does not necessarily classify undead as slaves in the same mechanical sense as enslaved historical figures.

=Modding Slavery=
There is no dedicated `SLAVE` creature mechanic in *Dwarf Fortress*. A mod can simulate slavery by defining the enslaved creature as an `ANIMAL` and also as PET. There are three main approaches.
{| class="wikitable"
|+ Modding approaches
|-
! Method !! Description !! Can be embarked with !! Can be traded !! Has slave-population in world-gen !! Can be trained !! Can have labours !! Can have a specific interaction !! Can have specific traits !! Can have a pet-value !! Slave can be married to non slave and have kids || Graphic modding needed
|-
| Existing creature as ANIMAL || Define a existing creature itself as an ANIMAL.|| yes || yes || yes || If non-speaking || If can_learn || No || No || yes || yes || no
|-
| Special caste as ANIMAL || Add a special caste to an existing creature and define that caste as an ANIMAL || Yes for the special caste, but not the main race || both || No || If non-speaking || If can_learn || Only for the special caste || Only for the special caste ||Yes, both || yes || yes
|-
| Creature copy as ANIMAL|| Create a copy of the original creature and define the copy as an ANIMAL. || Yes for the special creature, but not for the main race || both || Yes || If non-speaking || If can_learn || Only for the special creature || Only for the special creature || Yes, both || no || yes
|}
* Can be embarked with: creatures can be selected as livestock animals
* Can be traded: can be selected in the trade agreement
* Can have a specific interaction: an interaction specific for this slave-creature can be defined
* Can have specific traits: tokens as desired can be assigned to the slave-creature.

The choice depends on the desired behaviour. A special caste is useful when the enslaved version should remain closely connected to the original creature. A separate creature provides more freedom when the enslaved version needs substantially different properties.

==Assigning tasks==
* You can assign them tasks if they are CAN_LEARN and CAN_SPEAK

==How to make them show up==
* for creatures that do not naturally spawn, you need [ANIMAL_ALWAYS_PRESENT]. otherwise the civ has them only available if they somehow domesticated them
* you need [ANIMAL_ALWAYS_PET] to make them selectable for embark.

==Other notes about ANIMAL-sapients==
* It can be assigned a (bed)room
* It can be assigned position like tavern keeper or priest
* It can never be assigned for any of the noble positions
* It cannot be assigned a pond or pit and cannot be tied to a rope
* It cannot be assigned to a trainer
* If an ANIMAL-sapient is brought by the merchants, it will come clothed and the merchants will charge extra for the clothing.
* Its thoughts can be viewed in full detail.
* It can be expelled. It does not seem to make any relationships at all.
* If they cannot speak, they are listed as livestock, but cannot be assigned labours, so they can be assigned labours, if they are able to speak.
* If they cannot speak, they are trainable
Further testing is required to determine if it will petition for citizenship.
* If you catch a hostile creature in a war, it cannot be pacified. It can, however, be sold to traders.
* If you attack a site that is inhabited by the creature that you have defined as animal, you, unfortunately, cannot capture them as livestock.

==Example==
A mod that wants dwarves to have an enslaved caste can add a special `ANIMAL` caste to the dwarf creature. Setting its population ratio to `0` prevents enslaved dwarves from appearing as a separate natural population, while still allowing the caste to be used for individual enslaved dwarves.

For elves or other races, a separate copy of the creature can instead be used as the enslaved version. This provides more control over its properties, but the game treats it as a different creature.

Pet

2026-09-29T17:47:08Z

Silverwing235:

{{Quality|Exceptional|10:37, 21 February 2023 (CST)}}
{{av}}
[[File:pet_preview.png|right]]'''Pets''' are [[creatures]] that have been adopted by your [[dwarves]]. Almost all domestic animals that are not pets are termed "[[stray]]" animals. All creatures that can be [[Animal trainer|trained]] (those possessing either the {{token|PET}} or {{token|PET_EXOTIC}} [[creature token]]s) can be made into pets; in the case of dwarves, that is most creatures that are not [[:Category:Humanoids|sapient]] (''emphasis on the'' "[[Animal_trainer#Taming_intelligent_creatures|most]]"). All pets will follow their owners around, providing a companionship [[happiness]] bonus (based on the creature's pet value), being fed by their owners if they are [[grazer]]s, and, in many cases, protecting them from harm, either by actively attacking enemies, or by acting as meat shields that allow their charges to scramble away to safety.

==Mechanics==
=== Pet value ===
{{Translation
| dwarven = bab
| elvish = querete
| goblin = amro
| human = pathril}}All creatures who can become pets (and some who can't, because of missing the aforementioned creature tokens) possess a '''pet value''' in their raw files which determines how much they are worth. Higher pet values normally imply the animal is more exotic, impressive or uncommon than others. For example, a [[dog]] has a pet value of 30, a [[jaguar]] of 50, a [[panda]] of 300 and a [[cave crocodile]] 700. A creature with no pet value is treated as having a value of 0. See the full [[list of creatures by pet value]] for details.

Dwarves who adopt creatures with high pet values will be slightly happier than those who adopt creatures with low ones, so Urist McSpiderlover will be especially cheerful to have a [[giant cave spider]] following them around, when compared to Urist McCarrotlover and their [[rabbit]]s {{verify}}. Regardless, both low-value and high-value pets are a means to keep dwarves from becoming stressed.

Pet value is most relevant for [[trading]], as it determines how many [[Currency|dwarfbucks]] you'll receive for selling the creature away. It also interferes directly upon taking [[domestic animal]]s during [[embark]]ing, as animals with higher pet values will cost more points than others. The cost in points in the embarking screen is 1+(pet value/2) for an untrained animal and 1+pet value for a war/hunting one.

=== Adopting ===
Pets normally cannot be assigned; rather, dwarves will adopt them on an ''ad hoc'' basis. The only exception is [[Animal trainer|trained hunting and war animals]], which will be adopted by whomever they are assigned to. Dwarves that are idling near a wandering [[stray]] animal that was set available for adoption may choose to make them their pet, giving them a name, causing the animal to follow them around, and giving the owner a {{dftext|happy|2:1}}{{dftext| after adopting a new pet|7:0}} [[thought]]. The chances of this event happening are strongly influenced by your dwarves' personal [[preferences]]; while they will rarely go out of their way to adopt animals, every dwarf has a preference for a certain creature, and will select them as pets when available, often resulting in, say, the fortress engraver being followed around by a family of [[dog]]s. If the owner of a pet dies, the pet will keep their name but become a stray.

You can control what animals are up for adoption through the animal {{menu icon|u}} Units menu, in the "Pets/Livestock" tab. There, you can toggle {{dftext|Available|3:1}} / {{dftext|Unavailable|4:1}} on each tame individual, freeing them up for adoption. Animals will never be adopted out of a [[cage]], and must be let out to roam for adoption to take place. [[Stray]] animals tend to accumulate at [[meeting area]]s, which facilitates adoption. Make sure that your meeting areas are large enough to accommodate all your strays and prevent [[overcrowding]], and be aware that [[grazer|grazing]] animals tend to starve to death in your [[dining room]] if you do not assign them to a [[pasture]] instead.

Note that dwarves with a [[preference]] for an animal may adopt that animal ''despite'' its not being available for adoption.

If a [[grazer]] which is ''already'' a pet becomes hungry, it will generate a job for its owner to feed it; however, this job is low-priority, so it's possible for the pet to starve to death if the owner is otherwise occupied.

[[Cat]]s are notable for being an exception to the rule; they will assign ''themselves'' to dwarves, and cannot be made available or unavailable. Vermin pets will perch on their masters' shoulders, protecting them from those darned cats.

==== Determining ownership ====

For a specific animal, you can also use the {{menu icon|u}} Units menu, under "Pets/Livestock". Click on [[File:Mag glass icon.png]] near specific animal to zoom to that pet's location and automatically view the details of that creature. At the top of the general information screen (which is the default) are listed the creature's name, the translation of that name, and, if owned, it will state {{dftext|Pet of <the owner>|7:1}}. If no owner is listed*, then it is unclaimed.

(* Usually an unclaimed pet will also be unnamed, however it is possible for a stray animal to earn a name, usually by killing wild animals - this also happens to be true of wild animals who kill dwarves.)

=== Utility ===
Pets will provide a happiness bonus to their owner for the duration of their or their owner's lives. If the dwarf dies, the animal becomes a stray, and is available for adoption again. If the pet dies, the owner will get a negative thought, made worse if the pet isn't given a proper [[burial]]. This even happens if the pet dies peacefully, from old age.

As long as a creature is somebody's pet, they cannot be [[butcher]]ed, [[restraint|chained]], or [[cage]]d; this can lead to a [[catsplosion]] when there are several crazy cat ladies in your fortress, and you don't immediately butcher all the kittens or geld the tomcats. If you do manage to assign a pet to a cage or restraint (by issuing the order before the adoption), the new owner will attempt to release it. Newly acquired pets that were previously scheduled for butchering will still be butchered, however the new owner will experience a negative thought from the loss of their pet.

Another possible use is for large grazers, which are unable to keep themselves fed via grazing. By turning them into a pet, you can, essentially, have a dwarf dedicated to keeping them fed. This could open up some interesting options (such as utilizing tame [[elephant]]s, without worrying about them starving themselves).

==Types of pets==
=== Good pets ===
The value of a pet is based upon the species' internal pet value. It also helps if the animals in question aren't useful for anything else, although assigning pets to pastures to keep them in place works fine, allowing such things as pet [[alligator]] [[egg production|egg farms]]. Milkable and shearable pets are excellent, since they can still be taken to a [[farmer's workshop]] to get their goods. The best pets of all are [[cave dragon]]s and [[megabeast]]s, if the world is old enough and/or you are lucky enough to cage some.

=== Bad pets ===
Some animals, especially [[Domestic_animal|poultry]], root around, which can attract vermin. This makes them bad as pets that follow your dwarves around. They can still be pastured, which prevents them from wandering around your fort, and both the positive and negative effects of a pet, until the pet dies.

=== Migrant pets ===
[[Migrant]]s will bring stray animals, but may also bring one or more pets along. While this can be a boon, some players may find it a hindrance; pet animals with no value beyond [[butchery]], such as [[mule]]s, may be viewed as clutter, and, as pets, cannot simply be butchered. One solution is to assign them to a [[zone]] designated as a pasture somewhere conveniently dangerous, such as under an [[bridge|atom smasher]], or in a field to trip up [[ambush|ambushers]]. Be warned that dead pets do generate negative [[thought]]s, so it's a judgement call as to which is worse.

=== Vermin ===
Many types of [[vermin]] can be trained and set as available to be a pet. In practice, dwarves rarely have a preference for vermin, and so they generally won't adopt any. Adopted vermin are carried by the dwarf as an item-a dwarf may adopt up to three, but migrant dwarves never arrive with vermin for a pet.

== In Adventurer Mode ==
''Main article: [[Mount#Adventure mode]]''

[[Adventurer]]s can buy pets during [[Adventurer mode character creation#Mounts and pets|character creation]], or claim stray animals. Pets follow their owner while exploring the world.

To claim a stray animal, walk up to it and press {{adv menu icon|h}}, then choose to claim it in the menu - this action always succeeds. Pets can be gifted to other people as a [[Talking|conversation]] option, listed as "Gift a (large) pet or mount (new menu)".

Using [[Necromancer|necromancy]] to reanimate a corpse will also claim the resulting [[undead]] creature as a pet.

=== Combat ===
Pets will join their owner's [[Level of conflict|conflicts]] - as animals don't have access to non-lethal [[combat]], fighting alongside an animal will escalate the fight to Lethal.
[[Animal trainer#Hunting/War training|Hunting and war trained]] animals can be bought during character creation, improving their sight range or attacks respectively.

=== Utility ===
Provided the creature has the requisite abilities ({{token|MOUNT}}/{{token|MOUNT_EXOTIC}} or {{token|PACK_ANIMAL}} respectively), pets can be ridden or used to store items.

==See also==
*[[Animal trainer]]
*[[Animal caretaker]]
*[[Exotic pet]]
*[[Mount]]
*[[Adventurer mode gameplay#Companions|Companions]]

[[ru:Pet]]
{{category|Creature attributes}}
{{category|Fortress mode}}
{{category|Adventurer mode}}

Tool

2026-09-29T11:52:06Z

Silverwing235:

{{Quality|Superior}}
{{av}}

[[File:tools_sprites_preview.png|right]]'''Tools''' are finished goods, used for a variety of mundane purposes by civilians and [[night creature]]s. Some tools can also be used as [[weapon]]s, though it is usually much better to use, say, a [[sword]] over a carving fork. [[Tools#Other Tools|Other tools]] can be created and used by your dwarves in [[fortress mode]], including as [[furniture]]. [[Honeycomb]]s also count as tools, and are stockpiled as such.

==Tools Usable as Weapons==
{| class="wikitable" border="border"
! Type
! Graphic
! Size
! Attack
! [[Attack type]]
! Contact Area
! Penetration
! Velocity
! [[DF2012:Combat_skill#Weapon_skills|Skill Used]]
|- valign="top"
|rowspan="3"| Carving knife
|rowspan="3"|[[File:carving_knife_sprite.png]]
|rowspan="3"|150
| Slash || Edge || 800 || 600 || 1.25×
|rowspan="3"| Dagger
|-
| Stab || Edge || 4 || 800 || 1×
|-
| Handle strike || Blunt || 15 || (400) || 1×
|- valign="top"
|rowspan="3"| Boning knife
|rowspan="3"|[[File:boning_knife_sprite.png]]
|rowspan="3"|50
| Slash || Edge || 500 || 300 || 1.25×
|rowspan="3"| Dagger
|-
| Stab || Edge || 2 || 400 || 1×
|-
| Handle strike || Blunt || 10 || (200) || 1×
|- valign="top"
|rowspan="3"| Slicing knife
|rowspan="3"|[[File:slicing_knife_sprite.png]]
|rowspan="3"|150
| Slash || Edge || 900 || 700 || 1.25×
|rowspan="3"| Dagger
|-
| Stab || Edge || 3 || 900 || 1x
|-
| Handle strike || Blunt || 15 || (400) || 1×
|- valign="top"
|rowspan="3"| Meat cleaver
|rowspan="3"|[[File:meat_cleaver_sprite.png]]
|rowspan="3"|300
| Hack || Edge || 800 || 400 || 1.25×
|rowspan="3"| Axe
|-
| Flat slap || Blunt || 800 || (400) || 1.25×
|-
| Handle strike || Blunt || 20 || (400) || 1×
|- valign="top"
|rowspan="2"| Carving fork
|rowspan="2"|[[File:carving_fork_sprite.png]]
|rowspan="2"|150
| Stab || Edge || 1 || 100 || 1×
|rowspan="2"| Dagger
|-
| Handle strike || Blunt || 15 || 400 || 1×
|- valign="top"
|rowspan="3"| (Stone) Axe
|rowspan="3"|[[File:stone_axe_sprite.png]]
|rowspan="3"|400
| Hack || Edge || 800 || 400 || 1.25×
|rowspan="3"| Axe
|-
| Flat slap || Blunt || 800 || 400 || 1×
|-
| Helve strike || Blunt || 20 || 400 || 1×
|}

==Other Tools==

{| class="wikitable sortable" border="border"
|-
! Type
! Tile
! Graphic
! Size (cm³)
! Material
! Capacity (cm³)
! Base Value
! Usage
|-
| Cauldron || style="text-align:center;" | {{Tile|ô|7:1}} || style="text-align:center;" | [[File:cauldron_sprite.png]] || 4000 || Metal 6 || 100,000 || 50 || Cooking liquids
|-
| Ladle || style="text-align:center;" | {{Tile|♪|7:1}} || style="text-align:center;" | [[File:ladle_sprite.png]] || 100 || Metal 1 || n/a || 10 || Liquid scoop
|-
| Bowl || style="text-align:center;" | {{Tile|°|7:1}} || style="text-align:center;" | [[File:bowl_sprite.png]] || 100 || Stone 1 || 3,000 || 10 || Meal container
|-
| Mortar || style="text-align:center;" | {{Tile|°|7:1}} || style="text-align:center;" | [[File:mortar_sprite.png]] || 100 || Stone 1 || 1,000 || 10 || Grind powder, receptacle
|-
| Pestle || style="text-align:center;" | {{Tile|/|7:1}} || style="text-align:center;" | [[File:pestle_sprite.png]] || 20 || Stone 1 || n/a || 10 || Grind powder, grinder
|-
| [[Nest box]] || style="text-align:center;" | {{Tile|◘|7:1}} || style="text-align:center;" | [[File:nest_box_sprite.png]] || 1000 || Any Hard 1 || 2,000 || 10 || Contains eggs
|-
| [[Jug]] || style="text-align:center;" | {{Tile|σ|7:1}} || style="text-align:center;" | [[File:jug_sprite.png]] || 300 || Any Hard 1 || 10,000 || 10 || Liquid container
|-
| [[Large pot]] || style="text-align:center;" | {{Tile|Φ|7:1}} || style="text-align:center;" | [[File:large_pot_sprite.png]] || 5000 || Any Hard 1 || 60,000 || 10 || Food storage
|-
| [[Hive]] || style="text-align:center;" | {{Tile|▬|7:1}} || style="text-align:center;" | [[File:hive.png]] || 2000 || Any Hard 1 || 5,000 || 10 || [[Beekeeping industry|Beekeeping]]
|-
| [[Honeycomb]] || style="text-align:center;" | {{Tile|∞|7:1}} || style="text-align:center;" | [[File:honeycomb_sprite.png]] || 1000 || n/a 1 || n/a || 10 || n/a
|-
| [[Storage|Pouch]] || style="text-align:center;" | {{Tile|¡|7:1}} || style="text-align:center;" | [[File:pouch_sprite.png]] || 100 || Soft 1 || 1,000 || 10 || Small object storage
|-
| [[Minecart]] || style="text-align:center;" | {{Tile|■|0:7:1}} || style="text-align:center;" | [[File:minecart_sprite.png]] || 40,000 || Wood/Metal 6 || 500,000 || 50 || Tracked cart
|-
| [[Wheelbarrow]] || style="text-align:center;" | {{Tile|Ö|7:1}} || style="text-align:center;" | [[File:wheelbarrow_sprite.png]] ||30,000 || Wood/Metal 6 || 100,000 || 50 || Heavy object hauling
|-
| [[Stepladder]] || style="text-align:center;" |{{Tile|₧|7:1}} || style="text-align:center;" | [[File:stepladder_sprite.png]] || 40,000 || Wood/Metal 6 || n/a || 50 || Fruit collection
|-
| Scroll rollers || style="text-align:center;" | {{Tile|÷|7:1}} || style="text-align:center;" | [[File:scroll roller sprite.png ]] || 100 || Any Hard 1 || n/a || 10 || Roll up sheets
|-
| [[Book binding]] || style="text-align:center;" |{{Tile|÷|7:1}} || style="text-align:center;" | [[File:book_binding_sprite.png]] || 100 || Any Hard 1 || n/a || 10 || Protect folded sheets
|-
| [[Scroll]] || style="text-align:center;" |{{Tile|∞|7:1}} || style="text-align:center;" | [[File:scroll_sprite.png]] || 200 || Any Sheet 1 || n/a || 20 || Contains writing
|-
| [[Quire]] || style="text-align:center;" |{{Tile|≡|7:1}} || style="text-align:center;" | [[File:quire_sprite.png]] || 100 || Any Sheet 1 || n/a || 20 || Contains writing
|-
| [[Bookcase]] || style="text-align:center;" |{{Tile|≡|0:7:1}} || style="text-align:center;" | [[File:bookcase_sprite.png]] || 1000 || Any Hard 6 || 100,000 || 10 || Bookcase (Furniture)
|-
| Helve || style="text-align:center;" | {{Tile|\|7:1}} || style="text-align:center;" | [[File:helve_sprite.png]] ||250 || Branch 1 || n/a || 10 || Crafting stone axes in [[adventure mode]]
|-
| [[Pedestal]] || style="text-align:center;" | {{Tile|ï|7:1}} || style="text-align:center;" | [[File:pedestal_sprite.png]] || 500 || Any Hard 6 || || 10 || Display furniture
|-
| [[Display case]] || style="text-align:center;" | {{Tile|π|0:7:1}} || style="text-align:center;" | [[File:display_case_sprite.png]] || 1000 || [[Log]] + [[Window]]|| || 10 || Display furniture
|-
| [[Altar]] || style="text-align:center;" | {{Tile|É|7:1}} || style="text-align:center;" | [[File:altar_sprite.png]] || 500 || Any Hard 6 || || 10 || Offering place (Furniture)
|-
| [[Die]] (a.k.a. dice) || style="text-align:center;" | {{Tile|◘|7:1}} || style="text-align:center;" | [[File:die_sprite.png]] || 5 || Any Hard 1 || || 1 || Divination
|-
| [[Instrument#Components|Instrument component]] || style="text-align:center;" | {{Tile|¢|7:1}} || style="text-align:center;" | [[File:Instrument sprite.png]] || Varies || Varies || || 10 || Constructing [[instrument]]s
|}

Hard materials include stone, metal, wood, and glass. Soft materials include silk, plant fibers, leather and adamantine thread. Sheet materials include papyrus, paper, and parchment.

A tool needs capacity of 600 per unit of [[liquid]] to contain: a jug can hold 10,000/600 = 16 units of liquid, a submerged minecart scoops 500,000/600 = 833 units of magma or water, etc.

==See also==
* [[Tool token]]

{{Translation
| dwarven = lòr
| elvish = wanala
| goblin = êngan
| human = shem
}}

{{Category|Items| }}
{{Gamedata|{{raw|v50:item_tool.txt|}}}}
[[ru:Tool]]

Tool

2026-09-29T11:51:47Z

Silverwing235: inaccurate for 53.16 adv mode, and perhaps further back - it is uncertain how far

Creature token

2026-09-28T22:08:43Z

Silverwing235: typo

{{Quality|Exceptional}}
{{av}}
{{Modding}}

The <code>[OBJECT:CREATURE]</code> [[token]] begins the definition of a ''Dwarf Fortress'' [[creature]] [[raw file]]. Each creature definition that follows begins with the {{token|creature|c|creature ID}} token, and the creature's exact properties and behavior are then specified by the use of further creature tokens. All known creature tokens are listed below.

Vanilla creature definitions can be found in <code>[[Game folder|<Dwarf Fortress>]]\data\vanilla\vanilla_creatures\</code>.
Creature ID is also used with [[graphics token]]s to make customizable [[graphics set]]s.

The [[caste]] tokens allow defining sub-species within the broader creature definition, including true biological castes and lesser variations, such as sexes. Creature tokens can either be 'Creature' or 'CASTE-only' type which can only be applied to creature or caste respectively, or 'CASTE' which can be applied to both. In the table bellow, creature type distinguishes tokens that can be applied to creature only, caste only, and both ('creature', 'CASTE-only', and 'CASTE' respectively)

__NOTOC__
{{clear}}
{{alphabetical TOC|style=margin: 1em auto;}}

==A==
{| {{prettytable}}
|- bgcolor="#ddd"
! width="20%" | Token
! width="10%" | Type
! width="20%" | Arguments
! width="50%" | Description

|-
| {{text anchor|ADOPTS_OWNER}}
| Caste
|
| Prevents the tamed creature from being made available for adoption, instead allowing it to automatically adopt whoever it wants. The basic requirements for adoption are intact, and the creature will only adopt individuals who have a [[preference]] for their species. Used by [[cat]]s in the vanilla game. When {{k|v}}iewing a tame creature with this token, the message "This animal isn't interested in your wishes" will appear instead of "This [adorable] animal can't work" or "This animal is waiting to be trained".

|-
| {{text anchor|ALCOHOL_DEPENDENT}}
| Caste
|
| Makes the creature need [[alcohol]] to get through the working day; it will choose to drink booze instead of [[water]] if possible. Going sober for too long reduces speed.

|-
| {{text anchor|ALL_ACTIVE}}
| Caste
|
| When set, the creature will appear at any time of day. Overrides {{token|DIURNAL|c}}, {{token|NOCTURNAL|c}}, {{token|CREPUSCULAR|c}}, {{token|MATUTINAL|c}}, and {{token|VESPERTINE|c}}.

|-
| {{text anchor|ALTTILE}}
| Creature
|
*'character' or tile number
| If set, the creature will blink between its {{token|TILE|c}} and its ALTTILE.

|-
| {{text anchor|AMBUSHPREDATOR}}
| Caste
|
| Makes the creature start out hidden and remain near its original location until its prey draws near. When combined with {{token|WEBBER|c}}, causes them to lay gigantic webs near their spawn location, though only for creatures present during embark.

|-
| {{text anchor|AMPHIBIOUS}}
| Caste
|
| Allows a creature to breathe both in and out of [[water]] (unlike {{token|AQUATIC|c}}) - does not prevent drowning in [[magma]].

|-
| {{text anchor|APP_MOD_DESC_RANGE}}
| Appearance Modifier
|
*Range (6 values, low to high)
| Based on info from [http://www.bay12forums.com/smf/index.php?topic=113762.msg3473069#msg3473069 Wannabehero on the forums]: When used with an appearance modifier token (BP_APPEARANCE_MODIFIER or BODY_APPEARANCE_MODIFIER), tells the game what numeric ranges to map to which descriptors.

The game uses 7 descriptor levels for each modifier, with the center one generally being to omit the thing from the creature description entirely. The six values in APP_MOD_DESC_RANGE define the boundaries between each described range. If this is not specified it uses the numbers 10:50:95:105:150:190.

|-
| {{text anchor|APP_MOD_GENETIC_MODEL}}
| Appearance Modifier
|
*Model (Accepts DOMINANT_MORE, DOMINANT_LESS, and MIX)
| Defines a genetic model for the relevant appearance modifier(s). May or may not do anything significant at present.

|-
| {{text anchor|APP_MOD_IMPORTANCE}}
| Appearance Modifier
|
*number
| Determines how important the appearance modifier is, for determining whether it shows up in the creature description.{{verify}}

|-
| {{text anchor|APP_MOD_NOUN}}
| Appearance Modifier
|
*noun
*SINGULAR or PLURAL
| Creates a noun for the appearance, and whether it is singular or plural.

|-
| {{text anchor|APP_MOD_RATE}}
| Appearance Modifier
|
*Rate (integer)
*Scale (DAILY, YEARLY)
*min (growth)
*max (growth)
*start year
*start day
*end year
*end day
| Setting the growth rate of the modifier. The last two tokens can be replaced by NO_END to have growth continue indefinitely.

|-
| {{text anchor|APPLY_CREATURE_VARIATION}}
| Caste
|
*creature variation ID
*(optional) any amount of arbitrary arguments
| Applies the specified [[creature variation token|creature variation]]. See [[Creature_variation_token#Arguments_and_conditional_tokens]] for how the subsequent arguments may be used.

|-
| {{text anchor|APPLY_CURRENT_CREATURE_VARIATION}}
| Special
|
| Applies the effects of all pending {{token|CV_ADD_TAG|c}} and {{token|CV_REMOVE_TAG|c}} tokens that have been defined in the current creature.

|-
| {{text anchor|AQUATIC}}
| Caste
|
| Enables the creature to breathe in water, but causes it to air-drown on dry land.

|-
| {{text anchor|ARENA_RESTRICTED}}
| Caste
|
| Causes the creature to be excluded from the [[object testing arena]]'s creature spawning list. Typically applied to spoileriffic creatures.

|-
| {{text anchor|ARTIFICIAL_HIVEABLE}}
| Creature
|
| Enables the creature to be kept in artificial [[hive]]s by [[beekeeper]]s.

|-
| {{text anchor|AT_PEACE_WITH_WILDLIFE}}
| Caste
|
| Prevents the creature from attacking or frightening creatures with the {{Token|NATURAL|c}} tag.

|-
| {{text anchor|ATTACK}}
| Caste
|
*token
*selection criteria (it's complicated)
| Defines the attack name, and the body part used. See [[#Attack Tokens|below]] for valid subtokens
'''Example:''' 
<code>[ATTACK:GORE:BODYPART:BY_CATEGORY:HORN]</code> 
''GORE'' = name of the attack 
''BODYPART:BY_CATEGORY:HORN'' = the horn is used to attack (presuming the creature has one)

|-
| {{text anchor|ATTACK_TRIGGER}}
| Caste
|
*population
*exported wealth
*created wealth
| Specifies when a [[megabeast]] or [[semi-megabeast]] will attack the fortress. The attacks will start occurring when all of the requirements are met. Setting a value to 0 disables the trigger.

|}

{{alphabetical TOC|style=margin: 1em auto;}}

==B==
{| {{prettytable}}
|- bgcolor="#ddd"
! width="20%" | Token
! width="10%" | Type
! width="20%" | Arguments
! width="50%" | Description

|-
| {{text anchor|BABY}}
| Caste
|
*integer
| Age at which creature is considered a child, the default is zero. One can think of this as the duration of the baby stage.

|-
| {{text anchor|BABYNAME}}
| Caste
|
*singular
*plural
| Defines a new name for a creature in baby state at the caste level. For non-caste-specific baby names, see {{token|GENERAL_BABY_NAME|c}}.

|-
| {{text anchor|BEACH_FREQUENCY}}
| Caste
|
*integer
| Creature may be subject to [[beaching]], becoming stranded on [[Beach|shores]], where they will eventually air-drown. The number indicates the frequency of the occurrence. Presumably requires the creature to be {{token|AQUATIC|c}}. Used by [[orca]]s, [[sperm whale]]s and [[sea nettle jellyfish]] in the vanilla game.

|-
| {{text anchor|BENIGN}}
| Caste
|
| The creature is non-aggressive by default, and will never automatically be engaged by companions or soldiers, running away from any creatures that are not friendly to it, and will only defend itself if it becomes enraged. Can be thought of as the counterpoint of the {{token|LARGE_PREDATOR|c}} tag. When tamed, animals with this tag will be useless for fortress defense.

This and {{token|TRADE_CAPACITY|c}} are required for {{token|PACK_ANIMAL|c}} to function properly, if an animal contains the aforementioned requirements without this tag: items loaded by the merchants will be dropped upon departure.

|-
| {{text anchor|BIOME}}
| Creature
|
* [[biome token]]
| Select a [[biome]] the creature may appear in.

|-
| {{text anchor|BLOOD}}
| Caste
|
* <[[material token]]>
* <[[Material_definition_token#Material_States|material state]]>
| Specifies what the creature's blood is made of.

|-
| {{text anchor|BLOODSUCKER}}
| Caste
|
| Causes [[vampire]]-like behaviour; the creature will suck the [[Creature_token#BLOOD|blood]] of unconscious victims when its [[Syndrome#TIME_SINCE_SUCKED_BLOOD|thirst for blood]] grows sufficiently large. When controlling the creature in adventure mode, this can be done at will. Seems to be required to make the creature denouncable (in-world) as a creature of the night.

|-
| {{text anchor|BODY}}
| Caste
|
*body parts
| Draws body parts from OBJECT:BODY files (such as body_default.txt)
'''Example:''' 
[BODY:BODY_WITH_HEAD_FLAG:HEART:GUTS:BRAIN:MOUTH] 
This is the body from a [[purring maggot]]. It creates a body with head, a heart, some guts, a brain, and a mouth. That's all a maggot needs.

The body parts need to be listed in an order such that any parent part appears before its connected children. For example [BODY:HEART:BODY_WITH_HEAD_FLAG] produces a "Body Token Recognized But Could Not Connect: HEART" error because HEART can't find any UPPERBODY(s) to connect to. Switching the order to [BODY:BODY_WITH_HEAD_FLAG:HEART] fixes the problem because now the UPPERBODY is created before the HEART tries to connect to it.

'''If the body is left undefined, the creature (or caste) will be tagged as [DOES_NOT_EXIST].''' {{verify}}

|-
| {{text anchor|BODY_APPEARANCE_MODIFIER}}
| Caste
|
*ATTRIBUTE
*lowest
*lower
*low
*median
*high
*higher
*highest
| These body modifiers give individual creatures different characteristics. In the case of HEIGHT, BROADNESS and LENGTH, the modifier is also a percentage change to the BODY_SIZE of the individual creature. The seven numbers afterward give a distribution of ranges. Each interval has an equal chance of occurring.
'''Example:''' 
[BODY_APPEARANCE_MODIFIER:HEIGHT:90:95:98:100:102:105:110] 
''HEIGHT'' : marks the height to be changed 
''90:95:98:100:102:105:110'' : sets the range from the shortest (90% of the average height) to the tallest (110% of the average height) creature variation.

|-
| {{text anchor|BODY_DETAIL_PLAN}}
| Caste
|
*PlanName
*Arguments
| Loads a plan from listed OBJECT:BODY_DETAIL_PLAN files, such as b_detail_plan_default.txt. Mass applies USE_MATERIAL_TEMPLATE, mass alters RELSIZE, alters body part positions, and will allow tissue layers to be defined. Tissue layers are defined in order of skin to bone here.
'''Example:''' 
[BODY_DETAIL_PLAN:VERTEBRATE_TISSUE_LAYERS:SKIN:FAT:MUSCLE:BONE:CARTILAGE] 
This creates the detailed body of a [[fox]], the skin, fat, muscle, bones and cartilage out of the vertebrate tissues. 
A [[Purring maggot|maggot]] would only need: 
''[BODY_DETAIL_PLAN:EXOSKELETON_TISSUE_LAYERS:SKIN:FAT:MUSCLE]''

|-
| {{text anchor|BODY_SIZE}}
| Caste
|
*years
*days
*size
| Sets size at a given age. Size is in cubic centimeters, and for normal body materials, is roughly equal to the creature's average weight in grams.
'''Example:''' 
[BODY_SIZE:0:0:10000] 
[BODY_SIZE:1:168:50000] 
[BODY_SIZE:12:0:220000] 
This describes the size of a [[minotaur]]. Its birth size would be 10,000 cm3 (~10 kg). At 1 year and 168 days old it would be 50,000 cm3 (~50 kg). And as an adult (at 12 years old) it would be 220,000 cm3 and weigh roughly 220 kg.

|-
| {{text anchor|BODYGLOSS}}
| Caste
|
*gloss
| Substitutes body part text with replacement text. Draws gloss information from OBJECT:BODY files (such as body_default.txt)

|-
| {{text anchor|BONECARN}}
| Caste
|
| Creature eats bones. Implies {{token|CARNIVORE|c}}. Currently does not work due to a bug ({{Bug|11069}}).

|-
| {{text anchor|BP_ADD_TYPE}}
| Caste
|
| Adds a type to a body part - used with {{token|SET_BP_GROUP|c}}. In vanilla DF, this is used for adding the type '[[Body token#GELDABLE|GELDABLE]]' to the lower body of certain [[cat|creatures]].

|-
| {{text anchor|BP_APPEARANCE_MODIFIER}}
| Caste
|
*QUALITY
*lowest
*lower
*low
*median
*high
*higher
*highest
| Sets up the breadth of possibilities for appearance qualities for a selected BP group. EG. Eyes (CLOSE_SET, DEEP_SET, ROUND_VS_NARROW, LARGE_IRIS),Lips (THICKNESS), Nose (BROADNESS, LENGTH, UPTURNED, CONVEX), Ear (SPLAYED_OUT, HANGING_LOBES, BROADNESS, HEIGHT), Tooth (GAPS), Skull (HIGH_CHEEKBONES, BROAD_CHIN, JUTTING CHIN, SQUARE_CHIN), Neck (DEEP_VOICE, RASPY_VOICE), Head (BROADNESS, HEIGHT)

|-
| {{text anchor|BP_REMOVE_TYPE}}
| Caste
|
| Removes a type from a body part. Used with {{token|SET_BP_GROUP|c}}.

|-
| {{text anchor|BUILDINGDESTROYER}}
| Caste
|
*1 or 2
| Allows a creature to destroy furniture and buildings. Value [1] targets mostly doors, hatches, furniture and the like. Value [2] targets anything not made with the {{k|b}} + {{k|C}} commands.
|}

{{alphabetical TOC|style=margin: 1em auto;}}

==C==
{| {{prettytable}}
|- bgcolor="#ddd"
! width="20%" | Token
! width="10%" | Type
! width="20%" | Arguments
! width="50%" | Description

|-
| {{text anchor|CAN_DO_INTERACTION}}
| Caste
|
*interaction token
| The creature can perform an interaction. See [[interaction token]].

|-
| {{text anchor|CAN_LEARN}}
| Caste
|
| The creature gains [[skill]]s and can have [[labor|professions]]. If a member of a civilization (even a pet) has this token, it'll need to eat, drink and sleep. Note that this token makes the creature unable to be eaten by an adventurer, so it is not recommended for uncivilized monsters. Adventurers lacking this token can allocate but not increase attributes and skills. Skills allocated will disappear on start. A creature with at least this token or the {{token|CAN_SPEAK|c}} token will be able to have [[Personality value|values]] and [[Personality goal|goals]].

|-
| {{text anchor|CAN_SPEAK}}
| Caste
|
| Can [[talking|talk]]. Note that this is not necessary for a creature to gain social skills but to make friends in fortress mode. A creature with at least this token or the {{token|CAN_LEARN|c}} token will be able to have [[Personality value|values]] and [[Personality goal|goals]].

|-
| {{text anchor|CANNOT_CLIMB}}
| Caste
|
| Creature cannot [[climber|climb]], even if it has free grasp parts.

|-
| {{text anchor|CANNOT_JUMP}}
| Caste
|
| Creature cannot [[jump]].

|-
| {{text anchor|CANNOT_UNDEAD}}
| Caste
|
| Acts like {{token|NOT_LIVING|c}}, except that {{token|OPPOSED_TO_LIFE|c}} creatures will attack them.

|-
| {{text anchor|CANOPENDOORS}}
| Caste
|
| Defunct, as doors cannot be set as tightly closed anymore.

|-
| {{text anchor|CARNIVORE}}
| Caste
|
| Creature ''only'' eats [[meat]]. If the creature goes on rampages in worldgen, it will often devour the people/animals it kills.

|-
| {{text anchor|CASTE}}
| Creature
|
*name
| Defines a [[caste]].

|-
| {{text anchor|CASTE_ALTTILE}}
| Caste
|
*tile number or "letter"
| Caste-specific {{token|ALTTILE|c}}. Requires {{token|CASTE_TILE|c}}.

|-
| {{text anchor|CASTE_COLOR}}
| Caste
|
*fg
*bg
*brightness
| Caste-specific {{token|COLOR|c}}.

|-
| {{text anchor|CASTE_GLOWCOLOR}}
| Caste
|
*fg
*bg
*brightness
| Caste-specific {{token|GLOWCOLOR|c}}.

|-
| {{text anchor|CASTE_GLOWTILE}}
| Caste
|
*tile value or "letter"
| Caste-specific {{token|GLOWTILE|c}}.

|-
| {{text anchor|CASTE_NAME}}
| Caste
|
*singular
*plural
*adjective
| While {{token|NAME|c}} describes the name of the species, {{token|CASTE_NAME|c}} names individuals of the species. Unlike other caste-specific descriptions, this token is required, even for creatures without separate castes. If left undefined, the creature will not show up in the [[arena]] and members of the species will be labeled as "nothing".

|-
| {{text anchor|CASTE_PROFESSION_NAME}}
| Caste
|
*[[Unit type token]] (Profession)
*singular
*plural
| Caste-specific {{token|PROFESSION_NAME|c}}.

|-
| {{text anchor|CASTE_SOLDIER_ALTTILE}}
| Caste
|
*'character' or tile number
| Caste-specific {{token|SOLDIER_ALTTILE|c}}. Requires {{token|CASTE_SOLDIER_TILE|c}}.

|-
| {{text anchor|CASTE_SOLDIER_TILE}}
| Caste
|
*'character' or tile number
| Caste-specific {{token|CREATURE_SOLDIER_TILE|c}}.

|-
| {{text anchor|CASTE_TILE}}
| Caste
|
* tile number or "letter"
| Caste-specific {{token|CREATURE_TILE|c}}.

|-
| {{text anchor|CAVE_ADAPT}}
| Caste
|
| Causes the creature to develop [[cave adaptation]].

Allows for creature's race to be involved in jokes that end in "And the [race] saw the sun and vomited on the spot!"

|-
| {{text anchor|CDI}}
| Caste
|
*Varies
| Specifies interaction details following a {{token|CAN_DO_INTERACTION|c}} token. See [[interaction token]].

|-
| {{text anchor|CHANGE_BODY_SIZE_PERC}}
| Caste
|
*integer
| Multiplies body size by a factor of (integer)%. 50 halves size, 200 doubles.

|-
| {{text anchor|CHANGE_FREQUENCY_PERC}}
| Creature
|
*integer
| Multiplies frequency by a factor of (integer)%.

|-
| {{text anchor|CHILD}}
| Caste
|
*integer
| Age at which creature is considered an adult - one can think of this as the duration of the [[children|child]] stage. Allows the creature's offspring to be rendered fully tame if [[animal trainer|trained]] during their childhood.

|-
| {{text anchor|CHILDNAME}}
| Caste
|
*singular
*plural
| Defines a new name for a creature in the child state at the caste level. For non-caste-specific child names, see {{token|GENERAL_CHILD_NAME|c}}.

|-
| {{text anchor|CLUSTER_NUMBER}}
| Creature
|
*min
*max
| The minimum/maximum numbers of how many creatures per spawned cluster. Vermin fish with this token in combination with temperate ocean and river biome tokens [http://www.bay12forums.com/smf/index.php?topic=51864.msg1122319#msg1122319 will perform seasonal migrations]. Defaults to 1:1 if not specified.

|-
| {{text anchor|CLUTCH_SIZE}}
| Caste
|
*min
*max
|Number of [[egg]]s laid in one sitting.

|-
| {{text anchor|COLONY_EXTERNAL}}
| Caste
|
| Caste hovers around colony.

|-
| {{text anchor|COLOR}}
| Creature
|
*foreground
*background
*brightness
| Color of the creature's tile. (See [[Color]] for usage.)

|-
| {{text anchor|COMMON_DOMESTIC}}
| Caste
|
| When combined with any of {{token|PET|c}}, {{token|PACK_ANIMAL|c}}, {{token|WAGON_PULLER|c}} and/or {{token|MOUNT|c}}, the creature is guaranteed to be domesticated by any [[civilization]] with {{token|COMMON_DOMESTIC_PET|e}}, {{token|COMMON_DOMESTIC_PACK|e}}, {{token|COMMON_DOMESTIC_PULL|e}} and/or {{token|COMMON_DOMESTIC_MOUNT|e}} respectively. Such civilizations will always have access to the creature, even in the absence of wild populations. This token is invalid on {{token|FANCIFUL|c}} creatures.

|-
| {{text anchor|CONVERTED_SPOUSE}}
| Caste
|
| Creatures of this caste's species with the {{token|SPOUSE_CONVERTER|c}} and {{token|NIGHT_CREATURE_HUNTER|c}} tokens will kidnap {{token|SPOUSE_CONVERSION_TARGET|c}}s of an appropriate sex and convert them into castes with CONVERTED_SPOUSE.

|-
| {{text anchor|COOKABLE_LIVE}}
| Caste
|
| Set this on a vermin creature to allow it to be cooked in meals while it is still alive, as well as when it's dead but not yet [[fishery|cleaned]]. Used by some water-dwelling vermin such as [[mussel]]s, [[oyster]]s, and [[cave lobster]]s. Currently does not work correctly when applied to non-{{token|FISHITEM|c}} vermin.{{bug|13200}}

|-
| {{text anchor|CRAZED}}
| Caste
|
| Creature is '[[insanity|berserk]]' and will attack all other creatures, except members of its own species that '''also''' have the CRAZED tag. It will show {{DFtext|Berserk|4:1}} in the [[unit list]]. Berserk creatures go on rampages during [[world generation|worldgen]] much more frequently than non-berserk ones.

|-
| {{text anchor|COPY_TAGS_FROM}}
| Special
|
*creature ID
| Copies another specified creature. This will override any definitions made before it; essentially, it makes this creature identical to the other one, which can then be modified. Often used in combination with {{token|APPLY_CREATURE_VARIATION|c}} to import standard variations from a file. The vanilla [[giant animal]]s and [[animal person|animal people]]s are examples of this token combination.

|-
| {{text anchor|CREATURE}}
| Creature
|
*creature ID
| A unique, arbitrary identifier that begins the definition of each new creature, and is used to reference the creature in other tokens and raws.

|-
| {{text anchor|CREATURE_CLASS}}
| Caste
|
*classname
| An arbitrary creature classification - can be set to anything, but the only vanilla uses are GENERAL_POISON (used in syndromes), EDIBLE_GROUND_BUG (used as targets for {{token|GOBBLE_VERMIN_CLASS|c}}), MAMMAL, and POISONOUS (both used for kobold pet eligibility). If a creature has the REAL_WORLD_EXTINCT class, they can be customized in how they appear during world generation, and will also have another creature class token to denote what prehistoric period they existed in. A single creature can have multiple classes.

The full list of tokens that use creature classes is:

* Creature tokens: {{token|GOBBLE_VERMIN_CLASS|c}}, {{token|GOBBLE_VERMIN_CLASS|c}}
* Interaction tokens: {{token|IT_AFFECTED_CLASS|in}}, {{token|IT_IMMUNE_CLASS|in}}
* Animal definition (Entity) tokens: {{token|ANIMAL_CLASS|e}}, {{token|ANIMAL_FORBIDDEN_CLASS|e}}
* Position (Entity) token: {{token|ALLOWED_CLASS|po}}
* Syndrome tokens: {{token|SYN_AFFECTED_CLASS|sy}}, {{token|SYN_IMMUNE_CLASS|sy}}, {{token|CE_SENSE_CREATURE_CLASS|sy}}
* Extinction tokens: CAMBRIAN, CARBONIFEROUS, CENOZOIC, CRETACEOUS, DEVONIAN, JURASSIC, ORDOVICIAN, PERMIAN, SILURIAN, TRIASSIC [Todo: add token links]
|-
| {{text anchor|CREATURE_SOLDIER_TILE}}
| Creature
|
*'character' or tile number
| Creatures active in their civilization's [[military]] will use this tile instead.

|-
| {{text anchor|CREATURE_TILE}}
| Creature
|
*'character' or tile number
| The symbol of the creature in ASCII mode.

|-
| {{text anchor|CREPUSCULAR}}
| Caste
|
| When set, the creature will appear at dawn (between 4:30 AM and 6:00 AM) and in the evening (between 8:00 PM and 10:05 PM) in [[Adventurer mode]].

|-
| {{text anchor|CURIOUSBEAST_EATER}}
| Caste
|
| Allows a creature to [[Steals food|steal and eat edible items]] from a site. It will attempt to grab a food item and immediately make its way to the map's edge, where it will disappear with it. If the creature goes on rampages during worldgen, it will often steal food instead of attacking. Trained and tame instances of the creature will no longer display this behavior.

|-
| {{text anchor|CURIOUSBEAST_GUZZLER}}
| Caste
|
| Allows a creature to (very quickly) [[Steals drink|drink your alcohol]]. Or spill the barrel to the ground. Also affects undead versions of the creature. Unlike food or item thieves, drink thieves will consume your alcohol on the spot rather than run away with one piece of it. Trained and tame instances of the creature will no longer display this behavior.

|-
| {{text anchor|CURIOUSBEAST_ITEM}}
| Caste
|
| Allows a creature to [[Steals items|steal things]] (apparently, of the highest value it can find). It will attempt to grab an item of value and immediately make its way to the map's edge, where it will disappear with it. If a creature with any of the CURIOUSBEAST tokens carries anything off the map, even if it is a caravan's pack animal, it will be reported as stealing everything it carries. If the creature goes on rampages in worldgen, it will often steal items instead of attacking - [[kea]] birds are infamous for this. Trained and tame instances of the creature will no longer display this behavior. Also, makes the creature unable to drop hauled items until it enters combat.

|-
| {{text anchor|CV_ADD_TAG}}
| Special
|
*TAG NAME
| Adds a tag. Used in conjunction with creature variation templates.

|-
| {{text anchor|CV_REMOVE_TAG}}
| Special
|
*TAG NAME
| Removes a tag. Used in conjunction with creature variation templates.
|}

{{alphabetical TOC|style=margin: 1em auto;}}

==D==
{| {{prettytable}}
|- bgcolor="#ddd"
! width="20%" | Token
! width="10%" | Type
! width="20%" | Arguments
! width="50%" | Description

|-
| {{text anchor|DEMON}}
| Caste
|
| Found on generated [[demon]]s.

At least 1 demon generated, or custom must have the {{token|FLIER|c}} token in order for the [[Underworld|horrifying screams]] event to trigger.

|-
| {{text anchor|DESCRIPTION}}
| Caste
|
*text
| A brief description of the creature type, as displayed when viewing the creature's description/[[Thoughts and preferences|thoughts & preferences]] screen.

|-
| {{text anchor|DIE_WHEN_VERMIN_BITE}}
| Caste
|
| Causes the creature to die upon attacking. Used by [[honey bee]]s to simulate them dying after using their stingers.

|-
| {{text anchor|DIFFICULTY}}
| Caste
|
*integer
| Increases experience gain during adventure mode. Creatures with a difficulty of 11 or higher are not assigned for quests in adventure mode. Vanilla [[semimegabeast]]s have a difficulty of 5 and [[megabeast]]s have a difficulty of 10.

|-
| {{text anchor|DIURNAL}}
| Caste
|
| When set, the creature will only appear during the day (between 6:00 AM and 8:00 PM) in [[Adventurer mode]].

|-
| {{text anchor|DIVE_HUNTS_VERMIN}}
| Caste
|
| The creature hunts vermin by diving from the air. On tame creatures, it has the same effect as {{token|HUNTS_VERMIN|c}}. Found on [[peregrine falcon]]s.

|-
| {{text anchor|DOES_NOT_EXIST}}
| Creature
|
| Adding this token to a creature prevents it from appearing in generated worlds (unless it's marked as [[Entity_token#ANIMAL_ALWAYS_PRESENT|always present]] for a particular civilisation). For example, adding it to [[dog]]s will lead to worlds being generated without dogs in them. Also removes the creature from the [[object testing arena]]'s spawn list. If combined with {{token|FANCIFUL|c}}, artistic depictions of the creature will occur regardless. Used by [[centaur]]s, [[chimera]]s and [[griffon]]s in the vanilla game.

Note: a creature tagged as DOES_NOT_EXIST can still be [[Interaction_token#I_EFFECT|summoned]] successfully, as long as it has a body defined in its raws [http://www.bay12forums.com/smf/index.php?topic=165213.msg8086938#msg8086938], or, another creature can [[Syndrome#CE_BODY_TRANSFORMATION|transform]] into it.
|}

{{alphabetical TOC|style=margin: 1em auto;}}

==E==
{| {{prettytable}}
|- bgcolor="#ddd"
! width="20%" | Token
! width="10%" | Type
! width="20%" | Arguments
! width="50%" | Description

|-
| {{text anchor|EBO_ITEM}}
| Caste
|
*[[item token]]
*[[material token]] (ANY_HARD_STONE can be used for the material)
| Defines the item that the creature drops upon being [[butcher|butchered]]. Used with {{token|EXTRA_BUTCHER_OBJECT|c}}.

|-
| {{text anchor|EBO_SHAPE}}
| Caste
|
*gem shape
| The shape of the creature's extra [[butcher|butchering]] drop. Used with {{token|EXTRA_BUTCHER_OBJECT|c}}.

|-
| {{text anchor|EGG_MATERIAL}}
| Caste
|
* <[[material token]]>
* <[[Material_definition_token#Material_States|material state]]>
| Defines the material composition of [[egg]]s laid by the creature. [[creature_token#LAYS_EGGS|Egg-laying]] creatures in the default game define this 3 times, using LOCAL_CREATURE_MAT:EGGSHELL, LOCAL_CREATURE_MAT:EGG_WHITE, and then LOCAL_CREATURE_MAT:EGG_YOLK. Eggs will be made out of eggshell. Edibility is determined by tags on whites or yolk, but they otherwise do not exist.

|-
| {{text anchor|EGG_SIZE}}
| Caste
|
*size
| Determines the size of laid [[egg]]s. Doesn't affect hatching or cooking, but bigger eggs will be heavier, and may take longer to be hauled depending on the hauler's strength.

|-
| {{text anchor|EQUIPMENT_WAGON}}
| Creature
|
| Makes the creature appear as a large 3×3 [[wagon]] responsible for carrying trade goods, pulled by two {{token|WAGON_PULLER|c}} creatures and driven by a merchant.

|-
| {{text anchor|EQUIPS}}
| Caste
|
| Allows the creature to wear or wield items.

|-
| {{text anchor|EVIL}}
| Creature
|
| The creature is considered evil and will only show up in evil biomes. Civilizations with {{token|USE_EVIL_ANIMALS|e}} can domesticate them regardless of exotic status. Has no effect on cavern creatures except to restrict taming. A civilization with evil creatures can colonize evil areas.

Civilizations which list evil creatures as one of their main population options will potentially emerge following an underworld mining disaster, with the added caveat that a demon will be in charge of the civ. The rules which govern which noble position the demon in charge adopts however, are unclear. It either picks one of the predefined positions, or simply makes its own.

|-
| {{text anchor|EXTRA_BUTCHER_OBJECT}}
| Caste
|
* [[Body token#CATEGORY|BY_CATEGORY]] or [[Body token#CONTYPE|BY_TYPE]] or [[Body token#BP|BY_TOKEN]]
* TYPE, CATEGORY, or TOKEN
| The creature drops an additional object when [[butcher|butchered]], as defined by {{token|EBO_ITEM|c}} and {{token|EBO_SHAPE|c}}. Used for [[gizzard stone]]s in default creatures. For some materials, needs to be defined after caste definitions with SELECT_CASTE:ALL{{Bug|6355}}

|-
| {{text anchor|EXTRACT}}
| Caste
|
* [[material token]]
| Defines a creature extract which can be obtained via [[small animal dissection]].

|-
| {{text anchor|EXTRAVISION}}
| Caste
|
| The creature can see regardless of whether it has working eyes and has full 360 degree vision, making it impossible to strike the creature from a blind spot in combat. Invisible creatures will also be seen, namely [[intelligent undead]] using a "vanish" power.
|}

{{alphabetical TOC|style=margin: 1em auto;}}

==F==
{| {{prettytable}}
|- bgcolor="#ddd"
! width="20%" | Token
! width="10%" | Type
! width="20%" | Arguments
! width="50%" | Description

|-
| {{text anchor|FANCIFUL}}
| Creature
|
| The creature is a thing of legend and known to all civilizations. Its materials cannot be requested or preferred. The tag also adds some art value modifiers. Used by a [[Fanciful|number of creatures]]. Conflicts with {{token|COMMON_DOMESTIC|c}}.

|-
| {{text anchor|FEATURE_ATTACK_GROUP}}
| Caste
|
| Found on [[Animal people#Subterranean animal people|subterranean animal-man]] tribals. Currently defunct. In previous versions{{verify}}, it caused these creatures to crawl out of chasms and underground rivers.

|-
| {{text anchor|FEATURE_BEAST}}
| Caste
|
| Found on [[forgotten beast]]s. Presumably makes it act as such, initiating underground attacks on fortresses, or leads to the pop-up message upon encountering one{{verify}}. Displays the creature's {{token|DESCRIPTION|c}} in its [[legends mode]] entry and hides the creature from displaying in a world_sites_and_pops file. Does not create historical figures like generated forgotten beasts do.

Requires specifying a {{token|BIOME|c}} in which the creature will live, and both surface and subterranean biomes are allowed. Does not stack with {{token|LARGE_ROAMING|c}} and if both are used the creature will not spawn. Appears to be incompatible with {{token|DEMON|c}} even if used in separate castes.

|-
| {{text anchor|FEMALE}}
| Caste
|
| Makes the creature biologically female, enabling her to [[Breeding|bear young]]. Usually specified inside a caste.

|-
| {{text anchor|FIREIMMUNE}}
| Caste
|
| Makes the creature immune to [[Interaction_token#FIREBALL|FIREBALL]] and [[Interaction_token#FIREJET|FIREJET]] attacks, and allows it to path through high temperature zones, like lava or fires, but does not, by itself, make the creature immune to the damaging effects of burning in [[fire]], and does not prevent general heat damage or melting on its own (this would require adjustments to be made to the creature's body [[Material_definition_token|materials]] - see the [[Dragon/raw|dragon raws]] for an example).

|-
| {{text anchor|FIREIMMUNE_SUPER}}
| Caste
|
| Like {{token|FIREIMMUNE|c}}, but also renders the creature immune to [[Interaction_token#DRAGONFIRE|DRAGONFIRE]] attacks.

|-
| {{text anchor|FISHITEM}}
| Caste
|
| The creature's corpse is a single [[Item_token#FISH_RAW|FISH_RAW]] food item that needs to be cleaned (into a [[Item_token#FISH|FISH]] item) at a [[fishery]] to become edible. Before being cleaned the item is referred to as "raw". The food item is categorized under "fish" on the food and stocks screens, and when uncleaned it is sorted under "raw fish" in the stocks (but does not show up on the food screen).
Without this or {{token|COOKABLE_LIVE|c}}, [[fishing|fished]] vermin will turn into food the same way as non-vermin creatures, resulting in multiple units of food (meat, brain, lungs, eyes, spleen etc.) from a single fished vermin. These units of food are categorized as meat by the game.

|-
| {{text anchor|FIXED_TEMP}}
| Caste
|
*temperature
| The creature's body is constantly at this temperature, heating up or cooling the surrounding area. Alters the temperature of the creature's inventory and all adjacent tiles, [[Temperature|with all the effects that this implies]] - may trigger wildfires at high enough values. Also makes the creature immune to extreme heat or cold, as long as the temperature set is not harmful to the materials that the creature is made from. Corpses and body parts of creatures with a fixed temperature maintain their temperature even after death.

Note that temperatures of 12000 and higher may cause [[path|pathfinding]] issues in fortress mode.

|-
| {{text anchor|FLEEQUICK}}
| Caste
|
| If engaged in combat, the creature will flee at the first sign of resistance. Used by [[kobold]]s in the vanilla game.

|-
| {{text anchor|FLIER}}
| Caste
|
| Allows a creature to fly, independent of it having wings or not. Fortress Mode pathfinding only partially incorporates flying - flying creatures need a land path to exist between them and an area in order to access it, but as long as one such path exists, they do not need to use it, instead being able to fly over intervening obstacles. Winged creatures with this token can lose their ability to fly if their wings are crippled or severed. Winged creatures without this token will be unable to fly. (A 'wing' in this context refers to any body part with its own [[Body_token#FLIER|FLIER]] token).

At least 1 [[Demon]] must have the flier token in order for the [[Underworld|horrifying screams]] event to trigger.

|-
| {{text anchor|FREQUENCY}}
| Creature
|
*number, max 100
| The {{token|FREQUENCY|c}} value plays two separate roles. The first is in determining the initial distribution of creatures across the world map. Each creature is randomly assigned a single x, y co-ordinate on the world map, which act as the epicenter for that creature's distribution. A square is drawn around that x, y co-ordinate with a Manhattan radius equal to the {{token|FREQUENCY|c}} value divided by 100 times the world map size. For example, in a 256 by 256 size world map, the [[lion]] might be assigned 14, 112. The [[lion]] has {{token|FREQUENCY:5|c}}, and so a square is drawn by moving 13 tiles in each direction from the [[lion]]'s x, y co-ordinate. This is the [[lion]]'s "territory".

Each sub-region in the world will attempt to fill lists of wildlife. There are five lists - {{token|VERMIN_GROUNDER|c}}, {{token|VERMIN_SOIL|c}}, {{token|VERMIN_SOIL_COLONY|c}}, {{token|LARGE_ROAMING|c}}, and {{token|LARGE_PREDATOR|c}}, corresponding with the relevant tokens. The game will attempt to place seven creatures in each list for each sub-region. The game will select the seven nearest valid creatures. Creatures are valid for sub-region's list if they have the requisite token for that list, if they have the valid token for that sub-region's biome (for example, the [lion] can only be selected for {{token|BIOME:SAVANNA_TROPICAL|c}}, {{token|BIOME:GRASSLAND_TROPICAL|c}}, and {{token|BIOME:SHRUBLAND_TROPICAL|c}}, and if their "territory" as defined by their random epicenter and {{token|FREQUENCY|c}} radius overlaps with that sub-region. These lists then determine the creatures that can actually appear within that sub-region during gameplay.

There are some exceptions to the above. If the game was not capable of filling all seven entries in a list, it will drop the overlapping territory requirement, and simply pull the nearest creature which has the correct token and biome availability. Conversely, if a creature has an epicenter but has not appeared on any of the list for any of the world map's sub-regions, the creature will be assigned to the relevant list for the nearest appropriate sub-region - meaning it is occasionally possible to have lists of eight creatures or more. This is more common in smaller worlds where there are less possible sub-regions to be assigned towards. Creatures with the {{token|GOOD|c}} and {{token|EVIL|c}} tokens ignore the epicenter distribution system altogether. They are always capable of appearing in appropriate biomes which are {{token|GOOD|b}} or {{token|EVIL|b}} respectively. This is not true for {{token|SAVAGE|c}}, which acts more like the biome tokens. Creatures with {{token|UBIQUITOUS|c}} have a "territory" which covers the entire map, regardless of their epicenter (although they can still fail to be chosen if there are 7 creatures which are eligible and have nearer epicenters to the sub-region in question).

The second use for {{token|FREQUENCY|c}} is to determine how often a creature actually appears on map. In Fortress Mode, the game will try and spawn large wildlife (creatures with {{token|LARGE_ROAMING|c}} or {{token|LARGE_PREDATOR|c}} in fairly regular waves. These waves include {{token|LARGE_ROAMING|c}}, {{token|LARGE_ROAMING|c}} combined with {{token|FLIER|c}}, {{token|LARGE_PREDATOR|c}}, and {{token|CURIOUS_BEAST|c}} - so a [[lion]] does not compete for selection with a [[gazelle]]. When the game decides it needs to spawn in a fresh wave of e.g. {{token|LARGE_ROAMING|c}} creatures, it will select one of the creatures available to it from the lists for that sub-region at random, with all creatures weighted equally. Once it has selected a creature, it then effectively rolls a d100 against the relevant creature's {{token|FREQUENCY|c}}. If the d100 is equal to the creature's {{token|FREQUENCY|c}} or less, that creature is then spawned in. If the d100 is above the creature's {{token|FREQUENCY|c}}, the game returns to the relevant list and selects again. {{token|UBIQUITOUS|c}} acts as {{token|FREQUENCY:100|c}} for these purposes - in other words, the creature cannot fail the d100 check and will always be spawned in if it is selected from the list.

Defaults to 50.

|}

{{alphabetical TOC|style=margin: 1em auto;}}

==G==
{| {{prettytable}}
|- bgcolor="#ddd"
! width="20%" | Token
! width="10%" | Type
! width="20%" | Arguments
! width="50%" | Description

|-
| {{text anchor|GAIT}}
| Caste
|
* <gait type>
* <gait name>
* <max [[Gait#Speed|speed]]>
* <build up time>
* <max turning [[Gait#Speed|speed]]>
* <start [[Gait#Speed|speed]]>
* <energy expenditure>
* <gait flag(s)>
| Defines a gait by which the creature can move. See [[Gait]] for more information. Specifically, you likely want to use one of the existing STANDARD_X_GAITS creature variations, as described in [[Gait#Gaits_and_Modding|this subsection]].

* <max speed> indicates the maximum [[Gait#Speed|speed]] achievable by a creature using this gait
* <start speed> indicates the creature's speed when it starts moving using this gait
* <build up time> indicates how long it will take for a creature using this gait to go from <start speed> to <max speed>. For example, a value of 10 means that it should be able to reach the maximum speed by moving 10 [[tile]]s in a straight line over even terrain.
* <max turning speed> indicates the maximum speed permissible when the creature suddenly changes its direction of motion. The creature's speed will be reduced to <max turning speed> if travelling at a higher speed than this before turning.
* <energy expenditure> indicates how energy-consuming the gait is. Higher values cause the creature to tire out faster. Persistent usage of a high-intensity gait will eventually lead to exhaustion and [[Status_icon#Non-flashing|collapse]].

'''NO_BUILD_UP''' can be specified instead of a <start speed> value to make the <max speed> instantly achievable upon initiating movement (this is equivalent to a <build up time> of 0). Note that <build up time> and <max turning speed> are both ignored if specified alongside this (as NO_BUILD_UP trumps <build up time> and preserves <max speed> whilst turning, and <max turning speed> cannot exceed <max speed>) so it is permissible to omit them so long as they are '''both''' omitted together.

It's possible to specify a <start speed> greater than the <max speed>; the moving creature will decelerate towards its <max speed> in this case.

'''valid gait types:'''
*'''WALK''' 
Used for moving normally over ground tiles.

*'''CRAWL''' 
Used for moving over ground tiles whilst [[Status_icon#Non-flashing|prone]].

*'''SWIM''' 
Used for moving through tiles containing [[water]] or [[magma]] at a [[Water#Depth|depth]] of at least 4/7.

*'''FLY''' 
Used for moving through [[open space]].

*'''CLIMB''' 
Used for moving whilst [[Climber|climbing]].

'''valid gait flags:'''
* '''AGILITY''' 
Speeds/slows movement depending on the creature's [[Attribute#Agility|Agility]] stat.

* '''STRENGTH''' 
Speeds/slows movement depending on the creature's [[Attribute#Strength|Strength]] stat.

* '''LAYERS_SLOW''' 
Makes [[Tissue_definition_token#THICKENS_ON_ENERGY_STORAGE|THICKENS_ON_ENERGY_STORAGE]] and [[Tissue_definition_token#THICKENS_ON_STRENGTH|THICKENS_ON_STRENGTH]] tissue layers slow movement depending on how thick they are. Adding the STRENGTH gait flag counteracts the impact of the latter layer.

* '''STEALTH_SLOWS:'''<percentage> 
Slows movement by the specified percentage when the creature is [[Ambusher|sneaking]].

|-
| {{text anchor|GENERAL_BABY_NAME}}
| Creature
|
*singular
*plural
| Like {{token|BABYNAME|c}}, but applied regardless of caste.

|-
| {{text anchor|GENERAL_CHILD_NAME}}
| Creature
|
*singular
*plural
| Like {{token|CHILDNAME|c}}, but applied regardless of caste.

|-
| {{text anchor|GENERAL_MATERIAL_FORCE_MULTIPLIER}}
| Caste
|
*value A
*value B
| Has the same function as {{token|MATERIAL_FORCE_MULTIPLIER|c}}, but applies to all attacks instead of just those involving a specific material. Appears to be overridden by MATERIAL_FORCE_MULTIPLIER ([[werebeast]]s, for example, use both tokens to provide resistance to all materials, with one exception to which they are especially vulnerable).

|-
| {{text anchor|GENERATED}}
| Creature
|
| Found on procedurally generated creatures like [[forgotten beast]]s, [[titan]]s, [[demon]]s, [[angel]]s, and [[night creature]]s. Cannot be specified in user-defined raws.

|-
| {{text anchor|GETS_INFECTIONS_FROM_ROT}}
| Caste
|
| Makes the creature get [[Health_care#Infection|infections]] from necrotic tissue.

|-
| {{text anchor|GETS_WOUND_INFECTIONS}}
| Caste
|
| Makes the creature's wounds become [[Health_care#Infection|infected]] if left untreated for too long.

|-
| {{text anchor|GLOWCOLOR}}
| Creature
|
*foreground
*background
*brightness
| The colour of the creature's {{token|GLOWTILE|c}}.

|-
| {{text anchor|GLOWTILE}}
| Creature
|
*ascii character
| If present, the being glows in the dark (generally used for Adventurer Mode). The tile is what replaces the being's current tile when it is obscured from your sight by darkness. The default setting for kobolds (a yellow quotation mark) provides a nice "glowing eyes" effect. The game is also hardcoded to automatically convert quotation mark GLOWTILES into apostrophes if the creature has lost one eye. This works at the generic creature level - for caste-specific glow tiles, use {{token|CASTE_GLOWTILE|c}} instead.

|-
| {{text anchor|GNAWER}}
| Caste
|
*verb
| The creature can and will gnaw its way out of [[animal trap]]s and [[cage]]s using the specified verb, depending on the material from which it is made (normally wood).

|-
| {{text anchor|GOBBLE_VERMIN_CLASS}}
| Caste
|
*class
| The creature eats vermin of the specified class.

|-
| {{text anchor|GOBBLE_VERMIN_CREATURE}}
| Caste
|
*creature
*caste
| The creature eats a specified [[vermin]].

|-
| {{text anchor|GO_TO_END}}
| Special
|
| When using tags from an existing creature, inserts new tags at the end of the creature.

|-
| {{text anchor|GO_TO_START}}
| Special
|
| When using tags from an existing creature, inserts new tags at the beginning of the creature.

|-
| {{text anchor|GO_TO_TAG}}
| Special
|
| When using tags from an existing creature, inserts new tags ''before'' the specified tag.

|-
| {{text anchor|GOOD}}
| Creature
|
| Creature is considered good and will only show up in good biomes - [[unicorn]]s, for example. Civilizations with {{token|USE_GOOD_ANIMALS|e}} can domesticate them regardless of exotic status. Has no effect on cavern creatures except to restrict taming. A civilization that has good creatures can colonise good areas in world-gen.

|-
| {{text anchor|GRASSTRAMPLE}}
| Caste
|
*value
| The value determines how rapidly [[grass]] is trampled when a creature steps on it - a value of 0 causes the creature to never damage grass, while a value of 100 causes grass to be trampled as rapidly as possible. Defaults to 5.

|-
| {{text anchor|GRAVITATE_BODY_SIZE}}
| Caste
|
*target value
| Used in Creature Variants. This token changes the adult body size to the average of the old adult body size and the target value and scales all intermediate growth stages by the same factor.

|-
| {{text anchor|GRAZER}}
| Caste
|
*number
| The creature is a grazer - if tamed in fortress mode, it needs a pasture to survive. The higher the number, the less frequently it needs to eat in order to live. Not used since 0.40.12, replaced by {{token|STANDARD_GRAZER|c}} to fix {{bugl|4113}}.
|}

{{alphabetical TOC|style=margin: 1em auto;}}

==H==
{| {{prettytable}}
|- bgcolor="#ddd"
! width="20%" | Token
! width="10%" | Type
! width="20%" | Arguments
! width="50%" | Description

|-
| {{text anchor|HABIT}}
| Caste
|
*type
*probability
| Defines certain behaviors for the creature. The habit types are:
*COLLECT_TROPHIES
*COOK_PEOPLE
*COOK_VERMIN
*GRIND_VERMIN
*COOK_BLOOD
*GRIND_BONE_MEAL
*EAT_BONE_PORRIDGE
*USE_ANY_MELEE_WEAPON
*GIANT_NEST
*COLLECT_WEALTH.
These require the creature to have a {{token|LAIR|c}} to work properly, and also don't seem to work on creatures who are not a {{token|SEMIMEGABEAST|c}}, {{token|MEGABEAST|c}}, or{{token|NIGHT_CREATURE_HUNTER|c}}.

|-
| {{text anchor|HABIT_NUM}}
| Caste
|
*number or TEST_ALL
| "If you set HABIT_NUM to a number, it should give you that exact number of habits according to the weights.".{{cite forum|60554/1719248}} All lists of HABITs are preceded by [HABIT_NUM:TEST_ALL]

|-
| {{text anchor|HAS_NERVES}}
| Caste
|
| The creature has nerves in its muscles. Cutting the muscle tissue can sever motor and sensory nerves, disabling the limb.

|-
| {{text anchor|HASSHELL}}
| Caste
|
| The creature has a shell. Seemingly no longer used - holdover from previous versions.

|-
| {{text anchor|HIVE_PRODUCT}}
| Creature
|
*number
*[[time]]
*[[item token]]s
| What product is harvested from [[Beekeeping industry|beekeeping]].

|-
| {{text anchor|HOMEOTHERM}}
| Caste
|
*number or NONE
| Default 'NONE'. The creature's normal body [[temperature]]. Creature ceases maintaining temperature on death unlike fixed material temperatures. Provides minor protection from environmental temperature to the creature.

|-
| {{text anchor|HUNTS_VERMIN}}
| Caste
|
| Creature hunts and kills nearby [[vermin]], randomly walking between places with food laying on the ground or in stockpiles, to check for possible [VERMIN_EATER] vermin, but they'll kill any other vermin too. Do not include this creature token on an intelligent entity that you intend to play as in fortress mode because it will prevent them from feeding themselves.

|}

{{alphabetical TOC|style=margin: 1em auto;}}

==I==
{| {{prettytable}}
|- bgcolor="#ddd"
! width="20%" | Token
! width="10%" | Type
! width="20%" | Arguments
! width="50%" | Description

|-
| {{text anchor|IMMOBILE}}
| Caste
|
| The creature cannot move. Found on [[sponge]]s. Will also stop a creature from breeding in fortress mode (MALE and FEMALE are affected, if one is IMMOBILE; no breeding will happen).

|-
| {{text anchor|IMMOBILE_LAND}}
| Caste
|
| The creature is immobile while on land. Only works on {{token|AQUATIC|c}} creatures which can't breathe on land.

|-
| {{text anchor|IMMOLATE}}
| Caste
|
| The creature radiates [[fire]]. It will ignite, and potentially completely destroy, items the creature is standing on. Also gives the vermin a high chance of escaping from [[animal trap]]s and [[cage]]s made of any flammable materials (specifically ones that could be ignited by magma).

|-
| {{text anchor|INTELLIGENT}}
| Caste
|
| Alias for {{token|CAN_SPEAK|c}} + {{token|CAN_LEARN|c}}.

|-
| {{text anchor|ITEMCORPSE}}
| Caste
|
* [[item token]]
* [[material token]]
| Determines if the creature leaves behind a non-standard corpse (i.e. wood, statue, bars, stone, pool of liquid, etc.). [[Ethics]] may prevent actually using the item in jobs or reactions.

|-
| {{text anchor|ITEMCORPSE_QUALITY}}
| Caste
|
* number
| The [[quality]] of an item-type corpse left behind. Valid values are: 0 for ordinary, 1 for well-crafted, 2 for finely-crafted, 3 for superior, 4 for exceptional, 5 for masterpiece.
|}

{{alphabetical TOC|style=margin: 1em auto;}}

==L==
{| {{prettytable}}
|- bgcolor="#ddd"
! width="20%" | Token
! width="10%" | Type
! width="20%" | Arguments
! width="50%" | Description

|-
| {{text anchor|LAIR}}
| Caste
|
*type
*probability
| Found on megabeasts, semimegabeasts, and night creatures. The creature will seek out sites of this type and take them as lairs. The lair types are:
*SIMPLE_BURROW
*SIMPLE_MOUND
*WILDERNESS_LOCATION
*SHRINE
*LABYRINTH

|-
| {{text anchor|LAIR_CHARACTERISTIC}}
| Caste
|
*characteristic
*probability
| Defines certain features of the creature's lair. The only valid characteristic is HAS_DOORS.

|-
| {{text anchor|LAIR_HUNTER}}
| Caste
|
| This creature will actively hunt adventurers in its lair.

|-
| {{text anchor|LAIR_HUNTER_SPEECH}}
| Caste
|
*speech file
| What this creature says while hunting adventurers in its lair.

|-
| {{text anchor|LARGE_PREDATOR}}
| Caste
|
| Will attack other creatures that are smaller than it. Tamed large predators will still attack wildlife. In [[fortress mode]], only one group of "large predators" (possibly two groups on "savage" maps) will appear on any given map. In [[adventurer mode]], large predators will try to ambush and attack you (and your party will attack them back). When tamed, large predators tend to be much more aggressive to enemies than non-large predators, making them a good choice for an animal army. They may go on rampages in worldgen, and adventurers may receive quests to kill them. Also, they can be mentioned in the intro paragraph when starting a fortress e.g. "ere the wolves get hungry."
A single biome supports 7 large predator species, picking randomly and rolling a d100 under its {{token|FREQUENCY|c}} to add it until all 7 slots are filled.

Incompatible with {{token|PACK_ANIMAL|c}} on a technicality, if included: hauled items are likely to be dropped upon entering the map (even if {{token|TRADE_CAPACITY|c}} is present) in contrast to when the merchants depart.

|-
| {{text anchor|LARGE_ROAMING}}
| Creature
|
| This is the core requisite tag allowing the creature to spawn as a wild animal in the appropriate biomes. Requires specifying a {{token|BIOME|c}} in which the creature will spawn. Does not require specifying a frequency, population number, or cluster number.

This tag stacks with {{token|MEGABEAST|c}}, {{token|SEMIMEGABEAST|c}}, or {{token|NIGHT_CREATURE_HUNTER|c}}; if used with one of these tags, the creature will spawn as both a boss and as a wild animal. This tag does not stack with {{token|FEATURE_BEAST|c}} and if both are used the creature will not spawn. This tag is unaffected by {{token|DEMON|c}}.
Large roamers are not able to spawn in Pool biomes as they do not connect to the edge of the map and are too small, Lake biomes are a suitable alternative.

|-
| {{text anchor|LAYS_EGGS}}
| Caste
|
| Creature lays [[egg]]s instead of giving birth to live young.

|-
| {{text anchor|LAYS_UNUSUAL_EGGS}}
| Caste
|
* [[item token]]
* [[material token]]
| Creature lays the specified item instead of regular eggs.

|-
| {{text anchor|LIGAMENTS}}
| Caste
|
* [[material token]]
*healing rate
| The creature has ligaments in its {{token|CONNECTIVE_TISSUE_ANCHOR|td}} tissues (bone or chitin by default). Cutting the bone/chitin tissue severs the ligaments, disabling motor function if the target is a limb.

|-
| {{text anchor|LIGHT_GEN}}
| Caste
|
| A vermin featuring this tag will remain visible to an adventurer even at night.

Subterranean vermin which feature this token will flicker in unexposed and unrevealed cavern layers while playing in Fortress Mode.

|-
| {{text anchor|LISP}}
| Caste
|
| Creature uses "sssssnake talk" (multiplies 'S' when talking - "My name isss Recisssiz."). Used by [[Serpent man|serpent men]] and [[Reptile man|reptile men]] in the vanilla game. C's with the same pronunciation (depending on the word) are not affected by this token.

|-
| {{text anchor|LITTERSIZE}}
| Caste
|
* minimum
* maximum
| Determines the number of offspring per one birth; default 1-3, not used in vanilla raws. See also {{token|MULTIPLE_LITTER_RARE|c}}.

|-
| {{text anchor|LOCAL_POPS_CONTROLLABLE}}
| Creature
|
| Allows you to play as a wild animal of this species in adventurer mode. Prevents trading of (tame) instances of this creature in caravans.

|-
| {{text anchor|LOCAL_POPS_PRODUCE_HEROES}}
| Creature
|
| Wild animals of this species may occasionally join a civilization. Prevents trading of (tame) instances of this creature in caravans.

|-
| {{text anchor|LOCKPICKER}}
| Caste
|
| Lets a creature open [[door]]s that are set to forbidden in fortress mode.

|-
| {{text anchor|LOOSE_CLUSTERS}}
| Creature
|
| The creatures will scatter if they have this tag, or form tight packs if they don't.

|-
| {{text anchor|LOW_LIGHT_VISION}}
| Caste
|
*number
| Determines how well a creature can see in the dark - higher is better. Dwarves have 10000, which amounts to perfect nightvision.
|}

{{alphabetical TOC|style=margin: 1em auto;}}

==M==
{| {{prettytable}}
|- bgcolor="#ddd"
! width="20%" | Token
! width="10%" | Type
! width="20%" | Arguments
! width="50%" | Description

|-
| {{text anchor|MAGICAL}}
| Caste
|
| According to Toady One, this is completely interchangeable with {{token|AT_PEACE_WITH_WILDLIFE|c}} and might have been used in very early versions of the game by wandering wizards, or the ent-type tree creatures that used to be animated by elves. [http://www.bay12forums.com/smf/index.php?topic=169696.msg8316954#msg8316954]

|-
| {{text anchor|MAGMA_VISION}}
| Caste
|
| The creature is able to see while submerged in [[magma]].

|-
| {{text anchor|MALE}}
| Caste
|
| Makes the creature biologically male; usually declared inside a caste.

|-
| {{text anchor|MANNERISM|MANNERISM_*}}
| Caste
|
*occasionally body part
| Adds a possible mannerism to the creature's profile. See [[creature mannerism token]] for further info.

|-
| {{text anchor|MATERIAL}}
| Creature
|
*material id
| Begins defining a new local material. Follow this with standard material definition tokens to define the material. A maximum of 200 materials can be defined on any given creature.

|-
| {{text anchor|MATERIAL_FORCE_MULTIPLIER}}
| Caste
|
*[[Material token]]
*value A
*value B
| When struck with a weapon made of the specified material, the force exerted will be multiplied by A/B, thus making the creature more or less susceptible to this material. For example, if A is 2 and B is 1, the force exerted by the defined material will be doubled. If A is 1 and B is 2, it will be halved instead. See also {{token|GENERAL_MATERIAL_FORCE_MULTIPLIER|c}}, which can be used to make this sort of effect applicable to all materials.

|-
| {{text anchor|MATUTINAL}}
| Caste
|
| When set, the creature will only appear at dawn (between 4:30 AM and 6:00 AM) in [[Adventurer mode]].

|-
| {{text anchor|MAXAGE}}
| Caste
|
*min
*max
| Determines the creature's natural lifespan, using the specified minimum and maximum age values (in years). Each individual creature with this token is generated with a predetermined date (calculated down to the exact [[time|tick]]!) between these values, at which it is destined to die of old age, should it live long enough. Note that the probability of death at any given age does not increase as the creature gets older [http://i.imgur.com/A1A4aA9.png].
Creatures which lack this token are naturally immortal. The [[Syndrome#CE_ADD_TAG|NO_AGING]] syndrome tag will prevent death by old age from occurring. Also note that, among civilized creatures, castes which lack this token will refuse to marry others with it, and vice versa.

|-
| {{text anchor|MEANDERER}}
| Caste
|
| Makes the creature slowly stroll around, unless it's in combat or performing a job. If combined with {{token|CAN_LEARN|c}}, will severely impact their [[pathfinding]] and lead the creature to move extremely slowly when not performing any task. <s>Problematically applies to animal people based on the animal, and war trained animals{{bug|9588}}</s> As of [[Release_information/52.05|version 52.05]], meandering behavior no longer applies to animal people and to animals that are trained for war or hunting..

|-
| {{text anchor|MEGABEAST}}
| Caste
|
| A 'boss' creature; a small number of those are created during worldgen, their histories and descendants (if any) will be tracked in worldgen (as opposed to simply 'spawning'), and they will occasionally go on rampages, potentially leading to worship if they attack the same place multiple times. Their presence and number will also influence world age names. When appearing in fortress mode, they will have a pop-up message announcing their arrival. They will remain hostile to the fortress military even after being tamed.{{bug|10731}} See [[megabeast]] page for more details.

Requires specifying a {{token|BIOME|c}} in which the creature will live. Subterranean biomes appear to not be allowed. Does stack with {{token|LARGE_ROAMING|c}} and if both are used the creature will spawn as both historical bosses and as wild animals.

|-
| {{text anchor|MENT_ATT_CAP_PERC}}
| Caste
|
*[[Attribute|ATTRIBUTE]] Token
*Cap %
|Default is 200. This means you can increase your attribute to 200% of its starting value (or the average value + your starting value if that is higher).

|-
| {{text anchor|MENT_ATT_RANGE}}
| Caste
|
*[[Attribute|ATTRIBUTE]]
*lowest
*lower
*low
*median
*high
*higher
*highest
| Sets up a [[Attribute#Soul_attributes|mental attribute]]'s range of values (0-5000). All mental attribute ranges default to 200:800:900:1000:1100:1300:2000.

|-
| {{text anchor|MENT_ATT_RATES}}
| Caste
|
*[[Attribute|ATTRIBUTE]] Token
*cost to improve
*unused counter rate
*rust counter rate
*demotion counter rate
| [[Attribute#Soul_attributes|Mental attribute]] gain/decay rates. Lower numbers in the last three slots make decay occur faster. Defaults are 500:4:5:4.

|-
| {{text anchor|MILKABLE}}
| Caste
|
* [[material token]]
* frequency
| Allows the creature to be [[milk]]ed in the [[farmer's workshop]]. The frequency is the amount of [[time|ticks]] the creature needs to "recharge" (i.e. how much time needs to pass before it can be milked again). Does not work on [[#CAN_LEARN|sentient]] creatures, regardless of [[ethics]].

|-
| {{text anchor|MISCHIEVIOUS}}
| Caste
|
| Alias for {{token|MISCHIEVOUS|c}}.

|-
| {{text anchor|MISCHIEVOUS}}
| Caste
|
| The creature spawns [[stealth]]ed and will attempt to path into the fortress, pulling any [[lever]]s it comes across. It will be invisible on the map and [[unit list]] until spotted by a citizen, at which point the game will pause and recenter on the creature. Used by [[gremlin]]s in the vanilla game. "They go on little missions to mess with various fortress buildings, not just levers."

|-
| {{text anchor|MODVALUE}}
| Caste
|
| Seemingly no longer used.

|-
| {{text anchor|MOUNT}}
| Caste
|
| Creature may be used as a [[mount]]. No use for the player in fortress mode, but enemy [[siege|sieging]] forces may arrive with cavalry. Mounts are usable in [[adventure mode]].

|-
| {{text anchor|MOUNT_EXOTIC}}
| Caste
|
| Creature may be used as a [[mount]], but civilizations cannot domesticate it in worldgen without certain exceptions.

|-
| {{text anchor|MULTIPART_FULL_VISION}}
| Caste
|
| Allows the creature to have all-around vision, as long as it has multiple heads that can see.

|-
| {{text anchor|MULTIPLE_LITTER_RARE}}
| Caste
|
| Makes the species usually produce a single offspring per birth, with a 1/500 chance of using the {{token|LITTERSIZE|c}} as usual. Requires {{token|FEMALE|c}}.

|-
| {{text anchor|MUNDANE}}
| Creature
|
| Marks if the creature is an actual real-life creature. Only used for age-names at present.
|}

{{alphabetical TOC|style=margin: 1em auto;}}

==N==
{| {{prettytable}}
|- bgcolor="#ddd"
! width="20%" | Token
! width="10%" | Type
! width="20%" | Arguments
! width="50%" | Description

|-
| {{text anchor|NAME}}
| Creature
|
*singular
*plural
*adjective
| The generic name for any creature of this type - will be used for referring to the species in the abstract, such as the default material prefix. For labeling individual creatures, {{token|CASTE_NAME|c}} is necessary. If left undefined, the creature will be labeled as "nothing" by the game.

Some examples of adjective use:
* "super''dwarven'' strength"
* "the ''dwarven'' hillocks of X"
* Deity species as in "''feline'' deity"
* Megabeast attacks in worldgen. One with multiple dragons being a "''draconic'' rampage"

|-
| {{text anchor|NATURAL}}
| Caste
|
| Animal is considered to be natural. NATURAL animals will not engage creatures tagged with {{token|AT_PEACE_WITH_WILDLIFE|c}} in combat unless they are members of a hostile entity and vice-versa.

|-
| {{text anchor|NATURAL_ANIMAL}}
| Caste
|
| Alias of {{token|NATURAL|c}}.

|-
| {{text anchor|NATURAL_SKILL}}
| Caste
|
*[[Skill_token|Skill token]]
*value
| The creature possesses the specified [[skill]] at this level inherently - that is, it begins with the skill at this level, and the skill may never rust below that. A value of 15 is legendary.

|-
| {{text anchor|NIGHT_CREATURE}}
| Caste
|
| Creatures with this token can appear as [[experiment|experiments]]. Causes the creature to count as {{token|NOT_LIVING|c}}.

Killing a creature featuring this token provides one point of "hero" reputation. Adds the creature's description as part of the initial summary of their historical figure in legends mode. People will react to creatures with this token as a night creature (natch). In adventure mode, ambushes involving these units will say "Night creature!" instead of "Ambush!"

Prevents creature behavior enabled by {{token|LARGE_PREDATOR|c}}.

Removes the high nature value check imposed by {{token|LOCAL_POPS_PRODUCE_HEROES|c}}.

Prevents the AI from using ANIMATE interactions, unless the newly-animated{{token|OPPOSED_TO_LIFE|c}}undead will not attack them. The check for this is specifically whether the unit is:
*a ghost
*an animated unit
*a unit with the {{token|NO_AGING|c}} token added via {{token|CE_ADD_TAG|c}}. (This allows for the default exclusion of elves and goblins, unless raised as intelligent undead.)

|-
| {{text anchor|NIGHT_CREATURE_BOGEYMAN}}
| Caste
|
| Creatures with this token can appear in [[bogeyman|bogeyman ambushes]] in [[adventure mode]], where they adopt classical bogeyman traits such as stalking the adventurer and vaporising when dawn breaks. Such traits do not manifest if the creature is encountered outside of a bogeyman ambush (for instance, as a megabeast or a civilised being). In addition, their corpses and severed body parts turn into [[smoke]] after a short while. Note that setting the "Number of Bogeyman Types" in [[advanced world generation]] to 0 will only remove randomly-generated bogeymen.

|-
| {{text anchor|NIGHT_CREATURE_EXPERIMENTER}}
| Caste
|
| Found on some [[necromancer]]s. Creatures with this tag may periodically "perform horrible experiments" offscreen, during which they can use creature-targeting interactions with an <code>[[Interaction_token#I_SOURCE|[I_SOURCE:EXPERIMENT]]]</code> tag on living creatures in their area. Worlds are generated with a list of procedurally-generated experiments, allowing necromancers to turn living people and animals into [[Infected_ghoul|ghouls]] and [[Experiment|other experimental creatures]], and these will automatically be available to all experimenters; it does not appear possible to prevent this. You can mod in your own custom experiment interactions, but these are used very infrequently due to the large number of generated experiments.

|-
| {{text anchor|NIGHT_CREATURE_HUNTER}}
| Caste
|
| Found on [[night troll]]s and [[werebeast]]s. Implies that the creature is a [[night creature]], and shows its description in [[legends mode]] entry. The creature is always hostile and will start [[no quarter]] combat with any nearby creatures, except for members of its own race.{{verify}} Note that this tag does not override the creature's normal behavior in [[fortress mode]] except for the aforementioned aggression, and doesn't prevent the creature from fleeing the battles it started. It also removes the creature's materials from stockpile settings list, making them be stored there regardless of settings.

Does stack with {{token|LARGE_ROAMING|c}} and if both are used the creature will spawn as both historical hunters and as wild animals; this requires specifying a {{token|BIOME|c}} in which the creature will live, and subterranean biomes are allowed.

This tag causes the usual behaviour of werebeasts in worldgen, that is, fleeing towns upon being cursed and conducting raids from a lair. If this tag is absent from a deity curse, the accursed will simply be driven out of towns in a similar manner to [[vampire]]s. When paired with SPOUSE_CONVERTER, a very small population of the creature will be created during worldgen (sometimes only a single individual will be created), and their histories will be tracked (that is, they will not spawn spontaneously later, they must either have children or convert other creatures to increase their numbers). The creature will settle in a lair and go on rampages during worldgen. It will actively attempt to seek out potential conversion targets to abduct, convert, and have children with (if possible).

|-
| {{text anchor|NIGHT_CREATURE_NIGHTMARE}}
| Caste
|
| Found on [[nightmare]]s. Corpses and severed body parts derived from creatures with this token turn into [[smoke]] after a short while.

|-
| {{text anchor|NO_AUTUMN}}
| Caste
|
| The creature caste does not appear in [[Calendar|autumn]].

|-
| {{text anchor|NO_CONNECTIONS_FOR_MOVEMENT}}
| Caste
|
| Creature doesn't require connected body parts to move{{verify}}; generally used on undead creatures with connections that have rotted away.

|-
| {{text anchor|NO_DIZZINESS}}
| Caste
|
| Creature cannot become [[Symptom#Dizziness|dizzy]].

|-
| {{text anchor|NO_DRINK}}
| Caste
|
| Creature does not need to drink.

|-
| {{text anchor|NO_EAT}}
| Caste
|
| Creature does not need to [[food|eat]].

|-
| {{text anchor|NO_FEVERS}}
| Caste
|
| Creature cannot suffer [[Symptom#Fever|fevers]].

|-
| {{text anchor|NO_GENDER}}
| Caste
|
| The creature is biologically sexless, making it unable to [[breeding|breed]].

|-
| {{text anchor|NO_PHYS_ATT_GAIN}}
| Caste
|
| The creature cannot raise any [[Attribute#Body_attributes|physical attributes]].

|-
| {{text anchor|NO_PHYS_ATT_RUST}}
| Caste
|
| The creature cannot lose any [[Attribute#Body_attributes|physical attributes]].

|-
| {{text anchor|NO_SLEEP}}
| Caste
|
| Creature does not need to sleep, but can still be rendered unconscious by other means.

|-
| {{text anchor|NO_SPRING}}
| Caste
|
| The creature caste does not appear in [[Calendar|spring]].

|-
| {{text anchor|NO_SUMMER}}
| Caste
|
| The creature caste does not appear in [[Calendar|summer]].

|-
| {{text anchor|NO_THOUGHT_CENTER_FOR_MOVEMENT}}
| Caste
|
| The bodyparts of this creature don't need to be connected to an organ with the {{token|THOUGHT|body}} tag in order to have motor function. Generally used on creatures that don't have brains. If a creature doesn't have a thought part and doesn't have this token, it will be unable to grasp or stand. Nautilus men experience this issue in vanilla.

|-
| {{text anchor|NO_UNIT_TYPE_COLOR}}
| Caste
|
| Prevents creature from selecting its color based on its profession (e.g. Miner, Hunter, Wrestler).

|-
| {{text anchor|NO_VEGETATION_PERTURB}}
| Caste{{Verify}}
|
| Likely prevents the creature from leaving broken vegetation tracks.{{Verify}}

|-
| {{text anchor|NO_WINTER}}
| Caste
|
| The creature caste does not appear in [[Calendar|winter]].

|-
| {{text anchor|NOBONES}}
| Caste
|
| Creature cannot be picked up for worldgen fell moods and cannot be made a skeleton deity.

|-
| {{text anchor|NOBREATHE}}
| Caste
|
| Creature doesn't need to breathe or have {{token|BREATHE|body}}parts in its body, nor can it drown or be strangled. Creatures living in magma must have this tag, otherwise they will drown.

|-
| {{text anchor|NOCTURNAL}}
| Caste
|
| When set, the creature will only appear at night (after 10:05 PM and before 4:30 AM) in [[Adventurer mode]].

|-
| {{text anchor|NOEMOTION}}
| Caste
|
| Creature has no emotions, thus; it is immune to the effects of [[stress]] and unable to rage, and its [[need]]s cannot be fulfilled in any way. Used on [[undead]] in the vanilla game.

|-
| {{text anchor|NOEXERT}}
| Caste
|
| Creature can't become tired or over-exerted from taking too many combat actions, or moving at full speed for extended periods of time.

|-
| {{text anchor|NOFEAR}}
| Caste
|
| Creature doesn't feel fear and will never flee from battle, and will be immune to [[ghost]]s' attempts to 'scare it to death'. Additionally, it causes [[bogeyman|bogeymen]] and [[nightmare]]s to become friendly towards the creature.

|-
| {{text anchor|NOMEAT}}
| Caste
|
| Creature will not be hunted or fed to wild beasts.

|-
| {{text anchor|NONAUSEA}}
| Caste
|
| Creature isn't nauseated by gut hits and cannot vomit.

|-
| {{text anchor|NOPAIN}}
| Caste
|
| Creature doesn't feel pain.

|-
| {{text anchor|NOSKIN}}
| Caste
|
| Creature will not drop a hide when [[butcher|butchered]].

|-
| {{text anchor|NOSKULL}}
| Caste
|
| Creature will not drop a skull on butchering, rot, or decay of severed head.

|-
| {{text anchor|NOSMELLYROT}}
| Caste
|
| Does not produce [[miasma]] when rotting.

|-
| {{text anchor|NOSTUCKINS}}
| Caste
|
| Weapons can't get stuck in the creature.

|-
| {{text anchor|NOSTUN}}
| Caste
|
| Creature can't be stunned and knocked unconscious by pain or head injuries. Creatures with this tag never wake up from sleep in Fortress Mode. If this creature needs to sleep while playing, it will die.

|-
| {{text anchor|NOT_BUTCHERABLE}}
| Caste
|
| Corpses from this creature cannot be [[butcher|butchered]]. Does not prevent the creature from being slaughtered while alive, however.

|-
| {{text anchor|NOT_LIVING}}
| Caste
|
| Cannot be raised from the dead by necromancers or evil clouds. Implies the creature is not a normal living being. Used by [[vampire]]s, [[Mummy|mummies]] and inorganic creatures like the [[amethyst man]] and [[bronze colossus]]. Creatures who are {{token|OPPOSED_TO_LIFE|c}} (undead) will be docile towards creatures with this token.

|-
| {{text anchor|NOTHOUGHT}}
| Caste
|
| Creature doesn't require a {{token|THOUGHT|body}} body part to survive. Has the added effect of preventing speech, though directly controlling creatures that would otherwise be capable of speaking allows them to engage in conversation.
|}

{{alphabetical TOC|style=margin: 1em auto;}}

==O==
{| {{prettytable}}
|- bgcolor="#ddd"
! width="20%" | Token
! width="10%" | Type
! width="20%" | Arguments
! width="50%" | Description

|-
| {{text anchor|ODOR_LEVEL}}
| Caste
|
*number
| How easy the creature is to [[smell]]. The higher the number, the easier the creature is to sniff out. Defaults to 50. Vanilla creatures have values from 0 (undetectable) to 90 (noticeable by humans and dwarves).

|-
| {{text anchor|ODOR_STRING}}
| Caste
|
*string
| What the creature [[smell]]s like. If no odor string is defined, the creature name (not the caste name) is used.

|-
| {{text anchor|OPPOSED_TO_LIFE}}
| Caste
|
| Is hostile to all creatures except undead and other non-living ones and will show {{DFtext|Opposed to life|0:1}} in the [[unit list]]. Used by [[undead]] in the vanilla game. Functions without the {{token|NOT_LIVING|c}} token, and seems to imply said token as well. Undead will not be hostile to otherwise-living creatures given this token. Living creatures given this token will attack living creatures that lack it, while ignoring other living creatures that also have this token.

|-
| {{text anchor|ORIENTATION}}
| Caste
|
*MALE/FEMALE
*disinterested chance
*casual chance
*strong chance
| Determines caste's likelihood of having sexual attraction to certain sexes. Values default to 75:20:5 for the same sex and 5:20:75 for the opposite sex. The first value indicates how likely to be entirely uninterested in the sex, the second decides if the creature will be able to become lovers with that sex, the third decides whether they will be able to marry in worldgen and post-worldgen world activities (which implies being able to become lovers). Marriage seems to be able to happen in fort mode play regardless, as long as they are lovers first.

|-
| {{text anchor|OUTSIDER_CONTROLLABLE}}
| Caste
|
| Lets you play as an [[Adventurer_mode_character_creation#Outsider|outsider]] of this species in adventure mode.

|}

{{alphabetical TOC|style=margin: 1em auto;}}

==P==
{| {{prettytable}}
|- bgcolor="#ddd"
! width="20%" | Token
! width="10%" | Type
! width="20%" | Arguments
! width="50%" | Description

|-
| {{text anchor|PACK_ANIMAL}}
| Caste
|
| Allows the creature to be used as a pack animal. Used by [[trading|merchants]] without wagons and adventurers. Also prevents creature from dropping hauled items on its own -- do ''not'' use for player-controllable creatures! May lead to the creature being domesticated during worldgen, even if it doesn't have {{token|COMMON_DOMESTIC|c}}.

Creatures with this tag but without {{token|BENIGN|c}}, and/or with {{token|LARGE_PREDATOR|c}} leads to hauled items being dropped.

|-
| {{text anchor|PARALYZEIMMUNE}}
| Caste
|
| The creature is immune to all [[Syndrome#CE_PARALYSIS|paralyzing]] special attacks.

|-
| {{text anchor|PATTERNFLIER}}
| Caste
|
| Used to control the bat riders with paralyze-dart blowguns that flew through the 2D chasm. Doesn't do anything now.

|-
| {{text anchor|PCG_LAYERING}}
| Creature
|
*[[Procedural graphics layer|Layering type]]
| Adds a layer to the current {{token|PROCEDURAL_CREATURE_GRAPHICS|c}} definition.

|-
| {{text anchor|PEARL}}
| Caste
|
| Does nothing.

|-
| {{text anchor|PENETRATEPOWER}}
| Caste
|
*value
| Controls the ability of [[vermin]] to find a way into containers when they are eating food from your stockpiles.

Objects made of most materials (e.g. metal) roll a number from 0-100, and if the resulting number is greater than the penetrate power, their contents escape for the time being. Objects made of [[wood]], [[leather]], [[amber]], or [[coral]] roll 0-95, and items made of [[cloth]] roll 0-90.

|-
| {{text anchor|PERSONALITY}}
| Caste
|
*ATTRIBUTE
*lowest
*median
*highest
| Determines the range and chance of personality facets. Standard is 0:50:100. See [[personality facet]] for more info.

|-
| {{text anchor|PET}}
| Caste
|
| Allows the creature to be [[Animal_trainer|tamed]] in Fortress mode. Prerequisite for all other working animal roles. Civilizations that encounter it in worldgen will tame and domesticate it for their own use. Adding this to civilization members will classify them as pets instead of citizens, with all the [[Fun|problems]] that entails. However, you can solve these problems using the popular plugin [https://dffd.bay12games.com/file.php?id=13095| Dwarf Therapist], which is completely unaffected by the tag.

|-
| {{text anchor|PET_EXOTIC}}
| Caste
|
| Allows the creature to be [[Animal_trainer|tamed]] in Fortress mode. Prequisite for all other working animal roles. Civilizations cannot domesticate it in worldgen, with certain exceptions. More difficult to tame?{{verify}} Adding this to civilization members will classify them as pets instead of citizens, with all the [[Fun|problems]] that entails. ([[Gremlin|Example]]).

|-
| {{text anchor|PETVALUE}}
| Caste
|
*value
| How valuable a tamed animal is. Actual cost in points in the embarking screen is 1+(PETVALUE/2) for an untrained animal, 1+PETVALUE for a war/hunting one.

|-
| {{text anchor|PETVALUE_DIVISOR}}
| Caste
|
*value
| Divides the creature's {{token|PETVALUE|c}} by the specified number. Used by [[honey bee]]s to prevent a single hive from being worth a fortune.

|-
| {{text anchor|PHYS_ATT_CAP_PERC}}
| Caste
|
*[[Attribute|ATTRIBUTE]] Token
*Cap %
|Default is 200. This means you can increase your attribute to 200% of its starting value (or the average value + your starting value if that is higher).

|-
| {{text anchor|PHYS_ATT_RANGE}}
| Caste
|
*[[Attribute|ATTRIBUTE]]
*lowest
*lower
*low
*median
*high
*higher
*highest
| Sets up a [[Attribute#Body_attributes|physical attribute]]'s range of values (0-5000). All physical attribute ranges default to 200:700:900:1000:1100:1300:2000.

|-
| {{text anchor|PHYS_ATT_RATES}}
| Caste
|
*[[Attribute|ATTRIBUTE]] Token
*cost to improve
*unused counter rate
*rust counter rate
*demotion counter rate
| [[Attribute#Body_attributes|Physical attribute]] gain/decay rates. Lower numbers in the last three slots make decay occur faster. Defaults for STRENGTH, AGILITY, TOUGHNESS, and ENDURANCE are 500:3:4:3, while RECUPERATION and DISEASE_RESISTANCE default to 500:NONE:NONE:NONE.

|-
| {{text anchor|PLUS_BP_GROUP}}
| Caste
|
*BY_TYPE, BY_CATEGORY, or BY_TOKEN
*body type, category, or token
| Adds a body part group to selected body part group. Presumably used immediately after {{token|SET_BP_GROUP|c}}.

|-
| {{text anchor|PLUS_MATERIAL}}
| Creature
|
*material
| Adds a material to selected materials. Used immediately after {{token|SELECT_MATERIAL|c}}.

|-
| {{text anchor|POP_RATIO}}
| Caste
|
*number (max 100000)
| Weighted population of caste; Lower is rarer. Not to be confused with {{token|FREQUENCY|c}}. A weight of 0 will{{version|51.06 experimental}} prevent a caste from spawning naturally. Regardless of pop ratio, [[Position token|Position]]s that only allow a certain caste can force it to spawn.

|-
| {{text anchor|POPULATION_NUMBER}}
| Creature
|
*min
*max
| The minimum/maximum numbers of how many of these creatures are present in each world map tile of the appropriate region. Defaults to 1:1 if not specified. If the creature's chosen {{token|CLUSTER_NUMBER|c}} happens to be larger, it will be used instead.

|-
| {{text anchor|POWER}}
| Caste
|
| Allows the being to represent itself as a deity, allowing it to become the leader of a civilized group. Not used by any creatures in the vanilla game. Requires {{token|CAN_SPEAK|c}} to actually do anything more than settle at a location (e.g. write books, lead armies, profane temples). Doesn't appear to do anything for creatures that are already civilized. Once the creature ascends to a position of leadership, it will proceed to act as a standard ruler for their entity and fulfill the same functions (hold tournaments, tame creatures, etc.).

|-
| {{text anchor|PREFSTRING}}
| Creature
|
*string
| Sets what other creatures [[Preferences|prefer]] about this creature. "Urist likes dwarves for their beards." Multiple entries will be chosen from at random. Creatures lacking a PREFSTRING token will never appear under another's preferences.

|-
| {{text anchor|PROCEDURAL_CREATURE_GRAPHICS}}
| Creature
|
* [[Graphics_token#Basic_creature_sprite_types|Sprite type]] or Caste then sprite type
| Makes the creature have procedural graphics built for it, like forgotten beasts/demons/titans/experiments. Must be associated with PCG_LAYERING tokens.

|-
| {{text anchor|PROFESSION_NAME}}
| Creature
|
*[[Unit type token]] (Profession)
*singular
*plural
| The generic name for members of this profession, at the creature level. In order to give members of specific castes different names for professions, use {{token|CASTE_PROFESSION_NAME|c}} instead.

|-
| {{text anchor|PRONE_TO_RAGE}}
| Caste
|
*Chance
| Creature has a percentage chance to flip out at visible non-friendly creatures. Enraged creatures attack anything regardless of timidity and get a strength bonus to their hits. This is what makes [[badger]]s so hardcore.

|-
| {{text anchor|PUS}}
| Caste
|
* <[[material token]]>
* <[[Material_definition_token#Material_States|material state]]>
| The creature has pus. Specifies the stuff secreted by [[Health_care#Infection|infected wounds]].
|}

{{alphabetical TOC|style=margin: 1em auto;}}

==R==
{| {{prettytable}}
|- bgcolor="#ddd"
! width="20%" | Token
! width="10%" | Type
! width="20%" | Arguments
! width="50%" | Description

|-
| {{text anchor|RELSIZE}}
| Caste
|
*BY_CATEGORY, BY_TYPE, BY_TOKEN
*body category, type, or token
*Relsize
| Specifies a new relative size for a part than what is stated in the body plan. For example, dwarves have larger livers.

|-
| {{text anchor|REMAINS}}
| Caste
|
*singular
*plural
| What the creature's [[remains]] are called.

|-
| {{text anchor|REMAINS_COLOR}}
| Caste
|
| What color the creature's [[remains]] are.

|-
| {{text anchor|REMAINS_ON_VERMIN_BITE_DEATH}}
| Caste
|
| Goes with {{token|VERMIN_BITE|c}} and {{token|DIE_WHEN_VERMIN_BITE|c}}, the vermin creature will leave remains on death when biting. Leaving this tag out will cause the creature to disappear entirely after it bites.

|-
| {{text anchor|REMAINS_UNDETERMINED}}
| Caste
|
| Nothing.

|-
| {{text anchor|REMOVE_MATERIAL}}
| Creature
|
*material token
| Removes a material from the creature.

|-
| {{text anchor|REMOVE_TISSUE}}
| Creature
|
*tissue token
| Removes a tissue from the creature.

|-
| {{text anchor|RETRACT_INTO_BP}}
| Caste
|
*BY_TYPE, BY_CATEGORY or BY_TOKEN
*body type, [[Body_token#CATEGORY|category]], or [[Body_token#BP|token]]
*Second person ("You") retract verb text
*Third person ("The giant snail") retract verb text
*Second person cancel retract text
*Third person cancel retract text
| The creature will retract into the specified body part(s) when threatened. It will be unable to move or attack, but enemies will only be able to attack the specified body part(s). When one of the specified body part is severed off, the creature automatically unretracts and cannot retract anymore. More than one body part can be selected by using BY_TYPE or BY_CATEGORY.

Second-person descriptions are used for adventurer mode natural ability. "<pro_pos>" can be used in the descriptions, being replaced with the proper pronoun (or lack thereof) in-game.

Undead curled up creatures are buggy, specifically those that retract into their upper bodies: [[echidna]]s, [[hedgehog]]s and [[pangolin]]s.{{bug|11463}}{{bug|10519}} The upper body is prevented from collapsing by a separate body part (the middle spine), which cannot be attacked when the creature is retracted. See {{token|PREVENTS_PARENT_COLLAPSE|bo}}. Living creatures eventually succumb to blood loss, but undead creatures do not. Giant creatures also take a very long time to bleed out.
|-
| {{text anchor|RETURNS_VERMIN_KILLS_TO_OWNER}}
| Creature
|
| Cat behavior. If it kills a vermin creature and has an owner, it carries the remains in its mouth and drops them at their feet. Requires {{token|HUNTS_VERMIN|c}}.

|-
| {{text anchor|ROOT_AROUND}}
| Caste
|
*BY_TYPE, BY_CATEGORY or BY_TOKEN
*body type, [[Body_token#CATEGORY|category]], or [[Body_token#BP|token]]
*Second person ("You") verb text
*Third person ("The hen") verb text
| Creature will occasionally root around in the grass, looking for insects. Used for flavor in Adventurer Mode, spawns vermin edible for this creature in Fortress Mode. Creatures missing the specified body part will be unable to perform this action. The action produces a message (visible in adventure mode) in the form:

{{DFtext|[creature] [verb text] the [description of creature's location].|6:0}}

In adventure mode, the "rooting around" ability will be included in the "natural abilities" menu, represented by its second person verb text.

|}

{{alphabetical TOC|style=margin: 1em auto;}}

==S==
{| {{prettytable}}
|- bgcolor="#ddd"
! width="20%" | Token
! width="10%" | Type
! width="20%" | Arguments
! width="50%" | Description

|-
| {{text anchor|SAVAGE}}
| Creature
|
| The creature will only show up in "savage" biomes. Has no effect on cavern creatures. Cannot be combined with {{token|GOOD|c}} or {{token|EVIL|c}}.

|-
| {{text anchor|SECRETION}}
| Caste
|
*<[[material token]]>
*<[[Material_definition_token#Material_States|material state]]>
*BY_TOKEN / BY_CATEGORY / BY_TYPE
*<[[Body_token#BP|body part ID]]> / <[[Body_token#CATEGORY|category]]> or ALL / <type (e.g. [[Body_token#GRASP|GRASP]])>
*<[[Body_detail_plan_token#BP_LAYERS|tissue layer]]> or ALL
*<trigger>
| Causes the specified tissue layer(s) of the indicated body part(s) to secrete the designated material. A size 100 ('covering') [[contaminant]] is created over the affected body part(s) in its specified material state (and at the temperature appropriate to this state) when the trigger condition is met, as long as one of the secretory tissue layers is still intact. Valid triggers are:
*'''CONTINUOUS'''
Secretion occurs once every 40 [[time|ticks]] in [[fortress mode]], and every tick in [[adventurer mode]].
*'''EXERTION'''
Secretion occurs continuously (at the rate described above) whilst the creature is at minimum {{Tile|Tired|6:1}} following physical exertion. Note that this cannot occur if the creature has {{token|NOEXERT|c}}.
*'''EXTREME_EMOTION'''
Secretion occurs continuously (as above) whilst the creature is distressed. Cannot occur in creatures with {{token|NOEMOTION|c}}.

|-
| {{text anchor|SELECT_ADDITIONAL_CASTE}}
| Creature
|
*<caste>
| Adds an additional previously defined caste to the selection. Used after {{token|SELECT_CASTE|c}}.

|-
| {{text anchor|SELECT_CASTE}}
| Creature
|
*<caste> or ALL
| Selects a previously defined caste

|-
| {{text anchor|SELECT_MATERIAL}}
| Creature
|
*<[[material token]]>
| Selects a locally defined material. Can be ALL.

|-
| {{text anchor|SELECT_TISSUE}}
| Creature
|
*tissue token
| Selects a tissue for editing.

|-
| {{text anchor|SEMIMEGABEAST}}
| Caste
|
| Essentially the same as {{token|MEGABEAST|c}}, but more of them are created during worldgen. See the [[semi-megabeast]] page for details.

|-
| {{text anchor|SENSE_CREATURE_CLASS}}
| Caste
|
* <[[Creature_token#CREATURE_CLASS|creature class]]>
* [[Tilesets|<tile value or character>]]
* [[Color#Color_values|<foreground color>:<background color>:<foreground brightness>]]
| Gives the creature the ability to sense creatures belonging to the specified [[Creature_token#CREATURE_CLASS|creature class]] even when they lie far beyond line of sight, including through walls and floors. It also appears to reduce or negate the combat penalty of [[Wound#Blindness|blind]] units when fighting creatures they can sense. In [[adventure mode]], the specified tile will be used to represent sensed creatures when they cannot be seen directly.

|-
| {{text anchor|SET_BP_GROUP}}
| Caste
|
*selection criteria BY_TYPE, BY_CATEGORY, BY_TOKEN
*category, type, or token
| Begins a selection of body parts.

|-
| {{text anchor|SKILL_LEARN_RATE}}
| Caste
|
*<[[skill_token]]>
*<percentage>
| The rate at which this creature learns this skill. Requires {{token|CAN_LEARN|c}} or {{token|INTELLIGENT|c}} to function.

|-
| {{text anchor|SKILL_LEARN_RATES}}
| Caste
|
*<percentage>
| The rate at which this creature learns all skills. Requires {{token|CAN_LEARN|c}} or {{token|INTELLIGENT|c}} to function.

|-
| {{text anchor|SKILL_RATE}}
| Caste
|
*[[skill_token]]
*<% of improvement points gained>
*<unused counter rate>
*<rust counter rate>
*<demotion counter rate>
| Like {{token|SKILL_RATES|c}}, but applies to individual skills instead. Requires {{token|CAN_LEARN|c}} or {{token|INTELLIGENT|c}} to function.

|-
| {{text anchor|SKILL_RATES}}
| Caste
|
*<% of improvement points gained>
*<unused counter rate>
*<rust counter rate>
*<demotion counter rate>
| Affects skill gain and decay. Lower numbers in the last three slots make decay occur faster ([SKILL_RATES:100:1:1:1] would cause rapid decay). The counter rates may also be replaced with NONE.
Default is [SKILL_RATES:100:8:16:16]. Requires {{token|CAN_LEARN|c}} or {{token|INTELLIGENT|c}} to function.

|-
| {{text anchor|SKILL_RUST_RATE}}
| Caste
|
*[[skill_token]]
*value
*value
*value
| The rate at which this skill decays. Lower values cause the skill to decay faster. Requires {{token|CAN_LEARN|c}} or {{token|INTELLIGENT|c}} to function.

|-
| {{text anchor|SKILL_RUST_RATES}}
| Caste
|
*value
*value
*value
| The rate at which all skills decay. Lower values cause the skills to decay faster. Requires {{token|CAN_LEARN|c}} or {{token|INTELLIGENT|c}} to function.

|-
| {{text anchor|SLAIN_CASTE_SPEECH}}
| Caste
|
*[[Speech file|text set]]
| Caste-specific {{token|SLAIN_SPEECH|c}}.

|-
| {{text anchor|SLAIN_SPEECH}}
| Creature
|
*[[Speech file|text set]]
| Boasting speeches relating to killing this creature. Examples include [[text_dwarf.txt/raw|text_dwarf.txt]] (<code>[SLAIN_SPEECH:SLAIN_DWARF]</code>) and text_elf.txt (<code>[SLAIN_SPEECH:SLAIN_ELF]</code>) in data\vanilla\vanilla_creatures\objects.

|-
| {{text anchor|SLOW_LEARNER}}
| Caste
|
| Allows the creature to learn skills without making the creature be considered sapient, though only at half of the normal rate (equivalent to {{token|SKILL_LEARN_RATES|c|50}}). All creatures that use this token in vanilla use it alongside {{token|CAN_LEARN|c}}, so it is not well known what it does by itself. Used by a number of 'primitive' creatures (like [[ogre]]s, [[giant]]s and [[troglodyte]]s) in the vanilla game. Prevents a player from recruiting nobility, even basic ones. (clarify?) Creatures with this token combined with {{token|EVIL|c}} can become domesticated by civilizations with {{token|USE_EVIL_ANIMALS|e}}, as seen commonly with goblin civilizations domesticating [[troll]]s.

|-
| {{text anchor|SMALL_REMAINS}}
| Caste
|
| Creature leaves "[[item token#REMAINS|remains]]" instead of a corpse. Used by [[vermin]].

|-
| {{text anchor|SMELL_TRIGGER}}
| Caste
|
*value
| Determines how keen a creature's sense of smell is - lower is better. At 10000, a creature cannot smell at all.

|-
| {{text anchor|SOLDIER_ALTTILE}}
| Creature
|
*'character' or tile number
| If this creature is active in its civilization's military, it will blink between its default tile and this one.

|-
| {{text anchor|SOUND}}
| Caste
|
* Sound application (currently accepts ALERT or PEACEFUL_INTERMITTENT)
* Sound range (in tiles)
* Sound delay (lower values = sound is produced more often)
* VOCALIZATION or NONE (determines whether the sound requires breathing or not)
* First-person description
* Third-person description
* Description when out of sight
| Creature makes sounds periodically, which can be heard in Adventure mode.
* First-person reads "You '''bark'''"
* Third-person reads "The [[capybara]] '''barks'''"
* Out of sight reads "You hear '''a loud bark'''"
with the text in bold being the description arguments of the token.

|-
| {{text anchor|SOURCE_HFID}}
| Creature
|
*Integer
| Found on generated [[angel]]s. This is the historical figure ID of the deity with which the angel is associated. Since HFIDs are not predictable before worldgen, this isn't terribly usable in non-lua mods.

|-
| {{text anchor|SPECIFIC_FOOD}}
| Caste
|
* PLANT or CREATURE
* Plant/creature ID
| Creature will only appear in biomes with this plant or creature available. Grazers given a specific type of grass (such as [[panda]]s and [[bamboo]]) will only eat that grass and nothing else, risking starvation if there's none available.

|-
| {{text anchor|SPHERE}}
| Creature
|
* [[Sphere#Available_spheres|sphere]]
| Sets what religious spheres the creature is aligned to, for purposes of being worshipped via the {{token|POWER|c}} token. Affects the creature's name. Creatures with spheres opposed to Death (ie: HEALING, LONGEVITY, YOUTH) will be much less likely to pursue the secrets of life and death.

|-
| {{text anchor|SPOUSE_CONVERSION_TARGET}}
| Caste
|
| This creature can be converted by a night creature with {{token|SPOUSE_CONVERTER|c}}.

|-
| {{text anchor|SPOUSE_CONVERTER}}
| Caste
|
| If the creature has the {{token|NIGHT_CREATURE_HUNTER|c}} tag, it will kidnap {{token|SPOUSE_CONVERSION_TARGET|c}}s and transform them into the caste of its species with the {{token|CONVERTED_SPOUSE|c}} tag during worldgen. It may also start families this way.

|-
| {{text anchor|SPREAD_EVIL_SPHERES_IF_RULER}}
| Caste
|
| If the creature rules over a [[site]], it will cause the local landscape to be corrupted into [[Surroundings#Evil|evil surroundings]] associated with the creature's [[Creature_token#SPHERE|sphere]]s. The creature must have at least one of the following [[sphere]]s for this to take effect: BLIGHT, DEATH, DISEASE, DEFORMITY, NIGHTMARES. The first three kill vegetation, while the others sometimes do. The last two get [[Plant_token#EVIL|evil plants]] and [[Creature_token#EVIL|evil animals]] sometimes. NIGHTMARES gets [[bogeyman|bogeymen]]. [http://www.bay12forums.com/smf/index.php?topic=169696.msg8162224#msg8162224] Used by [[demon]]s in the vanilla game.

|-
| {{text anchor|STANCE_CLIMBER}}
| Caste
|
| Caste does not require <code>[[Body_token#GRASP|[GRASP]]]</code> body parts to climb -- it can climb with <code>[[Body_token#STANCE|[STANCE]]]</code> parts instead.

|-
| {{text anchor|STANDARD_GRAZER}}
| Caste
|
| Acts as {{token|GRAZER|c}} but set to 20000*G*(max size)^(-3/4), where G defaults to 100 but can be set in d_init, and the whole thing is trapped between 150 and 3 million. Used for all grazers in the default creature raws.

|-
| {{text anchor|STRANGE_MOODS}}
| Caste
|
| The creature will get [[strange mood]]s in fortress mode and can produce artifacts.

|-
| {{text anchor|SUPERNATURAL}}
| Caste
|
| Gives the creature knowledge of any secrets with <code>[[Interaction_token#IS_SECRET|[SUPERNATURAL_LEARNING_POSSIBLE]]]</code> that match its [[Creature_token#SPHERE|spheres]] and also prevents it from becoming a [[vampire]] or [[werebeast]]. Other effects are unknown.

|-
| {{text anchor|SWIMS_INNATE}}
| Caste
|
| The creature naturally knows how to swim perfectly and does not use the [[swimmer]] skill, as opposed to {{token|SWIMS_LEARNED|c}} below. However, Fortress mode AI never paths into water anyway, so it's less useful there.

|-
| {{text anchor|SWIMS_LEARNED}}
| Caste
|
| The creature swims only as well as their present [[Swimmer|swimming skill]] allows them to.

|-
| {{text anchor|SYNDROME_DILUTION_FACTOR}}
| Caste
| <[[Syndrome#SYN_IDENTIFIER|syndrome identifier]]>:<percentage>
| Dilutes the effects of syndromes which have the specified identifier. A percentage of 100 is equal to the regular syndrome effect severity, higher percentages reduce severity.
|}

{{alphabetical TOC|style=margin: 1em auto;}}

==T==
{| {{prettytable}}
|- bgcolor="#ddd"
! width="20%" | Token
! width="10%" | Type
! width="20%" | Arguments
! width="50%" | Description

|-
| {{text anchor|TENDONS}}
| Caste
|
* [[material token]]
*healing rate
| The creature has tendons in its {{token|CONNECTIVE_TISSUE_ANCHOR|td}} tissues (bone or chitin by default). Cutting the bone/chitin tissue severs the tendons, disabling motor function if the target is a limb.

|-
| {{text anchor|THICKWEB}}
| Caste
|
| The creature's [[web]]s can catch larger creatures.

|-
| {{text anchor|TISSUE}}
| Creature
|
*name
| Begins defining a tissue in the creature file. Follow this with standard tissue definition tokens to define the tissue properties.

|-
| {{text anchor|TISSUE_LAYER}}
| Caste
|
*BY_TYPE, BY_CATEGORY, BY_TOKEN
*TYPE,CATEGORY, or TOKEN
*TISSUE
*LOCATION
| Adds the tissue layer to wherever it is required.
Non-argument Locations can be FRONT, RIGHT, LEFT, TOP, BOTTOM. Argument locations are AROUND and CLEANS, requiring a further body part and a % of coverage/cleansing

|-
| {{text anchor|TISSUE_LAYER_OVER}}
| Caste
|
*BY_TYPE, BY_CATEGORY, BY_TOKEN
*TYPE,CATEGORY, or TOKEN
*TISSUE
*LOCATION
| Alias for TISSUE_LAYER

|-
| {{text anchor|TISSUE_LAYER_UNDER}}
| Caste
|
*BY_TYPE, BY_CATEGORY, BY_TOKEN
*TYPE,CATEGORY, or TOKEN
*TISSUE
| Adds the tissue layer under a given part.
For example, an [[iron man]] has a gaseous poison within, and this tissue (GAS is its name) has the token [TISSUE_LEAKS] and its state is GAS, so when you puncture the iron outside and damage this tissue it leaks gas (can have a syndrome by using a previous one in the creature sample.) [TISSUE_LAYER_UNDER:BY_CATEGORY:ALL:{tissue}] {tissue} is what will be under the TISSUE_LAYER; here is an example Tissue from the Iron Man: 
[TISSUE:GAS] [TISSUE_NAME:gas:NP] [TISSUE_MATERIAL:LOCAL_CREATURE_MAT:GAS] [TISSUE_MAT_STATE:GAS] [RELATIVE_THICKNESS:50] [TISSUE_LEAKS] [TISSUE_SHAPE:LAYER]

|-
| {{text anchor|TITAN}}
| Caste
|
| Found on [[titan]]s. Cannot be specified in user-defined raws.

|-
| {{text anchor|TRADE_CAPACITY}}
| Caste
|
*number
| How much the creature can carry when used by merchants. 1000 by default. Completely ignored if the animal does not also have PACK_ANIMAL or WAGON, instead using BODY_SIZE^(2/3)/20, even if they're a pack animal due to ANIMAL_ALWAYS_PACK_ANIMAL.

|-
| {{text anchor|TRAINABLE}}
| Caste
|
| Shortcut for {{token|TRAINABLE_HUNTING|c}} + {{token|TRAINABLE_WAR|c}}.

|-
| {{text anchor|TRAINABLE_HUNTING}}
| Caste
|
| Can be [[Animal trainer|trained]] as a hunting beast, increasing speed.

|-
| {{text anchor|TRAINABLE_WAR}}
| Caste
|
| Can be [[Animal trainer|trained]] as a war beast, increasing strength and endurance.

|-
| {{text anchor|TRANCES}}
| Caste
|
| Allows the creature to go into [[martial trance]]s. Used by dwarves in the vanilla game.

|-
| {{text anchor|TRAPAVOID}}
| Caste
|
| The creature will never trigger [[trap]]s it steps on. Used by a [[Trapavoid|number of creatures]]. Doesn't make the creature immune to remotely activated traps (like retractable spikes being triggered while the creature is standing over them). TRAPAVOID creatures lose this power if they're immobilized while standing in a trap, be it by stepping on thick web, being paralyzed or being knocked unconscious.

|-
| {{text anchor|TRIGGERABLE_GROUP}}
| Creature
|
*min
*max
| A large swarm of vermin can be disturbed, usually in adventurer mode.

|-
| {{text anchor|TSU_NOUN}}
| Caste
|
*noun
*SINGULAR or PLURAL
| Noun for the {{token|TISSUE_STYLE_UNIT|c}}, used in the description of the tissue layer's style.
|}

{{alphabetical TOC|style=margin: 1em auto;}}

==U==
{| {{prettytable}}
|- bgcolor="#ddd"
! width="20%" | Token
! width="10%" | Type
! width="20%" | Arguments
! width="50%" | Description

|-
| {{text anchor|UBIQUITOUS}}
| Creature
|
| Creature will occur in every region with the correct biome. Does not apply to {{token|EVIL|c}}/{{token|GOOD|c}} tags. Supersedes {{token|FREQUENCY|c}} for the purposes of distributing populations through the map, they are present in every part of the valid biome. Respects {{token|FREQUENCY|c}} for the frequency of unit [[Creature token#CLUSTER_NUMBER|cluster]] spawns being of this species.

|-
| {{text anchor|UNDERGROUND_DEPTH}}
| Creature
|
*mindepth
*maxdepth
| Depth that the creature appears underground. Numbers can be from 0 to 5. 0 is actually 'above ground' and can be used if the creature is to appear both above and below ground. Values from 1-3 are the respective [[cavern]] levels, 4 is the [[magma sea]] and 5 is the [[HFS]]. A single argument may be used instead of min and max. [[Demon]]s use only 5:5; user-defined creatures with both this depth and {{token|FLIER}} will take part in the initial wave from the HFS alongside generated demons, but without {{token|FLIER}} they will only spawn from the map edges. Civilizations that can use underground plants or animals will only export (via the embark screen or caravans) things that are available at depth 1.

|-
| {{text anchor|UNDERSWIM}}
| Caste
|
| The creature is displayed as blue when in [[Water#Depth|7/7 water]]. Used on fish and amphibious creatures which swim under the water.

|-
| {{text anchor|UNIQUE_DEMON}}
| Caste
|
| Found on generated [[demon]]s; causes the game to create a single named instance of the demon, per caste, which will emerge from the underworld and take over civilizations during worldgen.

|-
| {{text anchor|USE_CASTE}}
| Creature
|
*new caste token
*old caste token
| Defines a new caste derived directly from a previous caste. The new caste inherits all properties of the old one. The effect of this tag is automatic if one has not yet defined any castes: "Any caste-level tag that occurs before castes are explicitly declared is saved up and placed on any caste that is declared later, unless the caste is explicitly derived from another caste."
Roostre: "When DF detects duplicate tokens in the raws of the same object, a failsafe seems to kick in; it takes the bottom-most of the duplicates, and disregards the others. In the case of tokens added by a mod, it prioritizes the duplicate in the mod." This means that if a tag is defined in the base-caste and redefined in the derived caste, the derived tag overwrites the base tag.

|-
| {{text anchor|USE_MATERIAL}}
| Creature
|
*new material ID
*old material ID
| Defines a new local creature material and populates it with all properties defined in the specified local creature material. A maximum of 200 materials can be defined on any given creature.

|-
| {{text anchor|USE_MATERIAL_TEMPLATE}}
| Creature
|
*new material token
*material template
| Defines a new local creature material and populates it with all properties defined in the specified template. A maximum of 200 materials can be defined on any given creature.

|-
| {{text anchor|USE_TISSUE}}
| Creature
|
*new tissue token
*old tissue id
| Defines a new local creature tissue and populates it with all properties defined in the local tissue specified in the second argument.

|-
| {{text anchor|USE_TISSUE_TEMPLATE}}
| Creature
|
*new tissue token
*tissue template
| Loads a tissue template listed in OBJECT:TISSUE_TEMPLATE files, such as tissue_template_default.txt.

|-
| {{text anchor|UTTERANCES}}
| Creature
|
| Changes the language of the creature into unintelligible 'kobold-speak', which creatures of other species will be unable to understand. If a civilized creature has this and is not part of a {{token|SKULKING|e}} civ, it will tend to start wars with all nearby civilizations and will be unable to make peace treaties due to 'inability to communicate'.
|}

{{alphabetical TOC|style=margin: 1em auto;}}

==V==
{| {{prettytable}}
|- bgcolor="#ddd"
! width="20%" | Token
! width="10%" | Type
! width="20%" | Arguments
! width="50%" | Description

|-
| {{text anchor|VEGETATION}}
| Caste
|
| Like {{token|AT_PEACE_WITH_WILDLIFE}}, but also makes the creature more valued in artwork by civilisations with the PLANT [[sphere]]. [http://www.bay12forums.com/smf/index.php?topic=169696.msg8316954#msg8316954] Used by [[grimeling]]s in the vanilla game.

|-
| {{text anchor|VERMIN_BITE}}
| Caste
|
*chance of occurrence{{verify}}
*verb (bitten, stung, etc.)
* [[material token]]
* [[Material_definition_token#Material_States|material state]]
| Enables vermin to bite other creatures, injecting the specified material. See {{token|SPECIALATTACK_INJECT_EXTRACT|c}} for details about injection - this token presumably works in a similar manner.{{verify}}

|-
| {{text anchor|VERMIN_EATER}}
| Creature
|
| The vermin creature will attempt to eat exposed food. See {{token|PENETRATEPOWER|c}}. Distinct from {{token|VERMIN_ROTTER|c}}.

|-
| {{text anchor|VERMIN_FISH}}
| Creature
|
| The vermin appears in [[water]] and will attempt to swim around. Required to catch the vermin with [[fishing]] or [[Fishery|capturing a live fish]].

|-
| {{text anchor|VERMIN_GROUNDER}}
| Creature
|
| The creature appears in "general" surface ground locations. Note that this doesn't stop the creature from flying if it can (most vermin birds have this tag).

|-
| {{text anchor|VERMIN_HATEABLE}}
| Caste
|
| Some dwarves will [[Preferences|hate]] the creature and get unhappy thoughts when around it. See the [[Hateable|list of hateable vermin]] for details.

|-
| {{text anchor|VERMIN_MICRO}}
| Caste
|
| This makes the creature move in a swarm of creatures of the same race as it (e.g. swarm of flies, swarm of ants).

|-
| {{text anchor|VERMIN_NOFISH}}
| Caste
|
| The creature cannot be caught by [[fishing]].

|-
| {{text anchor|VERMIN_NOROAM}}
| Caste
|
| The creature will not be observed randomly roaming about the map.

|-
| {{text anchor|VERMIN_NOTRAP}}
| Caste
|
| The creature cannot be caught in baited [[animal trap]]s; however, a "[[Trapper|catch live land animal]]" task may still be able to capture one if a dwarf finds one roaming around.

|-
| {{text anchor|VERMIN_ROTTER}}
| Creature
|
| The vermin are attracted to rotting stuff and loose food left in the open and cause unhappy thoughts to dwarves who encounter them. Present on flies, knuckle worms, acorn flies, and blood gnats.

|-
| {{text anchor|VERMIN_SOIL}}
| Creature
|
| The creature randomly appears near dirt or mud, and may be uncovered by creatures that have the {{token|ROOT_AROUND|c}} interaction such as [[goose|geese]] and [[chicken]]s. Dwarves will ignore the creature when given the "Capture live land animal" task.

|-
| {{text anchor|VERMIN_SOIL_COLONY}}
| Creature
|
| The vermin will appear in a single tile cluster of many vermin, such as a colony of ants.

|-
| {{text anchor|VERMINHUNTER}}
| Caste
|
| Old shorthand for "does cat stuff". Contains {{token|AT_PEACE_WITH_WILDLIFE|c}} + {{token|RETURNS_VERMIN_KILLS_TO_OWNER|c}} + {{token|HUNTS_VERMIN|c}} + {{token|ADOPTS_OWNER|c}}.

|-
| {{text anchor|VESPERTINE}}
| Caste
|
| When set, the creature will only appear in the evening (between 8:00 PM and 10:05 PM) in [[Adventurer mode]].

|-
| {{text anchor|VIEWRANGE}}
| Caste
|
*value
| Value should determine how close you have to get to a critter before it attacks (or prevents adv mode travel etc.) Default is 20.

|-
| {{text anchor|VISION_ARC}}
| Caste
|
*binocular vision arc
*non-binocular vision arc
| The width of the creature's vision arcs, in degrees (i.e. 0 to 360). The first number is binocular vision, the second is non-binocular vision. Binocular vision has a minimum of about 10 degrees, monocular, a maximum of about 350 degrees. Values past these limits will be accepted, but will default to ~10 degrees and ~350 degrees respectively. Defaults are 60:120.
|}

{{alphabetical TOC|style=margin: 1em auto;}}

==W==
{| {{prettytable}}
|- bgcolor="#ddd"
! width="20%" | Token
! width="10%" | Type
! width="20%" | Arguments
! width="50%" | Description

|-
| {{text anchor|WAGON_PULLER}}
| Caste
|
| Allows the creature to pull caravan wagons. If a civilization doesn't have access to any, it is restricted to trading with pack animals.

|-
| {{text anchor|WEBBER}}
| Caste
|
* [[material token]]
| Allows the creature to create [[web]]s, and defines what the webs are made of.

|-
| {{text anchor|WEBIMMUNE}}
| Caste
|
| The creature will not get caught in thick [[web]]s. Used by creatures who can shoot thick webs (such as [[giant cave spider]]s) in order to make them immune to their own attacks.
|}

==Attack Tokens==

Attacks can use four different part selection criteria. Except for TISSUE_LAYER, the base game makes use of all of these in its attacks.

{| {{prettytable}}
|- bgcolor="#ddd"
! width="20%" | Part type token
! width="30%" | Arguments
! width="60%" | Description

|-
| {{text anchor|BODYPART}}
|
* BY_TYPE/BY_TOKEN/BY_CATEGORY
* type/token/category
| This attack uses a particular body part; for example, ATTACK:PUNCH:BODYPART:BY_TYPE:GRASP will make it use any part that can hold onto an object.

|-
| {{text anchor|TISSUE_LAYER}}
|
* BY_TYPE/BY_TOKEN/BY_CATEGORY
* type/token/category
* tissue layer
| This attack uses a specific tissue layer on a specific body part; ATTACK:SCRATCH:TISSUE_LAYER:BY_TYPE:GRASP:BONE will make it use the bone of the hands.

|-
| {{text anchor|CHILD_BODYPART_GROUP}}
|
* BY_TYPE/BY_TOKEN/BY_CATEGORY
* type/token/category
* BY_TYPE/BY_TOKEN/BY_CATEGORY
* type/token/category
| Uses a body part that is subordinate to another; ATTACK:SLAP:CHILD_BODYPART_GROUP:BY_CATEGORY:ARM_LOWER:BY_TYPE:GRASP will make it use every hand attached to each lower arm (so it will generate one attack per lower arm, each of which will use every hand on that arm, assuming there are multiple hands per arm).

|-
| {{text anchor|CHILD_TISSUE_LAYER_GROUP}}
|
* BY_TYPE/BY_TOKEN/BY_CATEGORY
* type/token/category
* BY_TYPE/BY_TOKEN/BY_CATEGORY
* type/token/category
* tissue layer
| As CHILD_BODYPART_GROUP, but specifying a tissue, too; ATTACK:BITE:CHILD_BODYPART_GROUP:BY_CATEGORY:HEAD:BY_CATEGORY:TOOTH

|}

{| {{prettytable}}
|- bgcolor="#ddd"
! width="20%" | Token
! width="10%" | Type
! width="20%" | Arguments
! width="50%" | Description

|-
| {{text anchor|ATTACK_SKILL}}
| Caste
|
*[[Skill token]]
| Defines the skill used by the attack.

|-
| {{text anchor|ATTACK_VERB}}
| Caste
|
*2nd person
*3rd person
| Descriptive text for the attack.

|-
| {{text anchor|ATTACK_CONTACT_PERC}}
| Caste
|
*% value
| The contact area of the attack, measured in % of the body part's volume. Note that all attack percentages can be more than 100%.

|-
| {{text anchor|ATTACK_PENETRATION_PERC}}
| Caste
|
*% value
| The penetration value of the attack, measured in % of the body part's volume. Requires ATTACK_FLAG_EDGE. Maximum value: 15000.

|-
| {{text anchor|ATTACK_PRIORITY}}
| Caste
|
*MAIN or SECOND
| Usage frequency. MAIN attacks are 100 times more frequently chosen than SECOND. Opportunity attacks ignore this preference.

|-
| {{text anchor|ATTACK_VELOCITY_MODIFIER}}
| Caste
|
*number
| The velocity multiplier of the attack, multiplied by 1000.

|-
| {{text anchor|ATTACK_FLAG_CANLATCH}}
| Caste
|
| Attacks that damage tissue have the chance to latch on in a wrestling hold. The grabbing bodypart can then use the "shake around" wrestling move, causing severe, armor-bypassing tensile damage according to the attacker's body volume.

|-
| {{text anchor|ATTACK_FLAG_WITH}}
| Caste
|
| Displays the name of the body part used to perform an attack while announcing it, e.g. "The weaver punches the bugbat with his right hand".

|-
| {{text anchor|ATTACK_FLAG_EDGE}}
| Caste
|
| The attack is edged, with all the effects on physical resistance and contact area that it entails.

|-
| {{text anchor|ATTACK_PREPARE_AND_RECOVER}}
| Caste
|
* Preparation time
* Recovery time
| Determines the length of time to prepare this attack and until one can perform this attack again. Values appear to be calculated in adventure mode ticks.

|-
| {{text anchor|ATTACK_FLAG_BAD_MULTIATTACK}}
| Caste
|
| Multiple strikes with this attack cannot be performed effectively.

|-
| {{text anchor|ATTACK_FLAG_INDEPENDENT_MULTIATTACK}}
| Caste
|
| Multiple strikes with this attack can be performed with no penalty. The creature will use all attacks with this token at once.

|-
| {{text anchor|SPECIALATTACK_INJECT_EXTRACT}}
| Caste
|
*<[[material token]]>
*<[[Material_definition_token#Material_States|material state]]>
*<min quantity>
*<max quantity>
| When added to an attack, causes the attack to inject the specified material into the victim's bloodstream. Once injected, the material will participate in [[temperature|thermal]] exchange within the creature - injecting something like molten [[iron]] (INORGANIC:IRON:LIQUID) would cause most unmodded creatures to melt (note that some of the injected material also [[contaminant|splatters]] over the bodypart used to carry out the attack, so it should be protected appropriately). If the injected material has an associated [[syndrome]] with the [[Syndrome#SYN_INJECTED|[SYN_INJECTED]]] token, it will be transmitted to the victim. If the attack is blunt, the injected material lacks the [[Material definition token#ENTERS_BLOOD|[ENTERS_BLOOD]]] token, the attacked bodypart has no [[Tissue_definition_token#VASCULAR|[VASCULAR]]] tissues, or the victim is bloodless, the material will splatter over the attacked body part instead.

|-
| {{text anchor|SPECIALATTACK_INTERACTION}}
| Caste
|
*interaction
| When this attack lands successfully, a specified interaction will take effect on the target creature. The attack must break the target creature's skin in order to work. This will take effect in worldgen as well. If the attack would break skin, the interaction will occur '''before the attack actually lands'''.

|-
| {{text anchor|SPECIALATTACK_SUCK_BLOOD}}
| Caste
|
*min
*max
| Successful attack draws out an amount of blood randomized between the min and max value. Beware that this '''will''' trigger any ingestion syndromes attached to the target creature's blood - for example, using this attack on a vampire will turn you into one too.
|}

==Tissue Layer Tokens==
Tissue layers are added to a creature's body parts by the creature tokens [[#TISSUE_LAYER|TISSUE_LAYER]], [[#TISSUE_LAYER_OVER|TISSUE_LAYER_OVER]], [[#TISSUE_LAYER_UNDER|TISSUE_LAYER_UNDER]], and the body detail plan token [[#TL_LAYERS|TL_LAYERS]].

These tissue layers are not the same thing as tissues, which are defined at creature level, but rather applications of the tissues. If the SKIN tissue of a creature is the more general and abstract notion of what skin is for that creature, then a tissue layer may be the "actual" skin on the creature's nose, head, or second toe. As most creatures have more than one body part, tissue layers are normally selected en masse.

Some tissue layer tokens are analogous to tissue definition tokens, e.g. [[#TL_CONNECTS|TL_CONNECTS]] to [[tissue_definition_token#CONNECTS|CONNECTS]].

{| {{prettytable}}
|- bgcolor="#ddd"
! width="20%" | Token
! width="10%" | Type
! width="20%" | Arguments
! width="50%" | Description

|-
| {{text anchor|SELECT_TISSUE_LAYER}}
| Caste
|
*TISSUE
*BY_CATEGORY, BY_TYPE, BY_TOKEN
*Location - category, type, or token | Selects a tissue at a location
* (optional) FRONT, BACK, LEFT, RIGHT, TOP, BOTTOM, AROUND.
| Begins a selection of tissue layers.
[SELECT_TISSUE_LAYER:HEART:BY_TYPE:HEART]

|-
| {{text anchor|PLUS_TISSUE_LAYER}}
| Caste
|
*TISSUE
*BY_CATEGORY, BY_TYPE, BY_TOKEN
*Location - category, type, or token
| Adds tissue layers to those selected.

|-
| {{text anchor|SET_TL_GROUP}}
| Caste
|
*TISSUE
*BY_CATEGORY, BY_TYPE, BY_TOKEN
*Location - category, type, or token
*tissue
| Begins a selection of tissue layers. Only usable for descriptor and cosmetic purposes.

Research has implied it may be redundant with SELECT_TISSUE_LAYER, as the latter allows for cosmetics as well as "functional" tokens such as TL_MAJOR_ARTERIES. Vanilla raws still use SET_TL_GROUP though, for all cosmetic purposes. More research is needed on this subject.

|-
| {{text anchor|PLUS_TL_GROUP}}
| Caste
|
*BY_CATEGORY, BY_TYPE, BY_TOKEN
*Location - category, type, or token
*tissue
| Adds tissue layers to those selected. Like SET_TL_GROUP, it may be redundant even if used in the vanilla raws.

|-
| {{text anchor|SET_LAYER_TISSUE}}
| Caste
|
*TISSUE
| Sets a selected tissue layer to be made of a different tissue.

|-
| {{text anchor|SHEARABLE_TISSUE_LAYER}}
| Caste
|
* tissue modifier
* required value
| Tissue layer can be sheared for its component material. The specified modifier must be at least of the desired value for shearing to be possible (for example, a [[llama]]'s wool must have a LENGTH of 300 before it is shearable).

|-
| {{text anchor|TISSUE_LAYER_APPEARANCE_MODIFIER}}
| Caste
|
*QUALITY
*lowest
*lower
*low
*median
*high
*higher
*highest
| Sets the range of qualities, including LENGTH, DENSE, HIGH_POSITION, CURLY, GREASY, WRINKLY

|-
| {{text anchor|TISSUE_STYLE_UNIT}}
| Caste
|
*tissue style unit ID
*shaping
| Sets tissue layer to be the target of TISSUE_STYLE token specified for an entity, works only on entity members. Mostly used with tissues HAIR, BEARD, MOUSTACHE, SIDEBURNS.

|-
| {{text anchor|TL_COLOR_MODIFIER}}
| Caste
|
*COLOR
*freq
*COLOR
*freq etc.
| Creates a list of colors/color patterns, giving each a relative frequency. If the given color or pattern does not exist, the tissue is described as being "transparent".

|-
| {{text anchor|TLCM_GENETIC_MODEL}}
| Caste
|
| The way the color modifier is passed on to offspring. May or may not work right now.{{verify}}

|-
| {{text anchor|TLCM_IMPORTANCE}}
| Caste
|
*number
| Presumably modifies the importance of the tissue layer color modifier, for description purposes.
HOWEVER using this appears to remove all mention of colour from creature descriptions. It does not appear in any default creatures.

|-
| {{text anchor|TLCM_NOUN}}
| Caste
|
*name
*SINGULAR or PLURAL
| Names the tissue layer color modifier, and determines the noun. Also used by [[Utility:Stonesense|Stonesense]] for colouring body parts.

|-
| {{text anchor|TLCM_TIMING}}
| Caste
|
*ROOT
*start change window years
*days
*end change window years
*days
| Determines the point in the creature's life when the color change begins and ends.

|-
| {{text anchor|TL_CONNECTS}}
| Caste
|
| Gives the CONNECTS attribute to selected layers.

|-
| {{text anchor|TL_HEALING_RATE}}
| Caste
|
*value
| Changes the HEALING_RATE of the selected tissue layers.

|-
| {{text anchor|TL_MAJOR_ARTERIES}}
| Caste
|
| Gives the "major arteries" attribute to selected layers. Used to add massive bleeding properties to the throat, made from skin.

|-
| {{text anchor|TL_PAIN_RECEPTORS}}
| Caste
|
*value
| Changes the number of pain receptors for selected tissue layers.

|-
| {{text anchor|TL_RELATIVE_THICKNESS}}
| Caste
|
*value
| Changes the relative thickness for selected tissue layers.

|-
| {{text anchor|TL_VASCULAR}}
| Caste
|
*value
| Sets a new VASCULAR value (which modulates bleeding) for selected tissue layers.

|}

==See Also==
*[[Body detail plan token]]
*[[Body token]]
*[[Material definition token]]
*[[Syndrome]]
*[[Tissue definition token]]
*[[Creature examples]]

{{Category|Modding}}
{{Category|Tokens}}
[[ru:Creature token]]

Axe

2026-09-27T22:28:15Z

Silverwing235:

{{av}}

'''Axe''' may refer to:
* [[Battle axe]]
* [[Great axe]]
* [[Training weapon|Training axe]], a type of training weapon
* Stone axe, a [[Adventurer_mode_gameplay#Crafting|craftable]] [[tool]] in [[adventure mode]]

Axes are [[weapon]]s. Every axe (except the training axe) can be used as [[equipment]] for tree cutting.

{{Translation
| dwarven = libash
| elvish = cuthefi
| goblin = agun
| human = osp
}}

{{disambig}}
[[ru:Axe]]

Advanced entity position mechanics

2026-09-27T18:28:46Z

Silverwing235: /* Units holding multiple positions in multiple entities */ small clarification

{{Quality|Fine}}
{{Modding}}

= Introduction =

[http://www.bay12forums.com/smf/index.php?topic=182239.0 Discussion thread on the forum]

This page documents observed and tested behavior of entity positions in ''Dwarf Fortress'', that is not fully described elsewhere on the wiki; focusing on advanced interactions between position tokens, including appointment, succession, election, and responsibility handling, across both civilization-level and site-level entities.

The mechanics described here are based on empirical testing in world generation and fortress mode, supplemented where necessary by raw analysis. In several cases, the game’s behavior is determined by evaluation order and interaction between multiple tags, rather than by individual tokens in isolation.

This page is intended for modders and advanced players who are designing or debugging custom entity position structures. It does not restate basic position mechanics, but instead highlights edge cases, non-obvious interactions, and behaviors that may appear inconsistent or undocumented.

Unless stated otherwise, the described behavior applies to current versions of the game and may differ from older releases.

==What is an entity? What is a position?==
An [[entity]] is an organizational structure that can have relationships with other entities, usually known as a [[civilization]] or a "[[site]] government" in the game, but e.g. [[merchant company|merchant companies]], [[Mercenary#Mercenary_Orders|mercenary orders]], [[guild|guilds]], [[religion|religious organizations]], bandits and necromancer towers are also entities (and necromancer towers use the same entity type as "site governments"). An entity can have positions - in most cases, these are hardcoded and generated by the game, but as for civilizations and sites, the [[raw file]]s can be customised.

A position is a special relationship between a unit and an entity. The unit holding a position has a larger influence over that entity than other citizens. Positions are mostly known as [[nobles]], but in this article. the technical term is used.

=Position levels (Site/Civ) and their interaction=
There are two basic types of positions that are customizable: '''civ(ilization)''' level and '''site level'''. Positions with the tag [SITE] are at site level, positions without the tag [SITE] are at 'civ level'. These two types of nobles can be considered '''loosely related systems'''. There are a few places where they can interact with each other.

Civ-level positions are in charge of the civilization as a whole, managing national [[trade]], laws, and [[war]]s. These are, for example, the vanilla [[monarch]], [[diplomat]] and [[general]]. (Note that the general doesn't really do anything, except creation of additional pets in world-gen for the general and possibly raising the animal training knowledge of the civilization to "general familiarity".)

'''[LAND_HOLDER]''' nobles are also positions at civ-level. These units are members of the national government, but have gained authority over some land or site. Once they do, they move to that place, but their position is still regarded as a civ-level position.

Site-level position holders are members of a site government (subsidiary to the civilization), and manage local affairs in that location. These are, for example, the [[mayor]], the [[sheriff]] and the [[broker]].

==Table of interaction between different position levels==
In this table, the possible interactions between different position levels are summarized.
The header row shows the positions defining the tokens.

The left column shows the position type that is referred to.
Example:
{| {{prettytable}}
|- bgcolor="#ddd"
! referred position-type
! LAND_HOLDER
|-
| civilization
| (baron is) APPOINTED_BY:MONARCH
|}
color coding: 
* Exists in vanilla
* Possible with mods
* Not possible
* possible to some extent.
* not yet fully investigated.
{| {{prettytable}}
|- bgcolor="#ddd"
! referred position-type
! Civilization
! SITE
! LAND_HOLDER
! CONQUERED_SITE

|-
| Civilization
| APPOINTED_BY COMMANDER REPLACED_BY SUCCESSION
| APPOINTED_BY COMMANDER REPLACED_BY SUCCESSION '''(1)'''
| APPOINTED_BY COMMANDER REPLACED_BY SUCCESSION
| APPOINTED_BY COMMANDER REPLACED_BY SUCCESSION

|-
| SITE
| APPOINTED_BY COMMANDER REPLACED_BY SUCCESSION '''(2)'''
| APPOINTED_BY COMMANDER REPLACED_BY SUCCESSION
| APPOINTED_BY '''(3)''' COMMANDER REPLACED_BY SUCCESSION '''(4)'''
| APPOINTED_BY COMMANDER REPLACED_BY SUCCESSION

|-
| LAND_HOLDER
| APPOINTED_BY COMMANDER REPLACED_BY '''(6)''' SUCCESSION
| APPOINTED_BY COMMANDER REPLACED_BY SUCCESSION '''(5)'''
| APPOINTED_BY COMMANDER REPLACED_BY '''(7)''' SUCCESSION '''(8)'''
| APPOINTED_BY COMMANDER REPLACED_BY SUCCESSION

|-
| CONQUERED_SITE
| APPOINTED_BY COMMANDER REPLACED_BY SUCCESSION
| APPOINTED_BY COMMANDER REPLACED_BY SUCCESSION
| APPOINTED_BY COMMANDER REPLACED_BY SUCCESSION
| APPOINTED_BY COMMANDER REPLACED_BY SUCCESSION
|}

Remarks:
# Works only in world-gen, if a unit with that civ-position is present at the site.
# Works only in world-gen, the site-position holding unit will then move to the capital.
# Is completely ignored
# Works only in world-gen.
# Works only in world-gen.
# Won't appear at all
# This is necessary for the landholder chain to work properly, it doesn’t work otherwise.
# This works only outside of the landholder chain, so when landholders are simply regarded as civ-level nobles. might also work in world-gen
#

== Other interactions ==

Unfortunately, interactions with positions of other entities don't seem possible, such as APPOINTED_BY: HIGH_PRIEST. With [VARIABLE_POSITIONS], positions are automatically created with codes like CUSTOM_LAW_MAKER_2, but interaction with these positions don't seem to work, either. For more info on those, see [[Variable positions]]

=General=

==Civ-level nobles living at your site==
Nobles from your civilization can come to live at your fortress. This happens in vanilla with landholders such as [[Baron]], [[Count]] and [[Duke]], with the Monarch, but sometimes also with non-landed LAND_HOLDERS.

When a civ-level noble becomes a [[citizen]] at your location, their position is shown among the site-level positions in your [[nobles screen]]. They appear to function as a site-level noble. They may have [[demand]]s, [[mandate]]s, [[squad]]s and the like. They can appoint nobles at the site-level.

Even if they have certain site related [RESPONSIBILITY]ies, they will not do the tasks that go with them.

==Fortress mode, worldgen and their differences==
Their are a few differences in how positions function between fortress mode (normal play mode) and the world generation (world-gen).

In '''fortress mode''', the player has some control over the appointment of nobles, limited by elections, automatic filled-in positions and succession rules. Pre-fortress mode, which is referred to as '''worldgen''', the game will always attempt to assign nobles whenever possible. It is subjected to the same rules as in fortress mode, but there are some exceptions. In '''[[World activities]]''', which is the thing that happens in the world while you play fortress mode, it seems as if the same rules are applied as fortress mode.

A difference between player-fortress-mode and worldgen, is caused by visibility (see below). Positions that are not visible by the player and thus not available for assignment, will be available in world-gen and will thus be automatically assigned.

In fortress mode, a position that is both [ELECTED] and [APPOINTED_BY], cannot be appointed by the player and is also not elected, and can thus not be filled. But in world-gen sites however, these positions are automatically filled.

Positions with [AS_NEEDED] are almost never created and filled in world-gen (depending on their [RESPONSIBILITY]ies), but can always be used in player mode.

A position can, in fortress mode, be filled by the same unit. A unit can gain multiple positions in fortress mode, for example because of [[elections]]. This will not happen in world-gen mode: a unit can only have one position. See also remarks on 'embark' and 'Losing a position'.

In worldgen, [SUCCESSION] between civ-levels and [SITE-]levels may happen. This will not happen in fortress mode, or even off-site in [[World activities]].

In fortress mode, premature SUCCESSION may happen. This will not happen in worldgen mode.

==Units holding multiple positions in multiple entities==
A unit can hold multiple positions in its civilisation or in its site-entity, however in world-gen a unit will not hold multiple positions in one site-entity or in one civilisation (note that in world-gen a unit can hold multiple variable positions of the same entity, if the entity is ie. an outcast group). It is however possible - in world-gen - for a unit to hold multiple positions as long as the positions belong to different civilizations / site-entities (ie. it is possible for a militia commander of a site-entity to later on also become a monarch of the parent civilization, while staying a militia commander), if a unit holds a position of two different site-entities (the unit will usually have left one of the groups, without relinquishing the position). Only at player-managed sites can units be holding multiple positions (of the site-entity) at once. It is currently unknown, whether it is possible in world-gen for a unit to have a civ-level position in two different civilisations (but it probably is possible, as a a unit can belong to multiple civilizations and a unit usually does not relinquish a position, when the unit gets another position, as long as the entities of both positions are not the same).

In world-gen, if there are too many positions to be filled, they simply stay empty until more units are available. E.G, a unit at a site might inherit a civ-level position and still remain a member of the local government. When this happens however, they move to the capital. If a unit gains a new position, either inherited or otherwise, it drops the previous one (of that civilisation or site-entity) - the unit will not drop any positions unrelated to the entity of the new position (ie. a CUSTOM_OUTCAST_FACTOR will not relinquish that position, if the unit becomes the ruler of a civilization and a militia commander will also not necessarily relinquish the position, if the unit becomes also the monarch of the corresponding civilization). If a unit assumes a civ-position in fortress mode, it leaves the current position.

If a unit holds the same site-position multiple times, it has no additional effect.

If a unit holds multiple different positions of the same entity, it has all those positions' responsibilities and properties, stacked up. Presumably, the demands for those combined positions are determined by the highest-ranking position in the stack.

A unit holding a position with a succession token can be assigned another position with a (different) succession token.

A unit holding a position with a squad position cannot hold another squad position - it is dropped from the first of those when the second position is assigned.
A unit holding a position with a succession token cannot be assigned to a squad position - the unit is simply not available. It works the other way around, though.

=Specific Tags and functions=
==[PRECEDENCE]==
The first defined position with precedence of 1 counts as the ruler of the civ. See also: [[Position_token#PRECEDENCE|PRECEDENCE]].

If the precedence is omitted or has a negative value, the game sets 0 as precedence, which seems to have no effect whatsoever. When a unit has multiple positions, the name of the position with the highest rank in precedence is shown behind the unit's name.

If you omit precedence entirely, or set it to [PRECEDENCE:NONE], the position name will not be shown after the unit’s name. Your *Urist Mason* will remain simply *Mason*. This can be useful for positions that are unimportant or purely functional. The position will also not appear in the civilisation overview of your site on the world map. The position name is shown in messages, but remains hidden on the nobles screen as well. To make it visible there, use [LAND_NAME].

==[RESPONSIBILITY]ies==
Both civ and [SITE] positions can carry responsibilities. However, not all responsibilities are active for both types: some function only for civ positions, others only for site positions. When a civ noble arrives at a site and takes up residence, they do not perform responsibilities that are intended for SITE nobles. As a result, these responsibilities neither trigger their associated tasks nor unlock related game mechanics. For example, a civ-level manager living in a fortress will not perform management duties there and doesn't unlock the management-screen, even with an assigned office.
This behavior applies to the following [SITE]-level responsibilities:
* [RESPONSIBILITY:ACCOUNTING]
* [RESPONSIBILITY:BUILD_MORALE]
* [RESPONSIBILITY:HEALTH_MANAGEMENT]
* [RESPONSIBILITY:LAW_ENFORCEMENT]
* [RESPONSIBILITY:MANAGE_PRODUCTION]
* [RESPONSIBILITY:MEET_WORKERS]
* [RESPONSIBILITY:TRADE] (functions differently)
Other responsibilities may be affected as well, but have not yet been fully tested.

===World-gen effects of the [RESPONSIBILITY] of available positions ===
It is possible to cause civs and individual sites to change their behavior substantially when they reach a certain size, by controlling nobles.
* If a site can only appoint a position with [MILITARY_GOALS] after reaching a particular size, that site will not send armies on missions until the required size is reached.
* A civ-level [LAW_MAKING] position is required for the civilization to have any kind of cohesion. Without it, sites will be constantly embroiled in territorial disputes and civil wars will be commonplace.
* [MILITARY_STRATEGY] positions go out and tame wild animals. This makes your civ gain those animals as domesticated and also brings them in sieges.
* The [[Personality_facet|Personality]] of the position's holder determines how they lead the civ.

===[DELIVERS_MESSAGES]===
The only [AS_NEEDED]-position that is created in worldgen based on responsibility is that of the site-level responsibility [DELIVERS_MESSAGES].

===Outpost Liaisons and Diplomats===
Civ-positions with the responsibility [ESTABLISH_COLONY_TRADE_AGREEMENTS] ([[Outpost_Liaison|Outpost Liaison]]s) will meet with the site-noble who has responsibility for [RECEIVE_DIPLOMATS] and the highest rank of precedence (i.e. the lowest precedence value). Usually this is the [[Expedition_leader|Expedition leader]].

Once a [LAND_HOLDER] is assigned to the site, civ-positions with the responsibility [MAKE_TOPIC_AGREEMENTS] ([[Diplomat]]s) will meet with '''civ'''-level nobles present at the site who have the [RECEIVE_DIPLOMATS] responsibility. If multiple eligible nobles are available, one is selected at random. If no eligible noble is present, the diplomat leaves angrily. If the landholder is no longer present at the site, diplomats will not arrive at all.

It appears that Outpost Liaisons and Diplomats are chosen for a diplomatic mission based on availability. When multiple candidates exist, the position defined last in the raws is most often selected.

===[TRADE]===
Civ-level nobles with [TRADE] will arrive with the caravan, just as the Outpost Liaison. Their behavior is no longer active in the vanilla game, but the mechanics are still present. See [[40d:Guild_representative|Guild representative]] for more details. This civ-noble will only meet with the SITE noble with [TRADE], usually the [[Broker]].

If two civ-nobles exist with both [TRADE] and [ESTABLISH_COLONY_TRADE_AGREEMENTS], they both arrive at the same time. Even if both tokens are assigned to a single position, if more than one instance of that position exists, two of them will arrive. However in that case, somehow the elevation of the site and appointment of landholder isn't offered.

If the SITE-noble they intend to meet has both [TRADE] and [RECEIVE_DIPLOMATS], only one meeting will proceed and the other is cancelled. However, when two SITE-nobles are available, each with either [TRADE] or [RECEIVE_DIPLOMATS], both meetings will proceed and both civ-nobles will attempt to negotiate a trade agreement. It is not known what happens if these agreements are accepted or refused.

In the trade depot, the last defined position with the [TRADE] responsibility is shown as broker. However when requesting a trader, the first defined position with [TRADE] will actually go there to do the trade.

==[NUMBER]==
A position might be defined with a number. In that case, as many as defined can be available. If the positions become available in world-gen and when embarking, they are all filled in completely.

If the ruling position (with PRECEDENCE of 1) has a NUMBER higher than 1, a random unit of the ones holding these positions is shown as ruler in the embark screen.

A [NUMBER] of 0 (zero) has the same effect as 1.

===Automatic spreading of assumed, non-singular positions===
If there are civ positions that have a NUMBER higher then '1' and which are assumed (not APPOINTED_BY or ELECTED) but are '''not DUTY_BOUND''', these are automatically spread among the civilisation, based on population. If there are a number of '''20''' available slots of that position, they spread among a civilization with a combined population of, for example, 1000 of which your fortress has 100 (10%), '''2''' of your fortress' citizens will assume that position.
This may probably also work with elected and appointed positions, but that may be depending on the death of the current holders and this needs more testing. Assumption works within a day, anyway.

===[AS_NEEDED]===
These positions can be created automatically by the game in worldgen. This, however, only works with:
* [LAND_HOLDER]'s
* squad commanders (needs more testing)
* Messengers at sites

For all other types of positions, they're not created in worldgen; even if defined with RESPONSIBILITY's. For example, even in war, the game wouldn't create a MILITARY_GOALS position if they have AS_NEEDED as a number. However, in fortress mode / player mode, these positions can be created by the player at will.

Positions with AS_NEEDED need to be created first, before any symbols are assignable as 'symbols' (objects) for the position holder to carry or wear, but they cannot be created and then ELECTED in fortress mode - that only works with APPOINTED_BY.

==[REPLACED_BY], [REQUIRES_POPULATION], [REQUIRES_MARKET]==

The token [REPLACED_BY:position] means that once the replacing position meets its requirements for activation, the 'to-be-replaced' position will disappear. This is defined in [REQUIRES_POPULATION] or [REQUIRES_MARKET]. The tags are closely related to each other and seem to only have a meaningful function if combined. Nobles with [REQUIRES_POPULATION] require the population to have a specific size. Nobles with [REQUIRES_MARKET] are only activated in market sites, such as fortresses or towns. [REQUIRES_POPULATION] and [REQUIRES_MARKET] can be combined, activating that position once both requirements are met.

The [REQUIRES_MARKET] can be used to differentiate positions between hamlets and hillocks, and larger sites. IThe market always is build the year after the site is founded. So a position that is to be replaced, will be gone immediately.

The [REQUIRES_POPULATION]-tag works on the civ-level as well as on site-level, but those systems are in this mechanic strictly separated. Site-level positions cannot be replaced by civ-level positions and visa versa. This makes sense, because they both depend on their own population-count. When using REQUIRES_POPULATION on civ-level, it counts the total population of the civilisation.

See also: [[Advanced_entity_position_mechanics#Evaluation_of_Positions|Evaluation of positions]]

===Effect of replacement (and on [LAND_HOLDER]s)===

Replacement is immediate and complete - the current holding unit loses the position, even before SUCCESSION_BY_POSITION rules are applied. A position with a number of 1 will replace all the slots of a position with a higher number of slots.

Even if the next position is available but not visible, replacement still takes place. If a position is replaced, it is completely gone - it cannot be appointed, succeeded, elected or assumed any longer.
The unit immediately loses its position.

In legends, replacement is mentioned as: "(unit name) ceased to be (position name)" The replacement of an AS_NEEDED position empties the position's slot forever. In fortress mode, it may seem as if you can create new slots and appoint new units in the nobles screen, but this is reversed as soon as you close the window.

The landholder chain uses [REPLACED_BY] differently. It does not clear the position completely, but uses it for succession to the next level's position. [REPLACE_BY] is required to let that system work properly. This also means that the way in which landholders succeed (replace + as_needed) does not work in any other way.

Replacement between LAND_HOLDERS and other site- or civ positions does not work in any way. Only the vanilla replacement sequence between levels of LAND_HOLDERs does work. If the token is omitted for landholders, the landholder chain is broken, so replacement is required for the landholder system to work.

[REQUIRES_POPULATION] also does not work for [LAND_HOLDER], when you set [NUMBER] to 1. The position is not created when the required population is reached.

===What doesn't work===

'''Attention: If a position cannot be appointed, for example because of 'mutual appointment', it still exists according to replacement mechanics and will replace other positions if so defined. If a certain position(a) will be replaced by the baron's assistant, which can only be appointed by the [LAND_HOLDER] baron, than that position(s) still will be replaced from the start of the game, even if no baron or their assistant is ever present.'''

A position that is replaced by a somehow non-fillable position is still replaced. This counts for mutual-appointing positions, replacement by not-yet-assigned landholders, replacement by AS_NEEDED positions, or replacement by not-yet-appointed positions.

Replacement does not work if the replaced position is a [LAND_HOLDER], even with civ-positions. In that case, the LAND_HOLDER's position is not replaced. It does not matter if AS_NEEDED is used, or a fixed number, and it also does not matter what type of position the replacer is. So this only works (correctly) with positions that become available by REQUIRES_POPULATION.

==[CONQUERED_SITE]==

This tag determines which position is used to assign a [[Forced administrator]].

In legends mode, this is visible as an event describing the reconquest of the site: a new group is formed and the forced administrator is installed as its ruler.

All positions defined with this tag are assigned during this process, meaning multiple positions can be appointed at once.

The holder of a position marked with [CONQUERED_SITE] cannot appoint any other [SITE] positions, unless the civilization has site variable positions, in which case the forced administrator can appoint such site variable positions (allthough the variable positions for that site need to be created first and such creation only happens during world-gen, but not normal world activities).

Combining [CONQUERED_SITE] with [SITE] causes the position to function both as a forced administrator and as a normal site position available in fortress mode. However, this provides no meaningful additional mechanics and is effectively inferior to using [SITE] alone:
* [APPOINTED_BY] lines are completely ignored, meaning that the roles are automatically assumed.
* [SUCCESSION] is likewise ignored.
* the [CONQUERED_SITE]-position cannot appoint other [CONQUERED_SITE], [SITE] or combined positions.

There have been remarks that reclaiming a fortress is unplayable because of the lack of regular nobles. Unfortunately, it seems that it can't be fixed by modding.

=Availability and visibility=
==Availability of (new) positions==
Warning: Do not mistake "availability" for "visibility"!

Of all the possible positions existing in your site's entity, there may only be some available.
* Positions with [REQUIRES_POPULATION] require the population to have a specific size.
* Positions with [REQUIRES_MARKET] will only appear in "large" sites (which may have different rules for different site types). This tag has no effect in fort mode.
* Positions that are appointed by positions that have an AS_NEEDED number. The appointable positions only become available after an appointer position-slot is created. This works also on civ-level. If a position is appointed by a Land-holder, it only becomes available, when that level of landholder is created.

Only the replaced positions are culled and are no longer available.
A position that requires a certain population will become available, even if it doesn't have [APPOINTED_BY] or [ELECTED]. In that case, see 'automatic assignment' and 'assumption'

In fortress mode, in some cases 'succession' is evaluated immediately after a position becomes available. See: Succession.
==Visibility of positions==
A position might be available, but can still be invisible for the player in the [[nobles screen]]. The positions with their respective holders are visible for players:
* All site-positions that are already filled-in (even if they could not be re-filled-in considering current conditions)
* Site positions that are appointable by a filled-in site position
* Site positions that are appointable by a filled-in civ position, when that civ positions holder becomes a citizen of your fortress.
* Civ positions of units that are also a citizen of your fortress.
If a position becomes available, for example because a certain pop number has been reached, or if it is available from the start(like expedition leader), as long as it cannot be appointed, it still is INVISIBLE for the player.

It might strike someone as odd if a position becomes filled automatically in fortress mode when that position is not even visible. This might be the case if the current holder of a non-appointable position dies or succeeds another position. Regardless of player visibility, these positions will be automatically filled in if the necessary requisitions are met. It might happen with the expedition leader.

A situation with a non-visible but available position, is for example when a position is solely appointed by the expedition leader, when the expedition leader's position is left vacant. It can no longer be appointed by the player and is invisible. Then, it gets automatically assumed, proving that the position still was available.

A position that is both [APPOINTED_BY] and [ELECTED] is visible, but players cannot interact with it.

={{text anchor|Evaluation of Positions}}=
The game does not continuously check whether positions should become available, elected or be [REPLACE_BY]. This is well-known behavior—for example with the [[mayor]], who does not appear automatically when the required population ([REQUIRES_POPULATION]) is reached. Instead, positions must somehow be evaluated. This applies in several other situations as well

'''Cases that require a trigger:'''
* Election of a newly created position
* Election after the current holder dies
* Automatic assumption of a newly created position (this may take up to a day)
* New citizens (such as migrants) considering available positions
* Premature succession of a newly created position

'''Cases that do not wait for a trigger:'''
* Succession following the death of the previous holder
* Automatic assumption of existing positions that have become vacant

'''Triggers that cause the game to reevaluate noble positions:'''
* Succession of a [SITE]-position due to the death of the current holder
* [[Advanced_entity_position_mechanics#Election_Day|Election Day]]
* Automatic assumption of a [SITE]-position that becomes vacant
* (Re)assigning any site position manually
* Settlement elevation on the LAND_HOLDER track (e.g. gaining a [[Baron]] or [[Count]])

=Gaining a position=
There are several ways a unit can gain a position:
* Appointment: A unit is appointed by another unit or by the player.
* Election: A unit is elected by and among the members of the entity
* Assumption: A position is neither elected or appointed: a random unit just simply 'takes' the position
* Succession: a unit is the valid successor of this position(A), either by its current position(B) or because they are that position(A)-holder's heir.

Available positions will automatically be assigned to a random civ member when a new site/civ is created.

==Who can take a position==

* If so defined, a unit needs to be the right caste and/or class - it does not seem to work with creature types.
* The unit needs to be an adult member of the site or its parent civ's government; that is also CAN_LEARN or INTELLIGENT (SLOW_LEARNER cannot take positions) or otherwise is able to think.

==Appointment==

Positions that have an [APPOINTED_BY:position] token require that position to exist, to be available and appointed. Any position that is APPOINTED_BY can be appointed if the appointer's position is filled in.
For site-positions to be appointed, it is required that the appointer is present at that location.

If the appointing unit is temporarily not present, or if that position is not filled, positions depending on it cannot be appointed. This is the case with [[militia captains]], when the [[militia commander]] is on a [[mission]].

A site position cannot appoint a civ position ''or'' LAND_HOLDER in any way whatsoever.

Civ-level positions can appoint other civ-level positions and site-level positions can appoint other site-level positions.

Contrary to what has been said elsewhere, civ-level nobles also can appoint site-level nobles. They need to be at the site to do so. Landholders can appoint both site-level and civ-level nobles. These systems are therefore not as separate as was assumed.

'''Mutual appointment''' cannot take place. If these are the only requisites of the position, then the positions will never appear or get filled. These unfillable positions can be put to good use, for example, to replace a position that is no longer needed without creating a new one.

'''Self appointment''' doesn't normally work. If you have a position that is only appointed by itself, it is never appointed and also cannot be assumed. However, if the position has a number higher than 1, and is filled by multiple units (for example by another position that is now empty), than those units can re-assign or appoint each other from that their shared position.

If an APPOINTED_BY token refers to a non-existing position's code, the effects are as if the appointment token doesn't exist at all.

===Automatic appointment in world-gen and on the civ level===

Outside of fortress mode, the game will always attempt to appoint nobles whenever possible, as long as these positions are '''available''', even if they are invisible to the player.
It shows this message in legends: "(unit name) has been appointed to the position of (position name)"

In world-gen, all positions become available and are automatically appointed, taking population- and appointment-requirements into consideration.

Positions that are REPLACED_BY are culled and won't be filled.

If a citizen of your fortress holds a civ-level position that can appoint another civ-level position, the appointment will happen automatically and without player intervention. It may happen that another citizen of your fortress is appointed by that unit, creating civ-level position holders in your fortress, but it is unknown what is required to force this effect.

===Manual appointments by players in fortress mode===
In fortress mode, the positions that need to be appointed stay empty on embark. and it is the player's job to appoint those. A player can appoint a unit to any available position, according to the hereabove mentioned conditions. The player takes the role of the automatic appointment-system, but has no direct control over elections, successions and replacement. There are some differences in what is possible at world-gen sites and at player-controlled sites.

* A position that is appointed by a unit present as a fortress citizen, can be appointed, re-appointed or left vacant. This means also by civ-level nobles living as a citizen in your fortress; not when they are only visiting, like the diplomat.
* A position whose appointing positions are all either vacant or [REPLACED_BY] can no longer be appointed. If the position is already filled, it cannot be reappointed or vacated; the current holder simply remains in office.
* A position that is APPOINTED_BY a unit present as the land_holder of your site, can be appointed, reassigned or left vacant.
* A position that has SUCCESSION BY_HEIR or BY_POSITION can 'initially' be appointed and also re-appointed or left vacant, but as soon as the [[nobles]] screen closes, ''it can no longer be replaced or left vacant''. From then on, the succession-rules determine who gains that position when the current holder loses the position. This works even if the SUCCESSION:BY_POSITION-position is vacant or replaced.
* A position that is ELECTED nor APPOINTED_BY, can always be (re-)appointed by the player. This is the case with the [[Expedition leader]]. If it is left vacant however, it cannot be appointed, but will be assumed shortly after.
* A position that is both ELECTED and APPOINTED_BY, cannot be appointed by the player. Contrary to world-gen sites, its slot is visible, but it doesn't show the +-sign. This is either by AS_NEEDED or by a fixed number. Even if the position somehow gets filled (re)assignment is never possible
* A player can appoint a number of units to a position, as much as the NUMBER token dictates. If it is AS_NEEDED, the player may create as many slots as they like, also contrary to world-gen sites.
* A civ-position can never be appointed, even if the appointing civ noble is a citizen of your fortress. A civ position also never can be re-assigned or left vacant, would that position be defined as appointed by a site-position.

==Election==
Read more in [[Elections]]. The message that is shown is: "(creature name) has been elected to the position of (position name)"

In worldgen, there is no functional difference between ELECTED and non-appointment, except that elected nobles tend to have high social skills and/or skills related to the position, while non-elected ones are assigned randomly. See: [[Elections]]

A succession goes before an election.

A position that is both ELECTED and APPOINTED_BY never gets elected. Even if the appointees' position somehow gets filled, (re)-elections won't happen. So, it doesn't seem possible to have an elected position become available when a certain other position becomes filled.

An ELECTED civ-(or LAND_HOLDER) position at your site will never be (re)-elected in fortress mode. So real (re-)election only works with SITE-positions.

=== {{text anchor|Election Day}} ===
Election Day takes place on the 17th of Summer. On this day, a full reevaluation is performed, including all currently elected positions, which are subject to re-election. Contrary to the information on [[Elections]], nothing occurs at the start of a season.

Positions that are both [APPOINTED_BY] and [ELECTED] will not be re-elected on Election Day when assigned through [SUCCESSION].

=== Election Eligiblity ===
Any citizen may stand for election. Eligibility cannot be restricted using [ACCEPTED_CREATURE], [REJECTED_CREATURE], [ACCEPTED_CLASS], [REJECTED_CLASS], or [GENDER]. Units currently having a [SUCCESSION]-position even may be elected for a position with a [SQUAD]-token, which is otherwise impossible to assign or even succeed.

=== Skills ===
In elections, skills are taken into account for the tokens of the position which is elected.
{| class="wikitable"
|+ Relevant skills per position token
|-
! Position Token !! Relevant skills
|-
| Responsibility [[Position_token#DELIVER_MESSAGES|[DELIVER_MESSAGES]]] || [[Ambusher]], [[Observer]] and [[Social_skill|Social skills]]
|-
| Responsibility [[Position_token#ACCOUNTING|[ACCOUNTING]]] || [[Record_keeper|Record keeper]]
|-
| Responsibility [[Position_token#ESPIONAGE|[ESPIONAGE]]] || [[Schemer]]
|-
| Responsibility [[Position_token#HEALTH_MANAGEMENT|[HEALTH_MANAGEMENT]]] || [[Diagnostician|Diagnostician]]
|-
| Responsibility [[Position_token#MAKE_INTRODUCTIONS|[MAKE_INTRODUCTIONS]]] || [[Social_skill|Social skills]]
|-
| Responsibility [[Position_token#MAKE_PEACE_AGREEMENTS|[MAKE_PEACE_AGREEMENTS]]] || [[Social_skill|Social skills]]
|-
| Responsibility [[Position_token#MAKE_TOPIC_AGREEMENTS|[MAKE_TOPIC_AGREEMENTS]]] || [[Social_skill|Social skills]]
|-
| Responsibility [[Position_token#MANAGE_PRODUCTION|[MANAGE_PRODUCTION]]] || [[Organizer]]
|-
| Responsibility [[Position_token#MEET_WORKERS|[MEET_WORKERS]]] || [[Social_skill|Social skills]]
|-
| Responsibility [[Position_token#RECEIVE_DIPLOMATS|[RECEIVE_DIPLOMATS]]] || [[Social_skill|Social skills]]
|-
| Responsibility [[Position_token#RELIGION|[RELIGION]]] || [[Social_skill|Social skills]]
|-
| Responsibility [[Position_token#TAME_EXOTICS|[TAME_EXOTICS]]] || [[Animal_trainer|Animal trainer]]
|-
| Responsibility [[Position_token#TRADE|[TRADE]]] || [[Social_skill|Social skills]] and [[Appraiser|Appraiser]]
|-
| [[Position_token#SQUAD|[SQUAD]]]-token || [[Tactician]] and [[Leader]]
|}

==Assumption==

A position that is not APPOINTED_BY nor ELECTED, or is appointed by positions that are not available in your site or civ, will be assumable by a random dwarf. If it has responsibilities that require certain skills, then these are taken into consideration on embark, but not when the position is assumed during the actual game.

Normally, one to three units will take the into consideration to assume a position. Most of the time when there are multiple open positions, only a single unit will assume all of them. However, a position that has REJECTED_CREATURE, REJECTED_CLASS, ALLOWED_CREATURE or ALLOWED_CLASS will be filled with all different units, even if the creature or class mentioned is irrelevant. It seems that this forces the game to loop over all the available units.

The message that is shown in Legends mode is: "(unit name) has assumed the position of (position name)". This may also take place in fortress mode, which then shows this message to the player.

If an assumable position becomes empty, it will be assumed within a day. This is the case when you leave the position of expedition-leader vacant. It also happens with entities.

Assumable positions that become empty will not be assumed if that position has a valid [SUCCESSION] -successor. In that case, the successor inherits the position.

Even positions that are somehow invisible because they cannot be directly APPOINTED_BY players, can be assumed.

When you embark, the assumable positions are automatically assigned to a random unit. If there are multiple of these positions at embark, they all are assigned to the same unit. If there are enough positions available, multiple units may gain a position, but often no more than three different ones.

If a dwarf in fortress mode assumes a position, that already has another position, it will leave the current position empty. When that position also is assumed, then this will continue until all positions have a dwarf appointed to them, with no other position.

A unit that already has a position with a [SUCCESSION] token won't take assumable positions into consideration that have a [SQUAD] token. This can be used by the modder to prevent unwanted loss of current positions.

A position that has an appointer which got replaced because of REPLACED_BY, will not become assumable. Also, positions that have an AS_NEEDED appointer that is not yet filled (or ever), will also not be assumed.

==Succession==

If a position-holder dies or advances to a new position via succession, the position will be granted to another unit based on the [SUCCESSION] tag. If they have an heir or the succeeding position exists, that unit will be assigned. If not, a new one will be appointed according to the usual rules. The message that is shown is: "(creature name) being the rightful heir, has inherited the position of (position name)"

The succeeding creature will also lose its previous position. When succession is defined using BY_POSITION, the unit naturally loses the referenced position. However, it also loses any other positions it may hold. If a unit could simultaneously inherit multiple positions, the last-defined succession overrides the earlier one, clearing the previously acquired position

Succession works both at site-level and at civ-level, both in world-gen and in fortress-mode. Succession by position on the civ-level is also visible and functional in fortress-mode. If both civ-level nobles are a citizen of your fortress, succession is applied visually. Vanilla example: The [[druid]] is succeeded by the [[acolyte]]. This means that as soon as the druid dies, the acolyte takes over.

When a position that is succeeded by position becomes available, immediately it is checked if a position-successor is available and the position is filled with that unit. Even if this is an [ELECTED] position, succession goes first. When elections eventually do happen, succession plays no role.

It is possible to assign multiple levels of [SUCCESSION:BY_POSITION] in different positions, creating a line of positions where the death of one causes all those "below" them to advance.

A position can have multiple tokens with position-succession. It looks to be random which one is used. It is not always:
* The first or last defined token
* The first or last appointed unit
* the oldest or youngest
* one with a higher or lower precedence
* a unit with relevant skills

When a position is defined with a Succession-type, that unit cannot have another position that has a Squad-type. If the succession-position itself has a squad, than it can be assigned another position with a squad, but then it will loose the previous succesion position. See further details by "Squad"

Assumed positions can also be succeeded by position, if the current holder dies.

If the successor is an AS_NEEDED position, the used unit will leave a vacant position-slot on its removal by succession. This empty slot remains a real slot, which will only be cleaned up if you (un)appoint a unit to this position-series. It isn't cleaned up after regular position validation.

A civ-level position of a unit living at your site might be inherited by a unit holding that does not currently live at your site. This, unfortunately, moves that position to a unit off site. This may also happen with the landholder of your site, for example when it is succeeded by another civ-level position. This currently poses an unsolved challenge.

===Eligibility for succession===
Succession is restricted by the tokens [ACCEPTED_CREATURE], [REJECTED_CREATURE], [ACCEPTED_CLASS], [REJECTED_CLASS] and [GENDER].

===Site and civ combined succession===

Succession can work when combining site positions with civ-level positions or land_holders, but only in world-gen mode. In fortress mode, it only works with combining the same level of nobles, with Landholders regarded as civ-level. So, in fortress mode, a site's position cannot succeed a landholder's position and it cannot succeed another type of civ-level position, and vice versa.

This won't work even if the positions:
* are AS_NEEDED or having a fixed number.
* Are LAND_HOLDERs.

===Succession [BY_HEIR]===

When a heir is needed for succession, all children and then other relatives are validated. They cannot take the position if their status does not allow it, for example if they have become a member of another civilisation. See: "Who can take a position". If the unit has no valid heir on that location, the position may go to a unit living on another site. This may cause the title of Landholder of some land to be inherited by a unit living somewhere else. That might be a problem, because then you lose your landholders.

===Premature Succession===

There are cases where [SUCCESSION:BY_POSITION] is applied prematurely: at the moment a position is first created and becomes appointable or assumable, rather than after a current holder leaves. In this situation, the succession mechanism assigns a holder immediately, without any player interaction.

When a position becomes available for the first time, the game checks whether a valid successor-by-position exists. If so, that unit is assigned instantly. It can affect positions that would normally be appointed or elected by the player, causing succession to trigger before the player has any opportunity to intervene.

This behavior occurs only in Fortress mode, but can be applied both on [SITE]-positions as well in civ-positions. That last one however is a bit harder to control. Example: [[Advanced entity position mechanics#The Archduke|The Archduke]]

This premature succession only occurs the first time a position becomes available (i.e. when it is created and becomes appointable or assumable). Even if the position remains vacant and the conditions for succession improve later, premature succession will not trigger again. From that point onward, only normal succession rules apply.

Using premature succession, a position that has [ELECTED], [APPOINTED_BY], or both, can be filled directly.
Notably, positions that combine [ELECTED] and [APPOINTED_BY] are normally impossible to fill through regular mechanics. Premature succession bypasses both election and appointment entirely, making this combination uniquely reachable through this mechanism.

No initial election takes place, and no subsequent elections will ever occur for that position. Succession always takes precedence over election, both in premature succession and in normal succession cases.

This behavior applies only in Fortress mode, not during world generation. World-gen uses simplified and more efficient mechanics, and this interaction does not occur there. Premature succession can affect both site-level and civilization-level positions.

====Multiple succession chains====

Multiple succession chains may be defined and are resolved in the order they appear in the raws.

If a position has both:
* a direct succession chain (A → C), and
* a multi-step chain (A → B → C),

and intermediate positions are vacant, resolution proceeds according to raw order. A common outcome is:
# The direct succession (A → C) is applied first, assigning A to C.
# The remaining chain then advances (A → B).
# If C still has empty slots, the final step (B → C) may occur.

If position B is already filled, behavior depends entirely on raw definition order:
* nothing may happen, or
* B may move to C first, followed by A moving to B.
====Working triggers====
Premature succession is triggered when a succeedable position is created under the following conditions:
* The succeedable position is created because its [REQUIRES_POPULATION] threshold is reached. This applies even if the position is not [APPOINTED_BY]. Premature succession takes priority over automatic assumption (e.g. the mayor declaring themselves within a day).
** The position must either be assumable or appointed by an existing position. When said appointer-position also just has been created, the premature succession of the succeedable position happenes, even when the appointer-position is empty.
* The succeedable position can be [APPOINTED_BY] another position of the same level (site or civ) that has just been created because its [REQUIRES_POPULATION] was reached.
* The succeedable position can be appointed by another [SITE] [AS_NEEDED] position that has just been created and filled.
* The succeedable (site or civ) position is [APPOINTED_BY] the [LAND_HOLDER] position, which has just been created due to site elevation. This typically resolves when the diplomat leaves the map, at which point the landholder position becomes active.
* If all other requirements are met, premature succession can occur immediately after unpausing following embark, for positions with [REQUIRES_POPULATION:7].

====Non-working (triggers)====
Premature succession does '''not''' occur in the following cases:
* An [AS_NEEDED] succeedable position slot is manually created by the player while its succeeding position is already filled. [AS_NEEDED] positions must always be appointed after creation.
* The succeeding position is filled after the succeedable position becomes available. The moment of creation is the decisive trigger; filling the source position later is too late.
* The succeedable position can be appointed by another site or civ position with a fixed number of slots that has just been appointed. In this case, the succeedable position is just available for appointment itself, nothing more
* Any situation occurring during world generation.
* The succeeding position is [REPLACED_BY] the succeedable position. In this case, replacement removes the unit from the source position first, leaving no holder available for the succession mechanism to use.
* The position is [APPOINTED_BY] a civ-level position, that just became a citizen of your fortress. It must be noted that those civ-level positions were active all that time and the succeedable position could be appointed even before. The monarchs arrival does not trigger premature succession
* A [SQUAD]-position cannot inherit another [SQUAD]-position. This also means that premature succession will not work in this case.

=Losing a position=

A unit can lose a position when:
* It dies
* It succeeds another position, even if it has nothing to do with the previous position.
* It is assigned to another SQUAD-holding position
* It is convicted of a crime.
* Another unit is ELECTED for the position
* It is convinced by an adventurer to give up its position, or is overthrown in a coup.
* Its position becomes replaced
* Another unit is appointed by the player, or the position is left vacant.
* It has assumed another position (of the same entity), as this always leaves the previous position vacant.

Note: A unit does not lose a position when the unit leaves the group (entity). Neither will a unit lose a position, if the corresponding entity is considered to be dead.

=Embarkment=
Two types of positions are automatically filled by embark.
* Positions without [APPOINTED_BY] or [ELECTED] (assumable). All these positions, even with a NUMBER higher than 1, are all filled with one to three dwarves. Contrary to assumption, this doesn't take into account any limitations. REJECTED_CLASS, ALLOWED_CLASS, REJECTED_CREATURE, ALLOWED_CREATURE and GENDER are applied, but without the normal spread you may expect with assumptions. Also it doesn't look at [SUCCESSION] and [SQUAD] limitations.
* Positions that are elected are filled-in by the normal election rules.

Positions that have a defined appointer are never initially filled at embark.

All positions that don't have [REQUIRES_POPULATION] or with a [REQUIRES_POPULATION] of 7 or lower, will be available at embark.

=Land Holders=

A Landholder is a '''special civ-level noble''' who gets a certain piece of land to hold, when that land is elevated to a certain level, determined by the [LAND_HOLDER] tag, and by the landholder triggers in the game's settings. In vanilla, these are the baron, the count and the duke.

A unit gaining the landholder position does not migrate to that specific named land. In world-gen, they stay just where they are, probably at the capital. In fortress mode, you can suggest a citizen for the role. So for the time being that works.

Succession is then a real issue. If you use BY_HEIR, its solved when that landholder has children living at your site. But when its not the case, the title just goes to anyone randomly. Succession BY_POSITION works, but only in the civ-chain, and there's no way to guarantee a civ-holder is at your site at that time. Even with 'automatic spread' positions, it goes to one of them randomly.

==Functioning of the regular landholder chain==

The distinct difference between a landholder and a regular civ-level noble, is that a landholder may gain the position of landholder "of (sitename)" They are then seen as ruler of a particular site.

For a land_holder position to function as such, it has a few requirements:
* NUMBER:AS_NEEDED
* The first landholder-number of 1 is defined.
* No SITE (so civ) tag in that position.
*REPLACED_BY the next level landholder
If a landholder is defined with differentiating properties, it will function like a regular noble. A higher-up landholder that lacks the required tokens or connections will then not be used in elevation.

If a fortress meets the trigger for a new LAND_HOLDER tier when a caravan leaves, then the next time the outpost liaison or equivalent arrives, they will offer to make you an official colony, which will allow you to select all positions for that LAND_HOLDER level. Each time they appear, the outpost liaison will only promote your fortress one tier up the LAND_HOLDER track.

The landholder's LAND_NAME is not required for the functioning of this system. If omitted, messages will be shown with a more generic text.

==Appointment==

This mechanism differs from the regular methods of position management. It ignores all regular appointment- and election rules, so it more or less functions like automatic assignment. A landholder is, in vanilla, appointed by the monarch. Changing this doesn't seem to do anything. If they are appointed by a site-position, a not-yet-existing civ-position, or not appointed at all: the system keeps working as usual.

A landholder can appoint civ-positions and site positions. This works as expected: the positions only are appointed then when that landholder becomes available on civ-level or when he arrives at that site for site-level positions.

If your rank of landholder is the first of its rank in the realm, and is the sole appointer of some civ-position, then immediately as it gains the title, it will appoint the empty civ-slots. This may happen on your site, but the frequency and certainty is hard to determine.

==Succession==

Succession rules are applied to some extent:
* In world-gen it works according to succession rules, and site-positions can be used here. This means that a site position or a civ-position can inherit a landholder position, and vice versa.
* In fortress mode, once a landholder has been appointed, it then can inherit civ-level positions, and vice versa. This means that your baron can become king.
* Succession rules do not apply within the [LAND_HOLDER] chain; a count will not inherit a baron's land. This is because succession does not work well with the AS_NEEDED token.
* Premature succession works in fortress mode with landholders. If a unit gets a landholder's position and that landholder is the appointer of an as yet empty position, which is defined as succeeding from a third one, then the succession is immediately applied. The landholder themselves can even be the successor of a newly created position.
* A landholder's position is, in fortress mode, not successionable by a site-position or vice versa

===Impossibilities for succession by a site-position===
It would be very beneficial if the landholder can be succeeded by a [SITE]-position. So far, the following tests have not lead to positive results:
* making landholder and site-position both non-[DUTY_BOUND]
* make the site-position be [APPOINTED_BY] the landholder and/or the monarch
* give landholder and site-position [REJECTED_CREATURE]
* Let the monarch live at your site when succession could happen.
* Let the site-position be [REPLACED_BY] the landholder.

If the vanilla [SUCCESSION:BY_HEIR]-tag is omitted, a seemingly random unit somewhere in the realm is assigned this position.

==Nomination==

The player is able to nominate a unit to become the LAND_HOLDER, but this only works with units of [LAND_HOLDER] level 1. The player can select all units, only limited by the PRECEDENCE of the current units' positions.

A unit that has a position with a PRECEDENCE lower or equal to that of the landholder's position, cannot be selected. This means that a baron (or count) from another site or the monarch cannot be selected, because their precedence is lower or equal.

The GENDER token does not work here: also units with the wrong gender (sorry) can be selected.

==Levels==
In mods, up to 10 levels of LAND_HOLDER may be defined.

If a landholder is replaced by a wrong landholder number (1 replaced by 3), then the number 3 is still correctly attached to the settlement.

If the current landholder has the highest available landholder number, then the next elevation will not happen - the diplomat will not elevate your fortress to a higher position, even if that position might be REPLACED_BY a lower landholder.

These chains do work:
* 1 -> 2a - > 2b -> 3
* 1 -> 3 -> 2 -> 4

These chains do not work:
* 2 -> 3 (need to start at 1)
* 1 -> 4 -> 2 -> 3 (stops after 4 as the highest)
* 1a -> 2, 1b -> 2 (only 1a and 2 work, 1b is not used)

==Moving landholders==

It may happen that a land-holder no longer lives at the site which they are the landholder of, specifically when the current landholder dies, leaving the title to an heir living somewhere else.

To prevent this from happening, you can make their succession from heir and make sure that their kids live at your site. Or, you can make their position succeeded by another civ position, and make it so that this civ position is somehow available on your site. But if multiple of these positions exist, it cannot be guaranteed that a citizen of your fortress will inherit the title.

In world gen, a landholder lacking the DUTY_BOUND-token will also move to the site they like, according to legends mode.

==Replacement by a generic civ-position==

If a landholder is replaced by an AS_NEEDED non-landholder civ-position, then this will work: the current landholder loses that title upon settlement-elevation and gains that civ-title. However, the civ-title lacks the landholder-property of being attached to the land. It will not show the name of the settlement alongside the position's name. So no "minister of Shovelmounts"

If a landholder is replaced by a general AS_NEEDED civ-position, that itself is also replaced by a generic AS_NEEDED civ-position, then firstly the elevation is executed and also the unit gains that new position. However, he immediately loses it, because an AS_NEEDED position that is replaced by another position can be filled initially, but units wont be able to hold that title.

==Landholder with fixed number==

A landholder's position that has a fixed number will be created and filled directly when the civilisation is born, so this position slot is then not available for the regular landholder-mechanic and will also not be used. That landholder will thus not be attached to a settlement.

It doesn't matter if the landholder's position is connected to the regular landholder's-chain with the REPLACE_BY token.

==Responsibilities==

When given a certain [RESPONSIBILITY], a landholder may function as a regular civ-level noble. If the position has [TRADE] or [OUTPOST_NEGOTIATING] responsibilities, then the landholder functions both as a diplomat and as an actual land holder. A landholder with the [MILITARY_STRATEGY] responsibility will travel around taming creatures in world-gen, according to legends mode.

Besides that, the responsibilities work the same as with any other on-site living position-holder, civ or otherwise.

=Military=
==Squad management==
In the vanilla game, the Squad interface only becomes available after a militia commander has been appointed. Until then, the window displays:{{DFtext|You must appoint somebody first to create a squad.}}

What’s surprising is how this is determined internally. In the entity raw definition, '''only the last two positions that include a [SQUAD] token are checked''' to decide whether the interface is accessible at all. As a result, if your hierarchy defines commanders A through E, appointing '''Commander D or E''' unlocks squad formation, while appointing A–C does nothing.

In other words, squad availability is not tied to ''having a militia commander'', but to ''which specific positions happen to be last in the raw list''—a notably hacky implementation.

These 'last two' are always the last two '''available positions.''' So if they get [REPLACED_BY] or become available because of [REQUIRES_POPULATION], the game adapts to those.

==Squad assignment==

Squads can be assigned, even if the leader position has no holder.

A specific unit can only have one position associated with a squad. If it gains another 'squad holding position', it is unassigned from the first one. This does not work with a 0-squad, so only 1+squads are taken into consideration. This technique can possibly be used to distribute all positions equally among all citizens. It does however not work with election and assumption.

If a civ-level position is associated with a squad and it gets a site-level squad-holding position assigned, it loses the current civ-position.

Squads can get really messed up, if you make the position (or multiple) either elected or not-elected and not-appointed, then this can cause the game to assign multiple squads to the same unit. Automatic assignment and election does not take squads into account, but the nobles screen does. This can cause the positions to be cleared as the game figures out that they have more than one position, and immediately get elected or assumed again.

Positions that cannot have a squad-position:
* A site- or civ-position with a [SUCCESSION] token cannot be appointed a squad-holding-position. The other way around, however, does work. For example, if a site-position with a [SUCCESSION]-token is appointed to a unit that has already a position with [SQUAD]. But when that squad position is assigned to another unit, it cannot be assigned back.
* A position with [SUCCESSION] can also not be assigned as a '''member''' of a squad.
* A squad-holding position with a formed squad cannot be appointed to another squad holding position.

If a position has at least one squad member, it cannot be left vacant. First, the squad has to be disbanded, then the position may be cleared.

==0-squads==
A 0-Squad is defined in a position as [SQUAD:0:member:members]. It does not seem to do anything useful as of now.
* It cannot be used to activate the [[Squad|military interface]]
* It does not restrict the assignment of [SUCCESSION] positions.
* Assigning this position does not clear any previously held squad position.
* The [[Leader]] and [[Tactician]] skill are not marked as relevant skills and are not taken into account in elections.
* It cannot be formed as a squad.

=Further testing=
The following questions may need additional testing. Feel free to add or answer
* Everything regarding COMMANDING and army-structure
** [http://www.bay12forums.com/smf/index.php?topic=175437.msg8331668#msg8331668]
** [http://www.bay12forums.com/smf/index.php?topic=165213.msg8335682#msg8335682]
** [http://www.bay12forums.com/smf/index.php?topic=174584.msg8026854#msg8026854]
* Stuff about the monarch, its arrival and its entourage.

=Oddities (Bugs)=
Almost everything on this page could be called an oddity. Because of their unexpected usability, some may also be referred to as “undocumented features.” Others, however, are simply odd and not particularly useful, yet I hesitate to call them “bugs.”
* If a certain threshold is reached that makes an elected position electable, and the triggering event that initiates this evaluation is an assumption, then the resulting assumption works partially as an election. It referred to in the messages as an election and the [REJECTED_CREATURE]-token is not applied, like it is with assumptions.

=Examples=

===The Founder===
The founder is a single dwarf, appointed at embark. They will be the only one ever to have this position and are not replaceable. When they lose their position some way, the position will not be assumed by another dwarf.
{{gamedata|title=The Founder|
[POSITION:THE_FOUNDER]
[NAME:the founder:founders]
[NUMBER:1]
[SITE]
[ALLOWED_CREATURE:DWARF:ALL] - will only be filled at embark, but not assumable later.
[REJECTED_CREATURE:DWARF:ALL] - will only be filled at embark, but not assumable later.
[SUCCESSION:BY_POSITION:THE_FOUNDER] - not unassignable, also cannot be assigned to a [SQUAD] position.
[PRECEDENCE:200]
Non APPOINTED_BY
Non ELECTED
Optional: Add responsibilities to make the game select a unit with certain skills.
}}
===Marriage bar===
Dwarven matrons are held in great honour. Upon marriage, a female dwarf is no longer expected to perform menial labour. All dwarven males hold this position by default, granting their spouses exemption from menial work.

The position becomes available with the arrival of the first migrants; otherwise, on embark, it would be assumed by females. Its succession rule is non-functional, but this prevents the player from unassigning the position. A squad size of 1 and the succession rules together prevent a unit from assuming the position more than once.

With precedence set to NONE, the position name is hidden, while LAND_NAME remains visible on the nobles screen. All married females receive the suffix “, Mrs.” and are marked as Nobles.

The practical usefulness of this position is debatable, but it serves as a clear demonstration of several mechanics.
{{gamedata|title=Mrs. Urist|

[POSITION:MRS_URIST]
[NUMBER:300]
[SITE]
[ALLOWED_CREATURE:DWARF:MALE]
Not APPOINTED_BY
Not ELECTED
[LAND_NAME:Dwarven male]
[NAME:dwarven male:dwarven male]
[PRECEDENCE:NONE]
[SPOUSE_FEMALE:, Mrs.:spouses]
[MENIAL_WORK_EXEMPTION_SPOUSE]
[REQUIRES_POPULATION:8]
[SUCCESSION:BY_POSITION:MONARCH]
[SQUAD:1:member:members]
}}
===The Archduke===
The archduke is the leader of the civilization, but exists only from landholder 4-level. Until then, its position remains vacant. When a settlement is elevated to tier 4 (grand duke), the grand duke can appoint the ruler of the civilisation, the archduke. Because of 'Premature Succession', they themself inherit that position immediately, but only when in fortress mode. Its heir then becomes grand duke.
{{gamedata|title=The Archduke| no POSITION:MONARCH or other PRECEDENCE:1

[POSITION:THE_ARCHDUKE]
[NAME:archduke:archdukes]
[NAME_MALE:archduke:archdukes]
[NAME_FEMALE:archduchess:archduchesses]
[LAND_NAME:a archduchy]
[NUMBER:1]
[PRECEDENCE:1]
[SUCCESSION:BY_POSITION:GRAND_DUKE]
[APPOINTED_BY:GRAND_DUKE]
(add additional monarch-stuff, like spouse name, demands etc.)

[POSITION:GRAND_DUKE]
[NAME:grand duke:grand dukes]
[NAME_MALE:grand duke:grand dukes]
[NAME_FEMALE:grand duchess:grand duchesses]
[NUMBER:AS_NEEDED]
[LAND_HOLDER:4]
// Optional ...
[PRECEDENCE:19]
[LAND_NAME:a archduchy]
[RESPONSIBILITY:LAW_MAKING]
[RESPONSIBILITY:RECEIVE_DIPLOMATS]
[SUCCESSION:BY_HEIR]
[APPOINTED_BY:THE_ARCHDUKE]
(add additional landholder-stuff)

!!add to [POSITION:DUKE]
[REPLACED_BY:GRAND_DUKE]

}}
{{Category|Modding}}
{{Category|Entities}}
{{Category|Guides}}

Advanced entity position mechanics

2026-09-27T15:02:48Z

Silverwing235: /* Fortress mode, world-gen and their differences */

{{Quality|Fine}}
{{Modding}}

= Introduction =

[http://www.bay12forums.com/smf/index.php?topic=182239.0 Discussion thread on the forum]

This page documents observed and tested behavior of entity positions in ''Dwarf Fortress'', that is not fully described elsewhere on the wiki; focusing on advanced interactions between position tokens, including appointment, succession, election, and responsibility handling, across both civilization-level and site-level entities.

The mechanics described here are based on empirical testing in world generation and fortress mode, supplemented where necessary by raw analysis. In several cases, the game’s behavior is determined by evaluation order and interaction between multiple tags, rather than by individual tokens in isolation.

This page is intended for modders and advanced players who are designing or debugging custom entity position structures. It does not restate basic position mechanics, but instead highlights edge cases, non-obvious interactions, and behaviors that may appear inconsistent or undocumented.

Unless stated otherwise, the described behavior applies to current versions of the game and may differ from older releases.

==What is an entity? What is a position?==
An [[entity]] is an organizational structure that can have relationships with other entities, usually known as a [[civilization]] or a "[[site]] government" in the game, but e.g. [[merchant company|merchant companies]], [[Mercenary#Mercenary_Orders|mercenary orders]], [[guild|guilds]], [[religion|religious organizations]], bandits and necromancer towers are also entities (and necromancer towers use the same entity type as "site governments"). An entity can have positions - in most cases, these are hardcoded and generated by the game, but as for civilizations and sites, the [[raw file]]s can be customised.

A position is a special relationship between a unit and an entity. The unit holding a position has a larger influence over that entity than other citizens. Positions are mostly known as [[nobles]], but in this article. the technical term is used.

=Position levels (Site/Civ) and their interaction=
There are two basic types of positions that are customizable: '''civ(ilization)''' level and '''site level'''. Positions with the tag [SITE] are at site level, positions without the tag [SITE] are at 'civ level'. These two types of nobles can be considered '''loosely related systems'''. There are a few places where they can interact with each other.

Civ-level positions are in charge of the civilization as a whole, managing national [[trade]], laws, and [[war]]s. These are, for example, the vanilla [[monarch]], [[diplomat]] and [[general]]. (Note that the general doesn't really do anything, except creation of additional pets in world-gen for the general and possibly raising the animal training knowledge of the civilization to "general familiarity".)

'''[LAND_HOLDER]''' nobles are also positions at civ-level. These units are members of the national government, but have gained authority over some land or site. Once they do, they move to that place, but their position is still regarded as a civ-level position.

Site-level position holders are members of a site government (subsidiary to the civilization), and manage local affairs in that location. These are, for example, the [[mayor]], the [[sheriff]] and the [[broker]].

==Table of interaction between different position levels==
In this table, the possible interactions between different position levels are summarized.
The header row shows the positions defining the tokens.

The left column shows the position type that is referred to.
Example:
{| {{prettytable}}
|- bgcolor="#ddd"
! referred position-type
! LAND_HOLDER
|-
| civilization
| (baron is) APPOINTED_BY:MONARCH
|}
color coding: 
* Exists in vanilla
* Possible with mods
* Not possible
* possible to some extent.
* not yet fully investigated.
{| {{prettytable}}
|- bgcolor="#ddd"
! referred position-type
! Civilization
! SITE
! LAND_HOLDER
! CONQUERED_SITE

|-
| Civilization
| APPOINTED_BY COMMANDER REPLACED_BY SUCCESSION
| APPOINTED_BY COMMANDER REPLACED_BY SUCCESSION '''(1)'''
| APPOINTED_BY COMMANDER REPLACED_BY SUCCESSION
| APPOINTED_BY COMMANDER REPLACED_BY SUCCESSION

|-
| SITE
| APPOINTED_BY COMMANDER REPLACED_BY SUCCESSION '''(2)'''
| APPOINTED_BY COMMANDER REPLACED_BY SUCCESSION
| APPOINTED_BY '''(3)''' COMMANDER REPLACED_BY SUCCESSION '''(4)'''
| APPOINTED_BY COMMANDER REPLACED_BY SUCCESSION

|-
| LAND_HOLDER
| APPOINTED_BY COMMANDER REPLACED_BY '''(6)''' SUCCESSION
| APPOINTED_BY COMMANDER REPLACED_BY SUCCESSION '''(5)'''
| APPOINTED_BY COMMANDER REPLACED_BY '''(7)''' SUCCESSION '''(8)'''
| APPOINTED_BY COMMANDER REPLACED_BY SUCCESSION

|-
| CONQUERED_SITE
| APPOINTED_BY COMMANDER REPLACED_BY SUCCESSION
| APPOINTED_BY COMMANDER REPLACED_BY SUCCESSION
| APPOINTED_BY COMMANDER REPLACED_BY SUCCESSION
| APPOINTED_BY COMMANDER REPLACED_BY SUCCESSION
|}

Remarks:
# Works only in world-gen, if a unit with that civ-position is present at the site.
# Works only in world-gen, the site-position holding unit will then move to the capital.
# Is completely ignored
# Works only in world-gen.
# Works only in world-gen.
# Won't appear at all
# This is necessary for the landholder chain to work properly, it doesn’t work otherwise.
# This works only outside of the landholder chain, so when landholders are simply regarded as civ-level nobles. might also work in world-gen
#

== Other interactions ==

Unfortunately, interactions with positions of other entities don't seem possible, such as APPOINTED_BY: HIGH_PRIEST. With [VARIABLE_POSITIONS], positions are automatically created with codes like CUSTOM_LAW_MAKER_2, but interaction with these positions don't seem to work, either. For more info on those, see [[Variable positions]]

=General=

==Civ-level nobles living at your site==
Nobles from your civilization can come to live at your fortress. This happens in vanilla with landholders such as [[Baron]], [[Count]] and [[Duke]], with the Monarch, but sometimes also with non-landed LAND_HOLDERS.

When a civ-level noble becomes a [[citizen]] at your location, their position is shown among the site-level positions in your [[nobles screen]]. They appear to function as a site-level noble. They may have [[demand]]s, [[mandate]]s, [[squad]]s and the like. They can appoint nobles at the site-level.

Even if they have certain site related [RESPONSIBILITY]ies, they will not do the tasks that go with them.

==Fortress mode, worldgen and their differences==
Their are a few differences in how positions function between fortress mode (normal play mode) and the world generation (world-gen).

In '''fortress mode''', the player has some control over the appointment of nobles, limited by elections, automatic filled-in positions and succession rules. Pre-fortress mode, which is referred to as '''worldgen''', the game will always attempt to assign nobles whenever possible. It is subjected to the same rules as in fortress mode, but there are some exceptions. In '''[[World activities]]''', which is the thing that happens in the world while you play fortress mode, it seems as if the same rules are applied as fortress mode.

A difference between player-fortress-mode and worldgen, is caused by visibility (see below). Positions that are not visible by the player and thus not available for assignment, will be available in world-gen and will thus be automatically assigned.

In fortress mode, a position that is both [ELECTED] and [APPOINTED_BY], cannot be appointed by the player and is also not elected, and can thus not be filled. But in world-gen sites however, these positions are automatically filled.

Positions with [AS_NEEDED] are almost never created and filled in world-gen (depending on their [RESPONSIBILITY]ies), but can always be used in player mode.

A position can, in fortress mode, be filled by the same unit. A unit can gain multiple positions in fortress mode, for example because of [[elections]]. This will not happen in world-gen mode: a unit can only have one position. See also remarks on 'embark' and 'Losing a position'.

In worldgen, [SUCCESSION] between civ-levels and [SITE-]levels may happen. This will not happen in fortress mode, or even off-site in [[World activities]].

In fortress mode, premature SUCCESSION may happen. This will not happen in worldgen mode.

==Units holding multiple positions in multiple entities==
A unit can hold multiple positions in its civilisation or in its site-entity, however in world-gen a unit will not hold multiple positions in one site-entity or in one civilisation (note that in world-gen a unit can hold multiple variable positions of the same entity, if the entity is ie. an outcast group). It is however possible - in world-gen - for a unit to hold multiple positions as long as the positions belong to different civilizations / site-entities (ie. it is possible for a militia commander of a site-entity to later on also become a monarch of the parent civilization, while staying a militia commander), if a unit holds a position of two different site-entities (the unit will usually have left one of the groups, without relinquishing the position). Only at player-managed sites can units be holding multiple positions (of the site-entity) at once. It is currently unknown, whether it is possible in world-gen for a unit to have a civ-level position in two different civilisations (but it probably is possible, as a a unit can belong to multiple civilizations and a unit usually does not relinquish a position, when the unit gets another position, as long as the entities of both positions are not the same).

In world-gen, if there are too many positions to be filled, they simply stay empty until more units are available. E.G, a unit at a site might inherit a civ-level position and still remain a member of the local government. When this happens however, they move to the capital. If a unit gains a new position, either inherited or otherwise, it drops the previous one (of that civilisation or site-entity) - the unit will not drop any positions unrelated to the entity of the new position (ie. a CUSTOM_OUTCAST_FACTOR will not relinquish that position, if the unit becomes the ruler of a civilization and a militia commander will also not necessarily relinquish the position, if the unit becomes also the monarch of the corresponding civilization). If a unit assumes a civ-position in fortress mode, it leaves the current position.

If a unit holds the same site-position multiple times, it has no additional effect.

If a unit holds multiple different positions of the same entity, it has all those positions' responsibilities and properties, stacked up. Presumably, the demands for those combined positions are determined by the highest.

A unit holding a position with a succession token can be assigned another position with a (different) succession token.

A unit holding a position with a squad-position cannot hold another squad-position. It is dropped from the first of those, when the second position is assigned.
A unit holding a position with a succession token cannot be assigned to a squad-position - the unit is simply not available. It works the other way around, though.

=Specific Tags and functions=
==[PRECEDENCE]==
The first defined position with precedence of 1 counts as the ruler of the civ. See also: [[Position_token#PRECEDENCE|PRECEDENCE]].

If the precedence is omitted or has a negative value, the game sets 0 as precedence, which seems to have no effect whatsoever. When a unit has multiple positions, the name of the position with the highest rank in precedence is shown behind the unit's name.

If you omit precedence entirely, or set it to [PRECEDENCE:NONE], the position name will not be shown after the unit’s name. Your *Urist Mason* will remain simply *Mason*. This can be useful for positions that are unimportant or purely functional. The position will also not appear in the civilisation overview of your site on the world map. The position name is shown in messages, but remains hidden on the nobles screen as well. To make it visible there, use [LAND_NAME].

==[RESPONSIBILITY]ies==
Both civ and [SITE] positions can carry responsibilities. However, not all responsibilities are active for both types: some function only for civ positions, others only for site positions. When a civ noble arrives at a site and takes up residence, they do not perform responsibilities that are intended for SITE nobles. As a result, these responsibilities neither trigger their associated tasks nor unlock related game mechanics. For example, a civ-level manager living in a fortress will not perform management duties there and doesn't unlock the management-screen, even with an assigned office.
This behavior applies to the following [SITE]-level responsibilities:
* [RESPONSIBILITY:ACCOUNTING]
* [RESPONSIBILITY:BUILD_MORALE]
* [RESPONSIBILITY:HEALTH_MANAGEMENT]
* [RESPONSIBILITY:LAW_ENFORCEMENT]
* [RESPONSIBILITY:MANAGE_PRODUCTION]
* [RESPONSIBILITY:MEET_WORKERS]
* [RESPONSIBILITY:TRADE] (functions differently)
Other responsibilities may be affected as well, but have not yet been fully tested.

===World-gen effects of the [RESPONSIBILITY] of available positions ===
It is possible to cause civs and individual sites to change their behavior substantially when they reach a certain size, by controlling nobles.
* If a site can only appoint a position with [MILITARY_GOALS] after reaching a particular size, that site will not send armies on missions until the required size is reached.
* A civ-level [LAW_MAKING] position is required for the civilization to have any kind of cohesion. Without it, sites will be constantly embroiled in territorial disputes and civil wars will be commonplace.
* [MILITARY_STRATEGY] positions go out and tame wild animals. This makes your civ gain those animals as domesticated and also brings them in sieges.
* The [[Personality_facet|Personality]] of the position's holder determines how they lead the civ.

===[DELIVERS_MESSAGES]===
The only [AS_NEEDED]-position that is created in worldgen based on responsibility is that of the site-level responsibility [DELIVERS_MESSAGES].

===Outpost Liaisons and Diplomats===
Civ-positions with the responsibility [ESTABLISH_COLONY_TRADE_AGREEMENTS] ([[Outpost_Liaison|Outpost Liaison]]s) will meet with the site-noble who has responsibility for [RECEIVE_DIPLOMATS] and the highest rank of precedence (i.e. the lowest precedence value). Usually this is the [[Expedition_leader|Expedition leader]].

Once a [LAND_HOLDER] is assigned to the site, civ-positions with the responsibility [MAKE_TOPIC_AGREEMENTS] ([[Diplomat]]s) will meet with '''civ'''-level nobles present at the site who have the [RECEIVE_DIPLOMATS] responsibility. If multiple eligible nobles are available, one is selected at random. If no eligible noble is present, the diplomat leaves angrily. If the landholder is no longer present at the site, diplomats will not arrive at all.

It appears that Outpost Liaisons and Diplomats are chosen for a diplomatic mission based on availability. When multiple candidates exist, the position defined last in the raws is most often selected.

===[TRADE]===
Civ-level nobles with [TRADE] will arrive with the caravan, just as the Outpost Liaison. Their behavior is no longer active in the vanilla game, but the mechanics are still present. See [[40d:Guild_representative|Guild representative]] for more details. This civ-noble will only meet with the SITE noble with [TRADE], usually the [[Broker]].

If two civ-nobles exist with both [TRADE] and [ESTABLISH_COLONY_TRADE_AGREEMENTS], they both arrive at the same time. Even if both tokens are assigned to a single position, if more than one instance of that position exists, two of them will arrive. However in that case, somehow the elevation of the site and appointment of landholder isn't offered.

If the SITE-noble they intend to meet has both [TRADE] and [RECEIVE_DIPLOMATS], only one meeting will proceed and the other is cancelled. However, when two SITE-nobles are available, each with either [TRADE] or [RECEIVE_DIPLOMATS], both meetings will proceed and both civ-nobles will attempt to negotiate a trade agreement. It is not known what happens if these agreements are accepted or refused.

In the trade depot, the last defined position with the [TRADE] responsibility is shown as broker. However when requesting a trader, the first defined position with [TRADE] will actually go there to do the trade.

==[NUMBER]==
A position might be defined with a number. In that case, as many as defined can be available. If the positions become available in world-gen and when embarking, they are all filled in completely.

If the ruling position (with PRECEDENCE of 1) has a NUMBER higher than 1, a random unit of the ones holding these positions is shown as ruler in the embark screen.

A [NUMBER] of 0 (zero) has the same effect as 1.

===Automatic spreading of assumed, non-singular positions===
If there are civ positions that have a NUMBER higher then '1' and which are assumed (not APPOINTED_BY or ELECTED) but are '''not DUTY_BOUND''', these are automatically spread among the civilisation, based on population. If there are a number of '''20''' available slots of that position, they spread among a civilization with a combined population of, for example, 1000 of which your fortress has 100 (10%), '''2''' of your fortress' citizens will assume that position.
This may probably also work with elected and appointed positions, but that may be depending on the death of the current holders and this needs more testing. Assumption works within a day, anyway.

===[AS_NEEDED]===
These positions can be created automatically by the game in worldgen. This, however, only works with:
* [LAND_HOLDER]'s
* squad commanders (needs more testing)
* Messengers at sites

For all other types of positions, they're not created in worldgen; even if defined with RESPONSIBILITY's. For example, even in war, the game wouldn't create a MILITARY_GOALS position if they have AS_NEEDED as a number. However, in fortress mode / player mode, these positions can be created by the player at will.

Positions with AS_NEEDED need to be created first, before any symbols are assignable as 'symbols' (objects) for the position holder to carry or wear, but they cannot be created and then ELECTED in fortress mode - that only works with APPOINTED_BY.

==[REPLACED_BY], [REQUIRES_POPULATION], [REQUIRES_MARKET]==

The token [REPLACED_BY:position] means that once the replacing position meets its requirements for activation, the 'to-be-replaced' position will disappear. This is defined in [REQUIRES_POPULATION] or [REQUIRES_MARKET]. The tags are closely related to each other and seem to only have a meaningful function if combined. Nobles with [REQUIRES_POPULATION] require the population to have a specific size. Nobles with [REQUIRES_MARKET] are only activated in market sites, such as fortresses or towns. [REQUIRES_POPULATION] and [REQUIRES_MARKET] can be combined, activating that position once both requirements are met.

The [REQUIRES_MARKET] can be used to differentiate positions between hamlets and hillocks, and larger sites. IThe market always is build the year after the site is founded. So a position that is to be replaced, will be gone immediately.

The [REQUIRES_POPULATION]-tag works on the civ-level as well as on site-level, but those systems are in this mechanic strictly separated. Site-level positions cannot be replaced by civ-level positions and visa versa. This makes sense, because they both depend on their own population-count. When using REQUIRES_POPULATION on civ-level, it counts the total population of the civilisation.

See also: [[Advanced_entity_position_mechanics#Evaluation_of_Positions|Evaluation of positions]]

===Effect of replacement (and on [LAND_HOLDER]s)===

Replacement is immediate and complete - the current holding unit loses the position, even before SUCCESSION_BY_POSITION rules are applied. A position with a number of 1 will replace all the slots of a position with a higher number of slots.

Even if the next position is available but not visible, replacement still takes place. If a position is replaced, it is completely gone - it cannot be appointed, succeeded, elected or assumed any longer.
The unit immediately loses its position.

In legends, replacement is mentioned as: "(unit name) ceased to be (position name)" The replacement of an AS_NEEDED position empties the position's slot forever. In fortress mode, it may seem as if you can create new slots and appoint new units in the nobles screen, but this is reversed as soon as you close the window.

The landholder chain uses [REPLACED_BY] differently. It does not clear the position completely, but uses it for succession to the next level's position. [REPLACE_BY] is required to let that system work properly. This also means that the way in which landholders succeed (replace + as_needed) does not work in any other way.

Replacement between LAND_HOLDERS and other site- or civ positions does not work in any way. Only the vanilla replacement sequence between levels of LAND_HOLDERs does work. If the token is omitted for landholders, the landholder chain is broken, so replacement is required for the landholder system to work.

[REQUIRES_POPULATION] also does not work for [LAND_HOLDER], when you set [NUMBER] to 1. The position is not created when the required population is reached.

===What doesn't work===

'''Attention: If a position cannot be appointed, for example because of 'mutual appointment', it still exists according to replacement mechanics and will replace other positions if so defined. If a certain position(a) will be replaced by the baron's assistant, which can only be appointed by the [LAND_HOLDER] baron, than that position(s) still will be replaced from the start of the game, even if no baron or their assistant is ever present.'''

A position that is replaced by a somehow non-fillable position is still replaced. This counts for mutual-appointing positions, replacement by not-yet-assigned landholders, replacement by AS_NEEDED positions, or replacement by not-yet-appointed positions.

Replacement does not work if the replaced position is a [LAND_HOLDER], even with civ-positions. In that case, the LAND_HOLDER's position is not replaced. It does not matter if AS_NEEDED is used, or a fixed number, and it also does not matter what type of position the replacer is. So this only works (correctly) with positions that become available by REQUIRES_POPULATION.

==[CONQUERED_SITE]==

This tag determines which position is used to assign a [[Forced administrator]].

In legends mode, this is visible as an event describing the reconquest of the site: a new group is formed and the forced administrator is installed as its ruler.

All positions defined with this tag are assigned during this process, meaning multiple positions can be appointed at once.

The holder of a position marked with [CONQUERED_SITE] cannot appoint any other [SITE] positions, unless the civilization has site variable positions, in which case the forced administrator can appoint such site variable positions (allthough the variable positions for that site need to be created first and such creation only happens during world-gen, but not normal world activities).

Combining [CONQUERED_SITE] with [SITE] causes the position to function both as a forced administrator and as a normal site position available in fortress mode. However, this provides no meaningful additional mechanics and is effectively inferior to using [SITE] alone:
* [APPOINTED_BY] lines are completely ignored, meaning that the roles are automatically assumed.
* [SUCCESSION] is likewise ignored.
* the [CONQUERED_SITE]-position cannot appoint other [CONQUERED_SITE], [SITE] or combined positions.

There have been remarks that reclaiming a fortress is unplayable because of the lack of regular nobles. Unfortunately, it seems that it can't be fixed by modding.

=Availability and visibility=
==Availability of (new) positions==
Warning: Do not mistake "availability" for "visibility"!

Of all the possible positions existing in your site's entity, there may only be some available.
* Positions with [REQUIRES_POPULATION] require the population to have a specific size.
* Positions with [REQUIRES_MARKET] will only appear in "large" sites (which may have different rules for different site types). This tag has no effect in fort mode.
* Positions that are appointed by positions that have an AS_NEEDED number. The appointable positions only become available after an appointer position-slot is created. This works also on civ-level. If a position is appointed by a Land-holder, it only becomes available, when that level of landholder is created.

Only the replaced positions are culled and are no longer available.
A position that requires a certain population will become available, even if it doesn't have [APPOINTED_BY] or [ELECTED]. In that case, see 'automatic assignment' and 'assumption'

In fortress mode, in some cases 'succession' is evaluated immediately after a position becomes available. See: Succession.
==Visibility of positions==
A position might be available, but can still be invisible for the player in the [[nobles screen]]. The positions with their respective holders are visible for players:
* All site-positions that are already filled-in (even if they could not be re-filled-in considering current conditions)
* Site positions that are appointable by a filled-in site position
* Site positions that are appointable by a filled-in civ position, when that civ positions holder becomes a citizen of your fortress.
* Civ positions of units that are also a citizen of your fortress.
If a position becomes available, for example because a certain pop number has been reached, or if it is available from the start(like expedition leader), as long as it cannot be appointed, it still is INVISIBLE for the player.

It might strike someone as odd if a position becomes filled automatically in fortress mode when that position is not even visible. This might be the case if the current holder of a non-appointable position dies or succeeds another position. Regardless of player visibility, these positions will be automatically filled in if the necessary requisitions are met. It might happen with the expedition leader.

A situation with a non-visible but available position, is for example when a position is solely appointed by the expedition leader, when the expedition leader's position is left vacant. It can no longer be appointed by the player and is invisible. Then, it gets automatically assumed, proving that the position still was available.

A position that is both [APPOINTED_BY] and [ELECTED] is visible, but players cannot interact with it.

={{text anchor|Evaluation of Positions}}=
The game does not continuously check whether positions should become available, elected or be [REPLACE_BY]. This is well-known behavior—for example with the [[mayor]], who does not appear automatically when the required population ([REQUIRES_POPULATION]) is reached. Instead, positions must somehow be evaluated. This applies in several other situations as well

'''Cases that require a trigger:'''
* Election of a newly created position
* Election after the current holder dies
* Automatic assumption of a newly created position (this may take up to a day)
* New citizens (such as migrants) considering available positions
* Premature succession of a newly created position

'''Cases that do not wait for a trigger:'''
* Succession following the death of the previous holder
* Automatic assumption of existing positions that have become vacant

'''Triggers that cause the game to reevaluate noble positions:'''
* Succession of a [SITE]-position due to the death of the current holder
* [[Advanced_entity_position_mechanics#Election_Day|Election Day]]
* Automatic assumption of a [SITE]-position that becomes vacant
* (Re)assigning any site position manually
* Settlement elevation on the LAND_HOLDER track (e.g. gaining a [[Baron]] or [[Count]])

=Gaining a position=
There are several ways a unit can gain a position:
* Appointment: A unit is appointed by another unit or by the player.
* Election: A unit is elected by and among the members of the entity
* Assumption: A position is neither elected or appointed: a random unit just simply 'takes' the position
* Succession: a unit is the valid successor of this position(A), either by its current position(B) or because they are that position(A)-holder's heir.

Available positions will automatically be assigned to a random civ member when a new site/civ is created.

==Who can take a position==

* If so defined, a unit needs to be the right caste and/or class - it does not seem to work with creature types.
* The unit needs to be an adult member of the site or its parent civ's government; that is also CAN_LEARN or INTELLIGENT (SLOW_LEARNER cannot take positions) or otherwise is able to think.

==Appointment==

Positions that have an [APPOINTED_BY:position] token require that position to exist, to be available and appointed. Any position that is APPOINTED_BY can be appointed if the appointer's position is filled in.
For site-positions to be appointed, it is required that the appointer is present at that location.

If the appointing unit is temporarily not present, or if that position is not filled, positions depending on it cannot be appointed. This is the case with [[militia captains]], when the [[militia commander]] is on a [[mission]].

A site position cannot appoint a civ position ''or'' LAND_HOLDER in any way whatsoever.

Civ-level positions can appoint other civ-level positions and site-level positions can appoint other site-level positions.

Contrary to what has been said elsewhere, civ-level nobles also can appoint site-level nobles. They need to be at the site to do so. Landholders can appoint both site-level and civ-level nobles. These systems are therefore not as separate as was assumed.

'''Mutual appointment''' cannot take place. If these are the only requisites of the position, then the positions will never appear or get filled. These unfillable positions can be put to good use, for example, to replace a position that is no longer needed without creating a new one.

'''Self appointment''' doesn't normally work. If you have a position that is only appointed by itself, it is never appointed and also cannot be assumed. However, if the position has a number higher than 1, and is filled by multiple units (for example by another position that is now empty), than those units can re-assign or appoint each other from that their shared position.

If an APPOINTED_BY token refers to a non-existing position's code, the effects are as if the appointment token doesn't exist at all.

===Automatic appointment in world-gen and on the civ level===

Outside of fortress mode, the game will always attempt to appoint nobles whenever possible, as long as these positions are '''available''', even if they are invisible to the player.
It shows this message in legends: "(unit name) has been appointed to the position of (position name)"

In world-gen, all positions become available and are automatically appointed, taking population- and appointment-requirements into consideration.

Positions that are REPLACED_BY are culled and won't be filled.

If a citizen of your fortress holds a civ-level position that can appoint another civ-level position, the appointment will happen automatically and without player intervention. It may happen that another citizen of your fortress is appointed by that unit, creating civ-level position holders in your fortress, but it is unknown what is required to force this effect.

===Manual appointments by players in fortress mode===
In fortress mode, the positions that need to be appointed stay empty on embark. and it is the player's job to appoint those. A player can appoint a unit to any available position, according to the hereabove mentioned conditions. The player takes the role of the automatic appointment-system, but has no direct control over elections, successions and replacement. There are some differences in what is possible at world-gen sites and at player-controlled sites.

* A position that is appointed by a unit present as a fortress citizen, can be appointed, re-appointed or left vacant. This means also by civ-level nobles living as a citizen in your fortress; not when they are only visiting, like the diplomat.
* A position whose appointing positions are all either vacant or [REPLACED_BY] can no longer be appointed. If the position is already filled, it cannot be reappointed or vacated; the current holder simply remains in office.
* A position that is APPOINTED_BY a unit present as the land_holder of your site, can be appointed, reassigned or left vacant.
* A position that has SUCCESSION BY_HEIR or BY_POSITION can 'initially' be appointed and also re-appointed or left vacant, but as soon as the [[nobles]] screen closes, ''it can no longer be replaced or left vacant''. From then on, the succession-rules determine who gains that position when the current holder loses the position. This works even if the SUCCESSION:BY_POSITION-position is vacant or replaced.
* A position that is ELECTED nor APPOINTED_BY, can always be (re-)appointed by the player. This is the case with the [[Expedition leader]]. If it is left vacant however, it cannot be appointed, but will be assumed shortly after.
* A position that is both ELECTED and APPOINTED_BY, cannot be appointed by the player. Contrary to world-gen sites, its slot is visible, but it doesn't show the +-sign. This is either by AS_NEEDED or by a fixed number. Even if the position somehow gets filled (re)assignment is never possible
* A player can appoint a number of units to a position, as much as the NUMBER token dictates. If it is AS_NEEDED, the player may create as many slots as they like, also contrary to world-gen sites.
* A civ-position can never be appointed, even if the appointing civ noble is a citizen of your fortress. A civ position also never can be re-assigned or left vacant, would that position be defined as appointed by a site-position.

==Election==
Read more in [[Elections]]. The message that is shown is: "(creature name) has been elected to the position of (position name)"

In worldgen, there is no functional difference between ELECTED and non-appointment, except that elected nobles tend to have high social skills and/or skills related to the position, while non-elected ones are assigned randomly. See: [[Elections]]

A succession goes before an election.

A position that is both ELECTED and APPOINTED_BY never gets elected. Even if the appointees' position somehow gets filled, (re)-elections won't happen. So, it doesn't seem possible to have an elected position become available when a certain other position becomes filled.

An ELECTED civ-(or LAND_HOLDER) position at your site will never be (re)-elected in fortress mode. So real (re-)election only works with SITE-positions.

=== {{text anchor|Election Day}} ===
Election Day takes place on the 17th of Summer. On this day, a full reevaluation is performed, including all currently elected positions, which are subject to re-election. Contrary to the information on [[Elections]], nothing occurs at the start of a season.

Positions that are both [APPOINTED_BY] and [ELECTED] will not be re-elected on Election Day when assigned through [SUCCESSION].

=== Election Eligiblity ===
Any citizen may stand for election. Eligibility cannot be restricted using [ACCEPTED_CREATURE], [REJECTED_CREATURE], [ACCEPTED_CLASS], [REJECTED_CLASS], or [GENDER]. Units currently having a [SUCCESSION]-position even may be elected for a position with a [SQUAD]-token, which is otherwise impossible to assign or even succeed.

=== Skills ===
In elections, skills are taken into account for the tokens of the position which is elected.
{| class="wikitable"
|+ Relevant skills per position token
|-
! Position Token !! Relevant skills
|-
| Responsibility [[Position_token#DELIVER_MESSAGES|[DELIVER_MESSAGES]]] || [[Ambusher]], [[Observer]] and [[Social_skill|Social skills]]
|-
| Responsibility [[Position_token#ACCOUNTING|[ACCOUNTING]]] || [[Record_keeper|Record keeper]]
|-
| Responsibility [[Position_token#ESPIONAGE|[ESPIONAGE]]] || [[Schemer]]
|-
| Responsibility [[Position_token#HEALTH_MANAGEMENT|[HEALTH_MANAGEMENT]]] || [[Diagnostician|Diagnostician]]
|-
| Responsibility [[Position_token#MAKE_INTRODUCTIONS|[MAKE_INTRODUCTIONS]]] || [[Social_skill|Social skills]]
|-
| Responsibility [[Position_token#MAKE_PEACE_AGREEMENTS|[MAKE_PEACE_AGREEMENTS]]] || [[Social_skill|Social skills]]
|-
| Responsibility [[Position_token#MAKE_TOPIC_AGREEMENTS|[MAKE_TOPIC_AGREEMENTS]]] || [[Social_skill|Social skills]]
|-
| Responsibility [[Position_token#MANAGE_PRODUCTION|[MANAGE_PRODUCTION]]] || [[Organizer]]
|-
| Responsibility [[Position_token#MEET_WORKERS|[MEET_WORKERS]]] || [[Social_skill|Social skills]]
|-
| Responsibility [[Position_token#RECEIVE_DIPLOMATS|[RECEIVE_DIPLOMATS]]] || [[Social_skill|Social skills]]
|-
| Responsibility [[Position_token#RELIGION|[RELIGION]]] || [[Social_skill|Social skills]]
|-
| Responsibility [[Position_token#TAME_EXOTICS|[TAME_EXOTICS]]] || [[Animal_trainer|Animal trainer]]
|-
| Responsibility [[Position_token#TRADE|[TRADE]]] || [[Social_skill|Social skills]] and [[Appraiser|Appraiser]]
|-
| [[Position_token#SQUAD|[SQUAD]]]-token || [[Tactician]] and [[Leader]]
|}

==Assumption==

A position that is not APPOINTED_BY nor ELECTED, or is appointed by positions that are not available in your site or civ, will be assumable by a random dwarf. If it has responsibilities that require certain skills, then these are taken into consideration on embark, but not when the position is assumed during the actual game.

Normally, one to three units will take the into consideration to assume a position. Most of the time when there are multiple open positions, only a single unit will assume all of them. However, a position that has REJECTED_CREATURE, REJECTED_CLASS, ALLOWED_CREATURE or ALLOWED_CLASS will be filled with all different units, even if the creature or class mentioned is irrelevant. It seems that this forces the game to loop over all the available units.

The message that is shown in Legends mode is: "(unit name) has assumed the position of (position name)". This may also take place in fortress mode, which then shows this message to the player.

If an assumable position becomes empty, it will be assumed within a day. This is the case when you leave the position of expedition-leader vacant. It also happens with entities.

Assumable positions that become empty will not be assumed if that position has a valid [SUCCESSION] -successor. In that case, the successor inherits the position.

Even positions that are somehow invisible because they cannot be directly APPOINTED_BY players, can be assumed.

When you embark, the assumable positions are automatically assigned to a random unit. If there are multiple of these positions at embark, they all are assigned to the same unit. If there are enough positions available, multiple units may gain a position, but often no more than three different ones.

If a dwarf in fortress mode assumes a position, that already has another position, it will leave the current position empty. When that position also is assumed, then this will continue until all positions have a dwarf appointed to them, with no other position.

A unit that already has a position with a [SUCCESSION] token won't take assumable positions into consideration that have a [SQUAD] token. This can be used by the modder to prevent unwanted loss of current positions.

A position that has an appointer which got replaced because of REPLACED_BY, will not become assumable. Also, positions that have an AS_NEEDED appointer that is not yet filled (or ever), will also not be assumed.

==Succession==

If a position-holder dies or advances to a new position via succession, the position will be granted to another unit based on the [SUCCESSION] tag. If they have an heir or the succeeding position exists, that unit will be assigned. If not, a new one will be appointed according to the usual rules. The message that is shown is: "(creature name) being the rightful heir, has inherited the position of (position name)"

The succeeding creature will also lose its previous position. When succession is defined using BY_POSITION, the unit naturally loses the referenced position. However, it also loses any other positions it may hold. If a unit could simultaneously inherit multiple positions, the last-defined succession overrides the earlier one, clearing the previously acquired position

Succession works both at site-level and at civ-level, both in world-gen and in fortress-mode. Succession by position on the civ-level is also visible and functional in fortress-mode. If both civ-level nobles are a citizen of your fortress, succession is applied visually. Vanilla example: The [[druid]] is succeeded by the [[acolyte]]. This means that as soon as the druid dies, the acolyte takes over.

When a position that is succeeded by position becomes available, immediately it is checked if a position-successor is available and the position is filled with that unit. Even if this is an [ELECTED] position, succession goes first. When elections eventually do happen, succession plays no role.

It is possible to assign multiple levels of [SUCCESSION:BY_POSITION] in different positions, creating a line of positions where the death of one causes all those "below" them to advance.

A position can have multiple tokens with position-succession. It looks to be random which one is used. It is not always:
* The first or last defined token
* The first or last appointed unit
* the oldest or youngest
* one with a higher or lower precedence
* a unit with relevant skills

When a position is defined with a Succession-type, that unit cannot have another position that has a Squad-type. If the succession-position itself has a squad, than it can be assigned another position with a squad, but then it will loose the previous succesion position. See further details by "Squad"

Assumed positions can also be succeeded by position, if the current holder dies.

If the successor is an AS_NEEDED position, the used unit will leave a vacant position-slot on its removal by succession. This empty slot remains a real slot, which will only be cleaned up if you (un)appoint a unit to this position-series. It isn't cleaned up after regular position validation.

A civ-level position of a unit living at your site might be inherited by a unit holding that does not currently live at your site. This, unfortunately, moves that position to a unit off site. This may also happen with the landholder of your site, for example when it is succeeded by another civ-level position. This currently poses an unsolved challenge.

===Eligibility for succession===
Succession is restricted by the tokens [ACCEPTED_CREATURE], [REJECTED_CREATURE], [ACCEPTED_CLASS], [REJECTED_CLASS] and [GENDER].

===Site and civ combined succession===

Succession can work when combining site positions with civ-level positions or land_holders, but only in world-gen mode. In fortress mode, it only works with combining the same level of nobles, with Landholders regarded as civ-level. So, in fortress mode, a site's position cannot succeed a landholder's position and it cannot succeed another type of civ-level position, and vice versa.

This won't work even if the positions:
* are AS_NEEDED or having a fixed number.
* Are LAND_HOLDERs.

===Succession [BY_HEIR]===

When a heir is needed for succession, all children and then other relatives are validated. They cannot take the position if their status does not allow it, for example if they have become a member of another civilisation. See: "Who can take a position". If the unit has no valid heir on that location, the position may go to a unit living on another site. This may cause the title of Landholder of some land to be inherited by a unit living somewhere else. That might be a problem, because then you lose your landholders.

===Premature Succession===

There are cases where [SUCCESSION:BY_POSITION] is applied prematurely: at the moment a position is first created and becomes appointable or assumable, rather than after a current holder leaves. In this situation, the succession mechanism assigns a holder immediately, without any player interaction.

When a position becomes available for the first time, the game checks whether a valid successor-by-position exists. If so, that unit is assigned instantly. It can affect positions that would normally be appointed or elected by the player, causing succession to trigger before the player has any opportunity to intervene.

This behavior occurs only in Fortress mode, but can be applied both on [SITE]-positions as well in civ-positions. That last one however is a bit harder to control. Example: [[Advanced entity position mechanics#The Archduke|The Archduke]]

This premature succession only occurs the first time a position becomes available (i.e. when it is created and becomes appointable or assumable). Even if the position remains vacant and the conditions for succession improve later, premature succession will not trigger again. From that point onward, only normal succession rules apply.

Using premature succession, a position that has [ELECTED], [APPOINTED_BY], or both, can be filled directly.
Notably, positions that combine [ELECTED] and [APPOINTED_BY] are normally impossible to fill through regular mechanics. Premature succession bypasses both election and appointment entirely, making this combination uniquely reachable through this mechanism.

No initial election takes place, and no subsequent elections will ever occur for that position. Succession always takes precedence over election, both in premature succession and in normal succession cases.

This behavior applies only in Fortress mode, not during world generation. World-gen uses simplified and more efficient mechanics, and this interaction does not occur there. Premature succession can affect both site-level and civilization-level positions.

====Multiple succession chains====

Multiple succession chains may be defined and are resolved in the order they appear in the raws.

If a position has both:
* a direct succession chain (A → C), and
* a multi-step chain (A → B → C),

and intermediate positions are vacant, resolution proceeds according to raw order. A common outcome is:
# The direct succession (A → C) is applied first, assigning A to C.
# The remaining chain then advances (A → B).
# If C still has empty slots, the final step (B → C) may occur.

If position B is already filled, behavior depends entirely on raw definition order:
* nothing may happen, or
* B may move to C first, followed by A moving to B.
====Working triggers====
Premature succession is triggered when a succeedable position is created under the following conditions:
* The succeedable position is created because its [REQUIRES_POPULATION] threshold is reached. This applies even if the position is not [APPOINTED_BY]. Premature succession takes priority over automatic assumption (e.g. the mayor declaring themselves within a day).
** The position must either be assumable or appointed by an existing position. When said appointer-position also just has been created, the premature succession of the succeedable position happenes, even when the appointer-position is empty.
* The succeedable position can be [APPOINTED_BY] another position of the same level (site or civ) that has just been created because its [REQUIRES_POPULATION] was reached.
* The succeedable position can be appointed by another [SITE] [AS_NEEDED] position that has just been created and filled.
* The succeedable (site or civ) position is [APPOINTED_BY] the [LAND_HOLDER] position, which has just been created due to site elevation. This typically resolves when the diplomat leaves the map, at which point the landholder position becomes active.
* If all other requirements are met, premature succession can occur immediately after unpausing following embark, for positions with [REQUIRES_POPULATION:7].

====Non-working (triggers)====
Premature succession does '''not''' occur in the following cases:
* An [AS_NEEDED] succeedable position slot is manually created by the player while its succeeding position is already filled. [AS_NEEDED] positions must always be appointed after creation.
* The succeeding position is filled after the succeedable position becomes available. The moment of creation is the decisive trigger; filling the source position later is too late.
* The succeedable position can be appointed by another site or civ position with a fixed number of slots that has just been appointed. In this case, the succeedable position is just available for appointment itself, nothing more
* Any situation occurring during world generation.
* The succeeding position is [REPLACED_BY] the succeedable position. In this case, replacement removes the unit from the source position first, leaving no holder available for the succession mechanism to use.
* The position is [APPOINTED_BY] a civ-level position, that just became a citizen of your fortress. It must be noted that those civ-level positions were active all that time and the succeedable position could be appointed even before. The monarchs arrival does not trigger premature succession
* A [SQUAD]-position cannot inherit another [SQUAD]-position. This also means that premature succession will not work in this case.

=Losing a position=

A unit can lose a position when:
* It dies
* It succeeds another position, even if it has nothing to do with the previous position.
* It is assigned to another SQUAD-holding position
* It is convicted of a crime.
* Another unit is ELECTED for the position
* It is convinced by an adventurer to give up its position, or is overthrown in a coup.
* Its position becomes replaced
* Another unit is appointed by the player, or the position is left vacant.
* It has assumed another position (of the same entity), as this always leaves the previous position vacant.

Note: A unit does not lose a position when the unit leaves the group (entity). Neither will a unit lose a position, if the corresponding entity is considered to be dead.

=Embarkment=
Two types of positions are automatically filled by embark.
* Positions without [APPOINTED_BY] or [ELECTED] (assumable). All these positions, even with a NUMBER higher than 1, are all filled with one to three dwarves. Contrary to assumption, this doesn't take into account any limitations. REJECTED_CLASS, ALLOWED_CLASS, REJECTED_CREATURE, ALLOWED_CREATURE and GENDER are applied, but without the normal spread you may expect with assumptions. Also it doesn't look at [SUCCESSION] and [SQUAD] limitations.
* Positions that are elected are filled-in by the normal election rules.

Positions that have a defined appointer are never initially filled at embark.

All positions that don't have [REQUIRES_POPULATION] or with a [REQUIRES_POPULATION] of 7 or lower, will be available at embark.

=Land Holders=

A Landholder is a '''special civ-level noble''' who gets a certain piece of land to hold, when that land is elevated to a certain level, determined by the [LAND_HOLDER] tag, and by the landholder triggers in the game's settings. In vanilla, these are the baron, the count and the duke.

A unit gaining the landholder position does not migrate to that specific named land. In world-gen, they stay just where they are, probably at the capital. In fortress mode, you can suggest a citizen for the role. So for the time being that works.

Succession is then a real issue. If you use BY_HEIR, its solved when that landholder has children living at your site. But when its not the case, the title just goes to anyone randomly. Succession BY_POSITION works, but only in the civ-chain, and there's no way to guarantee a civ-holder is at your site at that time. Even with 'automatic spread' positions, it goes to one of them randomly.

==Functioning of the regular landholder chain==

The distinct difference between a landholder and a regular civ-level noble, is that a landholder may gain the position of landholder "of (sitename)" They are then seen as ruler of a particular site.

For a land_holder position to function as such, it has a few requirements:
* NUMBER:AS_NEEDED
* The first landholder-number of 1 is defined.
* No SITE (so civ) tag in that position.
*REPLACED_BY the next level landholder
If a landholder is defined with differentiating properties, it will function like a regular noble. A higher-up landholder that lacks the required tokens or connections will then not be used in elevation.

If a fortress meets the trigger for a new LAND_HOLDER tier when a caravan leaves, then the next time the outpost liaison or equivalent arrives, they will offer to make you an official colony, which will allow you to select all positions for that LAND_HOLDER level. Each time they appear, the outpost liaison will only promote your fortress one tier up the LAND_HOLDER track.

The landholder's LAND_NAME is not required for the functioning of this system. If omitted, messages will be shown with a more generic text.

==Appointment==

This mechanism differs from the regular methods of position management. It ignores all regular appointment- and election rules, so it more or less functions like automatic assignment. A landholder is, in vanilla, appointed by the monarch. Changing this doesn't seem to do anything. If they are appointed by a site-position, a not-yet-existing civ-position, or not appointed at all: the system keeps working as usual.

A landholder can appoint civ-positions and site positions. This works as expected: the positions only are appointed then when that landholder becomes available on civ-level or when he arrives at that site for site-level positions.

If your rank of landholder is the first of its rank in the realm, and is the sole appointer of some civ-position, then immediately as it gains the title, it will appoint the empty civ-slots. This may happen on your site, but the frequency and certainty is hard to determine.

==Succession==

Succession rules are applied to some extent:
* In world-gen it works according to succession rules, and site-positions can be used here. This means that a site position or a civ-position can inherit a landholder position, and vice versa.
* In fortress mode, once a landholder has been appointed, it then can inherit civ-level positions, and vice versa. This means that your baron can become king.
* Succession rules do not apply within the [LAND_HOLDER] chain; a count will not inherit a baron's land. This is because succession does not work well with the AS_NEEDED token.
* Premature succession works in fortress mode with landholders. If a unit gets a landholder's position and that landholder is the appointer of an as yet empty position, which is defined as succeeding from a third one, then the succession is immediately applied. The landholder themselves can even be the successor of a newly created position.
* A landholder's position is, in fortress mode, not successionable by a site-position or vice versa

===Impossibilities for succession by a site-position===
It would be very beneficial if the landholder can be succeeded by a [SITE]-position. So far, the following tests have not lead to positive results:
* making landholder and site-position both non-[DUTY_BOUND]
* make the site-position be [APPOINTED_BY] the landholder and/or the monarch
* give landholder and site-position [REJECTED_CREATURE]
* Let the monarch live at your site when succession could happen.
* Let the site-position be [REPLACED_BY] the landholder.

If the vanilla [SUCCESSION:BY_HEIR]-tag is omitted, a seemingly random unit somewhere in the realm is assigned this position.

==Nomination==

The player is able to nominate a unit to become the LAND_HOLDER, but this only works with units of [LAND_HOLDER] level 1. The player can select all units, only limited by the PRECEDENCE of the current units' positions.

A unit that has a position with a PRECEDENCE lower or equal to that of the landholder's position, cannot be selected. This means that a baron (or count) from another site or the monarch cannot be selected, because their precedence is lower or equal.

The GENDER token does not work here: also units with the wrong gender (sorry) can be selected.

==Levels==
In mods, up to 10 levels of LAND_HOLDER may be defined.

If a landholder is replaced by a wrong landholder number (1 replaced by 3), then the number 3 is still correctly attached to the settlement.

If the current landholder has the highest available landholder number, then the next elevation will not happen - the diplomat will not elevate your fortress to a higher position, even if that position might be REPLACED_BY a lower landholder.

These chains do work:
* 1 -> 2a - > 2b -> 3
* 1 -> 3 -> 2 -> 4

These chains do not work:
* 2 -> 3 (need to start at 1)
* 1 -> 4 -> 2 -> 3 (stops after 4 as the highest)
* 1a -> 2, 1b -> 2 (only 1a and 2 work, 1b is not used)

==Moving landholders==

It may happen that a land-holder no longer lives at the site which they are the landholder of, specifically when the current landholder dies, leaving the title to an heir living somewhere else.

To prevent this from happening, you can make their succession from heir and make sure that their kids live at your site. Or, you can make their position succeeded by another civ position, and make it so that this civ position is somehow available on your site. But if multiple of these positions exist, it cannot be guaranteed that a citizen of your fortress will inherit the title.

In world gen, a landholder lacking the DUTY_BOUND-token will also move to the site they like, according to legends mode.

==Replacement by a generic civ-position==

If a landholder is replaced by an AS_NEEDED non-landholder civ-position, then this will work: the current landholder loses that title upon settlement-elevation and gains that civ-title. However, the civ-title lacks the landholder-property of being attached to the land. It will not show the name of the settlement alongside the position's name. So no "minister of Shovelmounts"

If a landholder is replaced by a general AS_NEEDED civ-position, that itself is also replaced by a generic AS_NEEDED civ-position, then firstly the elevation is executed and also the unit gains that new position. However, he immediately loses it, because an AS_NEEDED position that is replaced by another position can be filled initially, but units wont be able to hold that title.

==Landholder with fixed number==

A landholder's position that has a fixed number will be created and filled directly when the civilisation is born, so this position slot is then not available for the regular landholder-mechanic and will also not be used. That landholder will thus not be attached to a settlement.

It doesn't matter if the landholder's position is connected to the regular landholder's-chain with the REPLACE_BY token.

==Responsibilities==

When given a certain [RESPONSIBILITY], a landholder may function as a regular civ-level noble. If the position has [TRADE] or [OUTPOST_NEGOTIATING] responsibilities, then the landholder functions both as a diplomat and as an actual land holder. A landholder with the [MILITARY_STRATEGY] responsibility will travel around taming creatures in world-gen, according to legends mode.

Besides that, the responsibilities work the same as with any other on-site living position-holder, civ or otherwise.

=Military=
==Squad management==
In the vanilla game, the Squad interface only becomes available after a militia commander has been appointed. Until then, the window displays:{{DFtext|You must appoint somebody first to create a squad.}}

What’s surprising is how this is determined internally. In the entity raw definition, '''only the last two positions that include a [SQUAD] token are checked''' to decide whether the interface is accessible at all. As a result, if your hierarchy defines commanders A through E, appointing '''Commander D or E''' unlocks squad formation, while appointing A–C does nothing.

In other words, squad availability is not tied to ''having a militia commander'', but to ''which specific positions happen to be last in the raw list''—a notably hacky implementation.

These 'last two' are always the last two '''available positions.''' So if they get [REPLACED_BY] or become available because of [REQUIRES_POPULATION], the game adapts to those.

==Squad assignment==

Squads can be assigned, even if the leader position has no holder.

A specific unit can only have one position associated with a squad. If it gains another 'squad holding position', it is unassigned from the first one. This does not work with a 0-squad, so only 1+squads are taken into consideration. This technique can possibly be used to distribute all positions equally among all citizens. It does however not work with election and assumption.

If a civ-level position is associated with a squad and it gets a site-level squad-holding position assigned, it loses the current civ-position.

Squads can get really messed up, if you make the position (or multiple) either elected or not-elected and not-appointed, then this can cause the game to assign multiple squads to the same unit. Automatic assignment and election does not take squads into account, but the nobles screen does. This can cause the positions to be cleared as the game figures out that they have more than one position, and immediately get elected or assumed again.

Positions that cannot have a squad-position:
* A site- or civ-position with a [SUCCESSION] token cannot be appointed a squad-holding-position. The other way around, however, does work. For example, if a site-position with a [SUCCESSION]-token is appointed to a unit that has already a position with [SQUAD]. But when that squad position is assigned to another unit, it cannot be assigned back.
* A position with [SUCCESSION] can also not be assigned as a '''member''' of a squad.
* A squad-holding position with a formed squad cannot be appointed to another squad holding position.

If a position has at least one squad member, it cannot be left vacant. First, the squad has to be disbanded, then the position may be cleared.

==0-squads==
A 0-Squad is defined in a position as [SQUAD:0:member:members]. It does not seem to do anything useful as of now.
* It cannot be used to activate the [[Squad|military interface]]
* It does not restrict the assignment of [SUCCESSION] positions.
* Assigning this position does not clear any previously held squad position.
* The [[Leader]] and [[Tactician]] skill are not marked as relevant skills and are not taken into account in elections.
* It cannot be formed as a squad.

=Further testing=
The following questions may need additional testing. Feel free to add or answer
* Everything regarding COMMANDING and army-structure
** [http://www.bay12forums.com/smf/index.php?topic=175437.msg8331668#msg8331668]
** [http://www.bay12forums.com/smf/index.php?topic=165213.msg8335682#msg8335682]
** [http://www.bay12forums.com/smf/index.php?topic=174584.msg8026854#msg8026854]
* Stuff about the monarch, its arrival and its entourage.

=Oddities (Bugs)=
Almost everything on this page could be called an oddity. Because of their unexpected usability, some may also be referred to as “undocumented features.” Others, however, are simply odd and not particularly useful, yet I hesitate to call them “bugs.”
* If a certain threshold is reached that makes an elected position electable, and the triggering event that initiates this evaluation is an assumption, then the resulting assumption works partially as an election. It referred to in the messages as an election and the [REJECTED_CREATURE]-token is not applied, like it is with assumptions.

=Examples=

===The Founder===
The founder is a single dwarf, appointed at embark. They will be the only one ever to have this position and are not replaceable. When they lose their position some way, the position will not be assumed by another dwarf.
{{gamedata|title=The Founder|
[POSITION:THE_FOUNDER]
[NAME:the founder:founders]
[NUMBER:1]
[SITE]
[ALLOWED_CREATURE:DWARF:ALL] - will only be filled at embark, but not assumable later.
[REJECTED_CREATURE:DWARF:ALL] - will only be filled at embark, but not assumable later.
[SUCCESSION:BY_POSITION:THE_FOUNDER] - not unassignable, also cannot be assigned to a [SQUAD] position.
[PRECEDENCE:200]
Non APPOINTED_BY
Non ELECTED
Optional: Add responsibilities to make the game select a unit with certain skills.
}}
===Marriage bar===
Dwarven matrons are held in great honour. Upon marriage, a female dwarf is no longer expected to perform menial labour. All dwarven males hold this position by default, granting their spouses exemption from menial work.

The position becomes available with the arrival of the first migrants; otherwise, on embark, it would be assumed by females. Its succession rule is non-functional, but this prevents the player from unassigning the position. A squad size of 1 and the succession rules together prevent a unit from assuming the position more than once.

With precedence set to NONE, the position name is hidden, while LAND_NAME remains visible on the nobles screen. All married females receive the suffix “, Mrs.” and are marked as Nobles.

The practical usefulness of this position is debatable, but it serves as a clear demonstration of several mechanics.
{{gamedata|title=Mrs. Urist|

[POSITION:MRS_URIST]
[NUMBER:300]
[SITE]
[ALLOWED_CREATURE:DWARF:MALE]
Not APPOINTED_BY
Not ELECTED
[LAND_NAME:Dwarven male]
[NAME:dwarven male:dwarven male]
[PRECEDENCE:NONE]
[SPOUSE_FEMALE:, Mrs.:spouses]
[MENIAL_WORK_EXEMPTION_SPOUSE]
[REQUIRES_POPULATION:8]
[SUCCESSION:BY_POSITION:MONARCH]
[SQUAD:1:member:members]
}}
===The Archduke===
The archduke is the leader of the civilization, but exists only from landholder 4-level. Until then, its position remains vacant. When a settlement is elevated to tier 4 (grand duke), the grand duke can appoint the ruler of the civilisation, the archduke. Because of 'Premature Succession', they themself inherit that position immediately, but only when in fortress mode. Its heir then becomes grand duke.
{{gamedata|title=The Archduke| no POSITION:MONARCH or other PRECEDENCE:1

[POSITION:THE_ARCHDUKE]
[NAME:archduke:archdukes]
[NAME_MALE:archduke:archdukes]
[NAME_FEMALE:archduchess:archduchesses]
[LAND_NAME:a archduchy]
[NUMBER:1]
[PRECEDENCE:1]
[SUCCESSION:BY_POSITION:GRAND_DUKE]
[APPOINTED_BY:GRAND_DUKE]
(add additional monarch-stuff, like spouse name, demands etc.)

[POSITION:GRAND_DUKE]
[NAME:grand duke:grand dukes]
[NAME_MALE:grand duke:grand dukes]
[NAME_FEMALE:grand duchess:grand duchesses]
[NUMBER:AS_NEEDED]
[LAND_HOLDER:4]
// Optional ...
[PRECEDENCE:19]
[LAND_NAME:a archduchy]
[RESPONSIBILITY:LAW_MAKING]
[RESPONSIBILITY:RECEIVE_DIPLOMATS]
[SUCCESSION:BY_HEIR]
[APPOINTED_BY:THE_ARCHDUKE]
(add additional landholder-stuff)

!!add to [POSITION:DUKE]
[REPLACED_BY:GRAND_DUKE]

}}
{{Category|Modding}}
{{Category|Entities}}
{{Category|Guides}}

Advanced entity position mechanics

2026-09-27T14:58:53Z

Silverwing235: /* Introduction */

{{Quality|Fine}}
{{Modding}}

= Introduction =

[http://www.bay12forums.com/smf/index.php?topic=182239.0 Discussion thread on the forum]

This page documents observed and tested behavior of entity positions in ''Dwarf Fortress'', that is not fully described elsewhere on the wiki; focusing on advanced interactions between position tokens, including appointment, succession, election, and responsibility handling, across both civilization-level and site-level entities.

The mechanics described here are based on empirical testing in world generation and fortress mode, supplemented where necessary by raw analysis. In several cases, the game’s behavior is determined by evaluation order and interaction between multiple tags, rather than by individual tokens in isolation.

This page is intended for modders and advanced players who are designing or debugging custom entity position structures. It does not restate basic position mechanics, but instead highlights edge cases, non-obvious interactions, and behaviors that may appear inconsistent or undocumented.

Unless stated otherwise, the described behavior applies to current versions of the game and may differ from older releases.

==What is an entity? What is a position?==
An [[entity]] is an organizational structure that can have relationships with other entities, usually known as a [[civilization]] or a "[[site]] government" in the game, but e.g. [[merchant company|merchant companies]], [[Mercenary#Mercenary_Orders|mercenary orders]], [[guild|guilds]], [[religion|religious organizations]], bandits and necromancer towers are also entities (and necromancer towers use the same entity type as "site governments"). An entity can have positions - in most cases, these are hardcoded and generated by the game, but as for civilizations and sites, the [[raw file]]s can be customised.

A position is a special relationship between a unit and an entity. The unit holding a position has a larger influence over that entity than other citizens. Positions are mostly known as [[nobles]], but in this article. the technical term is used.

=Position levels (Site/Civ) and their interaction=
There are two basic types of positions that are customizable: '''civ(ilization)''' level and '''site level'''. Positions with the tag [SITE] are at site level, positions without the tag [SITE] are at 'civ level'. These two types of nobles can be considered '''loosely related systems'''. There are a few places where they can interact with each other.

Civ-level positions are in charge of the civilization as a whole, managing national [[trade]], laws, and [[war]]s. These are, for example, the vanilla [[monarch]], [[diplomat]] and [[general]]. (Note that the general doesn't really do anything, except creation of additional pets in world-gen for the general and possibly raising the animal training knowledge of the civilization to "general familiarity".)

'''[LAND_HOLDER]''' nobles are also positions at civ-level. These units are members of the national government, but have gained authority over some land or site. Once they do, they move to that place, but their position is still regarded as a civ-level position.

Site-level position holders are members of a site government (subsidiary to the civilization), and manage local affairs in that location. These are, for example, the [[mayor]], the [[sheriff]] and the [[broker]].

==Table of interaction between different position levels==
In this table, the possible interactions between different position levels are summarized.
The header row shows the positions defining the tokens.

The left column shows the position type that is referred to.
Example:
{| {{prettytable}}
|- bgcolor="#ddd"
! referred position-type
! LAND_HOLDER
|-
| civilization
| (baron is) APPOINTED_BY:MONARCH
|}
color coding: 
* Exists in vanilla
* Possible with mods
* Not possible
* possible to some extent.
* not yet fully investigated.
{| {{prettytable}}
|- bgcolor="#ddd"
! referred position-type
! Civilization
! SITE
! LAND_HOLDER
! CONQUERED_SITE

|-
| Civilization
| APPOINTED_BY COMMANDER REPLACED_BY SUCCESSION
| APPOINTED_BY COMMANDER REPLACED_BY SUCCESSION '''(1)'''
| APPOINTED_BY COMMANDER REPLACED_BY SUCCESSION
| APPOINTED_BY COMMANDER REPLACED_BY SUCCESSION

|-
| SITE
| APPOINTED_BY COMMANDER REPLACED_BY SUCCESSION '''(2)'''
| APPOINTED_BY COMMANDER REPLACED_BY SUCCESSION
| APPOINTED_BY '''(3)''' COMMANDER REPLACED_BY SUCCESSION '''(4)'''
| APPOINTED_BY COMMANDER REPLACED_BY SUCCESSION

|-
| LAND_HOLDER
| APPOINTED_BY COMMANDER REPLACED_BY '''(6)''' SUCCESSION
| APPOINTED_BY COMMANDER REPLACED_BY SUCCESSION '''(5)'''
| APPOINTED_BY COMMANDER REPLACED_BY '''(7)''' SUCCESSION '''(8)'''
| APPOINTED_BY COMMANDER REPLACED_BY SUCCESSION

|-
| CONQUERED_SITE
| APPOINTED_BY COMMANDER REPLACED_BY SUCCESSION
| APPOINTED_BY COMMANDER REPLACED_BY SUCCESSION
| APPOINTED_BY COMMANDER REPLACED_BY SUCCESSION
| APPOINTED_BY COMMANDER REPLACED_BY SUCCESSION
|}

Remarks:
# Works only in world-gen, if a unit with that civ-position is present at the site.
# Works only in world-gen, the site-position holding unit will then move to the capital.
# Is completely ignored
# Works only in world-gen.
# Works only in world-gen.
# Won't appear at all
# This is necessary for the landholder chain to work properly, it doesn’t work otherwise.
# This works only outside of the landholder chain, so when landholders are simply regarded as civ-level nobles. might also work in world-gen
#

== Other interactions ==

Unfortunately, interactions with positions of other entities don't seem possible, such as APPOINTED_BY: HIGH_PRIEST. With [VARIABLE_POSITIONS], positions are automatically created with codes like CUSTOM_LAW_MAKER_2, but interaction with these positions don't seem to work, either. For more info on those, see [[Variable positions]]

=General=

==Civ-level nobles living at your site==
Nobles from your civilization can come to live at your fortress. This happens in vanilla with landholders such as [[Baron]], [[Count]] and [[Duke]], with the Monarch, but sometimes also with non-landed LAND_HOLDERS.

When a civ-level noble becomes a [[citizen]] at your location, their position is shown among the site-level positions in your [[nobles screen]]. They appear to function as a site-level noble. They may have [[demand]]s, [[mandate]]s, [[squad]]s and the like. They can appoint nobles at the site-level.

Even if they have certain site related [RESPONSIBILITY]ies, they will not do the tasks that go with them.

==Fortress mode, world-gen and their differences==
Their are a few differences in how positions function between fortress mode (normal play mode) and the world generation (world-gen).

In '''fortress mode''', the player has some control over the appointment of nobles, limited by elections, automatic filled-in positions and succession rules. Pre-fortress mode, which is referred to as '''world-gen''', the game will always attempt to assign nobles whenever possible. It is subjected to the same rules as in fortress-mode, but there are some exceptions. In '''[[World activities]]''', which is the thing that happens in the world while you play fortress mode, it seems as if the same rules are applied as fortress mode.

A difference between player-fortress-mode and world-gen, is causes by visibility (see below). Positions that are not visible by the player and thus not available for assignment, will be available in world-gen and will thus be automatically assigned.

In fortress mode, a position that is both [ELECTED] and [APPOINTED_BY], cannot be appointed by the player and is also not elected, and can thus not be filled. But in world-gen sites however, these positions are automatically filled.

Positions with [AS_NEEDED] are almost never created and filled in world-gen (depending on their [RESPONSIBILITY]ies), but can always be used in player mode.

A position can, in fortress mode, be filled by the same unit. A unit can gain multiple positions in fortress mode, for example because of [[elections]]. This will not happen in world-gen mode: a unit can only have one position. See also remarks on 'embark' and 'Losing a position'.

In world-gen, [SUCCESSION] between civ-levels and [SITE-]levels may happen. This will not happen in fortress mode, or even off-site in [[World activities]].

In fortress mode, premature SUCCESSION may happen. This will not happen in world-gen mode.

==Units holding multiple positions in multiple entities==
A unit can hold multiple positions in its civilisation or in its site-entity, however in world-gen a unit will not hold multiple positions in one site-entity or in one civilisation (note that in world-gen a unit can hold multiple variable positions of the same entity, if the entity is ie. an outcast group). It is however possible - in world-gen - for a unit to hold multiple positions as long as the positions belong to different civilizations / site-entities (ie. it is possible for a militia commander of a site-entity to later on also become a monarch of the parent civilization, while staying a militia commander), if a unit holds a position of two different site-entities (the unit will usually have left one of the groups, without relinquishing the position). Only at player-managed sites can units be holding multiple positions (of the site-entity) at once. It is currently unknown, whether it is possible in world-gen for a unit to have a civ-level position in two different civilisations (but it probably is possible, as a a unit can belong to multiple civilizations and a unit usually does not relinquish a position, when the unit gets another position, as long as the entities of both positions are not the same).

In world-gen, if there are too many positions to be filled, they simply stay empty until more units are available. E.G, a unit at a site might inherit a civ-level position and still remain a member of the local government. When this happens however, they move to the capital. If a unit gains a new position, either inherited or otherwise, it drops the previous one (of that civilisation or site-entity) - the unit will not drop any positions unrelated to the entity of the new position (ie. a CUSTOM_OUTCAST_FACTOR will not relinquish that position, if the unit becomes the ruler of a civilization and a militia commander will also not necessarily relinquish the position, if the unit becomes also the monarch of the corresponding civilization). If a unit assumes a civ-position in fortress mode, it leaves the current position.

If a unit holds the same site-position multiple times, it has no additional effect.

If a unit holds multiple different positions of the same entity, it has all those positions' responsibilities and properties, stacked up. Presumably, the demands for those combined positions are determined by the highest.

A unit holding a position with a succession token can be assigned another position with a (different) succession token.

A unit holding a position with a squad-position cannot hold another squad-position. It is dropped from the first of those, when the second position is assigned.
A unit holding a position with a succession token cannot be assigned to a squad-position - the unit is simply not available. It works the other way around, though.

=Specific Tags and functions=
==[PRECEDENCE]==
The first defined position with precedence of 1 counts as the ruler of the civ. See also: [[Position_token#PRECEDENCE|PRECEDENCE]].

If the precedence is omitted or has a negative value, the game sets 0 as precedence, which seems to have no effect whatsoever. When a unit has multiple positions, the name of the position with the highest rank in precedence is shown behind the unit's name.

If you omit precedence entirely, or set it to [PRECEDENCE:NONE], the position name will not be shown after the unit’s name. Your *Urist Mason* will remain simply *Mason*. This can be useful for positions that are unimportant or purely functional. The position will also not appear in the civilisation overview of your site on the world map. The position name is shown in messages, but remains hidden on the nobles screen as well. To make it visible there, use [LAND_NAME].

==[RESPONSIBILITY]ies==
Both civ and [SITE] positions can carry responsibilities. However, not all responsibilities are active for both types: some function only for civ positions, others only for site positions. When a civ noble arrives at a site and takes up residence, they do not perform responsibilities that are intended for SITE nobles. As a result, these responsibilities neither trigger their associated tasks nor unlock related game mechanics. For example, a civ-level manager living in a fortress will not perform management duties there and doesn't unlock the management-screen, even with an assigned office.
This behavior applies to the following [SITE]-level responsibilities:
* [RESPONSIBILITY:ACCOUNTING]
* [RESPONSIBILITY:BUILD_MORALE]
* [RESPONSIBILITY:HEALTH_MANAGEMENT]
* [RESPONSIBILITY:LAW_ENFORCEMENT]
* [RESPONSIBILITY:MANAGE_PRODUCTION]
* [RESPONSIBILITY:MEET_WORKERS]
* [RESPONSIBILITY:TRADE] (functions differently)
Other responsibilities may be affected as well, but have not yet been fully tested.

===World-gen effects of the [RESPONSIBILITY] of available positions ===
It is possible to cause civs and individual sites to change their behavior substantially when they reach a certain size, by controlling nobles.
* If a site can only appoint a position with [MILITARY_GOALS] after reaching a particular size, that site will not send armies on missions until the required size is reached.
* A civ-level [LAW_MAKING] position is required for the civilization to have any kind of cohesion. Without it, sites will be constantly embroiled in territorial disputes and civil wars will be commonplace.
* [MILITARY_STRATEGY] positions go out and tame wild animals. This makes your civ gain those animals as domesticated and also brings them in sieges.
* The [[Personality_facet|Personality]] of the position's holder determines how they lead the civ.

===[DELIVERS_MESSAGES]===
The only [AS_NEEDED]-position that is created in worldgen based on responsibility is that of the site-level responsibility [DELIVERS_MESSAGES].

===Outpost Liaisons and Diplomats===
Civ-positions with the responsibility [ESTABLISH_COLONY_TRADE_AGREEMENTS] ([[Outpost_Liaison|Outpost Liaison]]s) will meet with the site-noble who has responsibility for [RECEIVE_DIPLOMATS] and the highest rank of precedence (i.e. the lowest precedence value). Usually this is the [[Expedition_leader|Expedition leader]].

Once a [LAND_HOLDER] is assigned to the site, civ-positions with the responsibility [MAKE_TOPIC_AGREEMENTS] ([[Diplomat]]s) will meet with '''civ'''-level nobles present at the site who have the [RECEIVE_DIPLOMATS] responsibility. If multiple eligible nobles are available, one is selected at random. If no eligible noble is present, the diplomat leaves angrily. If the landholder is no longer present at the site, diplomats will not arrive at all.

It appears that Outpost Liaisons and Diplomats are chosen for a diplomatic mission based on availability. When multiple candidates exist, the position defined last in the raws is most often selected.

===[TRADE]===
Civ-level nobles with [TRADE] will arrive with the caravan, just as the Outpost Liaison. Their behavior is no longer active in the vanilla game, but the mechanics are still present. See [[40d:Guild_representative|Guild representative]] for more details. This civ-noble will only meet with the SITE noble with [TRADE], usually the [[Broker]].

If two civ-nobles exist with both [TRADE] and [ESTABLISH_COLONY_TRADE_AGREEMENTS], they both arrive at the same time. Even if both tokens are assigned to a single position, if more than one instance of that position exists, two of them will arrive. However in that case, somehow the elevation of the site and appointment of landholder isn't offered.

If the SITE-noble they intend to meet has both [TRADE] and [RECEIVE_DIPLOMATS], only one meeting will proceed and the other is cancelled. However, when two SITE-nobles are available, each with either [TRADE] or [RECEIVE_DIPLOMATS], both meetings will proceed and both civ-nobles will attempt to negotiate a trade agreement. It is not known what happens if these agreements are accepted or refused.

In the trade depot, the last defined position with the [TRADE] responsibility is shown as broker. However when requesting a trader, the first defined position with [TRADE] will actually go there to do the trade.

==[NUMBER]==
A position might be defined with a number. In that case, as many as defined can be available. If the positions become available in world-gen and when embarking, they are all filled in completely.

If the ruling position (with PRECEDENCE of 1) has a NUMBER higher than 1, a random unit of the ones holding these positions is shown as ruler in the embark screen.

A [NUMBER] of 0 (zero) has the same effect as 1.

===Automatic spreading of assumed, non-singular positions===
If there are civ positions that have a NUMBER higher then '1' and which are assumed (not APPOINTED_BY or ELECTED) but are '''not DUTY_BOUND''', these are automatically spread among the civilisation, based on population. If there are a number of '''20''' available slots of that position, they spread among a civilization with a combined population of, for example, 1000 of which your fortress has 100 (10%), '''2''' of your fortress' citizens will assume that position.
This may probably also work with elected and appointed positions, but that may be depending on the death of the current holders and this needs more testing. Assumption works within a day, anyway.

===[AS_NEEDED]===
These positions can be created automatically by the game in worldgen. This, however, only works with:
* [LAND_HOLDER]'s
* squad commanders (needs more testing)
* Messengers at sites

For all other types of positions, they're not created in worldgen; even if defined with RESPONSIBILITY's. For example, even in war, the game wouldn't create a MILITARY_GOALS position if they have AS_NEEDED as a number. However, in fortress mode / player mode, these positions can be created by the player at will.

Positions with AS_NEEDED need to be created first, before any symbols are assignable as 'symbols' (objects) for the position holder to carry or wear, but they cannot be created and then ELECTED in fortress mode - that only works with APPOINTED_BY.

==[REPLACED_BY], [REQUIRES_POPULATION], [REQUIRES_MARKET]==

The token [REPLACED_BY:position] means that once the replacing position meets its requirements for activation, the 'to-be-replaced' position will disappear. This is defined in [REQUIRES_POPULATION] or [REQUIRES_MARKET]. The tags are closely related to each other and seem to only have a meaningful function if combined. Nobles with [REQUIRES_POPULATION] require the population to have a specific size. Nobles with [REQUIRES_MARKET] are only activated in market sites, such as fortresses or towns. [REQUIRES_POPULATION] and [REQUIRES_MARKET] can be combined, activating that position once both requirements are met.

The [REQUIRES_MARKET] can be used to differentiate positions between hamlets and hillocks, and larger sites. IThe market always is build the year after the site is founded. So a position that is to be replaced, will be gone immediately.

The [REQUIRES_POPULATION]-tag works on the civ-level as well as on site-level, but those systems are in this mechanic strictly separated. Site-level positions cannot be replaced by civ-level positions and visa versa. This makes sense, because they both depend on their own population-count. When using REQUIRES_POPULATION on civ-level, it counts the total population of the civilisation.

See also: [[Advanced_entity_position_mechanics#Evaluation_of_Positions|Evaluation of positions]]

===Effect of replacement (and on [LAND_HOLDER]s)===

Replacement is immediate and complete - the current holding unit loses the position, even before SUCCESSION_BY_POSITION rules are applied. A position with a number of 1 will replace all the slots of a position with a higher number of slots.

Even if the next position is available but not visible, replacement still takes place. If a position is replaced, it is completely gone - it cannot be appointed, succeeded, elected or assumed any longer.
The unit immediately loses its position.

In legends, replacement is mentioned as: "(unit name) ceased to be (position name)" The replacement of an AS_NEEDED position empties the position's slot forever. In fortress mode, it may seem as if you can create new slots and appoint new units in the nobles screen, but this is reversed as soon as you close the window.

The landholder chain uses [REPLACED_BY] differently. It does not clear the position completely, but uses it for succession to the next level's position. [REPLACE_BY] is required to let that system work properly. This also means that the way in which landholders succeed (replace + as_needed) does not work in any other way.

Replacement between LAND_HOLDERS and other site- or civ positions does not work in any way. Only the vanilla replacement sequence between levels of LAND_HOLDERs does work. If the token is omitted for landholders, the landholder chain is broken, so replacement is required for the landholder system to work.

[REQUIRES_POPULATION] also does not work for [LAND_HOLDER], when you set [NUMBER] to 1. The position is not created when the required population is reached.

===What doesn't work===

'''Attention: If a position cannot be appointed, for example because of 'mutual appointment', it still exists according to replacement mechanics and will replace other positions if so defined. If a certain position(a) will be replaced by the baron's assistant, which can only be appointed by the [LAND_HOLDER] baron, than that position(s) still will be replaced from the start of the game, even if no baron or their assistant is ever present.'''

A position that is replaced by a somehow non-fillable position is still replaced. This counts for mutual-appointing positions, replacement by not-yet-assigned landholders, replacement by AS_NEEDED positions, or replacement by not-yet-appointed positions.

Replacement does not work if the replaced position is a [LAND_HOLDER], even with civ-positions. In that case, the LAND_HOLDER's position is not replaced. It does not matter if AS_NEEDED is used, or a fixed number, and it also does not matter what type of position the replacer is. So this only works (correctly) with positions that become available by REQUIRES_POPULATION.

==[CONQUERED_SITE]==

This tag determines which position is used to assign a [[Forced administrator]].

In legends mode, this is visible as an event describing the reconquest of the site: a new group is formed and the forced administrator is installed as its ruler.

All positions defined with this tag are assigned during this process, meaning multiple positions can be appointed at once.

The holder of a position marked with [CONQUERED_SITE] cannot appoint any other [SITE] positions, unless the civilization has site variable positions, in which case the forced administrator can appoint such site variable positions (allthough the variable positions for that site need to be created first and such creation only happens during world-gen, but not normal world activities).

Combining [CONQUERED_SITE] with [SITE] causes the position to function both as a forced administrator and as a normal site position available in fortress mode. However, this provides no meaningful additional mechanics and is effectively inferior to using [SITE] alone:
* [APPOINTED_BY] lines are completely ignored, meaning that the roles are automatically assumed.
* [SUCCESSION] is likewise ignored.
* the [CONQUERED_SITE]-position cannot appoint other [CONQUERED_SITE], [SITE] or combined positions.

There have been remarks that reclaiming a fortress is unplayable because of the lack of regular nobles. Unfortunately, it seems that it can't be fixed by modding.

=Availability and visibility=
==Availability of (new) positions==
Warning: Do not mistake "availability" for "visibility"!

Of all the possible positions existing in your site's entity, there may only be some available.
* Positions with [REQUIRES_POPULATION] require the population to have a specific size.
* Positions with [REQUIRES_MARKET] will only appear in "large" sites (which may have different rules for different site types). This tag has no effect in fort mode.
* Positions that are appointed by positions that have an AS_NEEDED number. The appointable positions only become available after an appointer position-slot is created. This works also on civ-level. If a position is appointed by a Land-holder, it only becomes available, when that level of landholder is created.

Only the replaced positions are culled and are no longer available.
A position that requires a certain population will become available, even if it doesn't have [APPOINTED_BY] or [ELECTED]. In that case, see 'automatic assignment' and 'assumption'

In fortress mode, in some cases 'succession' is evaluated immediately after a position becomes available. See: Succession.
==Visibility of positions==
A position might be available, but can still be invisible for the player in the [[nobles screen]]. The positions with their respective holders are visible for players:
* All site-positions that are already filled-in (even if they could not be re-filled-in considering current conditions)
* Site positions that are appointable by a filled-in site position
* Site positions that are appointable by a filled-in civ position, when that civ positions holder becomes a citizen of your fortress.
* Civ positions of units that are also a citizen of your fortress.
If a position becomes available, for example because a certain pop number has been reached, or if it is available from the start(like expedition leader), as long as it cannot be appointed, it still is INVISIBLE for the player.

It might strike someone as odd if a position becomes filled automatically in fortress mode when that position is not even visible. This might be the case if the current holder of a non-appointable position dies or succeeds another position. Regardless of player visibility, these positions will be automatically filled in if the necessary requisitions are met. It might happen with the expedition leader.

A situation with a non-visible but available position, is for example when a position is solely appointed by the expedition leader, when the expedition leader's position is left vacant. It can no longer be appointed by the player and is invisible. Then, it gets automatically assumed, proving that the position still was available.

A position that is both [APPOINTED_BY] and [ELECTED] is visible, but players cannot interact with it.

={{text anchor|Evaluation of Positions}}=
The game does not continuously check whether positions should become available, elected or be [REPLACE_BY]. This is well-known behavior—for example with the [[mayor]], who does not appear automatically when the required population ([REQUIRES_POPULATION]) is reached. Instead, positions must somehow be evaluated. This applies in several other situations as well

'''Cases that require a trigger:'''
* Election of a newly created position
* Election after the current holder dies
* Automatic assumption of a newly created position (this may take up to a day)
* New citizens (such as migrants) considering available positions
* Premature succession of a newly created position

'''Cases that do not wait for a trigger:'''
* Succession following the death of the previous holder
* Automatic assumption of existing positions that have become vacant

'''Triggers that cause the game to reevaluate noble positions:'''
* Succession of a [SITE]-position due to the death of the current holder
* [[Advanced_entity_position_mechanics#Election_Day|Election Day]]
* Automatic assumption of a [SITE]-position that becomes vacant
* (Re)assigning any site position manually
* Settlement elevation on the LAND_HOLDER track (e.g. gaining a [[Baron]] or [[Count]])

=Gaining a position=
There are several ways a unit can gain a position:
* Appointment: A unit is appointed by another unit or by the player.
* Election: A unit is elected by and among the members of the entity
* Assumption: A position is neither elected or appointed: a random unit just simply 'takes' the position
* Succession: a unit is the valid successor of this position(A), either by its current position(B) or because they are that position(A)-holder's heir.

Available positions will automatically be assigned to a random civ member when a new site/civ is created.

==Who can take a position==

* If so defined, a unit needs to be the right caste and/or class - it does not seem to work with creature types.
* The unit needs to be an adult member of the site or its parent civ's government; that is also CAN_LEARN or INTELLIGENT (SLOW_LEARNER cannot take positions) or otherwise is able to think.

==Appointment==

Positions that have an [APPOINTED_BY:position] token require that position to exist, to be available and appointed. Any position that is APPOINTED_BY can be appointed if the appointer's position is filled in.
For site-positions to be appointed, it is required that the appointer is present at that location.

If the appointing unit is temporarily not present, or if that position is not filled, positions depending on it cannot be appointed. This is the case with [[militia captains]], when the [[militia commander]] is on a [[mission]].

A site position cannot appoint a civ position ''or'' LAND_HOLDER in any way whatsoever.

Civ-level positions can appoint other civ-level positions and site-level positions can appoint other site-level positions.

Contrary to what has been said elsewhere, civ-level nobles also can appoint site-level nobles. They need to be at the site to do so. Landholders can appoint both site-level and civ-level nobles. These systems are therefore not as separate as was assumed.

'''Mutual appointment''' cannot take place. If these are the only requisites of the position, then the positions will never appear or get filled. These unfillable positions can be put to good use, for example, to replace a position that is no longer needed without creating a new one.

'''Self appointment''' doesn't normally work. If you have a position that is only appointed by itself, it is never appointed and also cannot be assumed. However, if the position has a number higher than 1, and is filled by multiple units (for example by another position that is now empty), than those units can re-assign or appoint each other from that their shared position.

If an APPOINTED_BY token refers to a non-existing position's code, the effects are as if the appointment token doesn't exist at all.

===Automatic appointment in world-gen and on the civ level===

Outside of fortress mode, the game will always attempt to appoint nobles whenever possible, as long as these positions are '''available''', even if they are invisible to the player.
It shows this message in legends: "(unit name) has been appointed to the position of (position name)"

In world-gen, all positions become available and are automatically appointed, taking population- and appointment-requirements into consideration.

Positions that are REPLACED_BY are culled and won't be filled.

If a citizen of your fortress holds a civ-level position that can appoint another civ-level position, the appointment will happen automatically and without player intervention. It may happen that another citizen of your fortress is appointed by that unit, creating civ-level position holders in your fortress, but it is unknown what is required to force this effect.

===Manual appointments by players in fortress mode===
In fortress mode, the positions that need to be appointed stay empty on embark. and it is the player's job to appoint those. A player can appoint a unit to any available position, according to the hereabove mentioned conditions. The player takes the role of the automatic appointment-system, but has no direct control over elections, successions and replacement. There are some differences in what is possible at world-gen sites and at player-controlled sites.

* A position that is appointed by a unit present as a fortress citizen, can be appointed, re-appointed or left vacant. This means also by civ-level nobles living as a citizen in your fortress; not when they are only visiting, like the diplomat.
* A position whose appointing positions are all either vacant or [REPLACED_BY] can no longer be appointed. If the position is already filled, it cannot be reappointed or vacated; the current holder simply remains in office.
* A position that is APPOINTED_BY a unit present as the land_holder of your site, can be appointed, reassigned or left vacant.
* A position that has SUCCESSION BY_HEIR or BY_POSITION can 'initially' be appointed and also re-appointed or left vacant, but as soon as the [[nobles]] screen closes, ''it can no longer be replaced or left vacant''. From then on, the succession-rules determine who gains that position when the current holder loses the position. This works even if the SUCCESSION:BY_POSITION-position is vacant or replaced.
* A position that is ELECTED nor APPOINTED_BY, can always be (re-)appointed by the player. This is the case with the [[Expedition leader]]. If it is left vacant however, it cannot be appointed, but will be assumed shortly after.
* A position that is both ELECTED and APPOINTED_BY, cannot be appointed by the player. Contrary to world-gen sites, its slot is visible, but it doesn't show the +-sign. This is either by AS_NEEDED or by a fixed number. Even if the position somehow gets filled (re)assignment is never possible
* A player can appoint a number of units to a position, as much as the NUMBER token dictates. If it is AS_NEEDED, the player may create as many slots as they like, also contrary to world-gen sites.
* A civ-position can never be appointed, even if the appointing civ noble is a citizen of your fortress. A civ position also never can be re-assigned or left vacant, would that position be defined as appointed by a site-position.

==Election==
Read more in [[Elections]]. The message that is shown is: "(creature name) has been elected to the position of (position name)"

In worldgen, there is no functional difference between ELECTED and non-appointment, except that elected nobles tend to have high social skills and/or skills related to the position, while non-elected ones are assigned randomly. See: [[Elections]]

A succession goes before an election.

A position that is both ELECTED and APPOINTED_BY never gets elected. Even if the appointees' position somehow gets filled, (re)-elections won't happen. So, it doesn't seem possible to have an elected position become available when a certain other position becomes filled.

An ELECTED civ-(or LAND_HOLDER) position at your site will never be (re)-elected in fortress mode. So real (re-)election only works with SITE-positions.

=== {{text anchor|Election Day}} ===
Election Day takes place on the 17th of Summer. On this day, a full reevaluation is performed, including all currently elected positions, which are subject to re-election. Contrary to the information on [[Elections]], nothing occurs at the start of a season.

Positions that are both [APPOINTED_BY] and [ELECTED] will not be re-elected on Election Day when assigned through [SUCCESSION].

=== Election Eligiblity ===
Any citizen may stand for election. Eligibility cannot be restricted using [ACCEPTED_CREATURE], [REJECTED_CREATURE], [ACCEPTED_CLASS], [REJECTED_CLASS], or [GENDER]. Units currently having a [SUCCESSION]-position even may be elected for a position with a [SQUAD]-token, which is otherwise impossible to assign or even succeed.

=== Skills ===
In elections, skills are taken into account for the tokens of the position which is elected.
{| class="wikitable"
|+ Relevant skills per position token
|-
! Position Token !! Relevant skills
|-
| Responsibility [[Position_token#DELIVER_MESSAGES|[DELIVER_MESSAGES]]] || [[Ambusher]], [[Observer]] and [[Social_skill|Social skills]]
|-
| Responsibility [[Position_token#ACCOUNTING|[ACCOUNTING]]] || [[Record_keeper|Record keeper]]
|-
| Responsibility [[Position_token#ESPIONAGE|[ESPIONAGE]]] || [[Schemer]]
|-
| Responsibility [[Position_token#HEALTH_MANAGEMENT|[HEALTH_MANAGEMENT]]] || [[Diagnostician|Diagnostician]]
|-
| Responsibility [[Position_token#MAKE_INTRODUCTIONS|[MAKE_INTRODUCTIONS]]] || [[Social_skill|Social skills]]
|-
| Responsibility [[Position_token#MAKE_PEACE_AGREEMENTS|[MAKE_PEACE_AGREEMENTS]]] || [[Social_skill|Social skills]]
|-
| Responsibility [[Position_token#MAKE_TOPIC_AGREEMENTS|[MAKE_TOPIC_AGREEMENTS]]] || [[Social_skill|Social skills]]
|-
| Responsibility [[Position_token#MANAGE_PRODUCTION|[MANAGE_PRODUCTION]]] || [[Organizer]]
|-
| Responsibility [[Position_token#MEET_WORKERS|[MEET_WORKERS]]] || [[Social_skill|Social skills]]
|-
| Responsibility [[Position_token#RECEIVE_DIPLOMATS|[RECEIVE_DIPLOMATS]]] || [[Social_skill|Social skills]]
|-
| Responsibility [[Position_token#RELIGION|[RELIGION]]] || [[Social_skill|Social skills]]
|-
| Responsibility [[Position_token#TAME_EXOTICS|[TAME_EXOTICS]]] || [[Animal_trainer|Animal trainer]]
|-
| Responsibility [[Position_token#TRADE|[TRADE]]] || [[Social_skill|Social skills]] and [[Appraiser|Appraiser]]
|-
| [[Position_token#SQUAD|[SQUAD]]]-token || [[Tactician]] and [[Leader]]
|}

==Assumption==

A position that is not APPOINTED_BY nor ELECTED, or is appointed by positions that are not available in your site or civ, will be assumable by a random dwarf. If it has responsibilities that require certain skills, then these are taken into consideration on embark, but not when the position is assumed during the actual game.

Normally, one to three units will take the into consideration to assume a position. Most of the time when there are multiple open positions, only a single unit will assume all of them. However, a position that has REJECTED_CREATURE, REJECTED_CLASS, ALLOWED_CREATURE or ALLOWED_CLASS will be filled with all different units, even if the creature or class mentioned is irrelevant. It seems that this forces the game to loop over all the available units.

The message that is shown in Legends mode is: "(unit name) has assumed the position of (position name)". This may also take place in fortress mode, which then shows this message to the player.

If an assumable position becomes empty, it will be assumed within a day. This is the case when you leave the position of expedition-leader vacant. It also happens with entities.

Assumable positions that become empty will not be assumed if that position has a valid [SUCCESSION] -successor. In that case, the successor inherits the position.

Even positions that are somehow invisible because they cannot be directly APPOINTED_BY players, can be assumed.

When you embark, the assumable positions are automatically assigned to a random unit. If there are multiple of these positions at embark, they all are assigned to the same unit. If there are enough positions available, multiple units may gain a position, but often no more than three different ones.

If a dwarf in fortress mode assumes a position, that already has another position, it will leave the current position empty. When that position also is assumed, then this will continue until all positions have a dwarf appointed to them, with no other position.

A unit that already has a position with a [SUCCESSION] token won't take assumable positions into consideration that have a [SQUAD] token. This can be used by the modder to prevent unwanted loss of current positions.

A position that has an appointer which got replaced because of REPLACED_BY, will not become assumable. Also, positions that have an AS_NEEDED appointer that is not yet filled (or ever), will also not be assumed.

==Succession==

If a position-holder dies or advances to a new position via succession, the position will be granted to another unit based on the [SUCCESSION] tag. If they have an heir or the succeeding position exists, that unit will be assigned. If not, a new one will be appointed according to the usual rules. The message that is shown is: "(creature name) being the rightful heir, has inherited the position of (position name)"

The succeeding creature will also lose its previous position. When succession is defined using BY_POSITION, the unit naturally loses the referenced position. However, it also loses any other positions it may hold. If a unit could simultaneously inherit multiple positions, the last-defined succession overrides the earlier one, clearing the previously acquired position

Succession works both at site-level and at civ-level, both in world-gen and in fortress-mode. Succession by position on the civ-level is also visible and functional in fortress-mode. If both civ-level nobles are a citizen of your fortress, succession is applied visually. Vanilla example: The [[druid]] is succeeded by the [[acolyte]]. This means that as soon as the druid dies, the acolyte takes over.

When a position that is succeeded by position becomes available, immediately it is checked if a position-successor is available and the position is filled with that unit. Even if this is an [ELECTED] position, succession goes first. When elections eventually do happen, succession plays no role.

It is possible to assign multiple levels of [SUCCESSION:BY_POSITION] in different positions, creating a line of positions where the death of one causes all those "below" them to advance.

A position can have multiple tokens with position-succession. It looks to be random which one is used. It is not always:
* The first or last defined token
* The first or last appointed unit
* the oldest or youngest
* one with a higher or lower precedence
* a unit with relevant skills

When a position is defined with a Succession-type, that unit cannot have another position that has a Squad-type. If the succession-position itself has a squad, than it can be assigned another position with a squad, but then it will loose the previous succesion position. See further details by "Squad"

Assumed positions can also be succeeded by position, if the current holder dies.

If the successor is an AS_NEEDED position, the used unit will leave a vacant position-slot on its removal by succession. This empty slot remains a real slot, which will only be cleaned up if you (un)appoint a unit to this position-series. It isn't cleaned up after regular position validation.

A civ-level position of a unit living at your site might be inherited by a unit holding that does not currently live at your site. This, unfortunately, moves that position to a unit off site. This may also happen with the landholder of your site, for example when it is succeeded by another civ-level position. This currently poses an unsolved challenge.

===Eligibility for succession===
Succession is restricted by the tokens [ACCEPTED_CREATURE], [REJECTED_CREATURE], [ACCEPTED_CLASS], [REJECTED_CLASS] and [GENDER].

===Site and civ combined succession===

Succession can work when combining site positions with civ-level positions or land_holders, but only in world-gen mode. In fortress mode, it only works with combining the same level of nobles, with Landholders regarded as civ-level. So, in fortress mode, a site's position cannot succeed a landholder's position and it cannot succeed another type of civ-level position, and vice versa.

This won't work even if the positions:
* are AS_NEEDED or having a fixed number.
* Are LAND_HOLDERs.

===Succession [BY_HEIR]===

When a heir is needed for succession, all children and then other relatives are validated. They cannot take the position if their status does not allow it, for example if they have become a member of another civilisation. See: "Who can take a position". If the unit has no valid heir on that location, the position may go to a unit living on another site. This may cause the title of Landholder of some land to be inherited by a unit living somewhere else. That might be a problem, because then you lose your landholders.

===Premature Succession===

There are cases where [SUCCESSION:BY_POSITION] is applied prematurely: at the moment a position is first created and becomes appointable or assumable, rather than after a current holder leaves. In this situation, the succession mechanism assigns a holder immediately, without any player interaction.

When a position becomes available for the first time, the game checks whether a valid successor-by-position exists. If so, that unit is assigned instantly. It can affect positions that would normally be appointed or elected by the player, causing succession to trigger before the player has any opportunity to intervene.

This behavior occurs only in Fortress mode, but can be applied both on [SITE]-positions as well in civ-positions. That last one however is a bit harder to control. Example: [[Advanced entity position mechanics#The Archduke|The Archduke]]

This premature succession only occurs the first time a position becomes available (i.e. when it is created and becomes appointable or assumable). Even if the position remains vacant and the conditions for succession improve later, premature succession will not trigger again. From that point onward, only normal succession rules apply.

Using premature succession, a position that has [ELECTED], [APPOINTED_BY], or both, can be filled directly.
Notably, positions that combine [ELECTED] and [APPOINTED_BY] are normally impossible to fill through regular mechanics. Premature succession bypasses both election and appointment entirely, making this combination uniquely reachable through this mechanism.

No initial election takes place, and no subsequent elections will ever occur for that position. Succession always takes precedence over election, both in premature succession and in normal succession cases.

This behavior applies only in Fortress mode, not during world generation. World-gen uses simplified and more efficient mechanics, and this interaction does not occur there. Premature succession can affect both site-level and civilization-level positions.

====Multiple succession chains====

Multiple succession chains may be defined and are resolved in the order they appear in the raws.

If a position has both:
* a direct succession chain (A → C), and
* a multi-step chain (A → B → C),

and intermediate positions are vacant, resolution proceeds according to raw order. A common outcome is:
# The direct succession (A → C) is applied first, assigning A to C.
# The remaining chain then advances (A → B).
# If C still has empty slots, the final step (B → C) may occur.

If position B is already filled, behavior depends entirely on raw definition order:
* nothing may happen, or
* B may move to C first, followed by A moving to B.
====Working triggers====
Premature succession is triggered when a succeedable position is created under the following conditions:
* The succeedable position is created because its [REQUIRES_POPULATION] threshold is reached. This applies even if the position is not [APPOINTED_BY]. Premature succession takes priority over automatic assumption (e.g. the mayor declaring themselves within a day).
** The position must either be assumable or appointed by an existing position. When said appointer-position also just has been created, the premature succession of the succeedable position happenes, even when the appointer-position is empty.
* The succeedable position can be [APPOINTED_BY] another position of the same level (site or civ) that has just been created because its [REQUIRES_POPULATION] was reached.
* The succeedable position can be appointed by another [SITE] [AS_NEEDED] position that has just been created and filled.
* The succeedable (site or civ) position is [APPOINTED_BY] the [LAND_HOLDER] position, which has just been created due to site elevation. This typically resolves when the diplomat leaves the map, at which point the landholder position becomes active.
* If all other requirements are met, premature succession can occur immediately after unpausing following embark, for positions with [REQUIRES_POPULATION:7].

====Non-working (triggers)====
Premature succession does '''not''' occur in the following cases:
* An [AS_NEEDED] succeedable position slot is manually created by the player while its succeeding position is already filled. [AS_NEEDED] positions must always be appointed after creation.
* The succeeding position is filled after the succeedable position becomes available. The moment of creation is the decisive trigger; filling the source position later is too late.
* The succeedable position can be appointed by another site or civ position with a fixed number of slots that has just been appointed. In this case, the succeedable position is just available for appointment itself, nothing more
* Any situation occurring during world generation.
* The succeeding position is [REPLACED_BY] the succeedable position. In this case, replacement removes the unit from the source position first, leaving no holder available for the succession mechanism to use.
* The position is [APPOINTED_BY] a civ-level position, that just became a citizen of your fortress. It must be noted that those civ-level positions were active all that time and the succeedable position could be appointed even before. The monarchs arrival does not trigger premature succession
* A [SQUAD]-position cannot inherit another [SQUAD]-position. This also means that premature succession will not work in this case.

=Losing a position=

A unit can lose a position when:
* It dies
* It succeeds another position, even if it has nothing to do with the previous position.
* It is assigned to another SQUAD-holding position
* It is convicted of a crime.
* Another unit is ELECTED for the position
* It is convinced by an adventurer to give up its position, or is overthrown in a coup.
* Its position becomes replaced
* Another unit is appointed by the player, or the position is left vacant.
* It has assumed another position (of the same entity), as this always leaves the previous position vacant.

Note: A unit does not lose a position when the unit leaves the group (entity). Neither will a unit lose a position, if the corresponding entity is considered to be dead.

=Embarkment=
Two types of positions are automatically filled by embark.
* Positions without [APPOINTED_BY] or [ELECTED] (assumable). All these positions, even with a NUMBER higher than 1, are all filled with one to three dwarves. Contrary to assumption, this doesn't take into account any limitations. REJECTED_CLASS, ALLOWED_CLASS, REJECTED_CREATURE, ALLOWED_CREATURE and GENDER are applied, but without the normal spread you may expect with assumptions. Also it doesn't look at [SUCCESSION] and [SQUAD] limitations.
* Positions that are elected are filled-in by the normal election rules.

Positions that have a defined appointer are never initially filled at embark.

All positions that don't have [REQUIRES_POPULATION] or with a [REQUIRES_POPULATION] of 7 or lower, will be available at embark.

=Land Holders=

A Landholder is a '''special civ-level noble''' who gets a certain piece of land to hold, when that land is elevated to a certain level, determined by the [LAND_HOLDER] tag, and by the landholder triggers in the game's settings. In vanilla, these are the baron, the count and the duke.

A unit gaining the landholder position does not migrate to that specific named land. In world-gen, they stay just where they are, probably at the capital. In fortress mode, you can suggest a citizen for the role. So for the time being that works.

Succession is then a real issue. If you use BY_HEIR, its solved when that landholder has children living at your site. But when its not the case, the title just goes to anyone randomly. Succession BY_POSITION works, but only in the civ-chain, and there's no way to guarantee a civ-holder is at your site at that time. Even with 'automatic spread' positions, it goes to one of them randomly.

==Functioning of the regular landholder chain==

The distinct difference between a landholder and a regular civ-level noble, is that a landholder may gain the position of landholder "of (sitename)" They are then seen as ruler of a particular site.

For a land_holder position to function as such, it has a few requirements:
* NUMBER:AS_NEEDED
* The first landholder-number of 1 is defined.
* No SITE (so civ) tag in that position.
*REPLACED_BY the next level landholder
If a landholder is defined with differentiating properties, it will function like a regular noble. A higher-up landholder that lacks the required tokens or connections will then not be used in elevation.

If a fortress meets the trigger for a new LAND_HOLDER tier when a caravan leaves, then the next time the outpost liaison or equivalent arrives, they will offer to make you an official colony, which will allow you to select all positions for that LAND_HOLDER level. Each time they appear, the outpost liaison will only promote your fortress one tier up the LAND_HOLDER track.

The landholder's LAND_NAME is not required for the functioning of this system. If omitted, messages will be shown with a more generic text.

==Appointment==

This mechanism differs from the regular methods of position management. It ignores all regular appointment- and election rules, so it more or less functions like automatic assignment. A landholder is, in vanilla, appointed by the monarch. Changing this doesn't seem to do anything. If they are appointed by a site-position, a not-yet-existing civ-position, or not appointed at all: the system keeps working as usual.

A landholder can appoint civ-positions and site positions. This works as expected: the positions only are appointed then when that landholder becomes available on civ-level or when he arrives at that site for site-level positions.

If your rank of landholder is the first of its rank in the realm, and is the sole appointer of some civ-position, then immediately as it gains the title, it will appoint the empty civ-slots. This may happen on your site, but the frequency and certainty is hard to determine.

==Succession==

Succession rules are applied to some extent:
* In world-gen it works according to succession rules, and site-positions can be used here. This means that a site position or a civ-position can inherit a landholder position, and vice versa.
* In fortress mode, once a landholder has been appointed, it then can inherit civ-level positions, and vice versa. This means that your baron can become king.
* Succession rules do not apply within the [LAND_HOLDER] chain; a count will not inherit a baron's land. This is because succession does not work well with the AS_NEEDED token.
* Premature succession works in fortress mode with landholders. If a unit gets a landholder's position and that landholder is the appointer of an as yet empty position, which is defined as succeeding from a third one, then the succession is immediately applied. The landholder themselves can even be the successor of a newly created position.
* A landholder's position is, in fortress mode, not successionable by a site-position or vice versa

===Impossibilities for succession by a site-position===
It would be very beneficial if the landholder can be succeeded by a [SITE]-position. So far, the following tests have not lead to positive results:
* making landholder and site-position both non-[DUTY_BOUND]
* make the site-position be [APPOINTED_BY] the landholder and/or the monarch
* give landholder and site-position [REJECTED_CREATURE]
* Let the monarch live at your site when succession could happen.
* Let the site-position be [REPLACED_BY] the landholder.

If the vanilla [SUCCESSION:BY_HEIR]-tag is omitted, a seemingly random unit somewhere in the realm is assigned this position.

==Nomination==

The player is able to nominate a unit to become the LAND_HOLDER, but this only works with units of [LAND_HOLDER] level 1. The player can select all units, only limited by the PRECEDENCE of the current units' positions.

A unit that has a position with a PRECEDENCE lower or equal to that of the landholder's position, cannot be selected. This means that a baron (or count) from another site or the monarch cannot be selected, because their precedence is lower or equal.

The GENDER token does not work here: also units with the wrong gender (sorry) can be selected.

==Levels==
In mods, up to 10 levels of LAND_HOLDER may be defined.

If a landholder is replaced by a wrong landholder number (1 replaced by 3), then the number 3 is still correctly attached to the settlement.

If the current landholder has the highest available landholder number, then the next elevation will not happen - the diplomat will not elevate your fortress to a higher position, even if that position might be REPLACED_BY a lower landholder.

These chains do work:
* 1 -> 2a - > 2b -> 3
* 1 -> 3 -> 2 -> 4

These chains do not work:
* 2 -> 3 (need to start at 1)
* 1 -> 4 -> 2 -> 3 (stops after 4 as the highest)
* 1a -> 2, 1b -> 2 (only 1a and 2 work, 1b is not used)

==Moving landholders==

It may happen that a land-holder no longer lives at the site which they are the landholder of, specifically when the current landholder dies, leaving the title to an heir living somewhere else.

To prevent this from happening, you can make their succession from heir and make sure that their kids live at your site. Or, you can make their position succeeded by another civ position, and make it so that this civ position is somehow available on your site. But if multiple of these positions exist, it cannot be guaranteed that a citizen of your fortress will inherit the title.

In world gen, a landholder lacking the DUTY_BOUND-token will also move to the site they like, according to legends mode.

==Replacement by a generic civ-position==

If a landholder is replaced by an AS_NEEDED non-landholder civ-position, then this will work: the current landholder loses that title upon settlement-elevation and gains that civ-title. However, the civ-title lacks the landholder-property of being attached to the land. It will not show the name of the settlement alongside the position's name. So no "minister of Shovelmounts"

If a landholder is replaced by a general AS_NEEDED civ-position, that itself is also replaced by a generic AS_NEEDED civ-position, then firstly the elevation is executed and also the unit gains that new position. However, he immediately loses it, because an AS_NEEDED position that is replaced by another position can be filled initially, but units wont be able to hold that title.

==Landholder with fixed number==

A landholder's position that has a fixed number will be created and filled directly when the civilisation is born, so this position slot is then not available for the regular landholder-mechanic and will also not be used. That landholder will thus not be attached to a settlement.

It doesn't matter if the landholder's position is connected to the regular landholder's-chain with the REPLACE_BY token.

==Responsibilities==

When given a certain [RESPONSIBILITY], a landholder may function as a regular civ-level noble. If the position has [TRADE] or [OUTPOST_NEGOTIATING] responsibilities, then the landholder functions both as a diplomat and as an actual land holder. A landholder with the [MILITARY_STRATEGY] responsibility will travel around taming creatures in world-gen, according to legends mode.

Besides that, the responsibilities work the same as with any other on-site living position-holder, civ or otherwise.

=Military=
==Squad management==
In the vanilla game, the Squad interface only becomes available after a militia commander has been appointed. Until then, the window displays:{{DFtext|You must appoint somebody first to create a squad.}}

What’s surprising is how this is determined internally. In the entity raw definition, '''only the last two positions that include a [SQUAD] token are checked''' to decide whether the interface is accessible at all. As a result, if your hierarchy defines commanders A through E, appointing '''Commander D or E''' unlocks squad formation, while appointing A–C does nothing.

In other words, squad availability is not tied to ''having a militia commander'', but to ''which specific positions happen to be last in the raw list''—a notably hacky implementation.

These 'last two' are always the last two '''available positions.''' So if they get [REPLACED_BY] or become available because of [REQUIRES_POPULATION], the game adapts to those.

==Squad assignment==

Squads can be assigned, even if the leader position has no holder.

A specific unit can only have one position associated with a squad. If it gains another 'squad holding position', it is unassigned from the first one. This does not work with a 0-squad, so only 1+squads are taken into consideration. This technique can possibly be used to distribute all positions equally among all citizens. It does however not work with election and assumption.

If a civ-level position is associated with a squad and it gets a site-level squad-holding position assigned, it loses the current civ-position.

Squads can get really messed up, if you make the position (or multiple) either elected or not-elected and not-appointed, then this can cause the game to assign multiple squads to the same unit. Automatic assignment and election does not take squads into account, but the nobles screen does. This can cause the positions to be cleared as the game figures out that they have more than one position, and immediately get elected or assumed again.

Positions that cannot have a squad-position:
* A site- or civ-position with a [SUCCESSION] token cannot be appointed a squad-holding-position. The other way around, however, does work. For example, if a site-position with a [SUCCESSION]-token is appointed to a unit that has already a position with [SQUAD]. But when that squad position is assigned to another unit, it cannot be assigned back.
* A position with [SUCCESSION] can also not be assigned as a '''member''' of a squad.
* A squad-holding position with a formed squad cannot be appointed to another squad holding position.

If a position has at least one squad member, it cannot be left vacant. First, the squad has to be disbanded, then the position may be cleared.

==0-squads==
A 0-Squad is defined in a position as [SQUAD:0:member:members]. It does not seem to do anything useful as of now.
* It cannot be used to activate the [[Squad|military interface]]
* It does not restrict the assignment of [SUCCESSION] positions.
* Assigning this position does not clear any previously held squad position.
* The [[Leader]] and [[Tactician]] skill are not marked as relevant skills and are not taken into account in elections.
* It cannot be formed as a squad.

=Further testing=
The following questions may need additional testing. Feel free to add or answer
* Everything regarding COMMANDING and army-structure
** [http://www.bay12forums.com/smf/index.php?topic=175437.msg8331668#msg8331668]
** [http://www.bay12forums.com/smf/index.php?topic=165213.msg8335682#msg8335682]
** [http://www.bay12forums.com/smf/index.php?topic=174584.msg8026854#msg8026854]
* Stuff about the monarch, its arrival and its entourage.

=Oddities (Bugs)=
Almost everything on this page could be called an oddity. Because of their unexpected usability, some may also be referred to as “undocumented features.” Others, however, are simply odd and not particularly useful, yet I hesitate to call them “bugs.”
* If a certain threshold is reached that makes an elected position electable, and the triggering event that initiates this evaluation is an assumption, then the resulting assumption works partially as an election. It referred to in the messages as an election and the [REJECTED_CREATURE]-token is not applied, like it is with assumptions.

=Examples=

===The Founder===
The founder is a single dwarf, appointed at embark. They will be the only one ever to have this position and are not replaceable. When they lose their position some way, the position will not be assumed by another dwarf.
{{gamedata|title=The Founder|
[POSITION:THE_FOUNDER]
[NAME:the founder:founders]
[NUMBER:1]
[SITE]
[ALLOWED_CREATURE:DWARF:ALL] - will only be filled at embark, but not assumable later.
[REJECTED_CREATURE:DWARF:ALL] - will only be filled at embark, but not assumable later.
[SUCCESSION:BY_POSITION:THE_FOUNDER] - not unassignable, also cannot be assigned to a [SQUAD] position.
[PRECEDENCE:200]
Non APPOINTED_BY
Non ELECTED
Optional: Add responsibilities to make the game select a unit with certain skills.
}}
===Marriage bar===
Dwarven matrons are held in great honour. Upon marriage, a female dwarf is no longer expected to perform menial labour. All dwarven males hold this position by default, granting their spouses exemption from menial work.

The position becomes available with the arrival of the first migrants; otherwise, on embark, it would be assumed by females. Its succession rule is non-functional, but this prevents the player from unassigning the position. A squad size of 1 and the succession rules together prevent a unit from assuming the position more than once.

With precedence set to NONE, the position name is hidden, while LAND_NAME remains visible on the nobles screen. All married females receive the suffix “, Mrs.” and are marked as Nobles.

The practical usefulness of this position is debatable, but it serves as a clear demonstration of several mechanics.
{{gamedata|title=Mrs. Urist|

[POSITION:MRS_URIST]
[NUMBER:300]
[SITE]
[ALLOWED_CREATURE:DWARF:MALE]
Not APPOINTED_BY
Not ELECTED
[LAND_NAME:Dwarven male]
[NAME:dwarven male:dwarven male]
[PRECEDENCE:NONE]
[SPOUSE_FEMALE:, Mrs.:spouses]
[MENIAL_WORK_EXEMPTION_SPOUSE]
[REQUIRES_POPULATION:8]
[SUCCESSION:BY_POSITION:MONARCH]
[SQUAD:1:member:members]
}}
===The Archduke===
The archduke is the leader of the civilization, but exists only from landholder 4-level. Until then, its position remains vacant. When a settlement is elevated to tier 4 (grand duke), the grand duke can appoint the ruler of the civilisation, the archduke. Because of 'Premature Succession', they themself inherit that position immediately, but only when in fortress mode. Its heir then becomes grand duke.
{{gamedata|title=The Archduke| no POSITION:MONARCH or other PRECEDENCE:1

[POSITION:THE_ARCHDUKE]
[NAME:archduke:archdukes]
[NAME_MALE:archduke:archdukes]
[NAME_FEMALE:archduchess:archduchesses]
[LAND_NAME:a archduchy]
[NUMBER:1]
[PRECEDENCE:1]
[SUCCESSION:BY_POSITION:GRAND_DUKE]
[APPOINTED_BY:GRAND_DUKE]
(add additional monarch-stuff, like spouse name, demands etc.)

[POSITION:GRAND_DUKE]
[NAME:grand duke:grand dukes]
[NAME_MALE:grand duke:grand dukes]
[NAME_FEMALE:grand duchess:grand duchesses]
[NUMBER:AS_NEEDED]
[LAND_HOLDER:4]
// Optional ...
[PRECEDENCE:19]
[LAND_NAME:a archduchy]
[RESPONSIBILITY:LAW_MAKING]
[RESPONSIBILITY:RECEIVE_DIPLOMATS]
[SUCCESSION:BY_HEIR]
[APPOINTED_BY:THE_ARCHDUKE]
(add additional landholder-stuff)

!!add to [POSITION:DUKE]
[REPLACED_BY:GRAND_DUKE]

}}
{{Category|Modding}}
{{Category|Entities}}
{{Category|Guides}}

Advanced entity position mechanics

2026-09-27T14:52:38Z

Silverwing235: /* [NUMBER] */ eliminate some ESL misformatting, and perhaps some SPAG litter also

{{Quality|Fine}}
{{Modding}}

= Introduction =

[http://www.bay12forums.com/smf/index.php?topic=182239.0 Discussion thread on the forum]

This page documents observed and tested behavior of entity positions in Dwarf Fortress that is not fully described elsewhere on the wiki. It focuses on advanced interactions between position tokens, including appointment, succession, election, and responsibility handling, across both civilization-level and site-level entities.

The mechanics described here are based on empirical testing in world generation and fortress mode, supplemented where necessary by raw analysis. In several cases, the game’s behavior is determined by evaluation order and interaction between multiple tags, rather than by individual tokens in isolation.

This page is intended for modders and advanced players who are designing or debugging custom entity position structures. It does not restate basic position mechanics, but instead highlights edge cases, non-obvious interactions, and behaviors that may appear inconsistent or undocumented.

Unless stated otherwise, the described behavior applies to current versions of the game and may differ from older releases.

==What is an entity? What is a position?==
An [[entity]] is an organizational structure that can have relationships with other entities, usually known as a [[civilization]] or a "[[site]] government" in the game, but ie. [[merchant company|merchant companies]], [[Mercenary#Mercenary_Orders|mercenary orders]], [[guild|guilds]], [[religion|religious organizations]], bandits and necromancer towers are also entities (and necromancer towers use the same entity type as "site governments"). An entity can have positions - in most cases, these are hardcoded and generated by the game, but as for civilizations and sites, the [[raw file]]s can be customised.

A position is a special relationship between a unit and an entity. The unit holding a position has a larger influence over that entity than other citizens. Positions are mostly known as [[nobles]], but in this article. the technical term is used.

=Position levels (Site/Civ) and their interaction=
There are two basic types of positions that are customizable: '''civ(ilization)''' level and '''site level'''. Positions with the tag [SITE] are at site level, positions without the tag [SITE] are at 'civ level'. These two types of nobles can be considered '''loosely related systems'''. There are a few places where they can interact with each other.

Civ-level positions are in charge of the civilization as a whole, managing national [[trade]], laws, and [[war]]s. These are, for example, the vanilla [[monarch]], [[diplomat]] and [[general]]. (Note that the general doesn't really do anything, except creation of additional pets in world-gen for the general and possibly raising the animal training knowledge of the civilization to "general familiarity".)

'''[LAND_HOLDER]''' nobles are also positions at civ-level. These units are members of the national government, but have gained authority over some land or site. Once they do, they move to that place, but their position is still regarded as a civ-level position.

Site-level position holders are members of a site government (subsidiary to the civilization), and manage local affairs in that location. These are, for example, the [[mayor]], the [[sheriff]] and the [[broker]].

==Table of interaction between different position levels==
In this table, the possible interactions between different position levels are summarized.
The header row shows the positions defining the tokens.

The left column shows the position type that is referred to.
Example:
{| {{prettytable}}
|- bgcolor="#ddd"
! referred position-type
! LAND_HOLDER
|-
| civilization
| (baron is) APPOINTED_BY:MONARCH
|}
color coding: 
* Exists in vanilla
* Possible with mods
* Not possible
* possible to some extent.
* not yet fully investigated.
{| {{prettytable}}
|- bgcolor="#ddd"
! referred position-type
! Civilization
! SITE
! LAND_HOLDER
! CONQUERED_SITE

|-
| Civilization
| APPOINTED_BY COMMANDER REPLACED_BY SUCCESSION
| APPOINTED_BY COMMANDER REPLACED_BY SUCCESSION '''(1)'''
| APPOINTED_BY COMMANDER REPLACED_BY SUCCESSION
| APPOINTED_BY COMMANDER REPLACED_BY SUCCESSION

|-
| SITE
| APPOINTED_BY COMMANDER REPLACED_BY SUCCESSION '''(2)'''
| APPOINTED_BY COMMANDER REPLACED_BY SUCCESSION
| APPOINTED_BY '''(3)''' COMMANDER REPLACED_BY SUCCESSION '''(4)'''
| APPOINTED_BY COMMANDER REPLACED_BY SUCCESSION

|-
| LAND_HOLDER
| APPOINTED_BY COMMANDER REPLACED_BY '''(6)''' SUCCESSION
| APPOINTED_BY COMMANDER REPLACED_BY SUCCESSION '''(5)'''
| APPOINTED_BY COMMANDER REPLACED_BY '''(7)''' SUCCESSION '''(8)'''
| APPOINTED_BY COMMANDER REPLACED_BY SUCCESSION

|-
| CONQUERED_SITE
| APPOINTED_BY COMMANDER REPLACED_BY SUCCESSION
| APPOINTED_BY COMMANDER REPLACED_BY SUCCESSION
| APPOINTED_BY COMMANDER REPLACED_BY SUCCESSION
| APPOINTED_BY COMMANDER REPLACED_BY SUCCESSION
|}

Remarks:
# Works only in world-gen, if a unit with that civ-position is present at the site.
# Works only in world-gen, the site-position holding unit will then move to the capital.
# Is completely ignored
# Works only in world-gen.
# Works only in world-gen.
# Won't appear at all
# This is necessary for the landholder chain to work properly, it doesn’t work otherwise.
# This works only outside of the landholder chain, so when landholders are simply regarded as civ-level nobles. might also work in world-gen
#

== Other interactions ==

Unfortunately, interactions with positions of other entities don't seem possible, such as APPOINTED_BY: HIGH_PRIEST. With [VARIABLE_POSITIONS], positions are automatically created with codes like CUSTOM_LAW_MAKER_2, but interaction with these positions don't seem to work, either. For more info on those, see [[Variable positions]]

=General=

==Civ-level nobles living at your site==
Nobles from your civilization can come to live at your fortress. This happens in vanilla with landholders such as [[Baron]], [[Count]] and [[Duke]], with the Monarch, but sometimes also with non-landed LAND_HOLDERS.

When a civ-level noble becomes a [[citizen]] at your location, their position is shown among the site-level positions in your [[nobles screen]]. They appear to function as a site-level noble. They may have [[demand]]s, [[mandate]]s, [[squad]]s and the like. They can appoint nobles at the site-level.

Even if they have certain site related [RESPONSIBILITY]ies, they will not do the tasks that go with them.

==Fortress mode, world-gen and their differences==
Their are a few differences in how positions function between fortress mode (normal play mode) and the world generation (world-gen).

In '''fortress mode''', the player has some control over the appointment of nobles, limited by elections, automatic filled-in positions and succession rules. Pre-fortress mode, which is referred to as '''world-gen''', the game will always attempt to assign nobles whenever possible. It is subjected to the same rules as in fortress-mode, but there are some exceptions. In '''[[World activities]]''', which is the thing that happens in the world while you play fortress mode, it seems as if the same rules are applied as fortress mode.

A difference between player-fortress-mode and world-gen, is causes by visibility (see below). Positions that are not visible by the player and thus not available for assignment, will be available in world-gen and will thus be automatically assigned.

In fortress mode, a position that is both [ELECTED] and [APPOINTED_BY], cannot be appointed by the player and is also not elected, and can thus not be filled. But in world-gen sites however, these positions are automatically filled.

Positions with [AS_NEEDED] are almost never created and filled in world-gen (depending on their [RESPONSIBILITY]ies), but can always be used in player mode.

A position can, in fortress mode, be filled by the same unit. A unit can gain multiple positions in fortress mode, for example because of [[elections]]. This will not happen in world-gen mode: a unit can only have one position. See also remarks on 'embark' and 'Losing a position'.

In world-gen, [SUCCESSION] between civ-levels and [SITE-]levels may happen. This will not happen in fortress mode, or even off-site in [[World activities]].

In fortress mode, premature SUCCESSION may happen. This will not happen in world-gen mode.

==Units holding multiple positions in multiple entities==
A unit can hold multiple positions in its civilisation or in its site-entity, however in world-gen a unit will not hold multiple positions in one site-entity or in one civilisation (note that in world-gen a unit can hold multiple variable positions of the same entity, if the entity is ie. an outcast group). It is however possible - in world-gen - for a unit to hold multiple positions as long as the positions belong to different civilizations / site-entities (ie. it is possible for a militia commander of a site-entity to later on also become a monarch of the parent civilization, while staying a militia commander), if a unit holds a position of two different site-entities (the unit will usually have left one of the groups, without relinquishing the position). Only at player-managed sites can units be holding multiple positions (of the site-entity) at once. It is currently unknown, whether it is possible in world-gen for a unit to have a civ-level position in two different civilisations (but it probably is possible, as a a unit can belong to multiple civilizations and a unit usually does not relinquish a position, when the unit gets another position, as long as the entities of both positions are not the same).

In world-gen, if there are too many positions to be filled, they simply stay empty until more units are available. E.G, a unit at a site might inherit a civ-level position and still remain a member of the local government. When this happens however, they move to the capital. If a unit gains a new position, either inherited or otherwise, it drops the previous one (of that civilisation or site-entity) - the unit will not drop any positions unrelated to the entity of the new position (ie. a CUSTOM_OUTCAST_FACTOR will not relinquish that position, if the unit becomes the ruler of a civilization and a militia commander will also not necessarily relinquish the position, if the unit becomes also the monarch of the corresponding civilization). If a unit assumes a civ-position in fortress mode, it leaves the current position.

If a unit holds the same site-position multiple times, it has no additional effect.

If a unit holds multiple different positions of the same entity, it has all those positions' responsibilities and properties, stacked up. Presumably, the demands for those combined positions are determined by the highest.

A unit holding a position with a succession token can be assigned another position with a (different) succession token.

A unit holding a position with a squad-position cannot hold another squad-position. It is dropped from the first of those, when the second position is assigned.
A unit holding a position with a succession token cannot be assigned to a squad-position - the unit is simply not available. It works the other way around, though.

=Specific Tags and functions=
==[PRECEDENCE]==
The first defined position with precedence of 1 counts as the ruler of the civ. See also: [[Position_token#PRECEDENCE|PRECEDENCE]].

If the precedence is omitted or has a negative value, the game sets 0 as precedence, which seems to have no effect whatsoever. When a unit has multiple positions, the name of the position with the highest rank in precedence is shown behind the unit's name.

If you omit precedence entirely, or set it to [PRECEDENCE:NONE], the position name will not be shown after the unit’s name. Your *Urist Mason* will remain simply *Mason*. This can be useful for positions that are unimportant or purely functional. The position will also not appear in the civilisation overview of your site on the world map. The position name is shown in messages, but remains hidden on the nobles screen as well. To make it visible there, use [LAND_NAME].

==[RESPONSIBILITY]ies==
Both civ and [SITE] positions can carry responsibilities. However, not all responsibilities are active for both types: some function only for civ positions, others only for site positions. When a civ noble arrives at a site and takes up residence, they do not perform responsibilities that are intended for SITE nobles. As a result, these responsibilities neither trigger their associated tasks nor unlock related game mechanics. For example, a civ-level manager living in a fortress will not perform management duties there and doesn't unlock the management-screen, even with an assigned office.
This behavior applies to the following [SITE]-level responsibilities:
* [RESPONSIBILITY:ACCOUNTING]
* [RESPONSIBILITY:BUILD_MORALE]
* [RESPONSIBILITY:HEALTH_MANAGEMENT]
* [RESPONSIBILITY:LAW_ENFORCEMENT]
* [RESPONSIBILITY:MANAGE_PRODUCTION]
* [RESPONSIBILITY:MEET_WORKERS]
* [RESPONSIBILITY:TRADE] (functions differently)
Other responsibilities may be affected as well, but have not yet been fully tested.

===World-gen effects of the [RESPONSIBILITY] of available positions ===
It is possible to cause civs and individual sites to change their behavior substantially when they reach a certain size, by controlling nobles.
* If a site can only appoint a position with [MILITARY_GOALS] after reaching a particular size, that site will not send armies on missions until the required size is reached.
* A civ-level [LAW_MAKING] position is required for the civilization to have any kind of cohesion. Without it, sites will be constantly embroiled in territorial disputes and civil wars will be commonplace.
* [MILITARY_STRATEGY] positions go out and tame wild animals. This makes your civ gain those animals as domesticated and also brings them in sieges.
* The [[Personality_facet|Personality]] of the position's holder determines how they lead the civ.

===[DELIVERS_MESSAGES]===
The only [AS_NEEDED]-position that is created in worldgen based on responsibility is that of the site-level responsibility [DELIVERS_MESSAGES].

===Outpost Liaisons and Diplomats===
Civ-positions with the responsibility [ESTABLISH_COLONY_TRADE_AGREEMENTS] ([[Outpost_Liaison|Outpost Liaison]]s) will meet with the site-noble who has responsibility for [RECEIVE_DIPLOMATS] and the highest rank of precedence (i.e. the lowest precedence value). Usually this is the [[Expedition_leader|Expedition leader]].

Once a [LAND_HOLDER] is assigned to the site, civ-positions with the responsibility [MAKE_TOPIC_AGREEMENTS] ([[Diplomat]]s) will meet with '''civ'''-level nobles present at the site who have the [RECEIVE_DIPLOMATS] responsibility. If multiple eligible nobles are available, one is selected at random. If no eligible noble is present, the diplomat leaves angrily. If the landholder is no longer present at the site, diplomats will not arrive at all.

It appears that Outpost Liaisons and Diplomats are chosen for a diplomatic mission based on availability. When multiple candidates exist, the position defined last in the raws is most often selected.

===[TRADE]===
Civ-level nobles with [TRADE] will arrive with the caravan, just as the Outpost Liaison. Their behavior is no longer active in the vanilla game, but the mechanics are still present. See [[40d:Guild_representative|Guild representative]] for more details. This civ-noble will only meet with the SITE noble with [TRADE], usually the [[Broker]].

If two civ-nobles exist with both [TRADE] and [ESTABLISH_COLONY_TRADE_AGREEMENTS], they both arrive at the same time. Even if both tokens are assigned to a single position, if more than one instance of that position exists, two of them will arrive. However in that case, somehow the elevation of the site and appointment of landholder isn't offered.

If the SITE-noble they intend to meet has both [TRADE] and [RECEIVE_DIPLOMATS], only one meeting will proceed and the other is cancelled. However, when two SITE-nobles are available, each with either [TRADE] or [RECEIVE_DIPLOMATS], both meetings will proceed and both civ-nobles will attempt to negotiate a trade agreement. It is not known what happens if these agreements are accepted or refused.

In the trade depot, the last defined position with the [TRADE] responsibility is shown as broker. However when requesting a trader, the first defined position with [TRADE] will actually go there to do the trade.

==[NUMBER]==
A position might be defined with a number. In that case, as many as defined can be available. If the positions become available in world-gen and when embarking, they are all filled in completely.

If the ruling position (with PRECEDENCE of 1) has a NUMBER higher than 1, a random unit of the ones holding these positions is shown as ruler in the embark screen.

A [NUMBER] of 0 (zero) has the same effect as 1.

===Automatic spreading of assumed, non-singular positions===
If there are civ positions that have a NUMBER higher then '1' and which are assumed (not APPOINTED_BY or ELECTED) but are '''not DUTY_BOUND''', these are automatically spread among the civilisation, based on population. If there are a number of '''20''' available slots of that position, they spread among a civilization with a combined population of, for example, 1000 of which your fortress has 100 (10%), '''2''' of your fortress' citizens will assume that position.
This may probably also work with elected and appointed positions, but that may be depending on the death of the current holders and this needs more testing. Assumption works within a day, anyway.

===[AS_NEEDED]===
These positions can be created automatically by the game in worldgen. This, however, only works with:
* [LAND_HOLDER]'s
* squad commanders (needs more testing)
* Messengers at sites

For all other types of positions, they're not created in worldgen; even if defined with RESPONSIBILITY's. For example, even in war, the game wouldn't create a MILITARY_GOALS position if they have AS_NEEDED as a number. However, in fortress mode / player mode, these positions can be created by the player at will.

Positions with AS_NEEDED need to be created first, before any symbols are assignable as 'symbols' (objects) for the position holder to carry or wear, but they cannot be created and then ELECTED in fortress mode - that only works with APPOINTED_BY.

==[REPLACED_BY], [REQUIRES_POPULATION], [REQUIRES_MARKET]==

The token [REPLACED_BY:position] means that once the replacing position meets its requirements for activation, the 'to-be-replaced' position will disappear. This is defined in [REQUIRES_POPULATION] or [REQUIRES_MARKET]. The tags are closely related to each other and seem to only have a meaningful function if combined. Nobles with [REQUIRES_POPULATION] require the population to have a specific size. Nobles with [REQUIRES_MARKET] are only activated in market sites, such as fortresses or towns. [REQUIRES_POPULATION] and [REQUIRES_MARKET] can be combined, activating that position once both requirements are met.

The [REQUIRES_MARKET] can be used to differentiate positions between hamlets and hillocks, and larger sites. IThe market always is build the year after the site is founded. So a position that is to be replaced, will be gone immediately.

The [REQUIRES_POPULATION]-tag works on the civ-level as well as on site-level, but those systems are in this mechanic strictly separated. Site-level positions cannot be replaced by civ-level positions and visa versa. This makes sense, because they both depend on their own population-count. When using REQUIRES_POPULATION on civ-level, it counts the total population of the civilisation.

See also: [[Advanced_entity_position_mechanics#Evaluation_of_Positions|Evaluation of positions]]

===Effect of replacement (and on [LAND_HOLDER]s)===

Replacement is immediate and complete - the current holding unit loses the position, even before SUCCESSION_BY_POSITION rules are applied. A position with a number of 1 will replace all the slots of a position with a higher number of slots.

Even if the next position is available but not visible, replacement still takes place. If a position is replaced, it is completely gone - it cannot be appointed, succeeded, elected or assumed any longer.
The unit immediately loses its position.

In legends, replacement is mentioned as: "(unit name) ceased to be (position name)" The replacement of an AS_NEEDED position empties the position's slot forever. In fortress mode, it may seem as if you can create new slots and appoint new units in the nobles screen, but this is reversed as soon as you close the window.

The landholder chain uses [REPLACED_BY] differently. It does not clear the position completely, but uses it for succession to the next level's position. [REPLACE_BY] is required to let that system work properly. This also means that the way in which landholders succeed (replace + as_needed) does not work in any other way.

Replacement between LAND_HOLDERS and other site- or civ positions does not work in any way. Only the vanilla replacement sequence between levels of LAND_HOLDERs does work. If the token is omitted for landholders, the landholder chain is broken, so replacement is required for the landholder system to work.

[REQUIRES_POPULATION] also does not work for [LAND_HOLDER], when you set [NUMBER] to 1. The position is not created when the required population is reached.

===What doesn't work===

'''Attention: If a position cannot be appointed, for example because of 'mutual appointment', it still exists according to replacement mechanics and will replace other positions if so defined. If a certain position(a) will be replaced by the baron's assistant, which can only be appointed by the [LAND_HOLDER] baron, than that position(s) still will be replaced from the start of the game, even if no baron or their assistant is ever present.'''

A position that is replaced by a somehow non-fillable position is still replaced. This counts for mutual-appointing positions, replacement by not-yet-assigned landholders, replacement by AS_NEEDED positions, or replacement by not-yet-appointed positions.

Replacement does not work if the replaced position is a [LAND_HOLDER], even with civ-positions. In that case, the LAND_HOLDER's position is not replaced. It does not matter if AS_NEEDED is used, or a fixed number, and it also does not matter what type of position the replacer is. So this only works (correctly) with positions that become available by REQUIRES_POPULATION.

==[CONQUERED_SITE]==

This tag determines which position is used to assign a [[Forced administrator]].

In legends mode, this is visible as an event describing the reconquest of the site: a new group is formed and the forced administrator is installed as its ruler.

All positions defined with this tag are assigned during this process, meaning multiple positions can be appointed at once.

The holder of a position marked with [CONQUERED_SITE] cannot appoint any other [SITE] positions, unless the civilization has site variable positions, in which case the forced administrator can appoint such site variable positions (allthough the variable positions for that site need to be created first and such creation only happens during world-gen, but not normal world activities).

Combining [CONQUERED_SITE] with [SITE] causes the position to function both as a forced administrator and as a normal site position available in fortress mode. However, this provides no meaningful additional mechanics and is effectively inferior to using [SITE] alone:
* [APPOINTED_BY] lines are completely ignored, meaning that the roles are automatically assumed.
* [SUCCESSION] is likewise ignored.
* the [CONQUERED_SITE]-position cannot appoint other [CONQUERED_SITE], [SITE] or combined positions.

There have been remarks that reclaiming a fortress is unplayable because of the lack of regular nobles. Unfortunately, it seems that it can't be fixed by modding.

=Availability and visibility=
==Availability of (new) positions==
Warning: Do not mistake "availability" for "visibility"!

Of all the possible positions existing in your site's entity, there may only be some available.
* Positions with [REQUIRES_POPULATION] require the population to have a specific size.
* Positions with [REQUIRES_MARKET] will only appear in "large" sites (which may have different rules for different site types). This tag has no effect in fort mode.
* Positions that are appointed by positions that have an AS_NEEDED number. The appointable positions only become available after an appointer position-slot is created. This works also on civ-level. If a position is appointed by a Land-holder, it only becomes available, when that level of landholder is created.

Only the replaced positions are culled and are no longer available.
A position that requires a certain population will become available, even if it doesn't have [APPOINTED_BY] or [ELECTED]. In that case, see 'automatic assignment' and 'assumption'

In fortress mode, in some cases 'succession' is evaluated immediately after a position becomes available. See: Succession.
==Visibility of positions==
A position might be available, but can still be invisible for the player in the [[nobles screen]]. The positions with their respective holders are visible for players:
* All site-positions that are already filled-in (even if they could not be re-filled-in considering current conditions)
* Site positions that are appointable by a filled-in site position
* Site positions that are appointable by a filled-in civ position, when that civ positions holder becomes a citizen of your fortress.
* Civ positions of units that are also a citizen of your fortress.
If a position becomes available, for example because a certain pop number has been reached, or if it is available from the start(like expedition leader), as long as it cannot be appointed, it still is INVISIBLE for the player.

It might strike someone as odd if a position becomes filled automatically in fortress mode when that position is not even visible. This might be the case if the current holder of a non-appointable position dies or succeeds another position. Regardless of player visibility, these positions will be automatically filled in if the necessary requisitions are met. It might happen with the expedition leader.

A situation with a non-visible but available position, is for example when a position is solely appointed by the expedition leader, when the expedition leader's position is left vacant. It can no longer be appointed by the player and is invisible. Then, it gets automatically assumed, proving that the position still was available.

A position that is both [APPOINTED_BY] and [ELECTED] is visible, but players cannot interact with it.

={{text anchor|Evaluation of Positions}}=
The game does not continuously check whether positions should become available, elected or be [REPLACE_BY]. This is well-known behavior—for example with the [[mayor]], who does not appear automatically when the required population ([REQUIRES_POPULATION]) is reached. Instead, positions must somehow be evaluated. This applies in several other situations as well

'''Cases that require a trigger:'''
* Election of a newly created position
* Election after the current holder dies
* Automatic assumption of a newly created position (this may take up to a day)
* New citizens (such as migrants) considering available positions
* Premature succession of a newly created position

'''Cases that do not wait for a trigger:'''
* Succession following the death of the previous holder
* Automatic assumption of existing positions that have become vacant

'''Triggers that cause the game to reevaluate noble positions:'''
* Succession of a [SITE]-position due to the death of the current holder
* [[Advanced_entity_position_mechanics#Election_Day|Election Day]]
* Automatic assumption of a [SITE]-position that becomes vacant
* (Re)assigning any site position manually
* Settlement elevation on the LAND_HOLDER track (e.g. gaining a [[Baron]] or [[Count]])

=Gaining a position=
There are several ways a unit can gain a position:
* Appointment: A unit is appointed by another unit or by the player.
* Election: A unit is elected by and among the members of the entity
* Assumption: A position is neither elected or appointed: a random unit just simply 'takes' the position
* Succession: a unit is the valid successor of this position(A), either by its current position(B) or because they are that position(A)-holder's heir.

Available positions will automatically be assigned to a random civ member when a new site/civ is created.

==Who can take a position==

* If so defined, a unit needs to be the right caste and/or class - it does not seem to work with creature types.
* The unit needs to be an adult member of the site or its parent civ's government; that is also CAN_LEARN or INTELLIGENT (SLOW_LEARNER cannot take positions) or otherwise is able to think.

==Appointment==

Positions that have an [APPOINTED_BY:position] token require that position to exist, to be available and appointed. Any position that is APPOINTED_BY can be appointed if the appointer's position is filled in.
For site-positions to be appointed, it is required that the appointer is present at that location.

If the appointing unit is temporarily not present, or if that position is not filled, positions depending on it cannot be appointed. This is the case with [[militia captains]], when the [[militia commander]] is on a [[mission]].

A site position cannot appoint a civ position ''or'' LAND_HOLDER in any way whatsoever.

Civ-level positions can appoint other civ-level positions and site-level positions can appoint other site-level positions.

Contrary to what has been said elsewhere, civ-level nobles also can appoint site-level nobles. They need to be at the site to do so. Landholders can appoint both site-level and civ-level nobles. These systems are therefore not as separate as was assumed.

'''Mutual appointment''' cannot take place. If these are the only requisites of the position, then the positions will never appear or get filled. These unfillable positions can be put to good use, for example, to replace a position that is no longer needed without creating a new one.

'''Self appointment''' doesn't normally work. If you have a position that is only appointed by itself, it is never appointed and also cannot be assumed. However, if the position has a number higher than 1, and is filled by multiple units (for example by another position that is now empty), than those units can re-assign or appoint each other from that their shared position.

If an APPOINTED_BY token refers to a non-existing position's code, the effects are as if the appointment token doesn't exist at all.

===Automatic appointment in world-gen and on the civ level===

Outside of fortress mode, the game will always attempt to appoint nobles whenever possible, as long as these positions are '''available''', even if they are invisible to the player.
It shows this message in legends: "(unit name) has been appointed to the position of (position name)"

In world-gen, all positions become available and are automatically appointed, taking population- and appointment-requirements into consideration.

Positions that are REPLACED_BY are culled and won't be filled.

If a citizen of your fortress holds a civ-level position that can appoint another civ-level position, the appointment will happen automatically and without player intervention. It may happen that another citizen of your fortress is appointed by that unit, creating civ-level position holders in your fortress, but it is unknown what is required to force this effect.

===Manual appointments by players in fortress mode===
In fortress mode, the positions that need to be appointed stay empty on embark. and it is the player's job to appoint those. A player can appoint a unit to any available position, according to the hereabove mentioned conditions. The player takes the role of the automatic appointment-system, but has no direct control over elections, successions and replacement. There are some differences in what is possible at world-gen sites and at player-controlled sites.

* A position that is appointed by a unit present as a fortress citizen, can be appointed, re-appointed or left vacant. This means also by civ-level nobles living as a citizen in your fortress; not when they are only visiting, like the diplomat.
* A position whose appointing positions are all either vacant or [REPLACED_BY] can no longer be appointed. If the position is already filled, it cannot be reappointed or vacated; the current holder simply remains in office.
* A position that is APPOINTED_BY a unit present as the land_holder of your site, can be appointed, reassigned or left vacant.
* A position that has SUCCESSION BY_HEIR or BY_POSITION can 'initially' be appointed and also re-appointed or left vacant, but as soon as the [[nobles]] screen closes, ''it can no longer be replaced or left vacant''. From then on, the succession-rules determine who gains that position when the current holder loses the position. This works even if the SUCCESSION:BY_POSITION-position is vacant or replaced.
* A position that is ELECTED nor APPOINTED_BY, can always be (re-)appointed by the player. This is the case with the [[Expedition leader]]. If it is left vacant however, it cannot be appointed, but will be assumed shortly after.
* A position that is both ELECTED and APPOINTED_BY, cannot be appointed by the player. Contrary to world-gen sites, its slot is visible, but it doesn't show the +-sign. This is either by AS_NEEDED or by a fixed number. Even if the position somehow gets filled (re)assignment is never possible
* A player can appoint a number of units to a position, as much as the NUMBER token dictates. If it is AS_NEEDED, the player may create as many slots as they like, also contrary to world-gen sites.
* A civ-position can never be appointed, even if the appointing civ noble is a citizen of your fortress. A civ position also never can be re-assigned or left vacant, would that position be defined as appointed by a site-position.

==Election==
Read more in [[Elections]]. The message that is shown is: "(creature name) has been elected to the position of (position name)"

In worldgen, there is no functional difference between ELECTED and non-appointment, except that elected nobles tend to have high social skills and/or skills related to the position, while non-elected ones are assigned randomly. See: [[Elections]]

A succession goes before an election.

A position that is both ELECTED and APPOINTED_BY never gets elected. Even if the appointees' position somehow gets filled, (re)-elections won't happen. So, it doesn't seem possible to have an elected position become available when a certain other position becomes filled.

An ELECTED civ-(or LAND_HOLDER) position at your site will never be (re)-elected in fortress mode. So real (re-)election only works with SITE-positions.

=== {{text anchor|Election Day}} ===
Election Day takes place on the 17th of Summer. On this day, a full reevaluation is performed, including all currently elected positions, which are subject to re-election. Contrary to the information on [[Elections]], nothing occurs at the start of a season.

Positions that are both [APPOINTED_BY] and [ELECTED] will not be re-elected on Election Day when assigned through [SUCCESSION].

=== Election Eligiblity ===
Any citizen may stand for election. Eligibility cannot be restricted using [ACCEPTED_CREATURE], [REJECTED_CREATURE], [ACCEPTED_CLASS], [REJECTED_CLASS], or [GENDER]. Units currently having a [SUCCESSION]-position even may be elected for a position with a [SQUAD]-token, which is otherwise impossible to assign or even succeed.

=== Skills ===
In elections, skills are taken into account for the tokens of the position which is elected.
{| class="wikitable"
|+ Relevant skills per position token
|-
! Position Token !! Relevant skills
|-
| Responsibility [[Position_token#DELIVER_MESSAGES|[DELIVER_MESSAGES]]] || [[Ambusher]], [[Observer]] and [[Social_skill|Social skills]]
|-
| Responsibility [[Position_token#ACCOUNTING|[ACCOUNTING]]] || [[Record_keeper|Record keeper]]
|-
| Responsibility [[Position_token#ESPIONAGE|[ESPIONAGE]]] || [[Schemer]]
|-
| Responsibility [[Position_token#HEALTH_MANAGEMENT|[HEALTH_MANAGEMENT]]] || [[Diagnostician|Diagnostician]]
|-
| Responsibility [[Position_token#MAKE_INTRODUCTIONS|[MAKE_INTRODUCTIONS]]] || [[Social_skill|Social skills]]
|-
| Responsibility [[Position_token#MAKE_PEACE_AGREEMENTS|[MAKE_PEACE_AGREEMENTS]]] || [[Social_skill|Social skills]]
|-
| Responsibility [[Position_token#MAKE_TOPIC_AGREEMENTS|[MAKE_TOPIC_AGREEMENTS]]] || [[Social_skill|Social skills]]
|-
| Responsibility [[Position_token#MANAGE_PRODUCTION|[MANAGE_PRODUCTION]]] || [[Organizer]]
|-
| Responsibility [[Position_token#MEET_WORKERS|[MEET_WORKERS]]] || [[Social_skill|Social skills]]
|-
| Responsibility [[Position_token#RECEIVE_DIPLOMATS|[RECEIVE_DIPLOMATS]]] || [[Social_skill|Social skills]]
|-
| Responsibility [[Position_token#RELIGION|[RELIGION]]] || [[Social_skill|Social skills]]
|-
| Responsibility [[Position_token#TAME_EXOTICS|[TAME_EXOTICS]]] || [[Animal_trainer|Animal trainer]]
|-
| Responsibility [[Position_token#TRADE|[TRADE]]] || [[Social_skill|Social skills]] and [[Appraiser|Appraiser]]
|-
| [[Position_token#SQUAD|[SQUAD]]]-token || [[Tactician]] and [[Leader]]
|}

==Assumption==

A position that is not APPOINTED_BY nor ELECTED, or is appointed by positions that are not available in your site or civ, will be assumable by a random dwarf. If it has responsibilities that require certain skills, then these are taken into consideration on embark, but not when the position is assumed during the actual game.

Normally, one to three units will take the into consideration to assume a position. Most of the time when there are multiple open positions, only a single unit will assume all of them. However, a position that has REJECTED_CREATURE, REJECTED_CLASS, ALLOWED_CREATURE or ALLOWED_CLASS will be filled with all different units, even if the creature or class mentioned is irrelevant. It seems that this forces the game to loop over all the available units.

The message that is shown in Legends mode is: "(unit name) has assumed the position of (position name)". This may also take place in fortress mode, which then shows this message to the player.

If an assumable position becomes empty, it will be assumed within a day. This is the case when you leave the position of expedition-leader vacant. It also happens with entities.

Assumable positions that become empty will not be assumed if that position has a valid [SUCCESSION] -successor. In that case, the successor inherits the position.

Even positions that are somehow invisible because they cannot be directly APPOINTED_BY players, can be assumed.

When you embark, the assumable positions are automatically assigned to a random unit. If there are multiple of these positions at embark, they all are assigned to the same unit. If there are enough positions available, multiple units may gain a position, but often no more than three different ones.

If a dwarf in fortress mode assumes a position, that already has another position, it will leave the current position empty. When that position also is assumed, then this will continue until all positions have a dwarf appointed to them, with no other position.

A unit that already has a position with a [SUCCESSION] token won't take assumable positions into consideration that have a [SQUAD] token. This can be used by the modder to prevent unwanted loss of current positions.

A position that has an appointer which got replaced because of REPLACED_BY, will not become assumable. Also, positions that have an AS_NEEDED appointer that is not yet filled (or ever), will also not be assumed.

==Succession==

If a position-holder dies or advances to a new position via succession, the position will be granted to another unit based on the [SUCCESSION] tag. If they have an heir or the succeeding position exists, that unit will be assigned. If not, a new one will be appointed according to the usual rules. The message that is shown is: "(creature name) being the rightful heir, has inherited the position of (position name)"

The succeeding creature will also lose its previous position. When succession is defined using BY_POSITION, the unit naturally loses the referenced position. However, it also loses any other positions it may hold. If a unit could simultaneously inherit multiple positions, the last-defined succession overrides the earlier one, clearing the previously acquired position

Succession works both at site-level and at civ-level, both in world-gen and in fortress-mode. Succession by position on the civ-level is also visible and functional in fortress-mode. If both civ-level nobles are a citizen of your fortress, succession is applied visually. Vanilla example: The [[druid]] is succeeded by the [[acolyte]]. This means that as soon as the druid dies, the acolyte takes over.

When a position that is succeeded by position becomes available, immediately it is checked if a position-successor is available and the position is filled with that unit. Even if this is an [ELECTED] position, succession goes first. When elections eventually do happen, succession plays no role.

It is possible to assign multiple levels of [SUCCESSION:BY_POSITION] in different positions, creating a line of positions where the death of one causes all those "below" them to advance.

A position can have multiple tokens with position-succession. It looks to be random which one is used. It is not always:
* The first or last defined token
* The first or last appointed unit
* the oldest or youngest
* one with a higher or lower precedence
* a unit with relevant skills

When a position is defined with a Succession-type, that unit cannot have another position that has a Squad-type. If the succession-position itself has a squad, than it can be assigned another position with a squad, but then it will loose the previous succesion position. See further details by "Squad"

Assumed positions can also be succeeded by position, if the current holder dies.

If the successor is an AS_NEEDED position, the used unit will leave a vacant position-slot on its removal by succession. This empty slot remains a real slot, which will only be cleaned up if you (un)appoint a unit to this position-series. It isn't cleaned up after regular position validation.

A civ-level position of a unit living at your site might be inherited by a unit holding that does not currently live at your site. This, unfortunately, moves that position to a unit off site. This may also happen with the landholder of your site, for example when it is succeeded by another civ-level position. This currently poses an unsolved challenge.

===Eligibility for succession===
Succession is restricted by the tokens [ACCEPTED_CREATURE], [REJECTED_CREATURE], [ACCEPTED_CLASS], [REJECTED_CLASS] and [GENDER].

===Site and civ combined succession===

Succession can work when combining site positions with civ-level positions or land_holders, but only in world-gen mode. In fortress mode, it only works with combining the same level of nobles, with Landholders regarded as civ-level. So, in fortress mode, a site's position cannot succeed a landholder's position and it cannot succeed another type of civ-level position, and vice versa.

This won't work even if the positions:
* are AS_NEEDED or having a fixed number.
* Are LAND_HOLDERs.

===Succession [BY_HEIR]===

When a heir is needed for succession, all children and then other relatives are validated. They cannot take the position if their status does not allow it, for example if they have become a member of another civilisation. See: "Who can take a position". If the unit has no valid heir on that location, the position may go to a unit living on another site. This may cause the title of Landholder of some land to be inherited by a unit living somewhere else. That might be a problem, because then you lose your landholders.

===Premature Succession===

There are cases where [SUCCESSION:BY_POSITION] is applied prematurely: at the moment a position is first created and becomes appointable or assumable, rather than after a current holder leaves. In this situation, the succession mechanism assigns a holder immediately, without any player interaction.

When a position becomes available for the first time, the game checks whether a valid successor-by-position exists. If so, that unit is assigned instantly. It can affect positions that would normally be appointed or elected by the player, causing succession to trigger before the player has any opportunity to intervene.

This behavior occurs only in Fortress mode, but can be applied both on [SITE]-positions as well in civ-positions. That last one however is a bit harder to control. Example: [[Advanced entity position mechanics#The Archduke|The Archduke]]

This premature succession only occurs the first time a position becomes available (i.e. when it is created and becomes appointable or assumable). Even if the position remains vacant and the conditions for succession improve later, premature succession will not trigger again. From that point onward, only normal succession rules apply.

Using premature succession, a position that has [ELECTED], [APPOINTED_BY], or both, can be filled directly.
Notably, positions that combine [ELECTED] and [APPOINTED_BY] are normally impossible to fill through regular mechanics. Premature succession bypasses both election and appointment entirely, making this combination uniquely reachable through this mechanism.

No initial election takes place, and no subsequent elections will ever occur for that position. Succession always takes precedence over election, both in premature succession and in normal succession cases.

This behavior applies only in Fortress mode, not during world generation. World-gen uses simplified and more efficient mechanics, and this interaction does not occur there. Premature succession can affect both site-level and civilization-level positions.

====Multiple succession chains====

Multiple succession chains may be defined and are resolved in the order they appear in the raws.

If a position has both:
* a direct succession chain (A → C), and
* a multi-step chain (A → B → C),

and intermediate positions are vacant, resolution proceeds according to raw order. A common outcome is:
# The direct succession (A → C) is applied first, assigning A to C.
# The remaining chain then advances (A → B).
# If C still has empty slots, the final step (B → C) may occur.

If position B is already filled, behavior depends entirely on raw definition order:
* nothing may happen, or
* B may move to C first, followed by A moving to B.
====Working triggers====
Premature succession is triggered when a succeedable position is created under the following conditions:
* The succeedable position is created because its [REQUIRES_POPULATION] threshold is reached. This applies even if the position is not [APPOINTED_BY]. Premature succession takes priority over automatic assumption (e.g. the mayor declaring themselves within a day).
** The position must either be assumable or appointed by an existing position. When said appointer-position also just has been created, the premature succession of the succeedable position happenes, even when the appointer-position is empty.
* The succeedable position can be [APPOINTED_BY] another position of the same level (site or civ) that has just been created because its [REQUIRES_POPULATION] was reached.
* The succeedable position can be appointed by another [SITE] [AS_NEEDED] position that has just been created and filled.
* The succeedable (site or civ) position is [APPOINTED_BY] the [LAND_HOLDER] position, which has just been created due to site elevation. This typically resolves when the diplomat leaves the map, at which point the landholder position becomes active.
* If all other requirements are met, premature succession can occur immediately after unpausing following embark, for positions with [REQUIRES_POPULATION:7].

====Non-working (triggers)====
Premature succession does '''not''' occur in the following cases:
* An [AS_NEEDED] succeedable position slot is manually created by the player while its succeeding position is already filled. [AS_NEEDED] positions must always be appointed after creation.
* The succeeding position is filled after the succeedable position becomes available. The moment of creation is the decisive trigger; filling the source position later is too late.
* The succeedable position can be appointed by another site or civ position with a fixed number of slots that has just been appointed. In this case, the succeedable position is just available for appointment itself, nothing more
* Any situation occurring during world generation.
* The succeeding position is [REPLACED_BY] the succeedable position. In this case, replacement removes the unit from the source position first, leaving no holder available for the succession mechanism to use.
* The position is [APPOINTED_BY] a civ-level position, that just became a citizen of your fortress. It must be noted that those civ-level positions were active all that time and the succeedable position could be appointed even before. The monarchs arrival does not trigger premature succession
* A [SQUAD]-position cannot inherit another [SQUAD]-position. This also means that premature succession will not work in this case.

=Losing a position=

A unit can lose a position when:
* It dies
* It succeeds another position, even if it has nothing to do with the previous position.
* It is assigned to another SQUAD-holding position
* It is convicted of a crime.
* Another unit is ELECTED for the position
* It is convinced by an adventurer to give up its position, or is overthrown in a coup.
* Its position becomes replaced
* Another unit is appointed by the player, or the position is left vacant.
* It has assumed another position (of the same entity), as this always leaves the previous position vacant.

Note: A unit does not lose a position when the unit leaves the group (entity). Neither will a unit lose a position, if the corresponding entity is considered to be dead.

=Embarkment=
Two types of positions are automatically filled by embark.
* Positions without [APPOINTED_BY] or [ELECTED] (assumable). All these positions, even with a NUMBER higher than 1, are all filled with one to three dwarves. Contrary to assumption, this doesn't take into account any limitations. REJECTED_CLASS, ALLOWED_CLASS, REJECTED_CREATURE, ALLOWED_CREATURE and GENDER are applied, but without the normal spread you may expect with assumptions. Also it doesn't look at [SUCCESSION] and [SQUAD] limitations.
* Positions that are elected are filled-in by the normal election rules.

Positions that have a defined appointer are never initially filled at embark.

All positions that don't have [REQUIRES_POPULATION] or with a [REQUIRES_POPULATION] of 7 or lower, will be available at embark.

=Land Holders=

A Landholder is a '''special civ-level noble''' who gets a certain piece of land to hold, when that land is elevated to a certain level, determined by the [LAND_HOLDER] tag, and by the landholder triggers in the game's settings. In vanilla, these are the baron, the count and the duke.

A unit gaining the landholder position does not migrate to that specific named land. In world-gen, they stay just where they are, probably at the capital. In fortress mode, you can suggest a citizen for the role. So for the time being that works.

Succession is then a real issue. If you use BY_HEIR, its solved when that landholder has children living at your site. But when its not the case, the title just goes to anyone randomly. Succession BY_POSITION works, but only in the civ-chain, and there's no way to guarantee a civ-holder is at your site at that time. Even with 'automatic spread' positions, it goes to one of them randomly.

==Functioning of the regular landholder chain==

The distinct difference between a landholder and a regular civ-level noble, is that a landholder may gain the position of landholder "of (sitename)" They are then seen as ruler of a particular site.

For a land_holder position to function as such, it has a few requirements:
* NUMBER:AS_NEEDED
* The first landholder-number of 1 is defined.
* No SITE (so civ) tag in that position.
*REPLACED_BY the next level landholder
If a landholder is defined with differentiating properties, it will function like a regular noble. A higher-up landholder that lacks the required tokens or connections will then not be used in elevation.

If a fortress meets the trigger for a new LAND_HOLDER tier when a caravan leaves, then the next time the outpost liaison or equivalent arrives, they will offer to make you an official colony, which will allow you to select all positions for that LAND_HOLDER level. Each time they appear, the outpost liaison will only promote your fortress one tier up the LAND_HOLDER track.

The landholder's LAND_NAME is not required for the functioning of this system. If omitted, messages will be shown with a more generic text.

==Appointment==

This mechanism differs from the regular methods of position management. It ignores all regular appointment- and election rules, so it more or less functions like automatic assignment. A landholder is, in vanilla, appointed by the monarch. Changing this doesn't seem to do anything. If they are appointed by a site-position, a not-yet-existing civ-position, or not appointed at all: the system keeps working as usual.

A landholder can appoint civ-positions and site positions. This works as expected: the positions only are appointed then when that landholder becomes available on civ-level or when he arrives at that site for site-level positions.

If your rank of landholder is the first of its rank in the realm, and is the sole appointer of some civ-position, then immediately as it gains the title, it will appoint the empty civ-slots. This may happen on your site, but the frequency and certainty is hard to determine.

==Succession==

Succession rules are applied to some extent:
* In world-gen it works according to succession rules, and site-positions can be used here. This means that a site position or a civ-position can inherit a landholder position, and vice versa.
* In fortress mode, once a landholder has been appointed, it then can inherit civ-level positions, and vice versa. This means that your baron can become king.
* Succession rules do not apply within the [LAND_HOLDER] chain; a count will not inherit a baron's land. This is because succession does not work well with the AS_NEEDED token.
* Premature succession works in fortress mode with landholders. If a unit gets a landholder's position and that landholder is the appointer of an as yet empty position, which is defined as succeeding from a third one, then the succession is immediately applied. The landholder themselves can even be the successor of a newly created position.
* A landholder's position is, in fortress mode, not successionable by a site-position or vice versa

===Impossibilities for succession by a site-position===
It would be very beneficial if the landholder can be succeeded by a [SITE]-position. So far, the following tests have not lead to positive results:
* making landholder and site-position both non-[DUTY_BOUND]
* make the site-position be [APPOINTED_BY] the landholder and/or the monarch
* give landholder and site-position [REJECTED_CREATURE]
* Let the monarch live at your site when succession could happen.
* Let the site-position be [REPLACED_BY] the landholder.

If the vanilla [SUCCESSION:BY_HEIR]-tag is omitted, a seemingly random unit somewhere in the realm is assigned this position.

==Nomination==

The player is able to nominate a unit to become the LAND_HOLDER, but this only works with units of [LAND_HOLDER] level 1. The player can select all units, only limited by the PRECEDENCE of the current units' positions.

A unit that has a position with a PRECEDENCE lower or equal to that of the landholder's position, cannot be selected. This means that a baron (or count) from another site or the monarch cannot be selected, because their precedence is lower or equal.

The GENDER token does not work here: also units with the wrong gender (sorry) can be selected.

==Levels==
In mods, up to 10 levels of LAND_HOLDER may be defined.

If a landholder is replaced by a wrong landholder number (1 replaced by 3), then the number 3 is still correctly attached to the settlement.

If the current landholder has the highest available landholder number, then the next elevation will not happen - the diplomat will not elevate your fortress to a higher position, even if that position might be REPLACED_BY a lower landholder.

These chains do work:
* 1 -> 2a - > 2b -> 3
* 1 -> 3 -> 2 -> 4

These chains do not work:
* 2 -> 3 (need to start at 1)
* 1 -> 4 -> 2 -> 3 (stops after 4 as the highest)
* 1a -> 2, 1b -> 2 (only 1a and 2 work, 1b is not used)

==Moving landholders==

It may happen that a land-holder no longer lives at the site which they are the landholder of, specifically when the current landholder dies, leaving the title to an heir living somewhere else.

To prevent this from happening, you can make their succession from heir and make sure that their kids live at your site. Or, you can make their position succeeded by another civ position, and make it so that this civ position is somehow available on your site. But if multiple of these positions exist, it cannot be guaranteed that a citizen of your fortress will inherit the title.

In world gen, a landholder lacking the DUTY_BOUND-token will also move to the site they like, according to legends mode.

==Replacement by a generic civ-position==

If a landholder is replaced by an AS_NEEDED non-landholder civ-position, then this will work: the current landholder loses that title upon settlement-elevation and gains that civ-title. However, the civ-title lacks the landholder-property of being attached to the land. It will not show the name of the settlement alongside the position's name. So no "minister of Shovelmounts"

If a landholder is replaced by a general AS_NEEDED civ-position, that itself is also replaced by a generic AS_NEEDED civ-position, then firstly the elevation is executed and also the unit gains that new position. However, he immediately loses it, because an AS_NEEDED position that is replaced by another position can be filled initially, but units wont be able to hold that title.

==Landholder with fixed number==

A landholder's position that has a fixed number will be created and filled directly when the civilisation is born, so this position slot is then not available for the regular landholder-mechanic and will also not be used. That landholder will thus not be attached to a settlement.

It doesn't matter if the landholder's position is connected to the regular landholder's-chain with the REPLACE_BY token.

==Responsibilities==

When given a certain [RESPONSIBILITY], a landholder may function as a regular civ-level noble. If the position has [TRADE] or [OUTPOST_NEGOTIATING] responsibilities, then the landholder functions both as a diplomat and as an actual land holder. A landholder with the [MILITARY_STRATEGY] responsibility will travel around taming creatures in world-gen, according to legends mode.

Besides that, the responsibilities work the same as with any other on-site living position-holder, civ or otherwise.

=Military=
==Squad management==
In the vanilla game, the Squad interface only becomes available after a militia commander has been appointed. Until then, the window displays:{{DFtext|You must appoint somebody first to create a squad.}}

What’s surprising is how this is determined internally. In the entity raw definition, '''only the last two positions that include a [SQUAD] token are checked''' to decide whether the interface is accessible at all. As a result, if your hierarchy defines commanders A through E, appointing '''Commander D or E''' unlocks squad formation, while appointing A–C does nothing.

In other words, squad availability is not tied to ''having a militia commander'', but to ''which specific positions happen to be last in the raw list''—a notably hacky implementation.

These 'last two' are always the last two '''available positions.''' So if they get [REPLACED_BY] or become available because of [REQUIRES_POPULATION], the game adapts to those.

==Squad assignment==

Squads can be assigned, even if the leader position has no holder.

A specific unit can only have one position associated with a squad. If it gains another 'squad holding position', it is unassigned from the first one. This does not work with a 0-squad, so only 1+squads are taken into consideration. This technique can possibly be used to distribute all positions equally among all citizens. It does however not work with election and assumption.

If a civ-level position is associated with a squad and it gets a site-level squad-holding position assigned, it loses the current civ-position.

Squads can get really messed up, if you make the position (or multiple) either elected or not-elected and not-appointed, then this can cause the game to assign multiple squads to the same unit. Automatic assignment and election does not take squads into account, but the nobles screen does. This can cause the positions to be cleared as the game figures out that they have more than one position, and immediately get elected or assumed again.

Positions that cannot have a squad-position:
* A site- or civ-position with a [SUCCESSION] token cannot be appointed a squad-holding-position. The other way around, however, does work. For example, if a site-position with a [SUCCESSION]-token is appointed to a unit that has already a position with [SQUAD]. But when that squad position is assigned to another unit, it cannot be assigned back.
* A position with [SUCCESSION] can also not be assigned as a '''member''' of a squad.
* A squad-holding position with a formed squad cannot be appointed to another squad holding position.

If a position has at least one squad member, it cannot be left vacant. First, the squad has to be disbanded, then the position may be cleared.

==0-squads==
A 0-Squad is defined in a position as [SQUAD:0:member:members]. It does not seem to do anything useful as of now.
* It cannot be used to activate the [[Squad|military interface]]
* It does not restrict the assignment of [SUCCESSION] positions.
* Assigning this position does not clear any previously held squad position.
* The [[Leader]] and [[Tactician]] skill are not marked as relevant skills and are not taken into account in elections.
* It cannot be formed as a squad.

=Further testing=
The following questions may need additional testing. Feel free to add or answer
* Everything regarding COMMANDING and army-structure
** [http://www.bay12forums.com/smf/index.php?topic=175437.msg8331668#msg8331668]
** [http://www.bay12forums.com/smf/index.php?topic=165213.msg8335682#msg8335682]
** [http://www.bay12forums.com/smf/index.php?topic=174584.msg8026854#msg8026854]
* Stuff about the monarch, its arrival and its entourage.

=Oddities (Bugs)=
Almost everything on this page could be called an oddity. Because of their unexpected usability, some may also be referred to as “undocumented features.” Others, however, are simply odd and not particularly useful, yet I hesitate to call them “bugs.”
* If a certain threshold is reached that makes an elected position electable, and the triggering event that initiates this evaluation is an assumption, then the resulting assumption works partially as an election. It referred to in the messages as an election and the [REJECTED_CREATURE]-token is not applied, like it is with assumptions.

=Examples=

===The Founder===
The founder is a single dwarf, appointed at embark. They will be the only one ever to have this position and are not replaceable. When they lose their position some way, the position will not be assumed by another dwarf.
{{gamedata|title=The Founder|
[POSITION:THE_FOUNDER]
[NAME:the founder:founders]
[NUMBER:1]
[SITE]
[ALLOWED_CREATURE:DWARF:ALL] - will only be filled at embark, but not assumable later.
[REJECTED_CREATURE:DWARF:ALL] - will only be filled at embark, but not assumable later.
[SUCCESSION:BY_POSITION:THE_FOUNDER] - not unassignable, also cannot be assigned to a [SQUAD] position.
[PRECEDENCE:200]
Non APPOINTED_BY
Non ELECTED
Optional: Add responsibilities to make the game select a unit with certain skills.
}}
===Marriage bar===
Dwarven matrons are held in great honour. Upon marriage, a female dwarf is no longer expected to perform menial labour. All dwarven males hold this position by default, granting their spouses exemption from menial work.

The position becomes available with the arrival of the first migrants; otherwise, on embark, it would be assumed by females. Its succession rule is non-functional, but this prevents the player from unassigning the position. A squad size of 1 and the succession rules together prevent a unit from assuming the position more than once.

With precedence set to NONE, the position name is hidden, while LAND_NAME remains visible on the nobles screen. All married females receive the suffix “, Mrs.” and are marked as Nobles.

The practical usefulness of this position is debatable, but it serves as a clear demonstration of several mechanics.
{{gamedata|title=Mrs. Urist|

[POSITION:MRS_URIST]
[NUMBER:300]
[SITE]
[ALLOWED_CREATURE:DWARF:MALE]
Not APPOINTED_BY
Not ELECTED
[LAND_NAME:Dwarven male]
[NAME:dwarven male:dwarven male]
[PRECEDENCE:NONE]
[SPOUSE_FEMALE:, Mrs.:spouses]
[MENIAL_WORK_EXEMPTION_SPOUSE]
[REQUIRES_POPULATION:8]
[SUCCESSION:BY_POSITION:MONARCH]
[SQUAD:1:member:members]
}}
===The Archduke===
The archduke is the leader of the civilization, but exists only from landholder 4-level. Until then, its position remains vacant. When a settlement is elevated to tier 4 (grand duke), the grand duke can appoint the ruler of the civilisation, the archduke. Because of 'Premature Succession', they themself inherit that position immediately, but only when in fortress mode. Its heir then becomes grand duke.
{{gamedata|title=The Archduke| no POSITION:MONARCH or other PRECEDENCE:1

[POSITION:THE_ARCHDUKE]
[NAME:archduke:archdukes]
[NAME_MALE:archduke:archdukes]
[NAME_FEMALE:archduchess:archduchesses]
[LAND_NAME:a archduchy]
[NUMBER:1]
[PRECEDENCE:1]
[SUCCESSION:BY_POSITION:GRAND_DUKE]
[APPOINTED_BY:GRAND_DUKE]
(add additional monarch-stuff, like spouse name, demands etc.)

[POSITION:GRAND_DUKE]
[NAME:grand duke:grand dukes]
[NAME_MALE:grand duke:grand dukes]
[NAME_FEMALE:grand duchess:grand duchesses]
[NUMBER:AS_NEEDED]
[LAND_HOLDER:4]
// Optional ...
[PRECEDENCE:19]
[LAND_NAME:a archduchy]
[RESPONSIBILITY:LAW_MAKING]
[RESPONSIBILITY:RECEIVE_DIPLOMATS]
[SUCCESSION:BY_HEIR]
[APPOINTED_BY:THE_ARCHDUKE]
(add additional landholder-stuff)

!!add to [POSITION:DUKE]
[REPLACED_BY:GRAND_DUKE]

}}
{{Category|Modding}}
{{Category|Entities}}
{{Category|Guides}}

Deity

2026-09-26T15:36:37Z

Silverwing235: /* Deities of your World */ clarify

{{Quality|Exceptional|17:53, 26 February 2023 (CST)}}
{{av}}
[[File:deity_icon_preview.png|200px|right]]A '''deity''' is a supernatural being or force of nature in the mythology of a world. Deities are overarching figures of the game's world, and are randomly generated during [[World generation|worldgen]], along with their corresponding [[divine metal]] and assigned different [[sphere]]s (the objects, creatures, concepts, etc. they are associated with). [[Religion|Religious]] [[creature]]s may worship one or more deities. Though deities remain unseen in standard gameplay, they are powerful, influential overarching forces behind a large amount of factors in the game.

Worship of deities correlates to what [[civilization]] a creature belongs to. [[Civilization#Mountain|Mountain]] and [[Civilization#Plains|plains]] civilizations worship multiple deities, most of which are often depicted as being of their main species, though, on occasion, they may worship a deity that is depicted as an [[animal]] or [[vermin]]. [[Religion]]s are able to spread across multiple civilizations. [[Civilization#Forest|Forest]] civilizations do not worship deities, and instead believe in a particular [[force]] amongst multiple such that permeate the forests. [[Civilization#Evil|Evil]] and [[Civilization #Skulking|skulking]] civilizations, meanwhile, do not worship anything by default. Because worship is denoted by civilization, it is possible for elves, goblins, or [[animal people]] who have joined a religious civilization to worship their deities.

''Note:'' Despite his meta importance, [[Armok]] doesn't actually exist as an in-game deity.

== Deities of your world ==
The easiest way to see what deities exist in your fortress's world is to create a zone > meeting area > temple, and then that screen will list the different deities that your current dwarves worship. A mouse-hover will show how many citizens worship a certain deity, plus a list of the deity's [[Sphere|spheres of influence]].

Although it has little effect on the game in fortress mode, fuller descriptions of the various gods can be read in [[legends mode]].

==Fortress mode==
Each dwarf, and many other creatures ({{token|INTELLIGENT}}/{{token|CAN_LEARN}}+{{token|CAN_SPEAK}} ''at least, such was presumably the intent''), have one or more deities listed among their [[relationship]]s. Almost all dwarves believe in at least one deity; most in two, and some, three. In the case of your dwarves, you can see the degree of belief they profess (''"faithful worshipper"'', ''"casual worshipper"'', etc.). Praying to deities is one of the most common ways a dwarf can fulfil their [[need]]s.

[[Fortress mode]] includes [[temples]] that can be dedicated to individual deities. The deities are also represented in [[statue]]s, [[engraving]]s and [[figurine]]s.

==Adventurer mode==
[[File:deity_view.png|thumb|240px|right|Deity seen before the game begins.]]Adventurers can select a deity or religion to follow during character creation, and choosing for them to be more than a casual worshipper will add the [[need]] to pray, which can be satisfied by {{Adv menu icon|k}} [[talking]] to them. Joining a [[religion]] or assuming an [[Name#Other names/false identities|identity]] will allow you to worship new gods.

In [[adventurer mode]], [[site]]s such as [[Monastery|monasteries]], fortresses, and human towns may contain [[temple]]s of various designs, possibly inhabited by [[priest]]s dedicated to a deity - if a worshipper of that deity were to desecrate a statue at that temple, there may be [[Cursed|consequences]]. Shrines may also be found at those and other types of sites where [[dice]] can be found, which can be rolled to maybe gain a boon or curse.

If the player selects the "Chosen" adventurer type, they will be connected to a deity, with a (''divinely-ordained'') destiny that must be fulfilled. Before the game begins, a portrait of the deity will be seen, explaining their quest to the adventurer. Selecting this path will have a deity as the adventurer's parent or supporting patron.

==Interaction in the world==
{{imagefix|[[File:Announce dietycurse icon.png|left]]|5}}
Deities occasionally influence events during world generation. Gods of death can create slabs, from which [[necromancer]]s learn the secrets of life and death. Furthermore, civilized creatures that profane a temple of the deity they worship incur the wrath of their former patron, being turned into a [[vampire]] or [[werebeast]] as punishment (even though being [[Immortality|immortal]] is not really a punishment to some).

{{Spoiler}}

Deities may occasionally collaborate with a [[demon]], raising it up from the underworld with a ritual conducted by an [[artifact]] [[slab]]. This is, in fact, exactly how said demons escape the [[Underworld]] and gain status in the mortal world. What demon in question is summoned, as well as the reason for this, appears to be linked to the god's particular [[sphere]]. For example, gods of death may summon demons "that more may die"; war-gods conduct the ritual "that war may rage forever" or "that great fortresses be raised and tested in siege". Gods of bravery and valor, meanwhile, do the same "that great acts of heroism may be performed." (Admittedly, anyone who can navigate a demonic site and come out alive should rightfully be called more than a great hero!)

Deities are served by [[angel]]s, randomized creatures who may wield equipment made of impossibly strong [[divine metal]] created by the deity. Angels are best known for guarding the contents of [[vault]]s, the treasure-houses of allied [[demon]]s; they may be the most exceedingly powerful and dangerous creatures in ''Dwarf Fortress'', more so than even demons. Successfully raiding a vault is a feat on par with conquering the Underworld—you may use the knowledge on the vault's slab all you want, but it's a tiny reward compared to vanquishing ''the forces of Heaven itself''.

== A world without deities ==
{{mod}}
Deities can be removed from the game through [[Entity token|modding entity raws]], by making all civilizations become areligious. In such a world, demonic leaders thrust the spire of slade by themselves, and place the slab in a vault created on their own. The vault is then left unguarded, since no [[angel]]s can exist without deities.

Removing deities makes [[vampire]]s, [[werebeast]]s, and [[necromancer]]s never spawn, as these can (currently) only be created through divine intervention.

== Physically summoning deities into the world ==

{{mod}}

Deities don't usually manifest themselves physically in vanilla DF, but they can be helped with a [http://www.bay12forums.com/smf/index.php?topic=164123.msg8361144#msg8361144 DFHack script]. The script doesn't just create a unit that 'looks' like the deity, it actually pulls the [[historical figure]] info from the deity and creates a [[nemesis]] record to link it to the newly created unit. Use with caution.

A deity will use the {{Raw tile|Ä}} tile instead of their corresponding creature tile.

[[File:deity3_preview.png|thumb|300px|center|This is Cintra, the goddess of [[cave-in]]s. With enough worship, enemy caves just collapse without warning.]]
{{Translation
| dwarven = mishar
| elvish = ricafa
| goblin = alsmust
| human = ahang
}}
{{Category|World}}
{{Category|Relationships}}
{{Category|Religion}}
[[ru:Deity]]

Deity

2026-09-26T12:34:02Z

Silverwing235: /* Adventurer mode */

{{Quality|Exceptional|17:53, 26 February 2023 (CST)}}
{{av}}
[[File:deity_icon_preview.png|200px|right]]A '''deity''' is a supernatural being or force of nature in the mythology of a world. Deities are overarching figures of the game's world, and are randomly generated during [[World generation|worldgen]], along with their corresponding [[divine metal]] and assigned different [[sphere]]s (the objects, creatures, concepts, etc. they are associated with). [[Religion|Religious]] [[creature]]s may worship one or more deities. Though deities remain unseen in standard gameplay, they are powerful, influential overarching forces behind a large amount of factors in the game.

Worship of deities correlates to what [[civilization]] a creature belongs to. [[Civilization#Mountain|Mountain]] and [[Civilization#Plains|plains]] civilizations worship multiple deities, most of which are often depicted as being of their main species, though, on occasion, they may worship a deity that is depicted as an [[animal]] or [[vermin]]. [[Religion]]s are able to spread across multiple civilizations. [[Civilization#Forest|Forest]] civilizations do not worship deities, and instead believe in a particular [[force]] amongst multiple such that permeate the forests. [[Civilization#Evil|Evil]] and [[Civilization #Skulking|skulking]] civilizations, meanwhile, do not worship anything by default. Because worship is denoted by civilization, it is possible for elves, goblins, or [[animal people]] who have joined a religious civilization to worship their deities.

''Note:'' Despite his meta importance, [[Armok]] doesn't actually exist as an in-game deity.

== Deities of your World ==
The easiest way to see what deities exist in your fortress is to create a zone > meeting area > temple, and then that screen will list the different deities that your current dwarves worship. A mouse-hover will show how many citizens worship a certain deity, plus a list of the deity's [[Sphere|spheres of influence]].

Although it has little effect on the game in fortress mode, fuller descriptions of the various gods can be read in [[legends mode]].

==Fortress mode==
Each dwarf, and many other creatures ({{token|INTELLIGENT}}/{{token|CAN_LEARN}}+{{token|CAN_SPEAK}} ''at least, such was presumably the intent''), have one or more deities listed among their [[relationship]]s. Almost all dwarves believe in at least one deity; most in two, and some, three. In the case of your dwarves, you can see the degree of belief they profess (''"faithful worshipper"'', ''"casual worshipper"'', etc.). Praying to deities is one of the most common ways a dwarf can fulfil their [[need]]s.

[[Fortress mode]] includes [[temples]] that can be dedicated to individual deities. The deities are also represented in [[statue]]s, [[engraving]]s and [[figurine]]s.

==Adventurer mode==
[[File:deity_view.png|thumb|240px|right|Deity seen before the game begins.]]Adventurers can select a deity or religion to follow during character creation, and choosing for them to be more than a casual worshipper will add the [[need]] to pray, which can be satisfied by {{Adv menu icon|k}} [[talking]] to them. Joining a [[religion]] or assuming an [[Name#Other names/false identities|identity]] will allow you to worship new gods.

In [[adventurer mode]], [[site]]s such as [[Monastery|monasteries]], fortresses, and human towns may contain [[temple]]s of various designs, possibly inhabited by [[priest]]s dedicated to a deity - if a worshipper of that deity were to desecrate a statue at that temple, there may be [[Cursed|consequences]]. Shrines may also be found at those and other types of sites where [[dice]] can be found, which can be rolled to maybe gain a boon or curse.

If the player selects the "Chosen" adventurer type, they will be connected to a deity, with a (''divinely-ordained'') destiny that must be fulfilled. Before the game begins, a portrait of the deity will be seen, explaining their quest to the adventurer. Selecting this path will have a deity as the adventurer's parent or supporting patron.

==Interaction in the world==
{{imagefix|[[File:Announce dietycurse icon.png|left]]|5}}
Deities occasionally influence events during world generation. Gods of death can create slabs, from which [[necromancer]]s learn the secrets of life and death. Furthermore, civilized creatures that profane a temple of the deity they worship incur the wrath of their former patron, being turned into a [[vampire]] or [[werebeast]] as punishment (even though being [[Immortality|immortal]] is not really a punishment to some).

{{Spoiler}}

Deities may occasionally collaborate with a [[demon]], raising it up from the underworld with a ritual conducted by an [[artifact]] [[slab]]. This is, in fact, exactly how said demons escape the [[Underworld]] and gain status in the mortal world. What demon in question is summoned, as well as the reason for this, appears to be linked to the god's particular [[sphere]]. For example, gods of death may summon demons "that more may die"; war-gods conduct the ritual "that war may rage forever" or "that great fortresses be raised and tested in siege". Gods of bravery and valor, meanwhile, do the same "that great acts of heroism may be performed." (Admittedly, anyone who can navigate a demonic site and come out alive should rightfully be called more than a great hero!)

Deities are served by [[angel]]s, randomized creatures who may wield equipment made of impossibly strong [[divine metal]] created by the deity. Angels are best known for guarding the contents of [[vault]]s, the treasure-houses of allied [[demon]]s; they may be the most exceedingly powerful and dangerous creatures in ''Dwarf Fortress'', more so than even demons. Successfully raiding a vault is a feat on par with conquering the Underworld—you may use the knowledge on the vault's slab all you want, but it's a tiny reward compared to vanquishing ''the forces of Heaven itself''.

== A world without deities ==
{{mod}}
Deities can be removed from the game through [[Entity token|modding entity raws]], by making all civilizations become areligious. In such a world, demonic leaders thrust the spire of slade by themselves, and place the slab in a vault created on their own. The vault is then left unguarded, since no [[angel]]s can exist without deities.

Removing deities makes [[vampire]]s, [[werebeast]]s, and [[necromancer]]s never spawn, as these can (currently) only be created through divine intervention.

== Physically summoning deities into the world ==

{{mod}}

Deities don't usually manifest themselves physically in vanilla DF, but they can be helped with a [http://www.bay12forums.com/smf/index.php?topic=164123.msg8361144#msg8361144 DFHack script]. The script doesn't just create a unit that 'looks' like the deity, it actually pulls the [[historical figure]] info from the deity and creates a [[nemesis]] record to link it to the newly created unit. Use with caution.

A deity will use the {{Raw tile|Ä}} tile instead of their corresponding creature tile.

[[File:deity3_preview.png|thumb|300px|center|This is Cintra, the goddess of [[cave-in]]s. With enough worship, enemy caves just collapse without warning.]]
{{Translation
| dwarven = mishar
| elvish = ricafa
| goblin = alsmust
| human = ahang
}}
{{Category|World}}
{{Category|Relationships}}
{{Category|Religion}}
[[ru:Deity]]

Advanced world generation

2026-09-26T11:30:59Z

Silverwing235: /* Poles */ grammar (and spelling) ensues

{{Quality|Superior}}
{{av}}
:''This article contains information on advanced world generation. For information on basic world generation, see [[World generation]].'' ''See [[World token]] to more easily find information by the names used in the world_gen.txt file, [[World rejection]] for information on solving problems related to worlds always being rejected, and [[Worldgen examples]] for example worlds.''

[[File:adv_worldgen_v50.png|thumb|400px|right|The advanced world generation screen. ''(Click to enlarge)'']]'''Advanced world generation''', also labeled as '''detailed mode''', allows substantially more detail-oriented options of customization than standard, basic world generation. This gives the player much more control over how their world is generated. To better understand this article, it is advised that one should read about [[World generation|'''basic world generation''']] first.

The advanced world generation screen is reached by clicking "Create new world" at the main menu, then clicking "Detailed mode". Once at that screen, clicking "Basic options" will return the user to the standard world generation screen.

== Parameter sets ==
There are multiple default sets of all the advanced world generation parameters hard-coded in ''Dwarf Fortress'', which will be overridden by the <tt>prefs/world_gen.txt</tt> file in the main ''Dwarf Fortress'' directory, if it exists. It does not exist by default, you must create it, either by saving the default sets, or saving a copy from the [[world_gen.txt]] wiki page or elsewhere. This file can then be edited with a text editor, and you can copy and paste other players' sets of parameters into it. For sources of such parameter sets see [[Advanced_world_generation#Parameter_set_examples|Parameter set examples]] below.

To get back the default sets, move the existing <tt>prefs/world_gen.txt</tt> to somewhere else (like Documents), or delete it if you do not want to keep the changes, then load the sets in the game, it will then use the hardcoded defaults.

== User interface ==
First, there is a line of text inputs and buttons along the top of the screen, from left to right:
* The drop down menu of currently defined parameter sets, click the down arrow to select a set that you want to work with. The currently selected set can be renamed by clicking the current name or the [[File:Quill.png]] button. The first set in the file is selected by default, usually "LARGE ISLAND". See [[#Parameter set title|Parameter set title]].
* The dimensions of the world for the selected set, see [[#World dimensions|World dimensions]].
* A text entry box to set all of the seed options to the same seed, will show "Random seed", "Various seeds", or, if all four seeds are set to use the same value, that value. See [[Advanced_world_generation#Seed_values|Seed values]] and [[Advanced_world_generation#Seed_values|Seed notes]].
* The Copy Button to make a copy of the currently selected set and appends it to the bottom of the list.
* The red Delete button to delete the currently selected set, you will be prompted to confirm the deletion.
* The New parameter set to create a new parameter set and appends it to the bottom of the list. This seems to just copy the default "LARGE REGION" set.
* The Save button to save all of the current sets to the <tt>prefs/world_gen.txt</tt> file.
* The Load button to load from the same file, there is no confirmation, '''any unsaved changes will be lost'''. If that file does not exist, this resets all of the sets to the defaults.

Most of the middle is the parameters themselves, with a scroll bar to the right. Each row of the list can include:
* The name of the option
* The range of accepted values; not every option has this, and does not always match the displayed value, for example "0 to 1" might show as "No" and "Yes".
:* Sometimes the range might not initially show on rows that it should, reloading the sets with the Load button sometimes fixes that.{{bug|13176}}
* A plus button to increase the value or cycle through options, when applicable (this button will be missing if the range is missing.)
* The current value; can be clicked to edit, to actually set a value you must press {{k|enter}}, without doing that, clicking another entry box or right clicking will instead reset to the currently set value.
* An edit button to show that the previous box is editable, same as clicking on the text box.
* A minus button to decrease the value or cycle through options, when applicable (this button will be missing if the range is missing).
* A red button to disable this parameter, when applicable, usually setting the value to 0, or -1.

{{notice bar|bgcolor=#faa|bordercolor=#f00|All of the buttons below leave this screen and do not prompt to save the sets, so unsaved changes may be lost.}}
At the bottom right are 3 or 4 more buttons:
* The Create world button to do just that using the currently selected set, '''unsaved changes are lost'''.
* The Basic options button to go back to the normal world generation screen, unsaved changes are not lost if you come directly back to Detailed mode.
* The [[Mods]] button to go to the mod selection screen, unsaved changes are not lost if you come directly back to Detailed mode. Only shown if mods are available.
* Back to main menu button to do just that, '''unsaved changes are lost'''.

=== World painter ===
:''Main article: [[World painter]]
The '''world painter''' tool is not in the current version of ''Dwarf Fortress''; it allowed you to paint features onto a map. '''However''', those maps can still be used when generating a world by pasting world painter parameter set maps created in old versions into the <tt>prefs/world_gen.txt</tt> file. [[Utilities#Perfect_World_DF|Perfect World DF]] is a utility that uses the same parameter functionality as the world painter to paint a map, and it also can work with the current version of ''Dwarf Fortress''.

== Generating a world ==
You can either use an already-defined parameter set, or you can edit them, though it is highly suggested to edit a copy of one of the defaults. Once you are happy with the parameters you should save the values you just edited before you click the Create world button. Information about each parameter is documented below.

The phases of the world generation process are (this order is not completely correct):
* Preparing elevation...
* Setting temperature...
* Running rivers...
* Forming lakes and minerals...
* Growing vegetation...
* Verifying terrain...
* Importing wildlife...
* Recounting legends...
* Placing civilizations...
* Making cave civilizations...
* Making cave pops...
* Placing other beasts...
* Placing megabeasts...
* Placing good/evil...
* Placing caves...
* Prehistory generation
* Finalizing civ mats...
* Finalizing art...
* Finalizing uniforms...
* Finalizing sites...

== Seed notes ==
The world generation process uses a PRNG (Pseudo Random Number Generator) algorithm. A PRNG will produce a sequence of numbers that "looks" random, even though the actual sequence of numbers will always be the same if the PRNG is started with the same seed value. Basically this means that if you run world generation with a certain seed value on your computer, and someone else runs world generation with the same seed value on their computer, the same sequence of random numbers will be generated on both computers. The practical impact of this is that someone else can generate exactly the same world that you generated by entering the same seed value that you used.

In the current version, the seed values for the world itself and the names seem to produce the same result, but you will get changes in events which will result in a very different world history.{{bug|6934}} Keep this in mind if you want to regenerate a particular world.

The way that a world is generated can also be affected by certain world tokens. Changing them causes that code to use more or fewer PRNG values, causing later uses to get different parts of the sequence. So, you cannot for example, change the minimum and maximum rainfall and get 'the same world but drier or wetter', instead, a different world is generated. That said, it would also seem that certain small changes to these world tokens can occasionally generate a very similar world, however, other tokens are more sensitive. For more information see the forum thread [http://www.bay12forums.com/smf/index.php?topic=112132.msg3404199#msg3404199 here].

The following are tokens which use the PRNG values in ways that changing them will likely cause broader changes:

* [DIM:X:X]
* [ELEVATION:X:X:X:X]
* [RAINFALL:X:X:X:X]
* [TEMPERATURE:X:X:X:X]
* [DRAINAGE:X:X:X:X]
* [VOLCANISM:X:X:X:X]
* [SAVAGERY:X:X:X:X]
* [ELEVATION_FREQUENCY:X:X:X:X:X:X]
* [RAIN_FREQUENCY:X:X:X:X:X:X]
* [DRAINAGE_FREQUENCY:X:X:X:X:X:X]
* [TEMPERATURE_FREQUENCY:X:X:X:X:X:X]
* [SAVAGERY_FREQUENCY:X:X:X:X:X:X]
* [VOLCANISM_FREQUENCY:X:X:X:X:X:X]
* [PARTIAL_OCEAN_EDGE_MIN:X]
* [COMPLETE_OCEAN_EDGE_MIN:X]
* [HAVE_BOTTOM_LAYER_1:X]
* [MINERAL_SCARCITY:X] {{cite talk/this|Mineral scarcity}}

Many other world parameters, such as end year and embark points, can, however, be changed without it having any effect on the geography of the world generated from the seed values.

Normally, you don't enter these seed values, the game comes up with values based on some other sort of pseudo-random information from things like the current date and time.

When generating a world, ''Dwarf Fortress'' records the seeds it used in [[gamelog.txt]]; they can also be found with <code>gui/gm-editor world.worldgen.worldgen_parms</code> in [[DFHack]].

== Advanced parameters ==
There are essentially 4 types of controls for the generation of the surface map;

'''Terrain parameters''': as described below, these 5 variables define the basic background world, how hot or cold it is, how much rainfall, how high the mountains are. The world automatically goes through the temperature range along the Y axis, although sometimes it will be hotter in the north, other times in the south, or cold at both. Minimum, maximum and X,Y variance can drastically alter the world.

'''Weighted meshes''': these are a way to fine-tune the amount of the 5 basic variables on the map. They can be used to set the specific distribution of different elevations or rainfall areas for example.

'''Feature parameters''': such as rivers, mountain peaks, volcanoes, and oceans, which can cause rejections if the terrain parameters don't allow enough suitable locations for the features to be placed.

'''Rejection parameters''': ''Dwarf Fortress'' uses a 'belt-and-braces' approach to world generation. The above controls allow you to shape the world, then the rejection parameters throw it out if it does not meet certain criteria. There are a number of rejection parameters for the number and degree of the 5 basic variables, for biome types, etc. If the world does not meet the requirements of any one rejection parameter the world is rejected and re-randomised. Also see [[World rejection]].

Leaving tokens out of a set in <tt>world_gen.txt</tt> will cause the game to use default values which are not adjusted for smaller world sizes, this may cause smaller worlds to always be rejected.

If you are experimenting with world design, there is also a [[Settings#Feature_toggles|game setting]] that will log the rejection reasons to ``[[map_rejection_log.txt]]``. With that information you can then either adjust the rejection parameters to allow those worlds, or the other parameters to prevent them from trying to generate. ''Dwarf Fortress'' will keep adding to the file, so you may want to trim or delete it occasionally.

The parameters are described below in the order that they appear in the list in the game, which is not necessarily the order they appear in <tt>world_gen.txt</tt>. See [[world token]] for an index that will help you look things up by token name. The tokens used in <tt>world_gen.txt</tt> are at the bottom of each of the following parameter descriptions.

=== Parameter set title ===
This sets the name of the parameter set itself, as used in the list of sets (this has nothing to do with the name of the generated world).
{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[TITLE:<name>]</nowiki></tt>
| <tt><nowiki>[TITLE:MEDIUM ISLAND]</nowiki></tt>
| Required
|}

=== World dimensions ===
The size of the map for the current set can be changed by changing the Width and Height values at the top next to the set title. You will need to confirm this, since changing the dimensions of the world will change other parameters, because many of them have different defaults depending on the surface area available.

Larger maps usually take longer to generate and may reduce [[Frames per second|FPS]] in-game, though this is really a matter of larger worlds usually having more civilizations, sites, historical figures, and events; restricting the number of those can speed up the process. Non-square maps may result in crashes{{bug|2928}}.
{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[DIM:<width>:<height>]</nowiki></tt>
| <tt><nowiki>[DIM:257:257]</nowiki></tt>
| Valid values are 17, 33, 65, 129, and 257, other values will use one of those. Changing the size in the file without adjusting other parameters can cause many rejections.
|}

=== Seed values ===
Enables the use of, and specifies seed values for, different parts of the world generation process. Just entering a specific seed does not enable it, that must be done separately, although using the box at the top to set all the seeds to the same value does enable them all. Enabling a seed puts the token in using what ever is in the text box below. If you enable a seed, but do not enter a seed, the string "Seed text" will be used (<tt><nowiki>[SEED:Seed text]</nowiki></tt>). Trying to use a <tt><nowiki>]</nowiki></tt> in the string in the file will end the seed there, since it closes the token, any text after that will be ignored. Normally, just leave these set to Random, unless trying to reproduce the results of a previous world generation. See also the [[Advanced_world_generation#Seed_notes|seed notes section]] above.
{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[SEED:<text>]</nowiki></tt>
| <tt><nowiki>[SEED:31337]</nowiki></tt>
| rowspan="4" |
For each of these not in the config file, a random seed will be used, and the first seed is not used to generate the others. The seeds used are output to [[gamelog.txt]] when world generation starts.
|-
| <tt><nowiki>[HISTORY_SEED:<text>]</nowiki></tt>
| <tt><nowiki>[HISTORY_SEED:31337]</nowiki></tt>
|-
| <tt><nowiki>[NAME_SEED:<text>]</nowiki></tt>
| <tt><nowiki>[NAME_SEED:31337]</nowiki></tt>
|-
| <tt><nowiki>[CREATURE_SEED:<text>]</nowiki></tt>
| <tt><nowiki>[CREATURE_SEED:31337]</nowiki></tt>
|}

=== World name ===
As previously mentioned, the title of the parameter set doesn't affect the name of the world. You can specify a particular name for your world, or leave the value blank for a random one. (The [[DFHack]] utility adds an option to rename the world using the in-game languages.)
{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[CUSTOM_NAME:<name>]</nowiki></tt>
| <tt><nowiki>[CUSTOM_NAME:Realm of Cheese Engravings]</nowiki></tt>
| For a random name, simply don't use this token.
|}

=== Embark Points ===
The number of points for equipment and animals when embarking in fortress mode (there is no equivalent setting for adventure mode). Normally, the default of 1504 is fine, but can be increased for various purposes like experimentation or to help dwarves survive in a particularly evil world, or reduced for certain [[challenges]].
{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[EMBARK_POINTS:<number>]</nowiki></tt>
| <tt><nowiki>[EMBARK_POINTS:1504]</nowiki></tt>
| 0 to 10,000
|}

=== End year ===
The maximum number of years generated for the world, although generation can be paused and the world used as is any time after the second year; the same as the [[World_generation#History|History]] parameter in basic world gen, except that you can enter an exact value. A too-short history can limit the materials available to civilizations, and [[Chosen|certain adventure mode features]] are only available after certain site events, while too long a history often leads to civilizations dying.

For more information on the history aspect of the game, see [[Legends]] and [[Calendar#Ages|Ages]].
{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[END_YEAR:<number>]</nowiki></tt>
| <tt><nowiki>[END_YEAR:250]</nowiki></tt>
| 2 to 10,000
|}

=== Population cap after civ creation ===
A soft limit to the total number of [[historical figure]]s alive at the same time during and post world generation across all civilizations, only preventing the birth of new historical figures.{{cite forum|140544/5701667}} Each civilization is allotted a percentage of the total by the percentage of sites they control.{{cite forum|159164/7553641}} Civilizations also have non-historical populations, and there is no setting to limit those (in early versions, all civilization members were historical figures, this is also why the name of this setting is misleading). Each [[entity]] also has limits from their raws, see the [[Entity_token#Population|population]] entity tokens, and setting this to unlimited will not remove those.

Huge historical figure populations can slow generation and the game in general.
{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[TOTAL_CIV_POPULATION:<number>]</nowiki></tt>
| <tt><nowiki>[TOTAL_CIV_POPULATION:15000]</nowiki></tt>
| -1 to 100,000, -1 is no limit
|}

=== Site cap after civ creation ===
Total number of [[site]]s that can be directly created by all civilizations combined like [[hillocks]], [[hamlet]]s, [[dark pits]], [[forest retreat]]s, etc. Does not prevent the placement of initial civilization sites, though they will then be counted for the limit. Does not affect creature sites like [[cave]]s or [[lair]]s, group sites like [[castle]]s, [[monastery|monasteries]], [[tower_(necromancy)|tower]]s, [[fort]]s, or [[camp]]s, or unpopulated sites like [[tomb]]s. After this limit is reached, no civilization will be able to place new sites. See the [[Entity_token#Placement|placement]] entity tokens for other ways that civilization site placement can be limited.

Increasing this will slow generation down and reduce the available places for player sites. Since the {{token|MAX_SITE_POP_NUMBER|entity}} entity token limits the historical figure population per site, this site cap can also limit the total historical figure population of all civilizations combined, and some expand faster than others getting more sites before the limit is reached.
{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[SITE_CAP:<number>]</nowiki></tt>
| <tt><nowiki>[SITE_CAP:1500]</nowiki></tt>
| -1 to 100,000, -1 is no limit
|}

=== Beast control ===

These parameters don't usually matter too much, but may matter for small numbers of beasts.

==== Percentage of Megabeasts and Titans Dead for Stoppage ====

The world starts out with a certain number of powerful megabeast and titan entities in existence. If a percentage of the megabeast and titan population dies out during history generation, then history generation will stop early. For example, if the elimination value is 80%, and the generated history starts with 200 entities and 160 of those 200 entities are eliminated by historical events before the End Year is reached, history generation will stop immediately.

If you want to end the creation of your world at the beginning of a certain age, choose the following values:
* Age of Legends: ~34%
* Age of Heroes: ~67%
If there are three or fewer titans or megabeasts in your world, the age will be given a special name reflecting the remaining megabeasts/titans, instead.

==== Year to Begin Checking Megabeast Percentage ====

The percentage of dead [[megabeast]]s and [[titan]]s for stoppage will not be checked until this year is reached in history generation. This can be used to ensure that a world reaches a certain year even if all of the megabeasts in the world are slain earlier.

If the number of living [[megabeast]]s and [[titan]]s starts at or drops to less than four, then world generation will always stop if the current year is equal to or greater than the Year to Begin Checking Megabeast Percentage ''regardless'' of how many [[megabeast]]s and [[titan]]s are dead — Percentage of Megabeasts and Titans Dead for Stoppage is ignored. The number of megabeasts and titans at the start of the world is set by the sum of the [[Advanced_world_generation#Max_Megabeasts_Caves|Max Megabeasts Caves]] and [[Advanced_world_generation#Titan_Parameters|Titan Number]] parameters.

{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[BEAST_END_YEAR:<year>:<percentage or -1>]</nowiki></tt>
| <tt><nowiki>[BEAST_END_YEAR:200:80]</nowiki></tt>
| Use -1 as percentage to disable. Year must still be at least 2.
|}

=== Cull Unimportant Historical Figures ===
{{main|Historical figure}}
Whether to remove unimportant dead historical figures after history generation; a short CPU-intensive step, but saves space which can speed up loading, saving, and running games with large histories. Legends mode will refer to culled creatures as "an unknown creature", and they will not appear in engravings, but likely would not have anyway.

Exactly what is considered important is not clear. A member of an abstract group killing a named creature is not important, nor is creating an artifact, even if that artifact had important history. Unculled historical figures can have parentage described as "The identity of" that parent "has been lost to time", so just having children is not, though having living direct relations seems to prevent culling.

{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[CULL_HISTORICAL_FIGURES:<0 or 1>]</nowiki></tt>
| <tt><nowiki>[CULL_HISTORICAL_FIGURES:0]</nowiki></tt>
| 0 = No, 1 = Yes
|}

=== Reveal All Historical Events ===

Setting this to Yes will allow access to most information about the history of the world in [[Legends mode]]. All events will be revealed, but some [[historical figure]]s, [[site]]s, [[region]]s, and [[civilization]]s and other entities may not be, possibly because they are not known to any civilization. If set to No, then you will have to discover historical information in [[adventure mode]] or by instructing dwarves to make engravings.{{Verify}}

{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[REVEAL_ALL_HISTORY:<0 or 1>]</nowiki></tt>
| <tt><nowiki>[REVEAL_ALL_HISTORY::1]</nowiki></tt>
| 0 = No, 1 = Yes
|}

=== Terrain Parameters ===

These set limits and variance for terrain elevation, rainfall, temperature, drainage, volcanism, and savagery which determines how those values are generated. What biomes exist are then determined by how these factors overlap with each other.

==== Minima and Maxima ====
These are the absolute minimum and maximum values that can ever be generated for a particular map square characteristic. By ''subtly'' tweaking the min and max values, vastly different maps can be made. Changing these can cause the occurrence of certain [[Biome|biomes]] to become impossible, so you may want to use [[#Terrain Mesh Sizes and Weights|Weighted Ranges]] instead.

==== X and Y Variance ====
These control how wildly things like elevation and rainfall can vary between adjacent map squares. For example, if these values are set to the maximum of 3,200 for elevation then you will end up with more very low areas right next to very high areas. The number for X determines the east-west variance and the number for Y determines the north-south variance. By setting only one of these to a high value you can, for example, create horizontal or vertical bands of areas which are more similar to each other.

Generally speaking, raising both of these values will create a more random "patchwork" of many small biomes while setting both x and y values to 0 will cause every square on the map to use a single random value for the given characteristic.

For "patchwork" worlds to avoid being rejected, [[#Maximum Number of Subregions|Maximum Number of Subregions]] will probably need to be increased from the default.

==== Elevation ====
This controls the range of terrain elevations that can occur in the world. Usually, you just want to leave the min/max values alone. Raising the minimum elevation can, for example, make it impossible for oceans to exist. This does '''not''' directly control the number of available Z-levels at a particular site, though high maximum values may contribute to peaks, which can raise the number of above ground Z-levels - in other words, a maximum elevation of 400 and minimum of 1 does not mean you get 400 Z-levels, but it might increase the number of Z-levels somewhat in some regions compared to others. Raising the variance will result in a more bumpy, uneven landscape.

Some biomes/features that are impacted by elevation:
* A high minimum (above 99) means no oceans, as they need elevations below 100.
* A low maximum (below 300) means no mountains, as mountains need elevations above 300.
* Rivers will be placed when the elevation maximum is 104 or higher. Therefore, keeping both values above 100 and below 104 will prevent all water tiles from appearing.
* Mountain peaks can only form at elevations of 400.

==== Rainfall ====
Controls the possible amounts of rainfall throughout the world, which can have various effects. Setting the minimum or maximum too high or low can make the formation of certain biomes impossible, see [[Advanced_world_generation#Biome_Type_Requirement_Table|biome requirements]] below. Also makes more rivers appear on the world map.

If [[#Do Orographic Precipitation and Rain Shadows|orographic precipitation and rain shadows]] is on, then mountains will cause additional variance in rainfall, so (for example) rainfall below a non-zero minimum can occur on one side of a mountain range. If you want the minimum and maximum for this parameter to be absolutely respected, you must turn off the orographic precipitation option. Additionally, with 'Orthographic Precipitation' turned on, orthographic precipitation and rain shadows will only occur in regions with greater than or equal to 50 drainage. {{cite forum|139916/5437643}}{{cite forum|140685/5484064}}

==== Temperature ====
{{main|Climate|Temperature}}
These parameters control how hot or cold various areas will be. If you lower the minimum and maximum values, the world will be colder overall, for example. As with the others, changing these values too much could make it impossible for certain biomes to exist. The temperature scale used in this setting is related to regular degrees Urist by the equation "local temp = world temp * 0.75 + 10000".{{cite forum|169696/8395484}} This scale doesn't seem to be used anywhere else in the game. See [[Climate]] for more info.

These parameters form the "base" temperature for an area, and describe peak summer temperature in a scale that isn't used elsewhere in the game. This number also does not correspond 1:1 with the final climate. [[Temperature]] is always influenced by a number of variables, including elevation, time of year, thick forestation, and if [[Advanced_world_generation#Poles|poles]] are enabled, latitude. These other variables are factored in after the temperature mesh is applied, and frequently bring temperatures above and below their set minimum and maximum values. ''The inclusion of Poles is particularly strong in this regard, as it allows latitude to raise and/or lower temperatures by more than 75 degrees Celsius! That said, the temperatures aren't raised or lowered by more than about 65 degrees past the set minimum and maximum. Furthermore, for typical ranges, the temperature will never be raised more than about 25 degrees past the maximum (but will still drop up to about 65 degrees Celsius below the minimum).'' (unsure about exact values, research needed)

Elves can spawn where the temperature is 10 degrees or warmer, and humans can spawn where the temperature is 0 degrees or warmer.

==== Drainage ====
Changing drainage parameters will change the way water-affected biomes are formed. Low drainage will contribute to the formation of [[Lake|lakes]], [[River|rivers]], and [[Swamp|swamps]]. High drainage will cause water to sink into the ground rather than sit on the surface, which is important for forming hills. See [[Advanced_world_generation#Biome_Type_Requirement_Table|biome requirements]] below.

Lower drainage values have been reported to contribute to the formation of thicker soil layers, though it is currently unknown exactly how other factors (such as elevation or perhaps rain) impact soil formation.

==== Volcanism ====
Volcanism controls the occurrence of igneous [[layer]]s, and the formation of volcanoes. For a volcano to form, a square must have a volcanism value of 100, so reducing the maximum from 100 will make volcanoes impossible. Raising the minimum will increase the rarity of non-igneous layers.

Setting the minimum to a high value is not a good way to produce multiple volcanoes, as you are likely to get a "Volcanism not evenly distributed" rejection. Instead, use the Minimum Number of Volcanoes parameter, and possibly adjust the weighted ranges for volcanism as described below.

==== Savagery ====
These parameters control the level of [[Surroundings#Savage|savagery]] on the map. Raising the minimum savagery too high may make it impossible for certain races to exist, and similarly lowering the maximum too far can make it impossible for certain creatures to exist. The largest chance of having unusable maps comes from a too-high savagery value.

==== Configuration Tokens ====
{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[ELEVATION:<min>:<max>:<x variance>:<y variance>]</nowiki></tt>
| <tt><nowiki>[ELEVATION:1:400:401:401]</nowiki></tt>
| Range: 0 to 400 Maximum of 400 required for mountain peaks. Variance range: 0-3200
|-
| <tt><nowiki>[RAINFALL:<min>:<max>:<x variance>:<y variance>]</nowiki></tt>
| <tt><nowiki>[RAINFALL:0:100:200:200]</nowiki></tt>
| Range: 0 to 100 Variance range: 0-3200
|-
| <tt><nowiki>[TEMPERATURE:<min>:<max>:<x variance>:<y variance>]</nowiki></tt>
| <tt><nowiki>[TEMPERATURE:25:75:200:200]</nowiki></tt>
| Range: -1000 to 1000 Variance range: 0-3200
|-
| <tt><nowiki>[DRAINAGE:<min>:<max>:<x variance>:<y variance>]</nowiki></tt>
| <tt><nowiki>[DRAINAGE:0:100:200:200]</nowiki></tt>
| Range: 0 to 100 Variance range: 0-3200
|-
| <tt><nowiki>[VOLCANISM:<min>:<max>:<x variance>:<y variance>]</nowiki></tt>
| <tt><nowiki>[VOLCANISM:1:100:200:200]</nowiki></tt>
| Range: 0 to 100 Maximum of 100 required for volcanoes. Variance range: 0-3200
|-
| <tt><nowiki>[SAVAGERY:<min>:<max>:<x variance>:<y variance>]</nowiki></tt>
| <tt><nowiki>[SAVAGERY:1:100:200:200]</nowiki></tt>
| Range: 0 to 100 Variance range: 0-3200
|}

=== Terrain Mesh Sizes and Range Weights ===
[[File:World_map-large-32x32-elevation-mesh.png|thumb|300px|A large world generated with an Elevation Mesh Size of 32×32 and range weights set to 1:0:0:0:1 (i.e., only extreme high and low elevations). Note how the grid intersections are either set very high (mountains) or very low (oceans) and the space between them is smoothed out.]]
These parameters influence the relative proportions of terrain feature ranges, without making other ranges impossible. For example, to have many more low-elevation squares exist, without making it impossible for high elevations; this makes changing these parameters often preferable to simply changing the above min/max values. See the image on the right for an example.

The basic steps of applying weighted ranges are as follows:
# Divide the world into a grid of quantity <code>2''MeshSize'' - 1</code> areas in both X and Y direction.
# At each grid intersection, set the value according to the weighted ranges.
# Smooth out the areas between the intersection points.
# Add noise according to the variance parameters.
Where ''MeshSize'' is the raw parameter value found in the <code>[[world_gen.txt]]</code>.

==== Interaction between Mesh Size and Weighted Ranges ====
Mesh size determines how many intersection points the world will have. As an example, setting it to 2×2 means the world will be divided into 4 areas, 2 across and 2 tall, and there will be a total of 9 intersection points (3×3), including the outer-most corners. The grid intersection points are in the middle of world tiles, and the minimum size for a grid area is a span of 9 world tiles in either direction, with adjacent areas sharing an overlapping world tile. On a pocket world, this means one grid tile will span 9×9 world tiles, whereas on a large world, one grid tile will span 129×129 world tiles. A pocket world will always use a 2×2 grid of 9×9 world tiles, since it has only 17×17 tiles total (even if the game UI allows setting those worlds to a 4×4 grid, which can happen when changing the world size; changing the world size doesn't adjust mesh size limits, but saving then reloading the parameters does). A world that is 17 tiles wide, but 257 tall, and set to a 32×32 mesh size, will have 3×33 intersection points.

Setting mesh size to something other than Ignore, will apply random values at those intersections, with those random values being more likely to be in the ranges with higher weights. Setting to Ignore will cause the weighted range settings to be ignored for that terrain characteristic; instead setting the 4 corners of the world to completely random values and smoothing between those, or in other words, using a 1×1 grid for square worlds; while for rectangular worlds, using the same ratio as the world dimensions with 1 in the narrow dimension (for example, a 1×16 grid for a 17×257 world).

For example, if the Elevation Weighted Range parameters are set to <code>60:10:10:10:10</code> (starting with the 0-20 range, and these values do not need to add up to any particular number), and elevation min and max are left at the defaults of 1 and 400 respectively, then about 60% (on average) of the grid line intersection points will be set to an elevation in the range of 1-80 (0% to 20%), and the other ranges will be represented by around 10% of the intersection points each. The exact distribution is still left up to chance, though ''on average'' it will be close to this specification. This allows random number generation to be non-linear for the given terrain characteristic.

Setting the weight for a range to None only prevents intersection points from being set to a value in that range; terrain between intersection points can still be smoothed to values in ranges set to None that are between the intersection point values. Setting all the weights to None just puts them all at the same weight, the same as the default of all at 1.

Weighted ranges do not make rejection checks, although they can be responsible for many rejections if you neglect to adjust or disable some of the [[#Minimum Number of Mid/Low/High Characteristic Squares|Minimum Number of Mid/Low/High Characteristic Squares]], for example.

==== Interaction between these and Variances ====
The end result can vary greatly depending on how the corresponding [[#X_and_Y_Variance|X and Y Variance]] parameters are set. First of all, if the variance is too high, the noise it adds can completely negate the effect of the weighted ranges. For instance, with a 2×2 mesh, the default variance parameters are high enough that usually the mesh grid can hardly be recognized. How strong the variance's effect is, is also dependent on the mesh size. Having a larger mesh size (i.e. smaller grid tiles) means the variance also has to be higher for a visible effect. For instance, with a variance of 400, the effects are clearly visible with a 2×2 mesh and barely visible at all with a 8×8 mesh. Note that this effect is directly dependent on the mesh size and not, as one might expect, on the actual size of the grid tiles. This means, that a large world with a 32×32 mesh will look essentially the same as a pocket world with a 2×2 mesh, only stretched to 256 times the size.

Also see this [http://www.bay12forums.com/smf/index.php?topic=139916.0 forum post] for more details.

==== Configuration Tokens ====
{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[ELEVATION_FREQUENCY:<mesh>:<0-20 weight>:<20-40 weight>:<40-60 weight>:<60-80 weight>:<80-100 weight>]</nowiki></tt>
| <tt><nowiki>[ELEVATION_FREQUENCY:2:1:2:3:4:5]</nowiki></tt>
| rowspan="6" | Valid mesh values:

1 = Ignore

2 = 2x2

3 = 4x4

4 = 8x8

5 = 16x16

6 = 32x32

(limited by world size)
|-
| <tt><nowiki>[RAIN_FREQUENCY:<mesh>:<0-20 weight>:<20-40 weight>:<40-60 weight>:<60-80 weight>:<80-100 weight>]</nowiki></tt>
| <tt><nowiki>[RAIN_FREQUENCY:3:1:2:3:4:5]</nowiki></tt>
|-
| <tt><nowiki>[DRAINAGE_FREQUENCY:<mesh>:<0-20 weight>:<20-40 weight>:<40-60 weight>:<60-80 weight>:<80-100 weight>]</nowiki></tt>
| <tt><nowiki>[DRAINAGE_FREQUENCY:4:1:2:3:4:5]</nowiki></tt>
|-
| <tt><nowiki>[SAVAGERY_FREQUENCY:<mesh>:<0-20 weight>:<20-40 weight>:<40-60 weight>:<60-80 weight>:<80-100 weight>]</nowiki></tt>
| <tt><nowiki>[SAVAGERY_FREQUENCY:5:1:2:3:4:5]</nowiki></tt>
|-
| <tt><nowiki>[TEMPERATURE_FREQUENCY:<mesh>:<0-20 weight>:<20-40 weight>:<40-60 weight>:<60-80 weight>:<80-100 weight>]</nowiki></tt>
| <tt><nowiki>[TEMPERATURE_FREQUENCY:1:1:1:1:1:1]</nowiki></tt>
|-
| <tt><nowiki>[VOLCANISM_FREQUENCY:<mesh>:<0-20 weight>:<20-40 weight>:<40-60 weight>:<60-80 weight>:<80-100 weight>]</nowiki></tt>
| <tt><nowiki>[VOLCANISM_FREQUENCY:1:1:1:1:1:1]</nowiki></tt>
|}

=== Poles ===

With this, you can influence how polar regions are added. The poles can be on the north or south edge, and the equator will be on the opposite edge, or in the middle if there are two poles. Poles cause the world to generate regions of temperature in a gradient from cold to hot as you move further from the poles, resulting in roughly lateral bands of climate types.

If poles are set to NONE, then there will be no seasonal changes in the weather (e.g. no winter snow in temperate biomes). Climate regions will tend to be a lot more erratic and broken up than with poles selected. Without poles there also appears to be a heavy bias towards temperate regions, often without any tropical biomes being generated when using the default temperature settings; doubling the minimum and maximum temperate values will begin to generate a similar number of tropical biomes as a world with poles.

{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[POLE:<placement>]</nowiki></tt>
| <tt><nowiki>[POLE:NORTH]</nowiki></tt>
| Viable options: NONE, NORTH_OR_SOUTH, NORTH_AND_OR_SOUTH, NORTH, SOUTH, NORTH_AND_SOUTH
|}

=== Minimum Mountain Peak Number ===

This will cause the world to be rejected if fewer than this many peaks (based on elevation) are present on the map. EG: elevations of 400 must be possible for mountain peaks to occur. If set to zero, then worlds will not be rejected based on number of peaks.

You may need to adjust elevation parameters, such as the highest weighted range, in order to get the desired number of elevation-400 squares needed for larger numbers of peaks. Like volcanoes, mountain peaks can make embark zones more interesting (reportedly, they do increase the highest Z-level above ground in all embark zones in the same region, even if the selected embark zone does not include the peak) but other than that, they don't appear to "do" anything special.
{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[PEAK_NUMBER_MIN:<number>]</nowiki></tt>
| <tt><nowiki>[PEAK_NUMBER_MIN:20]</nowiki></tt>
| Elevations of 400 must occur for peaks to form.
|}

=== Minimum Partial Edge Oceans ===

This will cause a world to be rejected unless there are at least this many oceans touching an edge of the map. If set to zero then worlds will not be rejected based on this criterion. Setting both this parameter and Minimum Complete Edge Oceans to values that total more than 4 when added together may cause all worlds to be rejected, as you can't have both a partial and complete edge ocean on a given edge.

{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[PARTIAL_OCEAN_EDGE_MIN:<number>]</nowiki></tt>
| <tt><nowiki>[PARTIAL_OCEAN_EDGE_MIN:2]</nowiki></tt>
| Maximum of 4
|}

=== Minimum Complete Edge Oceans ===

This will cause a world to be rejected unless there are at least this many oceans which completely cover an edge of the map. Since a square map only has 4 edges, the maximum value possible is 4. If set to zero then worlds will not be rejected based on this criterion but still might end up with complete edge oceans by chance.

Note that the ability for this many edge oceans to exist will be limited by elevation. Therefore, to actually create large oceans you will probably need to change things like the Elevation Mesh Size and Weighted Ranges to increase the number and distribution of very low elevation squares on the map. In addition, if Complete Edge Oceans is set to any value ''other'' than 0 or 4, you may need to lower elevation variance for at least one of the axes: if set too high, such as a variation of 1600 for both X and Y axes (the default for Large Island and Medium Island parameter sets), the game may generate worlds very slowly or even hang.{{bug|565}}

Given appropriate weight, range, and variance values for things like elevation, a setting of: 1 results in a world that seems like a chunk of coastline. One edge of the map will be completely underwater and there will be ocean taking up much of the map on that side (think the east or west coast of the United States, the north coast of Canada, or southern Europe). If your edge ocean happens to pick your world's frozen side, most of it will be glacier.

*2 results in another coastline along with the first one -- the map could end up looking something like Panama if the oceans pick opposite sides of the map.
*3 results in a peninsula, like Florida in the US. There will be oceans surrounding 3 sides of the map, and land touching only one side of the map.
*4 results in one or more island(s) depending on things like elevation variance and weights. Regardless of whether you get one island or multiple islands, the entire map will be surrounded by water.

Unfortunately, there's no easy way to control which oceans end up on which edges, except perhaps setting X/Y variance to different values.

Edge oceans will take up part of the other edges too. For example, a full edge ocean on the east side will have part of the north and south sides underwater, but that does ''not'' add to the ''partial'' edge oceans count.

{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[COMPLETE_OCEAN_EDGE_MIN:<number>]</nowiki></tt>
| <tt><nowiki>[COMPLETE_OCEAN_EDGE_MIN:0]</nowiki></tt>
| Maximum of 4
|}

=== Minimum Volcano Number ===

The game will attempt to place this many volcanoes, but there must be at least this many squares with a volcanism of 100, if there are not, the world will be rejected. Therefore, [[Advanced_world_generation#Volcanism|maximum volcanism]] above must be set to 100, and adjusting the [[Advanced_world_generation#Configuration_Tokens_2|volcanism weighted range]] above for 80-100 to a higher value can increase the number of those squares.

{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[VOLCANO_MIN:<number>]</nowiki></tt>
| <tt><nowiki>[VOLCANO_MIN:15]</nowiki></tt>
| Volcanoes require a volcanism of 100 to occur.
|}

=== Mineral Scarcity ===
Controls the frequency at which minerals occur; setting this value higher will decrease both the number of different types and amounts of ore and gems present on a map. The default value will result in a variety of metal ores, while the old default of ''sparse'' would be only a few ores, which may be limiting until other metals can be requested and traded for. Note that abundances are limited by removing large cluster and/or vein spawn types from certain z-levels entirely, which can counterintuitively increase the abundance of one specific ore or mineral. The abundance of small cluster deposits (including gemstones) is not significantly affected, only the variety of types.

The options "Very Rare", "Rare", "Sparse", "Frequent", and "Everywhere" in the [[World_generation#Basic_world_generation_menu|basic world generation menu]] use the values 50000, 10000, 2500, 500 and 100 respectively.

According to [http://www.bay12forums.com/smf/index.php?topic=79018.msg2063804#msg2063804 research] by Shandra in v0.31.25, this is the relationship between the value of this setting and the approximate number of gems and ore:

[[File:MineralSetting_v25_limit10k.png]]

This is for the same 8x8 embark region in a world which is otherwise the same, except for the mineral scarcity parameter (although most of the detailed information comes from experiments with previous versions). (The chart legend has an error, the first "Pot.(Types)" should read "Pot.(Amount)".)
{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[MINERAL_SCARCITY:<number>]</nowiki></tt>
| <tt><nowiki>[MINERAL_SCARCITY:100]</nowiki></tt>
| Range: 100 to 100,000
|}

=== Real-world extinct creatures ===
Controls if and where extinct animals and animal people can exist; either not at all, in [[savage]] or [[Surroundings#Neutral|wilderness]] areas, or as [[domestic animal]]s in civilizations.{{v|53.15}}
This world gen setting also affects the following:
All non-extinct settings give - in vanilla - elven and human civilizations who do settle in an area (during world gen), where the surroundings include dinosaurs the possibility to pick such dinos, which are land-based, above ground, non-vermin creatures, as (exotic) pets (and thus gain that dino as domesticated), with elves being notoriously better at this then humans (and more often then not even consider animals with the "exotic pet" token as normal "pets"). Dwarves, when settling in an area (in world gen), will usually - if at all - only pick any pack animals from the above ground surroundings as new domesticated animals (if any), thus they may only possibly gain dinos, which are also pack animals, by settling additional sites in world gen. Goblins do not gain any new domesticated above-ground animals by settling new sites. In addition, the domesticated option gives - in vanilla - dwarven, elven and human civilisation the possibility to pick dinos as domesticated animals (at the start of world generation), but these animals are currently - at least for dwarven civs - not added to resources.animals.pet_races (or resources.animals.exotic_pet_races) only to resources.animals.mount_races, resources.animals.pack_animal_races, resources.animals.minion_races, resources.animals.wagon_puller_races (in all cases if the dino has the appropriate creature token, which is trainable, hunting trainable or war trainable) of the corresponding civ entity.

{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[REAL_WORLD_EXTINCT:<option>]</nowiki></tt>
| <tt><nowiki>[REAL_WORLD_EXTINCT:UNTAMED_WILDS]</nowiki></tt>
| EXTINCT, ISOLATED, UNTAMED_WILDS, WILDERNESS, or DOMESTICATED
|}

=== Max Megabeast Caves ===

This is the number of [[megabeast]]s placed at the beginning of history. Megabeasts are [[hydra]]s, [[bronze colossus]]es, [[roc]]s, and [[dragon]]s, which are all placed in equal proportions [http://www.bay12forums.com/smf/index.php?topic=112465.msg3415177#msg3415177 data].

Increasing this value can lead to early extinction of civilizations.

{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[MEGABEAST_CAP:<number>]</nowiki></tt>
| <tt><nowiki>[MEGABEAST_CAP:75]</nowiki></tt>
| Megabeasts count towards BEAST_END_YEAR calculation.
|}

=== Max Semi-Megabeast Caves ===

This is the number of [[semi-megabeast]]s placed at the beginning of history. Semimegabeasts are [[giant]]s, [[ettin]]s, [[minotaur]]s, and [[cyclops]], which are placed in equal proportions [http://www.bay12forums.com/smf/index.php?topic=112465.msg3415188#msg3415188 data].

{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[SEMIMEGABEAST_CAP:<number>]</nowiki></tt>
| <tt><nowiki>[SEMIMEGABEAST_CAP:150]</nowiki></tt>
| Semimegabeasts do not count towards the BEAST_END_YEAR calculation.
|}

=== Titan Parameters ===

==== Number ====

This controls the number of [[titan]]s that exist at the beginning of history[http://www.bay12forums.com/smf/index.php?topic=112465.msg3415203#msg3415203 data]. The number of forgotten beasts is unaffected by this parameter [http://www.bay12forums.com/smf/index.php?topic=112465.msg3415155#msg3415155 data].

{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[TITAN_NUMBER:<number>]</nowiki></tt>
| <tt><nowiki>[TITAN_NUMBER:33]</nowiki></tt>
| Titans count towards BEAST_END_YEAR calculation.
|}

==== Attack Population Requirement ====

[[Titan]]s will begin to attack your fort once at least this many dwarves inhabit it, regardless of whether any other attack criteria have been met.

This number defaults to 80, which isn't usually too difficult to deal with.

==== Exported Wealth Requirement ====

Titans will begin to attack your fort once you have exported at least this many [[Currency|dwarfbucks]]-worth of goods, regardless of whether or not any other criteria have been met. This parameter defaults to None (disabled).

==== Created Wealth Requirement ====

Titans will begin to attack your fort once the fort's total wealth has reached this many [[Currency|dwarfbucks]] in value. This happens regardless of whether any of the other criteria, such as population, have been met; therefore, even with 1 dwarf, a fort could be attacked if the fort were worth at least this value.

{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[TITAN_ATTACK_TRIGGER:<population>:<exp wealth>:<created wealth>]</nowiki></tt>
| <tt><nowiki>[TITAN_ATTACK_TRIGGER:80:0:100000]</nowiki></tt>
| 0 = None (disabled). Only one requirement must be met for an attack.
|}

=== Number of Demon Types ===

[[Demon]]s are similar to [[titan]]s and [[forgotten beast]]s, in that they are procedurally generated, but most are not unique. Thus, many different types of demons can exist in the world, but there will also be many individuals of most types. Thanks to [[Underworld spire|certain fun things]], fewer demon types also means fewer goblin civilizations.{{cite forum|112465/7392706}} You need at least 2 demon types, or else goblin civilizations won't exist initially, though if dwarves breach the underworld during world generation, at least one will be generated then.

{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[DEMON_NUMBER:<number>]</nowiki></tt>
| <tt><nowiki>[DEMON_NUMBER:52]</nowiki></tt>
| 0 to 1000
|}

=== Number of Night Troll Types ===

The number of different [[night troll]]s, also procedurally generated, that will exist in the world. Setting this to zero means that the world will have no night trolls, custom or otherwise.

{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[NIGHT_TROLL_NUMBER:<number>]</nowiki></tt>
| <tt><nowiki>[NIGHT_TROLL_NUMBER:77]</nowiki></tt>
| 0 to 1000
|}

=== Number of Bogeyman Types ===
The number of different [[bogeyman]] forms that will exist in the world. Bogeymen are procedurally generated, though their forms do not vary by much. Setting this to zero means that the world will have no bogeymen, custom or otherwise.

{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[BOGEYMAN_NUMBER:<number>]</nowiki></tt>
| <tt><nowiki>[BOGEYMAN_NUMBER:27]</nowiki></tt>
| 0 to 1000
|}

=== Number of Nightmare Types ===
The number of different [[nightmare]] forms that will exist in the world. Nightmares are procedurally generated. Setting this to zero means that the world will have no nightmares, custom or otherwise.

{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[NIGHTMARE_NUMBER:<number>]</nowiki></tt>
| <tt><nowiki>[NIGHTMARE_NUMBER:27]</nowiki></tt>
| 0 to 1000
|}

=== Number of Vampire Curse Types ===

The number of different types of [[Vampire|vampires]] that will exist in the world. Although they are generated at the start of a new world, they aren't different from each other. Setting this to zero means no vampires will exist.

{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[VAMPIRE_NUMBER:<number>]</nowiki></tt>
| <tt><nowiki>[VAMPIRE_NUMBER:72]</nowiki></tt>
| 0 to 1000
|}

=== Werebeast Parameters ===

==== Number of Werebeast Curse Types====

The number of different types of [[werebeast]]s that can exist in the world. It is common for werebeasts, unlike vampires, to assume many different forms and variations, the most well-known of these amount to different species of animals, from lizards, to wolves, to even bears. Setting this to zero means no werebeasts will exist, and will also remove a large amount of [[fun]] from the game.

{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[WEREBEAST_NUMBER:<number>]</nowiki></tt>
| <tt><nowiki>[WEREBEAST_NUMBER:58]</nowiki></tt>
| 0 to 1000
|}

==== Attack Population Requirement ====

Werebeasts will begin to attack your fort once at least this many dwarves inhabit it, regardless of whether any other attack criteria have been met. This number defaults to 50 which will often be reached in the second year of the fort.

==== Exported Wealth Requirement ====
Werebeasts will begin to attack your fort once you have exported at least this many [[Currency|dwarfbucks]]-worth of goods, regardless of whether or not any other criteria have been met. This parameter defaults to 5000.

==== Created Wealth Requirement ====

Werebeasts will begin to attack your fort once the fort's total wealth has reached this many [[Currency|dwarfbucks]] in value. This happens regardless of whether any of the other criteria, such as population, have been met; therefore, even with 1 dwarf, a fort could be attacked if the fort were worth at least this value.

{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[WEREBEAST_ATTACK_TRIGGER:<population>:<exp wealth>:<created wealth>]</nowiki></tt>
| <tt><nowiki>[WEREBEAST_ATTACK_TRIGGER:50:5000:50000]</nowiki></tt>
| 0 = None (disabled). Only one requirement must be met for an attack.
|}

=== Number of Secret Types ===

The number of secrets that exist in the world. Currently, all secrets are secrets of life and death, and the ones holding these secrets are [[necromancer]]s, thus, setting this to zero means that no necromancers will appear.
Non-necromancer towers can still appear (extremely rarely) with zero secrets, constructed by independent undead groups.
The primary difference between secrets is the type of [[intelligent undead]] the necromancer can create, as well as additional powers the secret can grant, like summoning [[bogeymen]]. The more secrets, the higher the chance that the world will have necromancer [[Tower (necromancy)|tower]]s. With 1, this chance is low. With the default number, it's seemingly guaranteed.
Even with 1 secret, if you have any necromancer towers at all, it is likely a great number will quickly appear in world generation (though this isn't guaranteed).

{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[SECRET_NUMBER:<number>]</nowiki></tt>
| <tt><nowiki>[SECRET_NUMBER:52]</nowiki></tt>
| 0 to 1000
|}

=== Number of Regional Interaction Types ===

The number of interactions that can be caused in regions, which may incorporate evil rain and cloud types. Currently, only evil region interactions are generated this way.

{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[REGIONAL_INTERACTION_NUMBER:<number>]</nowiki></tt>
| <tt><nowiki>[REGIONAL_INTERACTION_NUMBER:20]</nowiki></tt>
| 0 to 1000
|}

=== Number of Disturbance Interaction Types ===
The number of different [[Mummy|disturbed dead]] that can exist in the world. Setting this to zero should prevent any mummy from appearing{{verify}}, but it will not prevent the creation of [[tomb]]s.
{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[DISTURBANCE_INTERACTION_NUMBER:<number>]</nowiki></tt>
| <tt><nowiki>[DISTURBANCE_INTERACTION_NUMBER:10]</nowiki></tt>
| 0 to 1000
|}

=== Number of Evil Cloud / Evil Rain Types ===

This number specifies how many [[Weather#Evil weather|various face-melting, eye-boiling, and zombifyingly-fun]] clouds of pure evil may appear in your world. Setting this to zero means you no longer will ever have to deal with encroaching dust walls of doom in that world. It is generally advised to keep this value low...

{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[EVIL_CLOUD_NUMBER:<number>]</nowiki></tt>
| <tt><nowiki>[EVIL_CLOUD_NUMBER:45]</nowiki></tt>
| 0 to 1000
|}

The latter number states how many different types of green-ooze drenchers, disconcerting blood-showers, and sickly yellow slime-baths can occur in your world. Compared to evil clouds though, this one hardly is worth stressing out about, usually.... Setting this to zero means the only semi-solid to fully-liquid fluids to fall from the sky will be pure H2O.

{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[EVIL_RAIN_NUMBER:<number>]</nowiki></tt>
| <tt><nowiki>[EVIL_RAIN_NUMBER:352]</nowiki></tt>
| 0 to 1000
|}

=== Generate Divine Materials ===
This turns the generation of [[Divine_metal|divine metals]] on or off. It does not influence the creation of [[vault]]s. Probably determines whenever or not using divination dice spawns weapons.

{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[GENERATE_DIVINE_MATERIALS:<1 or 0>]</nowiki></tt>
| <tt><nowiki>[GENERATE_DIVINE_MATERIALS:1]</nowiki></tt>
| 1/0 = Yes/No
|}

=== Generate Mythical Materials ===

{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[GENERATE_MYTHICAL_MATERIALS:<1 or 0>]</nowiki></tt>
| <tt><nowiki>[GENERATE_MYTHICAL_MATERIALS:1]</nowiki></tt>
| 1/0 = Yes/No
|}

=== Allow Mythical Healing ===

{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[ALLOW_MYTHICAL_HEALING:<1 or 0>]</nowiki></tt>
| <tt><nowiki>[ALLOW_MYTHICAL_HEALING:1]</nowiki></tt>
| 1/0 = Yes/No
|}

=== Allow Divination, Experiments, and Necromancy types ===
These allow or disallow [[die|divination]], demon or necromancer [[experiment]]s, and the more advanced [[necromancer]] abilities.

{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[ALLOW_DIVINATION:<1 or 0>]</nowiki></tt>
| <tt><nowiki>[ALLOW_DIVINATION:1]</nowiki></tt>
| 1/0 = Yes/No
|-
| <tt><nowiki>[ALLOW_DEMONIC_EXPERIMENTS:<1 or 0>]</nowiki></tt>
| <tt><nowiki>[ALLOW_DEMONIC_EXPERIMENTS:1]</nowiki></tt>
| 1/0 = Yes/No
|-
| <tt><nowiki>[ALLOW_NECROMANCER_EXPERIMENTS:<1 or 0>]</nowiki></tt>
| <tt><nowiki>[ALLOW_NECROMANCER_EXPERIMENTS:1]</nowiki></tt>
| 1/0 = Yes/No
|-
| <tt><nowiki>[ALLOW_NECROMANCER_LIEUTENANTS:<1 or 0>]</nowiki></tt>
| <tt><nowiki>[ALLOW_NECROMANCER_LIEUTENANTS:1]</nowiki></tt>
| 1/0 = Yes/No
|-
| <tt><nowiki>[ALLOW_NECROMANCER_GHOULS:<1 or 0>]</nowiki></tt>
| <tt><nowiki>[ALLOW_NECROMANCER_GHOULS:1]</nowiki></tt>
| 1/0 = Yes/No
|-
| <tt><nowiki>[ALLOW_NECROMANCER_SUMMONS:<1 or 0>]</nowiki></tt>
| <tt><nowiki>[ALLOW_NECROMANCER_SUMMONS:1]</nowiki></tt>
| 1/0 = Yes/No
|}

=== Desired Good/Evil Square Counts ===

These values change the amount of [[Surroundings#Good|good or evil]] tiles on the map, depending on the size of the region they are being considered for. The counts are for all tiles in all subregions of a given size considered together, ''not'' counts for each subregion considered separately (all tiles in the same subregion share the same [[surroundings]] values).

As used here, a "subregion" is a named world area. Subregion names and locations for a generated world are viewable in legends mode under "Regions". Subregions are classified by size the same way for all map sizes: 1-24 tiles is Small, 25-99 tiles is Medium, and 100+ tiles is Large.

The counts used here will always be restricted to regions of the given size, no matter how large the count. Also, the count is more of a goal than a minimum or maximum. As a result, you can end up with many more or many fewer than the requested number of squares in some situations. In particular, if you have something like a case where only 3 large regions exist in a world, and you request "1 evil square" in large regions, you will end up with one of the large regions being ''entirely evil''. So any non-zero value in one of these settings essentially means "force at least one region of this size to be all good/evil."

Note that the "evilness" of evil biomes is also impacted by savagery. Certain civilizations cannot exist in good and/or evil squares, so too many of one or the other may limit the size of certain types of civilizations - dwarves, for example, need non-aligned biomes. Creating too many evil biomes seems to lead to the danger of many civilizations' early extinction.

{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[GOOD_SQ_COUNTS::<med region>:<lg region>]</nowiki></tt>
| <tt><nowiki>[GOOD_SQ_COUNTS:100:1000:2000]</nowiki></tt>
| rowspan="2" | Set count to zero to disable for that region size.
|-
| <tt><nowiki>[EVIL_SQ_COUNTS::<med region>:<lg region>]</nowiki></tt>
| <tt><nowiki>[EVIL_SQ_COUNTS:100:1000:2000]</nowiki></tt>
|}

=== Minimum Biome Square Counts ===

These numbers control whether or not a world will be rejected based on a lack of different [[biome|biomes]]. Raising these numbers will '''not''' automatically generate the given number of squares of the given biome! For a biome to exist, certain conditions like elevation and rainfall must exist.

These parameters simply filter out worlds that (for example) randomly fail to have enough high elevation squares to support a given number of mountains, etc. Some settings may cause worlds to always be rejected. For example, if for some reason the maximum elevation parameter is set to a value below what will support mountain biomes, it will be impossible to satisfy a non-zero requirement for mountain squares. The same principle goes for other conditions and biomes such as low elevations and oceans, etc.

Certain civilizations require different biomes to exist (such as dwarves and mountains), so eliminating certain biomes will make it impossible for certain civilizations to form.

These parameters often result in infinite world rejection problems. See [[World rejection]] for information on solving problems related to worlds always being rejected due to one or more of these parameters.

0 means no minimum for rejection - setting it to 0 does not guarantee 0 squares of that biome.

==== Biome Type Requirement Table ====

Terrain requirements for various biomes are described below.{{Verify}} Note that some of the exact ranges are unknown.

{| {{prettytable}}
|- bgcolor="#dddddd"
! rowspan="2" | Biome
! colspan="4" | Terrain Requirement
|-
! Elevation
! Rainfall
! Temperature
! Drainage
|-
| Swamp/Marsh
| 100-299
| 33-100
| Non-Freezing
| 0-32
|-
| Desert/Badland
| 100-299
| 0-9
| non-freezing
| note1
|-
| Forest
| 100-299
| 66-100
| non-freezing
| 66-100
|-
| Mountains
| 300-400
| N/A
| N/A
| N/A
|-
| Ocean
| 0-99
| N/A
| N/A
| N/A
|-
| Glacier
| 100-299
| N/A
| Freezing
| 80(?)-100
|-
| Tundra
| 100-299
| N/A
| Freezing
| 0-66
|-
| Grassland
| 100-299
| 0-66
| Non-Freezing
| 0-66
|-
| Hills
| 100-299
| 0-66
| Non-Freezing
| 66-100
|}
note1 drainage: 00-32 sand desert, 33-49 rocky wasteland, 50-65 rocky wasteland but different characters/appearance, 66-100 badlands

==== Minimum Initial Square Count ====

'''Note: The exclusive purpose of these parameters is to cause world rejection.'''

This is the minimum number of squares of the given biome that must exist before things like erosion take place. One thing to keep in mind is the maximum number of squares on a map of a given size - if the total number of squares on a map is lower than the sum of all square count parameters, then you will get infinite world rejection.

To determine the number of squares on a map, just multiply the dimensions. In practice these parameters will need to sum to lower than the maximum because some space is needed for "slack".

{| {{prettytable}}
|- bgcolor="#dddddd"
! Map Size
! Number of Squares
|-
| 17×17
| 289
|-
| 33×33
| 1089
|-
| 65×65
| 4225
|-
| 129×129
| 16614
|-
| 257×257
| 66049
|}

==== Minimum Initial Region Count ====

This is the minimum number of regions of contiguous biome squares that must exist before other processes such as erosion take place.

==== Minimum Final Region Count ====

This many regions of the given biome must exist after erosion and similar phases of generation have been completed.

{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
|-
| <tt><nowiki>[REGION_COUNTS:SWAMP:<init sq>:<init rg>:<final rg>]</nowiki></tt>
| <tt><nowiki>[REGION_COUNTS:SWAMP:1032:7:6]</nowiki></tt>
|-
| <tt><nowiki>[REGION_COUNTS:DESERT:<init sq>:<init rg>:<final rg>]</nowiki></tt>
| <tt><nowiki>[REGION_COUNTS:DESERT:1032:7:6]</nowiki></tt>
|-
| <tt><nowiki>[REGION_COUNTS:FOREST:<init sq>:<init rg>:<final rg>]</nowiki></tt>
| <tt><nowiki>[REGION_COUNTS:FOREST:4128:13:12]</nowiki></tt>
|-
| <tt><nowiki>[REGION_COUNTS:MOUNTAINS:<init sq>:<init rg>:<final rg>]</nowiki></tt>
| <tt><nowiki>[REGION_COUNTS:MOUNTAINS:8256:9:9]</nowiki></tt>
|-
| <tt><nowiki>[REGION_COUNTS:OCEAN:<init sq>:<init rg>:<final rg>]</nowiki></tt>
| <tt><nowiki>[REGION_COUNTS:OCEAN:8256:7:6]</nowiki></tt>
|-
| <tt><nowiki>[REGION_COUNTS:GLACIER:<init sq>:<init rg>:<final rg>]</nowiki></tt>
| <tt><nowiki>[REGION_COUNTS:GLACIER:0:0:0]</nowiki></tt>
|-
| <tt><nowiki>[REGION_COUNTS:TUNDRA:<init sq>:<init rg>:<final rg>]</nowiki></tt>
| <tt><nowiki>[REGION_COUNTS:TUNDRA:0:0:0]</nowiki></tt>
|-
| <tt><nowiki>[REGION_COUNTS:GRASSLAND:<init sq>:<init rg>:<final rg>]</nowiki></tt>
| <tt><nowiki>[REGION_COUNTS:GRASSLAND:8256:13:12]</nowiki></tt>
|-
| <tt><nowiki>[REGION_COUNTS:HILLS:<init sq>:<init rg>:<final rg>]</nowiki></tt>
| <tt><nowiki>[REGION_COUNTS:HILLS:8256:13:12]</nowiki></tt>
|}

=== Erosion Cycle Count ===

Tells the world generator how long the world has to erode its tall peaks down to mountainsides during the 'running rivers...' stage of world creation. The higher this number, the less jagged the world will be, and the more wide the major rivers will be. If you use the maximum number, your mountains will dissolve before your eyes into plains which can lead to rejections if there aren't enough mountains to use for river start points and dwarven civilization origin points.

{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[EROSION_CYCLE_COUNT:<number>]</nowiki></tt>
| <tt><nowiki>[EROSION_CYCLE_COUNT:250]</nowiki></tt>
| Range: 0 to 1000
|}

=== Minimum/Desired River Start Locations ===

This is the minimum number of riverheads that must exist before and after erosion takes place. Worlds will be rejected if they fail to meet these numbers. As with minimum biome counts, raising this number doesn't automatically create this many riverheads. Other conditions like terrain and rainfall must exist for rivers to form.

Extremely high pre-erosion values speed erosion greatly, while low post erosion values are useful for limiting rejects due to lack of river origin points. One can try the 800 value to get more lakes.

{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[RIVER_MINS:<min pre-erosion>:<des post-erosion>]</nowiki></tt>
| <tt><nowiki>[RIVER_MINS:200:400]</nowiki></tt>
| Range: 0 to 800
|}

=== Periodically Erode Extreme Cliffs ===

If enabled, makes every impassable rock wall into a series of ramps. Some prefer to pump up erosion to about 250, and turn the "Desired pre-erosion river count" to 0 for good erosion and no extra canyons.

Normally this is set to Yes (1).

{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[PERIODICALLY_ERODE_EXTREMES:<1 or 0>]</nowiki></tt>
| <tt><nowiki>[PERIODICALLY_ERODE_EXTREMES:1]</nowiki></tt>
| 1/0 = Yes/No
|}

=== Do Orographic Precipitation and Rain Shadows ===

Toggle that allows terrain height to affect rainfall. For example, moist air coming from the ocean blows over the land. As the terrain gets higher, it forces the moist air up, causing it to rain on the seaward side of a mountain. Eventually, all the rain has fallen if the mountain is tall enough. So, when the breeze goes over the top, there's no moisture left to fall on the other side, creating a rain-shadow. In the current version, regions where drainage is above 50 will also create rain shadows, regardless of the underlying biome and elevation.{{cite forum|140685/5484064}}

Turning this on should create a tendency for more extreme rainfall in regions, creating more forests, deserts, marshlands, and grasslands. Also note that it can create rainfall outside of min-max rainfall settings, so even in a world with a 0 max rainfall you may get rainfall biomes. Turning it off should result in more controllable, less complex rainfall conditions based on rainfall parameters as it adds a random element which can distort or otherwise mess up the climates on a pregenerated map.

This should be disabled if you're importing a map or using a preset map file that has weather.

{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[OROGRAPHIC_PRECIPITATION:<1 or 0>]</nowiki></tt>
| <tt><nowiki>[OROGRAPHIC_PRECIPITATION:1]</nowiki></tt>
| 1/0 = Yes/No
|}

=== Maximum Number of Subregions ===

This is the number of separate biomes (the flashing regions you see on embark when you hit F1, F2, etc. when there's more than one biome on the embark location) that are allowed to exist on the entire map.

Setting this to very low values will result in numerous rejections depending on [[#X and Y Variance|variance parameters]]. If variance values are set to high numbers, many small biomes will be created causing rejection if this parameter value is not increased beyond the default.

Increasing the value of this tag is often a must when generating "patchwork" worlds with lots of biome variance, but simply increasing it without increasing variance parameters will not guarantee more biomes.

It is also interesting to note that the maximum subregions is 5000 which is more than the total number of squares for a pocket or small map. However, for a medium or large map (16641 or 66049 squares) it quickly becomes a mere fraction of the total number of possible subregions. In fact it would be quite easy on a large map to end up with far too many subregions and get endless rejections of this type.

{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[SUBREGION_MAX:<number>]</nowiki></tt>
| <tt><nowiki>[SUBREGION_MAX:2750]</nowiki></tt>
| Range: 1 to 5000
|}

=== Cavern Parameters ===
[[Caverns]] are the hollow areas underground, which dwarves tend to encounter when they're digging around. The '''Cavern Layer Number''' parameter determines how many cavern systems will be generated, not including the magma layer or the Bottom layer. Defaults to three - setting it to lower values could help FPS. Setting it to 2 will merge cavern 3 species into the 2nd cavern, and setting it to 1 will merge all into one cavern. However, disabling them entirely by setting it to 0 will make it impossible to grow any underground plants, as none will exist for your civilization to cultivate, nor will they be available on embark.

*Setting caverns to a sub-3 number (Spoiler, highlight to view) erases about one-third of HFS spires{{Bug|10267}} and prevents dig deep disasters. Additionally, random plant or animal species can be more frequently absent.

{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[CAVERN_LAYER_COUNT:<number>]</nowiki></tt>
| <tt><nowiki>[CAVERN_LAYER_COUNT:3]</nowiki></tt>
| Range: 0 to 3
|}

==== Cavern Layout Parameters ====

Open caverns and dense passageways are not mutually exclusive. When both are raised, bizarre results can occur, such as layers showing a combination of open caverns, a cluster of network passages, and natural walls sprinkling the inside of an otherwise open cavern. [http://www.bay12forums.com/smf/index.php?topic=76355.msg1936859#msg1936859 Reference]

If you want the largest open spaces possible, then decrease the density and increase the openness. If you want a labyrinth of passageways, lower the openness and raise the passage density.

Another interesting note about the cavern layers is that the seed and number of demon types affect the layout of the caverns.

<gallery widths=200 heights=200 perrow=2>
File:Open00Density100.jpg|Cavern slice with Openness of 0 and Density of 100
File:Open100Density00.jpg|Cavern slice with Openness of 100 and Density of 0
File:Open100Density100.jpg|Cavern slice with Openness of 100 and Density of 100
File:Open50Density50.jpg|Cavern slice with Openness of 50 and Density of 50
</gallery>

===== Layer Openness min/max =====

Dictates the size of cavern passages. When Passage Density (see below) is set to minimum (0), caverns will be open expanses. Raising the maximum will increase the size of the caverns.

{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[CAVERN_LAYER_OPENNESS_MIN:<number>]</nowiki></tt>
| <tt><nowiki>[CAVERN_LAYER_OPENNESS_MIN:0]</nowiki></tt>
| rowspan="2" | Range: 0 to 100
|-
| <tt><nowiki>[CAVERN_LAYER_OPENNESS_MAX:<number>]</nowiki></tt>
| <tt><nowiki>[CAVERN_LAYER_OPENNESS_MAX:100]</nowiki></tt>
|}

===== Layer Passage Density min/max =====

Determines how many passages form the cavern. If openness (see above) is set to minimum and density increased, then you will get a maze-like network of small criss-crossing passages. Raising the values further increases the number of the maze-like passages.

Caverns will be large, open spaces at 0, and comprised of many small vertical shafts of rock at 100. Setting both values to be the same results in a uniform look for the caverns.{{Verify}}

{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[CAVERN_LAYER_PASSAGE_DENSITY_MIN:<number>]</nowiki></tt>
| <tt><nowiki>[CAVERN_LAYER_PASSAGE_DENSITY_MIN:0]</nowiki></tt>
| rowspan="2" | Range: 0 to 100
|-
| <tt><nowiki>[CAVERN_LAYER_PASSAGE_DENSITY_MAX:<number>]</nowiki></tt>
| <tt><nowiki>[CAVERN_LAYER_PASSAGE_DENSITY_MAX:100]</nowiki></tt>
|}

===== Layer Water min/max =====

Determines the minimum and maximum percentage of water each cavern can contain.

Caverns with a water level of 10 or higher can support creatures and plants from the "Subterranean Water" biome, and caverns with a water level of 90 or lower can support the "Subterranean Chasm" biome; levels of 10-90 support ''both'' biomes, while levels below 10 or above 90 support only one.

{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[CAVERN_LAYER_WATER_MIN:<number>]</nowiki></tt>
| <tt><nowiki>[CAVERN_LAYER_WATER_MIN:0]</nowiki></tt>
| rowspan="2" | Range: 0 to 100
|-
| <tt><nowiki>[CAVERN_LAYER_WATER_MAX:<number>]</nowiki></tt>
| <tt><nowiki>[CAVERN_LAYER_WATER_MAX:100]</nowiki></tt>
|}

==== Magma Layer ====

This parameter controls whether the [[magma sea]] exists.

Setting 1/Yes causes the magma layer to exist, value 0/No prevents it. Appears not to have any impact on volcanoes nor volcanism, so even if 0/No, there will still be embark locations with magma. If a [[volcano]] exists, it appears to always tap the magma sea, but the magma sea will not be revealed by revealing the volcano.

{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
|-
| <tt><nowiki>[HAVE_BOTTOM_LAYER_1:<1 or 0>]</nowiki></tt>
| <tt><nowiki>[HAVE_BOTTOM_LAYER_1:1]</nowiki></tt>
|}

==== Bottom Layer ====

Determines if the space below the magma sea exists. If Yes the "HFS" layer is always present. Normally you want to leave this set to Yes for maximum fun.

If enabled, this will force the magma layer above it.

{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
|-
| <tt><nowiki>[HAVE_BOTTOM_LAYER_2:<1 or 0>]</nowiki></tt>
| <tt><nowiki>[HAVE_BOTTOM_LAYER_2:1]</nowiki></tt>
|}

=== Z Levels (Depth) Settings ===

These parameters control the "thickness" of various "layers" on the map. Note that a "layer" in this case does not refer to one Z-level, but refers to a number of related Z-levels such as "levels above ground".

The following table assumes that you have 3 cavern layers. (out of a minimum of 0-3) The Levels Above Layer settings control how many Z-Levels are above each layer. A layer may itself consist of multiple Z-Levels (and almost always does).

{|style="margin:1em 1em 1em 0;background:#F9F9F9;border:1px #AAA solid;border-collapse:collapse;" class="wikitable"
|-style="background:#F2F2F2;text-align:center;"
!style="border:1px #AAA solid;padding:0.2em;" width="120"|Setting Name
!style="border:1px #AAA solid;padding:0.2em;" width="200"|Token
!style="border:1px #AAA solid;padding:0.2em;"| Description
|-
|style="border:1px #AAA solid;padding:0.2em;"| Above Ground
|style="border:1px #AAA solid;padding:0.2em;"| <nowiki>[LEVELS_ABOVE_GROUND:<number>]</nowiki>
|style="border:1px #AAA solid;padding:0.2em;"| The number of Z-levels of air above the highest surface level. Has no impact on how many Z-levels deep the surface layer is.
|-
|style="border:1px #AAA solid;padding:0.2em;"| Above layer 1
|style="border:1px #AAA solid;padding:0.2em;"| <nowiki>[LEVELS_ABOVE_LAYER_1:<number>]</nowiki>
|style="border:1px #AAA solid;padding:0.2em;"| Z-levels of stone above the first cavern layer. Making this higher will guarantee ''at least'' that many levels to build your fortress, but will have no impact on how many z-levels thick the surface layer is. Also, the top of a cavern may be higher than the rest of a cavern, so in practice there will be more "solid" levels than this above the cavern.
As of version 0.31.25 this setting is inaccurate. The actual number of z-levels may vary in a range of approx. ±5, which may result in non-existence of any solid z-levels between a surface layer and first cavern layer.
|-
|style="border:1px #AAA solid;padding:0.2em;"| Above Layer 2
|style="border:1px #AAA solid;padding:0.2em;"| <nowiki>[LEVELS_ABOVE_LAYER_2:<number>]</nowiki>
|style="border:1px #AAA solid;padding:0.2em;"| Z-levels of earth between the very top of the second cavern and the very bottom of the first cavern.
|-
|style="border:1px #AAA solid;padding:0.2em;"| Above Layer 3
|style="border:1px #AAA solid;padding:0.2em;"| <nowiki>[LEVELS_ABOVE_LAYER_3:<number>]</nowiki>
|style="border:1px #AAA solid;padding:0.2em;"| Z-levels of earth between the very top of the third cavern and the very bottom of the second cavern.
|-
|style="border:1px #AAA solid;padding:0.2em;"| Above Layer 4
|style="border:1px #AAA solid;padding:0.2em;"| <nowiki>[LEVELS_ABOVE_LAYER_4:<number>]</nowiki>
|style="border:1px #AAA solid;padding:0.2em;"| Z-levels of earth between the very highest magma and the very bottom of the third cavern. Spoiler Hidden (select invisible text to read): Making this high will give a large area for HFS veins, so that it never touches caverns, giving more to mine '''if''' it was impacting the cavern previously.
|-
|style="border:1px #AAA solid;padding:0.2em;"| Above Layer 5
|style="border:1px #AAA solid;padding:0.2em;"| <nowiki>[LEVELS_ABOVE_LAYER_5:<number>]</nowiki>
|style="border:1px #AAA solid;padding:0.2em;"| Uncertain. May control the number of levels of "Semi Molten Rock" between HFS and Magma, may control number of levels of magma, may impact both. In experimentation, the overall depth of all magma sea and semi-molten rock levels appears to increase, but not consistent enough to say for certain. Only valid if Magma Layer present. Spoiler Hidden:Often the HFS vein will only extend as high as the highest magma, making this the only guaranteed way to increase amount of HFS to mine, but unfortunately also creating enormous useless semi-molten z-levels
|-
|style="border:1px #AAA solid;padding:0.2em;"| At Bottom
|style="border:1px #AAA solid;padding:0.2em;"| <nowiki>[LEVELS_AT_BOTTOM:<number>]</nowiki>
|style="border:1px #AAA solid;padding:0.2em;"| Appears to be number of levels of HFS chamber. Only valid if Bottom Layer present, often having no impact. Values larger than default result in strange things.
|}

Some implications:
* The number of surface layers (e.g. soil), at this time, cannot be controlled. For example, on a map with 1 layer of peat, then a layer of silt, then a layer of obsidian, there is no control to let you increase either one to be, say, 20 z-levels. (though you may get lucky with the obsidian).
* There can be multiple stone layers between the cavern and the surface, so, increasing Levels Above Layer 1 may give you more conglomerate or more granite, and you have no control over which stone layer spans those Z-levels.
* The layers shown on embark span across the cavern layers in an unknown and inconsistent way. Sometimes those 10 different layers of stone are evenly distributed over your 400 z-level deep map, sometimes the first 9 get 1 z-level each and the last gets the other 391 levels. No way to control found yet.
* The HFS chamber, if present, will always extend into the rock layers, and appears to always make contact with the bottom cave. Large values for levels above layer 5 and layer 4 can result in enormous chambers, but the number of levels at the top (the part with undead) appears to be unaffected.
* Unconfirmed whether number of levels between caverns has any impact on cavern height. There will be connecting ramps and/or shafts between cavern layers no matter how many levels are between them.
* '''Very Important''': These values appear to apply across a whole 16x16 region, not just embark areas. That means that if a 16x16 region is completely flat, but has one tall mountain in one far corner, even if you set Levels Above Ground low (e.g. 2 z-levels) you still have all the empty air of the highest mountain in every embark tile (e.g. 200 z-levels). Also can happen to the semi-molten layer, and can lead to unexpected behavior.
* Very large or small values can cause strange things to happen.

=== Minimum/Maximum Natural Cave Size ===
It's not clear what effect these currently have, other than changing them can change the location of caves somewhat.{{verify}}

{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[CAVE_MIN_SIZE:<number>]</nowiki></tt>
| <tt><nowiki>[CAVE_MIN_SIZE:5]</nowiki></tt>
| rowspan="2" | Range: 1 to 500
|-
| <tt><nowiki>[CAVE_MAX_SIZE:<number>]</nowiki></tt>
| <tt><nowiki>[CAVE_MAX_SIZE:25]</nowiki></tt>
|}

=== Number of Caves ===
The number of caves generated in mountainous and non-mountainous regions, mountain caves will always be generated on the edge of mountain ranges next to non-mountainous regions. Lurking [[kobold]]s set up shop in caves, and store their stolen items there - a setting of 0 in both will stop kobold civilizations from appearing. Special note: a cave is not initially a [[lair]], although beasts can later use them as their lair.
{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[MOUNTAIN_CAVE_MIN:<number>]</nowiki></tt>
| <tt><nowiki>[MOUNTAIN_CAVE_MIN:100]</nowiki></tt>
| rowspan="2" | Range: 0 to 800
|-
| <tt><nowiki>[NON_MOUNTAIN_CAVE_MIN:<number>]</nowiki></tt>
| <tt><nowiki>[NON_MOUNTAIN_CAVE_MIN:200]</nowiki></tt>
|}

=== Number of Mythical Sites ===
The number of [[mysterious dungeon|mysterious sites]] generated around the world. The extended effects of setting this to 0 has not been determined{{verify|is chosen still available? is quest still given? etc.}}.
{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[MYTHICAL_SITE_NUM:<number>]</nowiki></tt>
| <tt><nowiki>[MYTHICAL_SITE_NUM:200]</nowiki></tt>
| rowspan="2" | Range: 0 to 800
|}

=== Make Caves Visible ===
If set to no (default) then the location of caves will not be marked on the map. If set to yes, caves will appear on the map so that they may be sought out or avoided as desired.

{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[ALL_CAVES_VISIBLE:<1 or 0>]</nowiki></tt>
| <tt><nowiki>[ALL_CAVES_VISIBLE:0]</nowiki></tt>
| 1/0 = Yes/No
|}

=== Allow Init Options to Show Tunnels ===

If enabled, you will be able to see the underground tunnels often built by dwarves on the world map, and they will appear as black lines, similar to roads.

{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[SHOW_EMBARK_TUNNEL:<0-2>]</nowiki></tt>
| <tt><nowiki>[SHOW_EMBARK_TUNNEL:2]</nowiki></tt>
| 0 = No 1 = Only in Finder 2 = Always
|}

=== Number of Civilizations ===

This number of [[civilization]]s will be placed on the map before history generation begins. These civilizations may later die out due to historical events. It is noteworthy that the chance for any given civilization to be destroyed through megabeasts decreases with a higher total number of civilizations present[http://www.bay12forums.com/smf/index.php?PHPSESSID=7348f68f41a9659443c05b2acf534e6c&topic=112465.15 data]. The five races are dwarf, elf, human, goblin, and kobold; they will generally be placed in equal numbers until the quota has been reached. If there are not enough biomes or other worldgen prerequisites for an even distribution, certain civs will be much more or less frequent than others[http://www.bay12forums.com/smf/index.php?PHPSESSID=7348f68f41a9659443c05b2acf534e6c&topic=112465.15 data]. If there is an odd number of civs (not divisible by 5), then the remainder is distributed randomly. Kobold civs require caves to be placed; if no caves exist, then kobolds are skipped and will not appear. This does not cause rejections [http://www.bay12forums.com/smf/index.php?topic=112465.msg3415125#msg3415125 data]. Goblin civilizations require multiple demons, see the [[#Number_of_Demon_Types|number of demon types]] section above.

Note that a high value here can cause lots of map rejections, particularly on smaller maps as there simply isn't enough room or regions to put them all in.

{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[TOTAL_CIV_NUMBER:<number>]</nowiki></tt>
| <tt><nowiki>[TOTAL_CIV_NUMBER:40]</nowiki></tt>
| Range: 0 to 300
|}

=== Playable Civilization Required ===

If this is set to yes (default) then worlds will be rejected if no civilization with [[Entity token|CIV_CONTROLLABLE]] can be placed. In an unmodded game, only the dwarves have this token.

If set to no, the result may be a world that cannot be played in Fortress Mode.

{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[PLAYABLE_CIVILIZATION_REQUIRED:<1 or 0>]</nowiki></tt>
| <tt><nowiki>[PLAYABLE_CIVILIZATION_REQUIRED:1]</nowiki></tt>
| 1/0 = Yes/No
|}

=== Minimum Number of Mid/Low/High Characteristic Squares ===

Sets the minimum possible number of squares of certain ranges of each of the region qualities, such as elevation, rain, drainage, volcanism, savagery, and temperature. These need to be changed to reflect your regional meshes and weights, and are responsible for a HUGE number of map rejections. These values can all be set to 0 for much fewer map rejections, particularly in the case of more wacky, non-standard maps.

These values will cause worlds to be rejected unless at least the given number of squares of the given type are randomly generated. Setting these values too high could result in worlds always being rejected if other parameters such as the maximum/minimums for elevation, etc., don't allow enough of those squares to get generated.

{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[ELEVATION_RANGES:<low sq>:<mid sq>:<high sq>]</nowiki></tt>
| <tt><nowiki>[ELEVATION_RANGES:8256:16512:8256]</nowiki></tt>
| rowspan="5" | Minimum number of squares that must have low, medium, and high amounts of the given attribute. 
0 = No minimum
|-
| <tt><nowiki>[RAIN_RANGES:<low sq>:<mid sq>:<high sq>]</nowiki></tt>
| <tt><nowiki>[RAIN_RANGES:8256:16512:8256]</nowiki></tt>
|-
| <tt><nowiki>[DRAINAGE_RANGES:<low sq>:<mid sq>:<high sq>]</nowiki></tt>
| <tt><nowiki>[DRAINAGE_RANGES:8256:16512:8256]</nowiki></tt>
|-
| <tt><nowiki>[SAVAGERY_RANGES:<low sq>:<mid sq>:<high sq>]</nowiki></tt>
| <tt><nowiki>[SAVAGERY_RANGES:8256:16512:8256]</nowiki></tt>
|-
| <tt><nowiki>[VOLCANISM_RANGES:<low sq>:<mid sq>:<high sq>]</nowiki></tt>
| <tt><nowiki>[VOLCANISM_RANGES:8256:16512:8256]</nowiki></tt>
|}

==World rejection==

:''Main article: [[World rejection]]''

If you are having the common problem of generated worlds always being rejected by the world generator, see [[v0.31:World rejection|Solving World Rejection Problems (v0.31 page)]] as it contains many detailed suggestions on how to troubleshoot and solve these issues.

== Parameter set examples ==

If you're trying to do something specific, then the [[Worldgen examples]] - complete parameter sets that can be copied directly into your ''world_gen.txt'' file and customized as desired - might be helpful.
If none of the examples suit your needs, [[Worldgen tricks]] has strategies and tips on making a world just right for you.

For many, many more examples see:
* [http://www.bay12forums.com/smf/index.php?topic=101280 DF2012 (v0.34) WorldGen "Cookbook" Thread]
* [http://www.bay12forums.com/smf/index.php?topic=140180 DF2014 (v0.40) WorldGen "Cookbook" Thread]
* [http://www.bay12forums.com/smf/index.php?topic=168543.0 DF2014 (v0.44.02+) WorldGen "Cookbook" Thread]
* [http://www.bay12forums.com/smf/index.php?topic=175538 DF2014 (v0.47.01+) WorldGen "Cookbook" Thread]
* [http://www.bay12forums.com/smf/index.php?topic=180805.0 DF2022 (v0.50.01+) WorldGen "Cookbook" Thread]

{{World}}

Foul blendec

2026-09-25T23:34:16Z

Silverwing235:

{{Quality|Exceptional}}
{{Creaturelookup/0
|image=foul_blendec_sprite.png
|portrait=foul_blendec_portrait.png
|contrib=no
|death=nobutcher
|wiki=no}}
{{av}}
{{creaturedesc}}
'''Foul blendecs''' are [[fanciful]], intelligent [[creature]]s found in certain [[evil]]-aligned [[forest]]s. Standing as the size of a [[dwarf]], these once-believed to be skull-headed creatures spawn rarely, in groups of 3-5 individuals who will menace everything smaller than themselves. They will attack dwarves who provoke them and may cause great injury unless countered by a [[military]] squad. They are a male-only race - no female foul blendecs exist - and are also immortal, only dying to violence and disease. Foul blendecs are sapient and can open unlocked [[door]]s, though they're unlikely to enter a fortress unless chasing dwarves inside.

For the majority of their known existence, it was widely believed that these incredibly misunderstood creatures possessed eerie white skulls for heads, featuring "empty" or "rotten eye sockets". Recent studies have revealed such notions to have been false. Dwarven studies have demonstrated that there are in fact, no such eye sockets on the creature to even speak of. In spite of their artwork, the heads of the foul blendecs are in fact, entirely covered in the fairly standard creature tissues of skin, muscle, and fat. Where eyes might otherwise have been found on the creature, the area of the face is simply plastered over with skin. Their only other major distinguishing feature in appearance is their head's lack of hair.

Curiously, while no readily identifiable visual sensory organs are to be found on the creature, the foul blendecs nevertheless retain an ability to see, through a mysterious form of {{token|EXTRAVISION}}, (meaning it's impossible to blind them).

They possess a [[pet]] value of 250, but lack the necessary tokens to be [[Animal trainer|trainable]] (and even if [[Modding|modded]] to be trainable, the fact they are intelligent creatures will lead to [[Animal trainer#Taming_intelligent_creatures|strange behavior]]). Due to the aforementioned intelligence, dwarves will not [[butcher]], eat or use products made from foul blendecs, limiting their use to occupying space in your [[refuse]] [[stockpile]], [[live training]] or putting them somewhere more to your liking if you capture one in a [[cage]] [[trap]].

Their [[good]] counterparts are the [[satyr]]s.

Some dwarves [[Preferences|like]] foul blendecs for their ''goat heads'', their ''goat legs'' and their ''rotten eye sockets''.
<div style="margin-left: 10%;">
<gallery widths="180px" heights="280px" captionalign="right">
File:FoulBlendec.jpg|A foul blendec, drawn in crayon by [[Main:Bay 12 Games|Bay 12 Games]]
File:blendec_preview.png|A more detailed version of the foul creature. ''Art by kough_noises''
File:foul_blendec_preview2.jpg|Another detailed view of the foul creature. ''Art by Salasti''
</gallery></div>
{{D for Dwarf}}

Foul blendecs are quite reminiscent of another [http://darksouls.wikidot.com/capra-demon goat-skull-headed monster]. Dwarves who witness them carrying machetes and using [[dog]]s are recommended to kill the dogs first.
==Trivia==
*[[File:foul_blendec_sprites.png|right]]Initially, the premium version had a sprite for a child foul blendec. It was later removed from the game, because foul blendecs are adults at birth.
*[[ThreeToe]]'s story [http://www.bay12games.com/dwarves/story/tt_forest_befouled.html "Forest Befouled"] represents a potential origin story for foul blendecs being corrupted from satyrs.

{{gamedata}}
{{Creatures}}
{{Category|Humanoids}}

DF2014:Dwarf cancels task: Job item lost or destroyed

2026-09-22T21:24:35Z

Silverwing235:

{{quality|Fine|00:03, 21 January 2013 (UTC)}}{{av}}

{{DFtext|Urist McDwarf cancels Construct Building: Job item lost or destroyed.|4:1}}

A dwarf whose tasked item is no longer in the same tile as when their job was assigned will cancel the job with this message. Often the "missing" item will be a scant few tiles away, and the job can be reissued, referencing its new location. Occasionally, the item will have actually been destroyed (possibly as the result of a [[cave-in]] or [[Dwarven atom smasher|atom smashing]]).

While dwarves [[Main:Dwarf cancels Construct Building: Item blocking site|will not directly move tasked items]], they may ''indirectly'' move them (such as by [[channel]]ing out the floor underneath the item, disassembling a [[building]] containing the item, or removing the [[construction]] beneath the item). Items may also be moved by natural forces such as [[cave-in]]s and [[flow]]ing liquids, or by one of the many thieving creatures in ''Dwarf Fortress''.

This error may also occur if the tasked item changes state--such as a [[leather|raw hide]] becoming [[rot]]ten, or an [[ice]] boulder melting.

{{Category|Errors}}
{{Errors FAQ}}
[[ru:Dwarf_cancels_task:_Job_item_lost_or_destroyed]]

Web

2026-09-21T00:26:18Z

Silverwing235:

{{Quality|Superior}}
{{av}}
[[File:web_sprites_preview.png|right]]'''Webs''' {{Tile|☼|7:1}} are the source of [[silk]], very often appearing in [[cavern]]s, and occasionally on the surface. The web is most often labeled as being from [[cave spider]]s, [[giant cave spider]]s, [[phantom spider]]s (in [[evil]] biomes), or [[Brown recluse spider man|spider men]] (on the surface). If an embark region is populated by web-making creatures, a number of their webs will be present immediately after embark, though further webs will only appear if the creatures themselves show up and leave them.
== Effects ==
[[File:GCS Webs.png|thumb|left|104x132px|alt=Webs from a Giant Cave Spider.|Webs from a [[Giant cave spider]].]]
{{under construction}}
== Fortress mode ==
Webs will be collected ''automatically'' by dwarves with the [[weaving]] labor enabled, but not until the fortress has a [[loom]]. A ''collect webs'' task will be triggered at the loom as long as webs are present within the loom's [[burrow]]. This can be deactivated in Labor menu {{Menu icon|y}} (select the Standing Orders tab, then the Automated Workshops subtab, and toggle the "Automatically collect webs" button), an important option since webs often occur in dangerous places you might want to secure first. The [[weaver]] will drop the collected thread in the loom and, depending on the loom setting and availability of a stockpile, either leave it there, immediately weave it into cloth, or put it in a stockpile. Other ways to prevent collecting are preventing any dwarf from using the loom, deactivating the weaving [[labor]] on all dwarves, or removing all looms (lack of stockpiles alone will ''not'' prevent this). An easier alternative is just to suspend the collect webs task in each loom. It may be a good idea to only allow non-skilled weavers to collect webs and only skilled ones to actually weave cloth. Set high minimal skill on the actual weaving loom and just as high maximal skill on the collecting loom. Suspend weaving on the collecting loom and collecting on the weaving loom. This allows higher efficiency, since collecting is not in any way affected by weaving skill (it happens instantly), but trains it and the skill affects quality of woven cloth.
{{catbox|Webs}}
[[Image:Web traps 1.png|thumb|right|200px|A design to drop webs on [[:File:Web traps 0.png|traps below]].]]
Webs become [[thread|silk thread]] the moment they are picked up. (They are, however, shown in the {{k|k}}-stocks menu under -> thread.) Cave spider and phantom spider silk thread are worth 6[[currency|☼]]; giant cave spider silk webs and thread are worth 24[[currency|☼]]. [[Titan]], [[forgotten beast]] and even [[demon]] webs can be collected too, but they are worth only 6☼.

[[Giant cave spider]]s shoot long strings of dangerously entangling webs at targets prior to attacking - this behaviour can be used to create giant cave spider [[silk farm]]s. It is not advised to allow weavers to randomly gather webs on maps where giant cave spiders might be lurking nearby. [[Titan]]s, [[forgotten beast]]s, and other procedurally-generated creatures may also shoot webs.

Webs are delicate, and can be destroyed by contact with any creature (except a dwarf that is gathering that web), or by any other rough treatment such as [[Irrigation|irrigating]], etc. It also appears that if open to the outside, [[rain]] will destroy the webs remarkably quickly.

[[Vermin]] that come into contact with a web will immediately turn into [[corpse|remains]], and large creatures caught in thick webs (as left by giant cave spiders, titans, forgotten beasts, etc.) will be immobilized for a short period of time, forcibly activating any [[trap]]s they are standing on (even if they are normally [[trapavoid|immune to traps]]). Creatures that spin webs, however, are generally also immune to them - this means that cave spiders and phantom spiders are immune to webs' vermin-killing effect, and that web-spinning forgotten beasts cannot be captured by webbed [[cage trap]]s.

== Adventurer mode ==
When you're stuck and can't get up, press {{k|.}} to advance time; you automatically get free. When enemies are near you should press {{k|,}} for shorter ticks. Furthermore, you are unaffected by webs while [[Climber|climbing]]. You can also [[jump]] onto the webbed tile. [[Animal_people|Spider people]] can just walk onto the tile. While sharing a tile with the web, you can pick it up, and if you have an empty hand the web will be gathered as thread, but if you don't, the web will be gathered and placed in your backpack as web. Such web can be placed by dropping or throwing it. Any webs may disappear if the area is unloaded (such as by sleeping, waiting, traveling, etc) while web in your inventory will become thread. Also, new webs may appear when an area is reloaded.
[[File:web_preview.jpg|thumb|300px|center|Urist likes webs for their ability to ''catch obnoxious flies''.]]
{{Translation
| dwarven = orshar
| elvish = ilu
| goblin = ngostong
| human = mete
}}

{{Category|Items}}
{{Category|Creature attributes}}
[[ru:Web]]

DF2014:Web

2026-09-21T00:25:22Z

Silverwing235:

{{av}}{{Quality|Superior}}
[[File:GCS Webs.png|thumb|left|104x132px|alt=Webs from a Giant Cave Spider|Webs from a [[Giant cave spider]]]]
{{catbox|DF2014:Webs}}

'''Webs''' {{Tile|☼|7:1}} are the source of [[silk]], very often appear in [[cavern]]s, and occasionally appear on the surface. The web is most often labeled as being from [[cave spider]]s, [[giant cave spider]]s, [[phantom spider]]s (in [[evil]] biomes), or [[Brown recluse spider man|spider men]] (on the surface). If an embark region is populated by web-making creatures, a number of its webs will be present immediately after embark, though further webs will only appear if the creature itself shows up and leaves them.

Webs will be collected ''automatically'' by dwarves with the [[weaving]] labor enabled, but not until the fortress has a [[loom]]. A ''collect webs'' task will be triggered at the loom as long as webs are present within the loom's [[burrow]]. This can be comfortably deactivated with {{k|o}}-{{k|W}}-{{k|w}}, an important option since webs often occur in dangerous places you might want to secure first. The [[weaver]] will drop the collected thread in the loom and, depending on the loom setting and availability of a stockpile, either leave it there, immediately weave it into cloth, or put it in a stockpile. Other ways to prevent collecting are preventing any dwarf from using the loom ({{k|q}}-{{k|P}} - requires [[manager]]), deactivating the weaving [[labor]] on all dwarves, or removing all looms (lack of stockpiles alone will ''not'' prevent this). An easier alternative is just to suspend the collect webs task in each loom ({{k|q}}-{{k|s}}). It may be a good idea to only allow non-skilled weavers to collect webs and only skilled ones to actually weave cloth. Set high minimal skill on the actual weaving loom ({{k|q}}-{{k|P}}) and just as high maximal skill on the collecting loom. Suspend weaving on the collecting loom and collecting on the weaving loom. This allows higher efficiency, since collecting is not in any way affected by weaving skill (it happens instantly), but trains it and the skill affects quality of woven cloth.
[[Image:Web traps 1.png|thumb|right|200px|A design to drop webs on [[:File:Web traps 0.png|traps below]]]]
Webs become [[thread|silk thread]] the moment they are picked up. (They are, however, shown in the {{k|z}}-stocks menu under -> thread.) Cave spider and phantom spider silk thread are worth 6[[currency|☼]]; giant cave spider silk webs and thread are worth 24[[currency|☼]]. [[Titan]] and [[forgotten beast]] webs can be collected too, but they are worth only 6☼.

[[Giant cave spider]]s shoot long strings of dangerously entangling webs at targets prior to attacking - this behaviour can be used to create [[giant cave spider]] [[silk farm]]s. It is not advised to allow weavers to randomly gather webs on maps where giant cave spiders might be lurking nearby. [[Titan]]s, [[forgotten beast]]s, and other procedurally-generated creatures may also shoot webs.

Webs are delicate, and can be destroyed by contact with any creature (except a dwarf that is gathering that web), or by any other rough treatment such as [[Irrigation|irrigating]], etc. It also appears that if open to the outside, [[rain]] will destroy the webs remarkably quickly.

[[Vermin]] that come into contact with a web will immediately turn into [[corpse|remains]], and large creatures caught in thick webs (as left by giant cave spiders, titans, forgotten beasts, etc.) will be immobilized for a short period of time, forcibly activating any [[trap]]s they are standing on (even if they are normally immune to traps). Creatures that spin webs, however, are generally also immune to them - this means that cave spiders and phantom spiders are immune to webs' vermin-killing effect, and that web-spinning forgotten beasts cannot be captured by webbed [[cage trap]]s.

== Adventurer mode ==
When you're stuck and can't get up, press {{k|.}} to advance time; you automatically get free. When enemies are near you should press {{k|,}} for shorter ticks. Furthermore, you are unaffected by webs while [[Climber|climbing]]. You can also [[jump]] onto the webbed tile. [[Animal_people|Spider people]] can just walk onto the tile. While sharing a tile with the web, you can pick it up, and if you have an empty hand the web will be gathered as thread, but if you don't, the web will be gathered and placed in your backpack as web. Such web can be placed by dropping or throwing it. Any webs may disappear if the area is unloaded (such as by sleeping, waiting, traveling, etc) while web in your inventory will become thread. Also, new webs may appear when an area is reloaded.
[[File:web_preview.jpg|thumb|300px|center|Urist likes webs for their ability to ''catch obnoxious flies''.]]
{{Translation
| dwarven = orshar
| elvish = ilu
| goblin = ngostong
| human = mete
}}

{{Category|Items}}
{{Category|Creature attributes}}
[[ru:Web]]

Miner cancels dig: Inappropriate dig square

2026-09-21T00:20:18Z

Silverwing235:

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

{{DFtext|Urist McMiner cancels Dig: Inappropriate dig square.|4:1}}

This occurs when a miner attempts to dig out a tile that was designated for digging, but was subsequently removed by other means.

Several situations have been observed to generate this message:
* A miner prepares to dig out a tile, but the tile immediately above is channeled away
* A miner prepares to remove a ramp tile, but nearby digging causes it to collapse
* A tile containing a tree sapling is designated for channeling, and the tree matures to full size

{{Errors FAQ}}
{{Category|Errors}}
[[ru:Miner cancels dig: Inappropriate dig square]]

Saved game folder

2026-09-20T16:29:14Z

Silverwing235: /* Contents */

{{Quality|Superior}}
{{av}}
[[File:saving_v50_preview.png|thumb|280px|right|"Saving world information" always seems to take the longest time...]]The '''saved game folder''' is the location where the files containing the information for each [[world generation|world]] are stored by ''Dwarf Fortress''. Knowledge of the saved game folder is crucial to moving, backing up, or sharing saves. See '''[[Importing and exporting worlds]]''' for sharing world generation parameters and seeds.

== Saving ==
'''Warning''': Make sure there is sufficient free drive space before saving in ''Dwarf Fortress''!{{bug|2587}} Save folders can be large, ranging from just a few megabytes for small worlds with short histories, to several hundred megabytes for large worlds with many events, and even a gigabyte or two is possible in extreme cases. Also, in some cases, like [[world generation]], ''Dwarf Fortress'' needs twice as much drive space for the save, since it first saves to the <code>current</code> folder, then copies that to the actual save folder. If it runs out of hard drive space while saving, ''Dwarf Fortress'' will act as if it saved correctly, but the save will be corrupted. Opening other saves to verify that they still work, then saving and exiting, will then corrupt that previously-working save as well.

At any time while playing ''Dwarf Fortress'', you can manually save the game with {{Menu icon|Esc}} then selecting ''Save and return to title menu'' or ''Save and continue playing''. If the game asks for a name for the timeline or folder, type the name you want, then press {{k|Enter}} when done. There is also an autosave feature, which will periodically (1, 2, or 4 times per year) save the game. To toggle '''autosave''' and control its behavior, see [[Settings#Autosaves|game settings]].

The ''Retire the fortress (for the time being)'', ''Retire at this location (or rest a while)'', ''Abandon the fortress to ruin'', ''Give in to starvation'', ''Succumb to the invasion'', etc, options also save the world, but end the game mode, and the world will now be available to start a new game mode in.

=== Save and return to title menu ===
This option provides further options, which are also offered after retiring or abandoning:
* ''Save to this timeline'' - this is the normal save option for ''Dwarf Fortress'' which replaces the current ''Active save'' (any other saves will remain).
* ''Save to new timeline'' - this allows to save without replacing the current ''Active save'', will ask what to name the timeline, and the saves in this timeline will be grouped separately from the previous saves with this save being the ''Active save'' of the new group.
* ''Save to new folder (same timeline)'' - this also allows to save without replacing the current save, but will also be grouped together with the previous ''Active save'', and will also be classified as an ''Active save''. This is not recommended since it can be very confusing to both the player and the game.
Since these options are also presented when retiring or abandoning a fortress, choosing to save to a new timeline or folder is useful if you want to both keep the fortress active and check [[Legends]] mode.

=== Save and continue playing ===
This option also allows to save without replacing the current save, will ask what to name the save folder, will be classified as a ''Manual save'', and will be grouped together with the existing ''Active save''.

== Save folder format ==
{| class=wikitable style="float:right; margin:10px;"
|
[[File:Folder-orange.svg|20px|link=]] save
 &emsp;[[File:Folder.svg|20px|link=]] current
 &emsp;[[File:Folder.svg|20px|link=]] region#
 &emsp;[[File:Folder.svg|20px|link=]] region#-year-month-day
|}

The location of the <code>save</code> folder depends on the [[Settings#Portable_mode|portable mode setting]], and contains one or more sub-folders, each one holding one of your worlds, and a <code>current</code> folder which is used to track the changes to the active world while ''Dwarf Fortress'' is running; it is not important unless ''Dwarf Fortress'' is open, and can safely be deleted otherwise.

By default, individual worlds are saved with the folder name <code>region#</code>, where # is a number, starting with <code>region1</code> and then incrementing; however, world folders can be renamed without consequence '''if the game is not running''' (this will not change the actual name of the world). Autosave folders will be named starting with <code>autosave 1</code> and then incrementing.{{verify|does it only keep 2 autosave folders, alternating between?}} (''Region'' is also a term used for areas in worlds, thus is only used when referring to the folder name to avoid confusion.)

''Dwarf Fortress'' shows the name of save folders when listing saves. There is no way to rename these folders in the game, but it is safe to change them using the standard methods of your operating system if the game is not running. However, '''never''' alter or delete the folder with the name of the game you're playing ''while saving'' from the game, or while that game is running!

=== Contents ===
The saved game folder will usually have these contents:

* A series of files named <code>art_image-#.dat</code>. These store information about art and are necessary for proper functioning.
* A series of files named <code>feature-#-#.dat</code>. These store information about map features such as [[river]]s, [[cavern]]s, [[magma sea]]s, and [[adamantine|hidden fun stuff]]. These are only generated for parts of the world you have explored (e.g. by embarking in fortress mode), but using the [[site finder]] will generate them for the entire world. Replacing these files will usually cause unwanted effects, such as magma seas present on the surface, or (''perhaps in [[Adamantine#The_Great_Adamantine_Space_Elevator|Armokian]] fashion?'') spires of [[adamantine]] spiraling up into the sky.
* A series of files named <code>region_snapshot-#.dat</code>. These are the historical maps not currently available in [[Legends|Legends mode]].
* A series of files named <code>site-#.dat</code>. These store the detailed map data of previously abandoned or retired fortresses.
* A series of files named <code>unit-#.dat</code>. These contain the details of historical creatures which might potentially visit your fortress.
* A large file named <code>world.sav</code> or <code>world.dat</code>, depending on the mode currently active (or lack thereof). This file stores the world data, and in fortress mode is named <code>world.sav</code> and includes the current fortress data. The custom raws generated for the [[forgotten beast]]s, [[titan]]s, [[demon]]s, [[night creature]]s, and [[Evil|evil effects]] are stored inside this file. Replacing this entire file will almost certainly crash the game.

Missing one or more of these important files may indicate a problem with the save; such save corruption is a source of crashes. While you are free to modify these files, their formats are undocumented and can be fragile, so it is recommended to instead use [[DFHack]] to change the data in memory and then let the game save those changes.

DFHack will sometimes add its own files to a save folder, but ''Dwarf Fortress'' ignores these, so there is no reason not to include them in backups or for sharing.

For basic backups and sharing, all you need to know is: Always copy the whole folder, not parts of it, and if the world was generated with mods, you may want to include the <code>data\installed_mods\</code> folder also, the location of which also depends on the [[Settings#Portable_mode|portable mode setting]].

== Manually backing up saves ==
Toady recommends that you make backups, and always save to a fresh file:

# Copy the relevant folder in <code>save</code>, <code>region#</code> or whatever you may have named it, to a safe location.
# When you want to restore a backup, copy that folder back into <code>save</code>.

Do '''not''' overwrite an old folder, as it might leave residual files which could corrupt the save - always delete the old folder first.

== Automatically back up save files ==
Windows systems: A batch file script can be run to handle copying the save folder from a cloud location like drobox into DF before the game starts, start the game and when it finishes copy the save folder back to the cloud location.
If your interested in the script have a look at it https://onemancoder.wixsite.com/dwarffortress
The script also creates date_time stamped backups of your local game folder to c:\temp\df
as well as computer-name_date_time stamps of your cloud save games

(edit the info to make it more user friendly)

== Restoring saves ==
: ''See also: [[Save compatibility]]''

Restoring a save from backup can be confusing; the game saves back to the save you loaded, so if you load a seasonal autosave, the game will save to that folder (e.g. <code>autosave 1</code>) and not to the original folder (<code>region1</code>) where you might expect.{{verify|not confirmed for v50+}} If you want to load an autosave, it is recommended that you copy and rename the folder to indicate that. For instance, using the examples above, copy <code>autosave 1</code> to <code>region1-fix</code> and continue play on that save. Remember to only modify folders while the game is '''not''' running.

This can cause some panic when you see your <code>region1</code> save is several years earlier than expected, and it might look like you lost all your (fortress/adventer party) work to some bug. However, the "missing" save is going to be in the folder you loaded previously. ''Dwarf Fortress'' shows the save type, in-game year, and folder name of each save on the load screen; the highest year will usually be the most recent save, unless you've previously loaded from earlier save.

==Mods==
If a world is using a mod that's been updated, and is currently using an older version of that mod, the player will be prompted about this when a save is loading, causing a message like the following to appear: 
[[File:mod_version_v50_prompt.png]]

When this happens, you have the choice of simply updating the mod, updating ''all'' mods at once, continuing to use the older version of the mod in question without updating, selecting the previous task but not updating ''any'' possibly outdated mods or simply returning to the title screen.

[[Category:Files]]
[[Category:Modding]]
[[Category:World]]
[[ru:Saved game folder]]

Mandate

2026-09-17T08:16:58Z

Silverwing235:

{{migrated article}}
{{Quality|Unrated}}
{{av}}
{{buggy}}
[[File:Announce_agreement_icon.png]] A '''mandate''' is a [[noble]]'s request that your [[dwarves]] produce a certain item or type of item, or an [[Trading|export]] ban on certain items. Starting nobles such as the [[expedition leader]] will not make mandates; upgraded nobles like the [[mayor]] will. Fulfilling the mandate gives the noble a happy [[thought]].

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

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

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

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

== Production Mandate ==

When a noble makes a production mandate, you will have between 3-6 months to fulfill it. These mandate the production of certain goods, specifying the desired type, just like export bans. In previous versions, items (of any type) of a desired material could be mandated.

Getting the required items from a [[caravan]] will not fulfill a mandate. If a production mandate expires without being fulfilled, the noble will get an unhappy [[thought]], and one or more dwarves will be sentenced to punishment for the 'violation of production order' [[Justice|crime]]. The dwarf chosen tends to have a skill appropriate to the mandate, but random dwarves may be chosen as well. If the noble can't sentence any dwarves for punishment because all your dwarves are nobles, or the sentenced dwarves can't be punished because no officer is assigned, he will get another unhappy thought. Delaying fulfilment of an easily-achieved production mandate may prevent another, worse, mandate from being enacted (for a few months, at least). The color of the mandate indicator on the Nobles screen changes from brown to bright yellow to red, as the deadline approaches. You can determine your progress towards fulfilling the mandate by viewing the {{menu icon|n}} (then hit enter on the Noble with a mandate), and you will see the mandate listed like this example "Mandates: Make floodgates (2/3)", where in this example we have produced one floodgate and still need to produce two more. Once you produce the mandated items, the mandate goes away and nothing special happens to the items. They just go into your inventory, so on the not-outside chance the noble actually requests something useful (like armor, a weapon, or furniture) it's not a total waste. Choosing a [[Baron]] with a [[preference]] for useful items can help with this (as discussed below).

In a busy fortress, it's easy to miss the announcement of a production mandate. One way to avoid this is to change the NEW_MANDATE line in [[announcements.txt]] to [NEW_MANDATE:A_D:D_D:P] Another option is using the manager to create a work order for three goods every quarter.

== Export Bans ==

Export bans forbid the export of a certain item type, like [[armor|greaves]]. These bans are temporary, they last about half a year (approximately the same length of time as a production mandate) and then are ended by your noble.

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

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

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

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

==Requirements==

These are the criteria for a noble to issue a mandate{{cite forum|139032/5334341}}:
* Hasn't made a mandate/demand lately, the period can be adjusted in [[Difficulty#Mandates_and_demands|difficulty]] [[settings]].
* Isn't dead, hasn't left the map, isn't a projectile, and isn't caged
* Isn't insane (or in the middle of a mood)
* Isn't incapacitated (unconscious, webbed, or paralyzed)
* Isn't nauseated, winded, stunned, dizzy, or feverish
* Isn't bleeding
* Has a soul
* Is a member of your fortress

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

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

{{Category|Nobles}}
{{Category|Justice}}
[[ru:Mandate]]

23a:Elf

2026-09-13T10:55:27Z

Silverwing235: /* Diplomacy */ the 'but' here, appears to be causing an ungrammatical issue

{{quality|Fine|23:57, 13 August 2010 (UTC)}}
{{23a creaturelookup/0|butcher=no}}
{{av}}

'''Elves''' are intelligent [[humanoid]] [[creature]]s who live in [[Map legend#Sites|forest retreat]]s. Their retreats have no buildings, but the [[tree]]s in the area are named. They love nature and are ready to defend it, typically with [[bow]]s. They may invade a fortress which violates their tree-cutting limit.

== Elves in Fortress Mode ==
Elves are a [[trading]] race and send small [[caravan]]s without [[wagon]]s in [[Calendar|spring]], bringing [[cloth]] and various [[plant]]s.

They are very picky about what they will accept in return: Elves will not accept anything made from or decorated using a previously living creature (bone, shell, leather, horn, ivory, meat, fish, tallow, fat, or soap) or [[wood]] (including [[charcoal]], [[ash]], [[lye]], [[potash]], [[pearlash]], [[soap]], clear and crystal [[glass]] items, and [[obsidian]] short swords). Even offering them something wood-related will make them immediately pack up and leave.

[[Metal]] items are acceptable, even when [[charcoal]] is used in their production. Items made from [[silk]] are acceptable, as are all non-wooden plant-based products such as [[plump helmet]]s, seeds, and ☼Dwarven syrup biscuits[45]☼ (as long as no animal products were used in the recipe). You can also transport your goods to the [[trade depot]] in a wooden [[bin]], as long as you do not try to sell the bin. In order to sell food and booze, however, your [[barrel]]s will need to be made of metal. Living [[animals]] are acceptable, as long as the [[cage]] or [[trap]] is not made of [[wood]].

Although [[tower-cap]]s are giant mushrooms, they are considered [[tree]]s by the elves and thus are not acceptable.

==Diplomacy==
The first Elven caravan which arrives while a [[Baron]] is present at your fortress will be accompanied by a [[diplomat]] who will attempt to make first contact. This visit will consist entirely of either a stern warning (if you cut down any trees, which is all but guaranteed) or a congratulation (for not harming the forest) followed by leaving the map. During subsequent years, the diplomat will arrive a few weeks before or after the caravan and try to negotiate an annual quota on your woodcutting activities. Note that growing tower-caps does ''not'' exempt you from the woodcutting quota; evidently, elves don't like you cutting down giant mushrooms, either. Your remaining quota is viewable on the {{K|c}}ivilizations menu; select the elves, and hit tab a few times to cycle through the available information. The quota counts down towards zero as you cut more trees.

{{fulltext|The Elves Are Here!|The elves have brought the full force of their lands against you.}}

If your ignore their demands, the peace-loving elves are all too happy to take up arms. While they consider it barbaric to harm living creatures for food or craft, they consider it perfectly acceptable to massacre sentient dwarves and their pets in ambush. Being that they're all highly skilled markselves, you'll be in for a world of hurt. Just a handful of markselves will sneak up and start mowing down anything they see. However, it isn't a siege, and after a certain amount of damage is done, they'll leave the map, leaving you to deal with the aftermath of their hippie carnage. Unless you have some highly trained marksdwarves of your own, your best move is to simply get everyone inside the fortress, as you'll not be able to get them out of the open and inside the fort where dwarven prowess would have the advantage.

== Elves in Adventure Mode ==
Elven forest retreats are represented by yellow symbols in [[forest]]s on the world map. They do not have any [[shop]]s, but they seem to have a great amount of elite marksmen to recruit. The leader and quest giver of a retreat is called the "druid", who can be found wandering the forest floor with the other elves.

Elven characters start with a wooden [[weapon]] and a set of basic wooden [[armor]]. This limitation often leads to a quick death. They do have some advantages, however: they're one [[size]] larger than [[dwarves]], which makes them hit harder and absorb more damage, though they also have a natural armor penalty which causes them to take slightly more damage than normal. Their main redeeming quality is their speed, being roughly 20% faster than the other playable races.

{{gamedata}}
{{gamedata|title=Entity ([[civilization]]) Raws|{{raw|23a:entity_default.txt|ENTITY|FOREST}}}}
{{creatures}}
{{Category|Races}}
{{Category|Humanoids}}

23a:Elf

2026-09-13T10:53:03Z

Silverwing235: Doesn't Adv Mode...not exist yet? /confused

{{quality|Fine|23:57, 13 August 2010 (UTC)}}
{{23a creaturelookup/0|butcher=no}}
{{av}}

'''Elves''' are intelligent [[humanoid]] [[creature]]s who live in [[Map legend#Sites|forest retreat]]s. Their retreats have no buildings, but the [[tree]]s in the area are named. They love nature and are ready to defend it, typically with [[bow]]s. They may invade a fortress which violates their tree-cutting limit.

== Elves in Fortress Mode ==
Elves are a [[trading]] race and send small [[caravan]]s without [[wagon]]s in [[Calendar|spring]], bringing [[cloth]] and various [[plant]]s.

They are very picky about what they will accept in return: Elves will not accept anything made from or decorated using a previously living creature (bone, shell, leather, horn, ivory, meat, fish, tallow, fat, or soap) or [[wood]] (including [[charcoal]], [[ash]], [[lye]], [[potash]], [[pearlash]], [[soap]], clear and crystal [[glass]] items, and [[obsidian]] short swords). Even offering them something wood-related will make them immediately pack up and leave.

[[Metal]] items are acceptable, even when [[charcoal]] is used in their production. Items made from [[silk]] are acceptable, as are all non-wooden plant-based products such as [[plump helmet]]s, seeds, and ☼Dwarven syrup biscuits[45]☼ (as long as no animal products were used in the recipe). You can also transport your goods to the [[trade depot]] in a wooden [[bin]], as long as you do not try to sell the bin. In order to sell food and booze, however, your [[barrel]]s will need to be made of metal. Living [[animals]] are acceptable, as long as the [[cage]] or [[trap]] is not made of [[wood]].

Although [[tower-cap]]s are giant mushrooms, they are considered [[tree]]s by the elves and thus are not acceptable.

==Diplomacy==
The first Elven caravan which arrives while a [[Baron]] is present at your fortress will be accompanied by a [[diplomat]] who will attempt to make first contact. This visit will consist entirely of either a stern warning (if you cut down any trees, which is all but guaranteed) or a congratulation (for not harming the forest) followed by leaving the map. During subsequent years, the diplomat will arrive a few weeks before or after the caravan and try to negotiate an annual quota on your woodcutting activities. Note that growing tower-caps does ''not'' exempt you from the woodcutting quota; evidently, elves don't like you cutting down giant mushrooms, either. Your remaining quota is viewable on the {{K|c}}ivilizations menu; select the elves, and hit tab a few times to cycle through the available information. The quota counts down towards zero as you cut more trees.

{{fulltext|The Elves Are Here!|The elves have brought the full force of their lands against you.}}

If your ignore their demands, the peace-loving elves are all but too happy to take up arms. While they consider it barbaric to harm living creatures for food or craft, they consider it perfectly acceptable to massacre sentient dwarves and their pets in ambush. Being that they're all highly skilled markselves, you'll be in for a world of hurt. Just a handful of markselves will sneak up and start mowing down anything they see. However, it isn't a siege, and after a certain amount of damage is done, they'll leave the map, leaving you to deal with the aftermath of their hippie carnage. Unless you have some highly trained marksdwarves of your own, your best move is to simply get everyone inside the fortress, as you'll not be able to get them out of the open and inside the fort where dwarven prowess would have the advantage.

== Elves in Adventure Mode ==
Elven forest retreats are represented by yellow symbols in [[forest]]s on the world map. They do not have any [[shop]]s, but they seem to have a great amount of elite marksmen to recruit. The leader and quest giver of a retreat is called the "druid", who can be found wandering the forest floor with the other elves.

Elven characters start with a wooden [[weapon]] and a set of basic wooden [[armor]]. This limitation often leads to a quick death. They do have some advantages, however: they're one [[size]] larger than [[dwarves]], which makes them hit harder and absorb more damage, though they also have a natural armor penalty which causes them to take slightly more damage than normal. Their main redeeming quality is their speed, being roughly 20% faster than the other playable races.

{{gamedata}}
{{gamedata|title=Entity ([[civilization]]) Raws|{{raw|23a:entity_default.txt|ENTITY|FOREST}}}}
{{creatures}}
{{Category|Races}}
{{Category|Humanoids}}

Brimstone

2026-09-12T17:52:56Z

Silverwing235:

{{Quality|Exceptional}}
{{stonelookup/0
|graphic=brimstone_sprite.png
|wiki=sulfur}}
{{av}}

'''Brimstone''' (a name for a native crystalline form of the element sulfur IRL) is a yellow [[stone]], '''neither''' [[fire-safe]] nor [[magma-safe]], that is found in small clusters in [[igneous extrusive]] layers, as well as within [[gypsum]].

In [[adventurer mode]], some types of [[demon]]s can be detected by the odor of brimstone.

<gallery>
File:Soufre.jpg|Brimstone is really just elemental sulfur, but it sounds cooler
File:Min sulfur.jpg|Sulfur crystals
File:Soufresicile2.jpg|Annotated image, click for details
File:Sulfur on vulcano.jpg|Sulfur on a volcano
File:SulfurReagent.jpg|Sulfur powder
File:Burning-sulfur.png|Sulfur burns with a blue flame, and this creates a blood-red liquid
File:Kawah Ijen -East Java -Indonesia -sulphur-31July2009.jpg|A [[human]] carrying slabs of sulfur
</gallery>

{{Translation| dwarven = kâkdal-lam | elvish = fita-queca | goblin = nguxur-ngomstu | human = laka-ado}}

{{gamedata}}
{{stones}}

Mysterious dungeon

2026-09-09T14:10:38Z

Silverwing235: /* Treasure */

{{av}}
{{minorspoiler}}

[[File:Mythic sites preview.png|right]]
:''"This place is dangerous. Steel yourself against [[Dungeon guardian|ancient enemies]]. Try not to let yourself be surrounded, and remain standing. Enter and vanquish! Or slip in [[Ambusher|unseen]]. Securing the [[Primordial remnant|treasure]] is all that matters."''
:— A [[deity]]'s proclamation to their [[chosen]].

'''Mysterious lairs''', '''dungeons''' and '''palaces''' ([[File:Site mythical 1.png]][[File:Site mythical 2.png]][[File:Site mythical 3.png]] / {{Raw Tile|■|0:0:1}}) are '''mythical [[site]]s'''{{version|51.01-beta26}} that can be explored in [[adventurer mode]]. They are created in a time before time, with no known founder. In [[fortress mode]], [[messenger]]s can make contact with mysterious sites to establish an alliance or war by meeting with a guardian.

==Structure==
All mythic sites have an aboveground room and an underground section. There are a number of common features, such as vertical [[bars]] activated by [[lever]]s, [[Trap#Weapon trap|trapped]] [[chest]]s, and treasure on a [[Ramp|raised]] floor.

The smallest of the mythic site types, lairs are square buildings with two floors and several floor plans. Dungeons are larger and deeper, often with multiple levers protecting the treasure room. Palaces are even more elaborate, featuring several floors both above and below ground, and the building is circular, like a [[dark fortress]]. Many of the inhabitants have a special [[dungeon guardian]] [[syndrome]], and the strongest of them can wield a [[magic]] weapon: a [[Artifact|legendary]], [[Item quality|masterwork]] item, made from a [[primordial remnant]]. The rewards are greater, as [[Large pot|pots]] and [[jug]]s filled with [[Mythical substance|healing substances]] are scattered throughout.

[[File:Adv weather light inside eerie.png]] When inside a mythic site, the [[Weather|atmosphere]] is described as ''"The area gives off a sickly light."''

==Inhabitants==
Each site is lead by a [[dungeon guardian]], an [[Immortality|immortal]] [[historical figure]] with a unique title (such as "ancient of the trees" or "bark worshipper"). Currently, this guardian has no interactions throughout history, beyond being a member of a "mythic entity". They are equipped with [[Quality|high-quality]] [[weapon]]s and [[armor]], and good [[combat skill]]s to wield them. They also have a [[Flask|waterskin]] filled with a [[mythical substance]] they can drink to heal.

Their [[Syndrome|title]] grants them [[immortality]], immunity to blindness, fevers, exertion, and fear; removes their need to eat, sleep, and drink; and prevents their physical attributes from raising or rusting. They are sterile, and their personality is maximally loveless, hateful, violent, cruel, and non-altruistic. Visually, their skin is drawn with the same purple tone as a [[necromancer]], or represented as a {{Raw Tile|ÿ|5:1}} glyph.

A small squad of [[goblin]] soldiers (as [[Surroundings#Evil|evil]] creatures that don't need to eat or drink) also guard these sites. They are worse-equipped and less skilled than the aforementioned guardian.

Mythical sites also have [[Creature|animal]] populations, with access to "ancient" variants of predators. These creatures can potentially be drawn from the [[cavern]]s. Mythical animals gain a special prefix inspired by their [[sphere]], with the same effects as the [[dungeon guardian]] syndrome. They are tamed and loyal to the site's defenders.

All inhabitants speak the [[divine language]].

==Treasure==
Offering service to a [[religion]] will start a quest to collect a [[primordial remnant]] from a dungeon. The same [[sphere]] influences the name of both this object and the creature guarding it.

All types of [[armor]]s and [[weapon]]s can be found in chests - they will usually be of good quality, though any armor defaults to being sized for [[human]]s. Though the guardian's [[entity token]]s suggest that they should be able to make use of [[divine metal]]s and [[Divine fabric|fabric]], they do not have access to those materials.

Mysterious sites are the only known source of [[mythical substance]]s and [[magic]] items made from [[primordial remnant]]s.

==Gallery==
<gallery>
Mysterious lair floors anim.gif|The floors of a lair.
Mysterious lair basement.png|A simple lair's basement.
Mysterious dungeon ground floor.png|Entering a dungeon.
Mysterious dungeon basement.png|A dungeon's locked treasure room.
Mysterious palace embark.png|Upper floors of a palace viewed in Fortress mode.
</gallery>

==See Also==
*[[Dark fortress]]
*[[Vault]]

{{Scriptdata|title=Entity script}}
{{v50 world}}
{{Category|Adventurer mode}}
{{Category|Myth}}

Mysterious dungeon

2026-09-08T09:21:56Z

Silverwing235: reorganise a bit

{{av}}
{{minorspoiler}}

[[File:Mythic sites preview.png|right]]
:''"This place is dangerous. Steel yourself against [[Dungeon guardian|ancient enemies]]. Try not to let yourself be surrounded, and remain standing. Enter and vanquish! Or slip in [[Ambusher|unseen]]. Securing the [[Primordial remnant|treasure]] is all that matters."''
:— A [[deity]]'s proclamation to their [[chosen]].

'''Mysterious lairs''', '''dungeons''' and '''palaces''' ([[File:Site mythical 1.png]][[File:Site mythical 2.png]][[File:Site mythical 3.png]] / {{Raw Tile|■|0:0:1}}) are '''mythical [[site]]s'''{{version|51.01-beta26}} that can be explored in [[adventurer mode]]. They are created in a time before time, with no known founder. In [[fortress mode]], [[messenger]]s can make contact with mysterious sites to establish an alliance or war by meeting with a guardian.

==Structure==
All mythic sites have an aboveground room and an underground section. There are a number of common features, such as vertical [[bars]] activated by [[lever]]s, [[Trap#Weapon trap|trapped]] [[chest]]s, and treasure on a [[Ramp|raised]] floor.

The smallest of the mythic site types, lairs are square buildings with two floors and several floor plans. Dungeons are larger and deeper, often with multiple levers protecting the treasure room. Palaces are even more elaborate, featuring several floors both above and below ground, and the building is circular, like a [[dark fortress]]. Many of the inhabitants have a special [[dungeon guardian]] [[syndrome]], and the strongest of them can wield a [[magic]] weapon: a [[Artifact|legendary]], [[Item quality|masterwork]] item, made from a [[primordial remnant]]. The rewards are greater, as [[Large pot|pots]] and [[jug]]s filled with [[Mythical substance|healing substances]] are scattered throughout.

[[File:Adv weather light inside eerie.png]] When inside a mythic site, the [[Weather|atmosphere]] is described as ''"The area gives off a sickly light."''

==Inhabitants==
Each site is lead by a [[dungeon guardian]], an [[Immortality|immortal]] [[historical figure]] with a unique title (such as "ancient of the trees" or "bark worshipper"). Currently, this guardian has no interactions throughout history, beyond being a member of a "mythic entity". They are equipped with [[Quality|high-quality]] [[weapon]]s and [[armor]], and good [[combat skill]]s to wield them. They also have a [[Flask|waterskin]] filled with a [[mythical substance]] they can drink to heal.

Their [[Syndrome|title]] grants them [[immortality]], immunity to blindness, fevers, exertion, and fear; removes their need to eat, sleep, and drink; and prevents their physical attributes from raising or rusting. They are sterile, and their personality is maximally loveless, hateful, violent, cruel, and non-altruistic. Visually, their skin is drawn with the same purple tone as a [[necromancer]], or represented as a {{Raw Tile|ÿ|5:1}} glyph.

A small squad of [[goblin]] soldiers (as [[Surroundings#Evil|evil]] creatures that don't need to eat or drink) also guard these sites. They are worse-equipped and less skilled than the aforementioned guardian.

Mythical sites also have [[Creature|animal]] populations, with access to "ancient" variants of predators. These creatures can potentially be drawn from the [[cavern]]s. Mythical animals gain a special prefix inspired by their [[sphere]], with the same effects as the [[dungeon guardian]] syndrome. They are tamed and loyal to the site's defenders.

All inhabitants speak the [[divine language]].

==Treasure==
Offering service to a [[religion]] will start a quest to collect a [[primordial remnant]] from a dungeon. The same [[sphere]] influences the name of both this object and the creature guarding it.

All types of [[armor]] and [[weapon]] can be found in chests. It will usually be of good quality, though any armor defaults to being sized for [[human]]s. Though the guardian's [[entity token]]s suggest that they should be able to make use of [[divine metal]]s and [[Divine fabric|fabric]], they do not have access to those materials.

Mysterious sites are the only known source of [[mythical substance]]s and [[magic]] items made from [[primordial remnant]]s.

==Gallery==
<gallery>
Mysterious lair floors anim.gif|The floors of a lair.
Mysterious lair basement.png|A simple lair's basement.
Mysterious dungeon ground floor.png|Entering a dungeon.
Mysterious dungeon basement.png|A dungeon's locked treasure room.
Mysterious palace embark.png|Upper floors of a palace viewed in Fortress mode.
</gallery>

==See Also==
*[[Dark fortress]]
*[[Vault]]

{{Scriptdata|title=Entity script}}
{{v50 world}}
{{Category|Adventurer mode}}
{{Category|Myth}}

Sphere

2026-09-08T07:58:01Z

Silverwing235:

{{Quality|Superior|13:52, 26 February 2023 (CST)}}
{{av}}

[[File:Spheres_connection_graph.png|thumb|300px|right|A graph showing the connections between all the spheres. A thin line represents a friendship, a thick line a parent/child-relationship, and a red line preclusion.]]A '''sphere''', or '''cosmic principle''', is an aspect where a being has influence. [[Deity|Deities]], [[force]]s, [[angel]]s, [[demon]]s, [[megabeast]]s, [[semi-megabeast]]s, [[forgotten beast]]s and [[titan]]s may be associated with one or more spheres, and [[civilization]]s may prefer certain spheres when selecting creatures to worship. There are currently a total of 130 spheres in ''Dwarf Fortress''.

When entering [[mysterious dungeon]]s, they will be inhabited by [[dungeon guardian]]s with the fabric of their existence, as well as their names, connected to a sphere. These guardians can have three tiers of ranks. For example, if they're connected to the "chaos" sphere, their names can be "servant of change", "chaos priest" and "chaos elder" based on their rank. Ancient artifacts known as [[primordial remnant]]s are connected to spheres, taking a unique form and granting powers depending on the sphere they're connected to.

==Understanding spheres==
A being such as a [[deity]], [[demon]] or [[megabeast]] may come to represent or epitomize certain things like emotions, qualities, terrain types, and items, which are called "spheres". As an example from real-world mythology, the Greek goddess [http://en.wikipedia.org/wiki/Athena Athena] is goddess in the "spheres" of wisdom, warfare, handicrafts and reason.

Gods and adored megabeasts can grant secrets related to their spheres. In unmodded ''Dwarf Fortress'', this means that death gods can teach the secret of life and death to their worshipers, turning them into [[necromancer]]s. If those gods also happen to be associated with nightmares, they can grant the ability to summon [[bogeymen]] and [[nightmare]]s as well.

Dwarves and other creatures will come to worship certain "powerful beings" and, as such, will follow the "religion", and have a relationship with its "deity".

A [[historical figure]] with associated spheres that generates in the wild, or as a god, will be named after its spheres. So a death-aligned demon will be able to raise dead, and should they rule an entity, they will convert the surrounding regions into evil-aligned undead-raising biomes. Nightmare-aligned demons can summon bogeymen and nightmares. The [[Language#language_SYM.txt|symbols]] associated with the sphere will be used to generate first names, compound names, and titles. If an [[interaction]] from a deity creates an [[artifact]], then that artifact will be named using the spheres of the god who gave the blessing.

==Creatures with pre-determined spheres==
While many procedurally generated creatures in ''Dwarf Fortress'' are given random spheres upon creation, there are others who have static spheres, which remain constant across all save files:

*[[Bogeyman]]: Misery, night, nightmares
*[[Bronze colossus]]: Metals, strength, war
*[[Cyclops]]: Light, longevity, minerals, strength, thunder
*[[Dragon]]: Fire, wealth
*[[Ettin]]: Speech, strength
*[[Experiment]]: Deformity, night
*[[Giant]]: Food, strength
*[[Hydra]]: Muck, rebirth, strength
*[[Minotaur]]: Caverns, chaos, darkness, deformity, strength
*[[Nightmare]]: Misery, night, nightmares
*[[Roc]]: Hunting, sky, wind
*[[Werebeast]]: Animals, chaos, moon, night
*[[Night troll]]: Death, Night

==Sphere tokens==
{{Modding}}
According to Toady: "''Spheres have a parent/child list, a friend list, and a preclude list. A deity has either one or two base spheres, and then they pick friends of those spheres, while never choosing a precluded or parent/child sphere of any of the spheres they already have. I tried to be pretty lax with the preclude list so that interesting relationships could pop up.''"

[[Creature token#SPHERE|Creatures]] and [[Inorganic material definition token#SPHERE|inorganic materials]] can be assigned spheres with the [SPHERE:] token.

A [[Interaction token#IS_SPHERE|secret]] uses any number of [IS_SPHERE] tokens to determine what spheres it is available to.

{{clear}}
Available sphere tokens are:

{| {{prettytable}}
|- bgcolor="#999999"
! Sphere
! Parent spheres
! Child spheres
! Friend spheres
! Precluded spheres
! Associated string and properties
! Symbols
|-
| AGRICULTURE || || || FOOD, FERTILITY, RAIN || || it looks constantly to the sky for rain || [[Language_SYM.txt/Food|FOOD]], [[Language_SYM.txt/Nature|NATURE]]
|-
| ANIMALS || NATURE || FISH || PLANTS || || it growls, buzzes, clicks and generally makes a varied racket || [[Language_SYM.txt/Nature|NATURE]], [[Language_SYM.txt/Primitive|PRIMITIVE]]
|-
| ART || || DANCE, MUSIC, PAINTING, POETRY, SONG || INSPIRATION, BEAUTY || || it is decorated with intricate patterns || [[Language_SYM.txt/Flowery|FLOWERY]], [[Language_SYM.txt/Thought|THOUGHT]]
|-
| BALANCE || || || || || it is perfectly symmetric || [[Language_SYM.txt/Balance|BALANCE]]
|-
| BEAUTY || || || ART || BLIGHT, DEFORMITY, DISEASE, MUCK || it is strikingly beautiful || [[Language_SYM.txt/Flowery|FLOWERY]]
|-
| BIRTH || || || CHILDREN, CREATION, FAMILY, MARRIAGE, PREGNANCY, REBIRTH, YOUTH || || it is covered with a filmy sac || [[Language_SYM.txt/New|NEW]]
|-
| BLIGHT || || || DISEASE, DEATH || BEAUTY, FOOD, FERTILITY, HEALING || nearby vegetation seem(sic) to shrink away from it || [[Language_SYM.txt/Death|DEATH]], [[Language_SYM.txt/Ugly|UGLY]]
|-
| BOUNDARIES || || COASTS || || || the pieces of its body are carefully separated by markings || [[Language_SYM.txt/Boundary|BOUNDARY]]
|-
| CAVERNS || || || MOUNTAINS, EARTH || || its moans seem to echo no matter where it resides || NAME_CAVE
|-
| CHAOS || || || WAR || DISCIPLINE, ORDER, LAWS || it spins wildly, lurching and howling || [[Language_SYM.txt/Violent|VIOLENT]], [[Language_SYM.txt/Wild|WILD]]
|-
| CHARITY || || || GENEROSITY, SACRIFICE || JEALOUSY || it seems very pleasant|| [[Language_SYM.txt/Good|GOOD]]
|-
| CHILDREN || || || BIRTH, FAMILY, YOUTH, PREGNANCY || || it never misses an opportunity to jump in puddles || [[Language_SYM.txt/New|NEW]]
|-
| COASTS || BOUNDARIES || || LAKES, OCEANS || || it appears to be covered with rocky crags || [[Language_SYM.txt/Aquatic|AQUATIC]]
|-
| CONSOLATION || || || || MISERY || it radiates a sad kindness || [[Language_SYM.txt/Good|GOOD]], [[Language_SYM.txt/Peace|PEACE]]
|-
| COURAGE || || VALOR || || || it makes those around it feel brave || [[Language_SYM.txt/Assertive|ASSERTIVE]]
|-
| CRAFTS || || || CREATION, LABOR, METALS || || it appears constructed || [[Language_SYM.txt/Artifice|ARTIFICE]]
|-
| CREATION || || || CRAFTS, BIRTH, PREGNANCY, REBIRTH || || small objects seem to pop into existence around it || [[Language_SYM.txt/New|NEW]]
|-
| DANCE || ART || || FESTIVALS, MUSIC, REVELRY || || it whirls, skips and jumps whenever it moves || [[Language_SYM.txt/Dance|DANCE]], [[Language_SYM.txt/Flowery|FLOWERY]]
|-
| DARKNESS || || || NIGHT || DAWN, DAY, LIGHT, TWILIGHT, SUN || it is difficult to see clearly even in bright light || [[Language_SYM.txt/Darkness|DARKNESS]], [[Language_SYM.txt/Mystery|MYSTERY]]
|-
| DAWN || || || SUN, TWILIGHT || NIGHT, DAY, DARKNESS || it always turns to welcome the rise of the sun || [[Language_SYM.txt/New|NEW]], [[Language_SYM.txt/Color|COLOR]], [[Language_SYM.txt/Light|LIGHT]]
|-
| DAY || || || LIGHT, SUN || DARKNESS, NIGHT, DAWN, DUSK DREAMS, NIGHTMARES, TWILIGHT || it hums pleasantly when the sun is high in the sky || [[Language_SYM.txt/Light|LIGHT]]
|-
| DEATH || || || BLIGHT, DISEASE, MURDER, REBIRTH, SUICIDE, WAR || HEALING, LONGEVITY, YOUTH || it has a rattling exhale || [[Language_SYM.txt/Death|DEATH]]
|-
| DEFORMITY || || || DISEASE || BEAUTY || its body is bent and misshapen || [[Language_SYM.txt/Ugly|UGLY]]
|-
| DEPRAVITY || || || LUST || LAWS || it slavers uncontrollably || [[Language_SYM.txt/Evil|EVIL]], [[Language_SYM.txt/Wild|WILD]], [[Language_SYM.txt/Ugly|UGLY]]
|-
| DISCIPLINE || || || LAWS, ORDER || CHAOS || it moves with great focus || [[Language_SYM.txt/Leader|LEADER]], [[Language_SYM.txt/Order|ORDER]]
|-
| DISEASE || || || BLIGHT, DEATH, DEFORMITY || BEAUTY, HEALING || it bears malodorous pustules [ODOR_STRING:death][ODOR_LEVEL:100] || [[Language_SYM.txt/Death|DEATH]], [[Language_SYM.txt/Ugly|UGLY]]
|-
| DREAMS || || || NIGHT, NIGHTMARES || DAY || the details of its form are easily forgotten without deliberate concentration || [[Language_SYM.txt/Mystery|MYSTERY]]
|-
| DUSK || || || TWILIGHT || NIGHT, DAY || it never looks toward the sun || [[Language_SYM.txt/Darkness|DARKNESS]], [[Language_SYM.txt/Mystery|MYSTERY]]
|-
| DUTY || || || ORDER || || it is utterly still when not taking deliberate action || [[Language_SYM.txt/Leader|LEADER]]
|-
| EARTH || || METALS, MINERALS, SALT || CAVERNS, MOUNTAINS, VOLCANOS || || it looks very solid and stocky || [[Language_SYM.txt/Earth|EARTH]]
|-
| FAMILY || || || BIRTH, CHILDREN, MARRIAGE, PREGNANCY || || it appears to be closely related to every other of its kind || [[Language_SYM.txt/Domestic|DOMESTIC]], [[Language_SYM.txt/Family|FAMILY]]
|-
| FAME || || || RUMORS || SILENCE || Fanfare follows it wherever it goes || [[Language_SYM.txt/Assertive|ASSERTIVE]], [[Language_SYM.txt/Leader|LEADER]]
|-
| FATE || || || || LUCK || it never appears to be perturbed or surprised by any happening || [[Language_SYM.txt/Mystery|MYSTERY]], [[Language_SYM.txt/Mythic|MYTHIC]]
|-
| FERTILITY || || || AGRICULTURE, FOOD, RAIN || BLIGHT || it appears to be very healthy || [[Language_SYM.txt/New|NEW]]
|-
| FESTIVALS || || || DANCE, MUSIC, REVELRY, SONG || MISERY || it skips and twirls as it moves || [[Language_SYM.txt/Domestic|DOMESTIC]], [[Language_SYM.txt/Festival|FESTIVAL]]
|-
| FIRE || || || METALS, SUN, VOLCANOS || WATER, OCEANS, LAKES, RIVERS || a sheen around it always seems to rise upward || [[Language_SYM.txt/Fire|FIRE]]
|-
| FISH || ANIMALS || || OCEANS, LAKES, RIVERS, WATER, FISHING || || it only looks comfortable when it is in the water || [[Language_SYM.txt/Aquatic|AQUATIC]], [[Language_SYM.txt/Nature|NATURE]]
|-
| FISHING || || || FISH, HUNTING || || it always moves carefully around water || [[Language_SYM.txt/Aquatic|AQUATIC]], [[Language_SYM.txt/Nature|NATURE]]
|-
| FOOD || || || AGRICULTURE, FERTILITY || BLIGHT || it has the delicious smell of freshly-baked goods [ODOR_STRING:freshly-baked goods][ODOR_LEVEL:100] || [[Language_SYM.txt/Food|FOOD]]
|-
| FORGIVENESS || || || MERCY || REVENGE || it is impossible to hold a grudge near it || [[Language_SYM.txt/Good|GOOD]]
|-
| FORTRESSES || || || WAR || || it is very sturdy-looking || [[Language_SYM.txt/Protect|PROTECT]]
|-
| FREEDOM || || || || ORDER || it eagerly moves from place to place || [[Language_SYM.txt/Freedom|FREEDOM]]
|-
| GAMBLING || || || GAMES, LUCK || || it changes between two colors intermittently || [[Language_SYM.txt/Games|GAMES]], [[Language_SYM.txt/Luck|LUCK]], [[Language_SYM.txt/Wealth|WEALTH]]
|-
| GAMES || || || GAMBLING, LUCK || || it giggles at random || [[Language_SYM.txt/Games|GAMES]]
|-
| GENEROSITY || || || CHARITY, SACRIFICE || || it makes those around it want to give up their possessions || [[Language_SYM.txt/Good|GOOD]]
|-
| HAPPINESS || || || REVELRY || MISERY || it seems to smile constantly || [[Language_SYM.txt/Good|GOOD]]
|-
| HEALING || || || || DISEASE, BLIGHT, DEATH || it is surrounded by a gentle atmosphere || [[Language_SYM.txt/Good|GOOD]], [[Language_SYM.txt/Peace|PEACE]]
|-
| HOSPITALITY || || || || || it radiates an aura of welcoming || [[Language_SYM.txt/Domestic|DOMESTIC]], [[Language_SYM.txt/Good|GOOD]], [[Language_SYM.txt/Peace|PEACE]]
|-
| HUNTING || || || FISHING || || it inspects the ground intently as it moves || [[Language_SYM.txt/Nature|NATURE]], [[Language_SYM.txt/Primitive|PRIMITIVE]], [[Language_SYM.txt/Wild|WILD]]
|-
| INSPIRATION || || || ART, PAINTING, POETRY || || flashes of energy pulse across its surface intermittently || [[Language_SYM.txt/Thought|THOUGHT]]
|-
| JEALOUSY || || || || CHARITY || it appears to be a very bitter creature || [[Language_SYM.txt/Evil|EVIL]], [[Language_SYM.txt/Subordinate|SUBORDINATE]]
|-
| JEWELS || || || MINERALS, WEALTH || || its whole body appears to be faceted in a symmetric fashion || [[Language_SYM.txt/Color|COLOR]], [[Language_SYM.txt/Earth|EARTH]]
|-
| JUSTICE || || || LAWS || || it seems eager to pronounce judgment on others || [[Language_SYM.txt/Good|GOOD]], [[Language_SYM.txt/Protect|PROTECT]]
|-
| LABOR || || || CRAFTS || || it appears very deliberate in its actions || [[Language_SYM.txt/Artifice|ARTIFICE]], [[Language_SYM.txt/Domestic|DOMESTIC]]
|-
| LAKES || WATER || || COASTS, FISH, OCEANS, RIVERS || FIRE || it moves ponderously || [[Language_SYM.txt/Aquatic|AQUATIC]], NAME_LAKE
|-
| LAWS || || || DISCIPLINE, JUSTICE, OATHS, ORDER || CHAOS, DEPRAVITY, MURDER, THEFT || it has a very stark look about it || [[Language_SYM.txt/Order|ORDER]], [[Language_SYM.txt/Protect|PROTECT]], [[Language_SYM.txt/Restrain|RESTRAIN]]
|-
| LIES || || || TREACHERY, TRICKERY || TRUTH || it seems unerringly honest if one does not concentrate || [[Language_SYM.txt/Evil|EVIL]], [[Language_SYM.txt/Mystery|MYSTERY]]
|-
| LIGHT || || || DAY, RAINBOWS, SUN || DARKNESS, TWILIGHT || it returns surrounding light with a new vibrance and intensity || [[Language_SYM.txt/Color|COLOR]], [[Language_SYM.txt/Light|LIGHT]]
|-
| LIGHTNING || WEATHER || || RAIN, STORMS, THUNDER || || it crackles with energy || [[Language_SYM.txt/Assertive|ASSERTIVE]], [[Language_SYM.txt/Light|LIGHT]], [[Language_SYM.txt/Wild|WILD]]
|-
| LONGEVITY || || || YOUTH || DEATH || it always seems to be looking far into the distance || [[Language_SYM.txt/Old|OLD]]
|-
| LOVE || || || || || it stares longingly at those nearby || [[Language_SYM.txt/Flowery|FLOWERY]], [[Language_SYM.txt/Romantic|ROMANTIC]]
|-
| LOYALTY || || || OATHS || TREACHERY || it never abandons its companions || [[Language_SYM.txt/Good|GOOD]], [[Language_SYM.txt/Protect|PROTECT]]
|-
| LUCK || || || GAMBLING, GAMES || FATE || it changes direction suddenly at times || [[Language_SYM.txt/Luck|LUCK]]
|-
| LUST || || || DEPRAVITY || || it has an unnerving stare || [[Language_SYM.txt/Primitive|PRIMITIVE]], [[Language_SYM.txt/Romantic|ROMANTIC]]
|-
| MARRIAGE || || || BIRTH, FAMILY, OATHS, PREGNANCY || || it heckles those it meets that are not married || [[Language_SYM.txt/Flowery|FLOWERY]], [[Language_SYM.txt/Romantic|ROMANTIC]]
|-
| MERCY || || || FORGIVENESS || REVENGE || it always seems like it is on the verge of crying || [[Language_SYM.txt/Good|GOOD]], [[Language_SYM.txt/Protect|PROTECT]]
|-
| METALS || EARTH || || CRAFTS, FIRE, MINERALS || || it appears to have sharp shimmering edges on many parts of its body || [[Language_SYM.txt/Earth|EARTH]]
|-
| MINERALS || EARTH || || JEWELS, METALS || || it has an angular appearance || [[Language_SYM.txt/Earth|EARTH]]
|-
| MISERY || || || TORTURE || CONSOLATION, FESTIVALS, REVELRY, HAPPINESS || it has a distinctly depressing moan || [[Language_SYM.txt/Negative|NEGATIVE]]
|-
| MIST || || || || || it is difficult to see clearly || [[Language_SYM.txt/Mystery|MYSTERY]]
|-
| MOON || || || NIGHT, SKY || || it changes color with the phases of the moon || [[Language_SYM.txt/Darkness|DARKNESS]], [[Language_SYM.txt/Light|LIGHT]], [[Language_SYM.txt/Mystery|MYSTERY]]
|-
| MOUNTAINS || || || CAVERNS, EARTH, VOLCANOS || || it is very solidly built || [[Language_SYM.txt/Earth|EARTH]], NAME_MOUNTAINS
|-
| MUCK || || || || BEAUTY || there is a foul reek about it || [[Language_SYM.txt/Primitive|PRIMITIVE]], [[Language_SYM.txt/Ugly|UGLY]]
|-
| MURDER || || || DEATH || LAWS || it cannot abide anything that lives || [[Language_SYM.txt/Death|DEATH]], [[Language_SYM.txt/Evil|EVIL]]
|-
| MUSIC || ART || || DANCE, FESTIVALS, REVELRY, SONG || SILENCE || it sounds clear tones as its body moves in time || [[Language_SYM.txt/Flowery|FLOWERY]], [[Language_SYM.txt/Music|MUSIC]], '''not'' [[Language_SYM.txt/Silence|SILENCE]]
|-
| NATURE || || ANIMALS, PLANTS || RAIN, SUN, WATER, WEATHER || || it seems most at ease when it is outdoors || [[Language_SYM.txt/Nature|NATURE]]
|-
| NIGHT || || || DARKNESS, DREAMS, MOON, NIGHTMARES, STARS || DAY, DAWN, DUSK, TWILIGHT || it eerily reflects the light of the stars and moon || [[Language_SYM.txt/Darkness|DARKNESS]]
|-
| NIGHTMARES || || || DREAMS, NIGHT || DAY || it reminds those that look upon it of their most unpleasant memories || [[Language_SYM.txt/Darkness|DARKNESS]], [[Language_SYM.txt/Death|DEATH]], [[Language_SYM.txt/Evil|EVIL]], [[Language_SYM.txt/Mystery|MYSTERY]], [[Language_SYM.txt/Ugly|UGLY]], [[Language_SYM.txt/Violent|VIOLENT]]
|-
| OATHS || || || LAWS, LOYALTY, MARRIAGE || TREACHERY || it cannot look directly at somebody that has broken an oath || [[Language_SYM.txt/Order|ORDER]], [[Language_SYM.txt/Protect|PROTECT]]
|-
| OCEANS || WATER || || COASTS, FISH, LAKES, RIVERS, SALT || FIRE || it always raises a part of its body toward the moon || [[Language_SYM.txt/Aquatic|AQUATIC]], NAME_OCEAN
|-
| ORDER || || || DISCIPLINE, DUTY, LAWS || CHAOS, FREEDOM || it moves very stiffly || [[Language_SYM.txt/Order|ORDER]]
|-
| PAINTING || ART || || INSPIRATION || || its surface is always enlivened with a refreshing play of color || [[Language_SYM.txt/Color|COLOR]], [[Language_SYM.txt/Flowery|FLOWERY]]
|-
| PEACE || || || || || it has an incredibly calm demeanor || [[Language_SYM.txt/Peace|PEACE]]
|-
| PERSUASION || || || POETRY, SPEECH || || it rocks back and forth whenever somebody changes their mind in its presence || [[Language_SYM.txt/Assertive|ASSERTIVE]]
|-
| PLANTS || NATURE || TREES || ANIMALS, RAIN || || it always seems to point toward the sun when it is in the sky || [[Language_SYM.txt/Nature|NATURE]]
|-
| POETRY || ART || || INSPIRATION, PERSUASION, SONG, WRITING || || it recites verses in a strange language on occasion || [[Language_SYM.txt/Flowery|FLOWERY]], [[Language_SYM.txt/Thought|THOUGHT]]
|-
| PREGNANCY || || || BIRTH, CHILDREN, CREATION, FAMILY, MARRIAGE || || it appears to be expecting || [[Language_SYM.txt/New|NEW]], [[Language_SYM.txt/Romantic|ROMANTIC]]
|-
| RAIN || WATER, WEATHER || || AGRICULTURE, FERTILITY, LIGHTNING, NATURE, PLANTS, RAINBOWS, STORMS, THUNDER, TREES || || it leaves water wherever it goes || [[Language_SYM.txt/Aquatic|AQUATIC]], [[Language_SYM.txt/Sky|SKY]]
|-
| RAINBOWS || WEATHER || || LIGHT, RAIN, SKY || || it is strikingly colored || [[Language_SYM.txt/Color|COLOR]], [[Language_SYM.txt/Sky|SKY]]
|-
| REBIRTH || || || BIRTH, CREATION, DEATH || || it alternates from instant to instant between sluggishness and extreme vibrancy || [[Language_SYM.txt/New|NEW]]
|-
| REVELRY || || || DANCE, FESTIVALS, HAPPINESS, MUSIC, SONG || MISERY || it moves with a bouncing rhythm || [[Language_SYM.txt/Festival|FESTIVAL]], [[Language_SYM.txt/Good|GOOD]], [[Language_SYM.txt/Wild|WILD]]
|-
| REVENGE || || || || FORGIVENESS, MERCY || it has a fixed and unblinking gaze when interacting || [[Language_SYM.txt/Violent|VIOLENT]]
|-
| RIVERS || WATER || || FISH, LAKES, OCEANS || FIRE || its outer surface seems to flow about its body|| [[Language_SYM.txt/Aquatic|AQUATIC]]
|-
| RULERSHIP || || || || || it is hard to disobey || [[Language_SYM.txt/Leader|LEADER]]
|-
| RUMORS || || || FAME || || it always nods eagerly when somebody is speaking || [[Language_SYM.txt/Mystery|MYSTERY]]
|-
| SACRIFICE || || || CHARITY, GENEROSITY || WEALTH || it inspires those around it to acts of great sacrifice || [[Language_SYM.txt/Protect|PROTECT]]
|-
| SALT || EARTH || || OCEANS || || it makes nearby water undrinkable || NAME_OCEAN
|-
| SCHOLARSHIP || || || WISDOM, WRITING || || it always seems to be deep in thought || [[Language_SYM.txt/Thought|THOUGHT]]
|-
| SEASONS || || || || || its form is ever-changing || [[Language_SYM.txt/Nature|NATURE]]
|-
| SILENCE || || || || FAME, MUSIC || it makes absolutely no sound || [[Language_SYM.txt/Silence|SILENCE]], [[Language_SYM.txt/Peace|PEACE]], '''not''' [[Language_SYM.txt/Music|MUSIC]]
|-
| SKY || || || MOON, RAINBOWS, SUN, STARS, WEATHER, WIND || || it has a slowly shifting pattern on its surface || [[Language_SYM.txt/Sky|SKY]]
|-
| SONG || ART || || FESTIVALS, MUSIC, POETRY, REVELRY || || it sings beautiful songs endlessly || [[Language_SYM.txt/Flowery|FLOWERY]], [[Language_SYM.txt/Music|MUSIC]]
|-
| SPEECH || || || PERSUASION || || it pays attention carefully to anybody that is speaking || [[Language_SYM.txt/Flowery|FLOWERY]], [[Language_SYM.txt/Thought|THOUGHT]]
|-
| STARS || || || NIGHT, SKY || || it appears to sparkle after night falls || [[Language_SYM.txt/Sky|SKY]], [[Language_SYM.txt/Mystery|MYSTERY]]
|-
| STORMS || WEATHER || || LIGHTNING, RAIN, THUNDER || || its movement is the sound of wind and rain || [[Language_SYM.txt/Assertive|ASSERTIVE]], [[Language_SYM.txt/Sky|SKY]], [[Language_SYM.txt/Wild|WILD]]
|-
| STRENGTH || || || || || it looks solidly built || [[Language_SYM.txt/Assertive|ASSERTIVE]]
|-
| SUICIDE || || || DEATH || || it mutters to itself about death || [[Language_SYM.txt/Death|DEATH]]
|-
| SUN || || || DAWN, DAY, FIRE, LIGHT, NATURE, SKY || DARKNESS || it is difficult to look at directly || [[Language_SYM.txt/Assertive|ASSERTIVE]], [[Language_SYM.txt/Light|LIGHT]], [[Language_SYM.txt/Sky|SKY]]
|-
| THEFT || || || || LAWS, TRADE || it always seems to have its attention on the most valuable object in the area || [[Language_SYM.txt/Evil|EVIL]], [[Language_SYM.txt/Mystery|MYSTERY]]
|-
| THRALLDOM || || || || || its movements sound like the rattling of chains || [[Language_SYM.txt/Leader|LEADER]], [[Language_SYM.txt/Subordinate|SUBORDINATE]]
|-
| THUNDER || WEATHER || || LIGHTNING, RAIN, STORMS || || it is incredibly noisy || [[Language_SYM.txt/Assertive|ASSERTIVE]], [[Language_SYM.txt/Sky|SKY]], [[Language_SYM.txt/Wild|WILD]]
|-
| TORTURE || || || MISERY || || it appears to be covered with sharp hooks and barbs || [[Language_SYM.txt/Evil|EVIL]]
|-
| TRADE || || || WEALTH || THEFT || it seems most content when a fair wind is blowing || [[Language_SYM.txt/Trade|TRADE]], [[Language_SYM.txt/Travel|TRAVEL]]
|-
| TRAVELERS || || || || || it never stops moving completely || [[Language_SYM.txt/Trade|TRADE]], [[Language_SYM.txt/Travel|TRAVEL]]
|-
| TREACHERY || || || LIES, TRICKERY || LOYALTY, OATHS || it is unsettling to be around || [[Language_SYM.txt/Evil|EVIL]], [[Language_SYM.txt/Mystery|MYSTERY]]
|-
| TREES || PLANTS || || RAIN || || it is top-heavy || [[Language_SYM.txt/Nature|NATURE]], NAME_FOREST
|-
| TRICKERY || || || LIES, TREACHERY || TRUTH || it has a tendency to laugh quietly to itself every so often || [[Language_SYM.txt/Mystery|MYSTERY]]
|-
| TRUTH || || || || LIES, TRICKERY || it tenses up throughout its entire body whenever somebody tells a falsehood in its presence || [[Language_SYM.txt/Good|GOOD]], [[Language_SYM.txt/Truth|TRUTH]]
|-
| TWILIGHT || || || DAWN, DUSK || LIGHT, DARKNESS, DAY, NIGHT || it chitters briefly before sunrise and just after nightfall || [[Language_SYM.txt/Darkness|DARKNESS]], [[Language_SYM.txt/Mystery|MYSTERY]]
|-
| VALOR || COURAGE || || WAR || || it always tries to embolden any fighting in its presence with exhortations of bravery, even its foes || [[Language_SYM.txt/Assertive|ASSERTIVE]], [[Language_SYM.txt/Violent|VIOLENT]]
|-
| VICTORY || || || WAR || || it looks very proud of itself || [[Language_SYM.txt/Assertive|ASSERTIVE]], [[Language_SYM.txt/Leader|LEADER]]
|-
| VOLCANOS || || || EARTH, FIRE, MOUNTAINS || || it seems to glow brightly from within || [[Language_SYM.txt/Fire|FIRE]], NAME_VOLCANO
|-
| WAR || || || CHAOS, DEATH, FORTRESSES, VALOR, VICTORY || || it bellows and cheers without pause || [[Language_SYM.txt/Assertive|ASSERTIVE]], [[Language_SYM.txt/Leader|LEADER]], [[Language_SYM.txt/Violent|VIOLENT]]
|-
| WATER || || LAKES, OCEANS, RIVERS, RAIN || FISH, NATURE || FIRE || it seems to flow as it moves || [[Language_SYM.txt/Aquatic|AQUATIC]]
|-
| WEALTH || || || JEWELS, TRADE || SACRIFICE || it always seems to be counting something || [[Language_SYM.txt/Wealth|WEALTH]]
|-
| WEATHER || || LIGHTNING, RAIN, RAINBOWS, STORMS, THUNDER, WIND || NATURE, SKY || || it changes appearance based on the clouds and precipitation above || [[Language_SYM.txt/Sky|SKY]]
|-
| WIND || WEATHER || || SKY || || it is surrounded by an everpresent rush of wind || [[Language_SYM.txt/Assertive|ASSERTIVE]], [[Language_SYM.txt/Sky|SKY]], [[Language_SYM.txt/Wild|WILD]]
|-
| WISDOM || || || SCHOLARSHIP || || it acts with unwavering calm || [[Language_SYM.txt/Thought|THOUGHT]]
|-
| WRITING || || || POETRY, SCHOLARSHIP || || it is covered with divine writing || [[Language_SYM.txt/Thought|THOUGHT]]
|-
| YOUTH || || || BIRTH, CHILDREN, LONGEVITY || DEATH || it appears spry and vigorous || [[Language_SYM.txt/Assertive|ASSERTIVE]], [[Language_SYM.txt/New|NEW]]
|}

{{Category|World}}
{{Category|Relationships}}
[[ru:Sphere]]

Trap

2026-09-05T14:18:15Z

Silverwing235: /* Cage trap */

{{Quality|Exceptional|12:31, 21 February 2023 (CST)}}
{{av}}
{{For/see|information on trapping [[vermin]]|[[animal trap]]}}
{{For/see|complex, multi-tile configurations|[[trap design]]}}
[[File:caged_skunk_preview.png|right]]
'''Traps''' are a relatively quick and easy method of defending a fortress. Unlike [[soldier]]s, they're always on duty, and, once set up, need less management. On the other hand, they are immobile and can only lie in wait for foes to walk over the 1 tile they (each) occupy. Traps can be built from the {{k|b}}uild->{{k|t}}raps menu. Most traps need one [[mechanism]], a dwarf with the [[mechanic]] labor designated (higher [[skill]]ed mechanics take less time to build a trap), and at least one other component depending on the type of trap – a stone, a cage, or one or more weapons. They can be built indoors or outdoors on a vacant [[floor]] (natural or constructed). Traps will block the passage of [[caravan]] [[wagon]]s, but not [[trader]]s or their caravans with only pack animals.

Stone-fall, weapon and cage traps will be triggered by most hostile entities entering their tile, with the possible exception of [[thief|thieves]], flying creatures and other [[Forgotten beast|occasional]] [[Titan|fun]] [[Demon|surprises]]. Also some [[invader]]s may recognize some of your traps and avoid them if they can. Any [[unconscious]] creature will trigger traps, including your own dwarves. Conscious dwarves, [[guest]]s, [[liaison|allies]], [[caravan]]s and [[domestic animal]]s do ''not'' set off self-triggered traps.

__TOC__

== Trap management ==
Making mechanisms, setting up traps, and constructing a variety of other buildings all require the [[mechanic]]s skill. Only mechanisms have a quality level so it's a good idea to enable mechanic on the general work force of your fort and restrict mechanic workshops to skilled workers with the profile manager. Clogged traps and triggered cages will generate a "load trap" or "clean trap" labor even if said traps are forbidden. This could quickly send your dwarves into a danger zone as they go to maintain it. This can be prevented by drawing a burrow around said traps, assigning no one to it, and toggling the burrow to restrict all workshops on it to the burrow. Strangely this will also work for the traps (likely because the behaviors that check for jobs is not building-specific, but area-specific, so all jobs generated in the area must be undertaken by those in the burrow). Your dwarves will not touch the traps until the burrow is unrestricted.

Note that only dwarves with the [[mechanic]] labor ''enabled'' will reload cage, stone, or weapon traps. In combat situations, mechanics have a nasty habit of wanting to reload (or clean) traps when they are triggered, regardless of who or what might be near them. [[Forbid]]ding traps after they are built will keep [[Urist|Urist McSuicide]] from deciding to reload a trap in the middle of a [[siege]]. Just remember to unforbid them when things calm down, so the traps are all ready for next time. Note that forbidding a trap after it has been triggered doesn't help, as the job to refill the trap has already been issued in that case, so a mechanic will carry a stone out to the trap anyway. Alternatively, simply order your dwarves to stay within a safe [[burrow]] until any threats have been dealt with.

If a cage trap has captured something and has been left alone for an extended period of time (nearly a year or longer) the caged individual escapes and you will get the announcement "Something has emptied a cage!". If put into a stockpile or claimed, captured individuals will be prevented from escaping, but may suffer [[hunger]].

It is possible to determine the state of a trap (loaded/unloaded) and the components it contains using the {{K|t}} query.

Traps can be deconstructed by pressing {{k|t}} to view the trap (or {{k|q}}, although the name of the trap will not be displayed until it is flagged for removal), followed by {{k|x}} to remove it. Deconstructing a trap leaves the components used in its creation on the ground around the tile. Traps destroyed by hostile action may return damaged objects.

=== Mechanism quality ===
[[File:mechanism_sprite_x2.png|right]]All of the traps listed below, other than Upright Spear*, use [[mechanism]]s in their construction. For weapon traps and stone-fall traps, the [[quality]] of the mechanism used determines the skill level with which the weapon is swung or fired or the boulder is flung:

* Basic - Dabbling (0)
* -Well- - Competent (3)
* +Fine+ - Talented (6)
* *Superior* - Professional (9)
* ≡Exceptional≡ - Master (12)
* ☼Masterwork☼ (including Artifact) - Legendary (15)

Mechanism quality has no effect on cage traps.

: (* Upright spears ''can'' use a mechanism to trigger or automate them, but the mechanism quality has no effect on damage)

== Types of traps ==
There are 4 types of traps; the player selects which type, and selects any specific components, when they designate the trap to be built:

:* '''Stone fall trap''': drops a single [[stone]] on the target, then needs to be re-armed
:* '''Weapon trap''': attempts to hit the target with 1-10 [[weapon]]s, selected from weapons available to the fortress. No re-arming necessary, but subject to being jammed by a corpse
:* '''Cage trap''': traps the victim in a [[cage]], which must be provided; once caged, the cage and prisoner can be moved, and the trap re-armed with a new (empty) cage
:* '''Upright spear/spike''': just that, 1-10 [[spear]]s or [[spike]]s in the ground; can be passive (to make a fall more lethal), or linked to a trigger and/or automated (to poke repeatedly)

=== Stone-fall trap ===
[[File:DFwikiStonefallTrap.png|thumb|right|Stone-fall trap, the one on the left is loaded, while the one on the right is not]]
The simplest trap to construct, a stone-fall trap is essentially a [[stone]] suspended up in the air which is dropped on intruders when the trap is triggered. These are a popular defensive measure early on, as the components needed are readily available as soon as you start mining. A single stone trap will usually '''not''' severely wound or kill most animals and enemies, but can break a bone, which gives you more than enough time and advantage to finish them off with [[military]]. The [[density|weight]] of the stone used in the trap affects the amount of damage the trap does.*

: (* It can be difficult to get your dwarves to use heavier stones, like [[galena]] or [[cinnabar]], when loading the traps. Patient micromanaging from the {{k|z}}/stock menu and/or using {{k|f}}orbid often does the trick. Consider a dedicated "heavy stone" stockpile near the trap, possibly with a door that can temporarily seal the dwarf, trap and stockpile together, so that's the only (or at least nearest) choice they have.)

After each use, a stone-fall trap needs to be reloaded with another stone. This is done by any [[dwarf]] with [[mechanic]] [[skill]] enabled, a task which your dwarves will see to automatically. The dwarf will generally not use the stone that just dropped, but a new one (would you want to put your hands on that gory mess?). Being that stonefall traps do '''not''' alert you of ambushes when triggered by hidden invaders* (the way cage traps do), and ''automatically'' trigger a "reload" job, this can frequently lead your mechanics into peril. You can make your mechanics' lives a lot easier and longer if you disable that labor during sieges or burrow them away from the enemy.

: ''(* For something a bit more complex but quite elegant that will notify you, see [[Trap_design#Land_mines|land mine]].)''

Stone-fall traps respect [[economic stone]] restrictions (which can be changed under Labor/Stone Use). Stone-fall traps cannot be loaded with [[clay]].

Before you write off stone-fall traps as worse versions of weapon traps (see next), note that weapon traps require you to have previously made, [[goblinite|found]], or [[caravan|traded]] for those [[weapon]]s, making them more of an option somewhat later in the game, and then haul and install each, making the completed trap very time consuming. A stone-fall trap only requires a quick mechanism and a stone.

* Shortcut {{k|b}} {{k|t}} {{k|t}}
* Components used: [[mechanism]] and an ordinary [[stone]]
* Appearance: {{Raw Tile|^|7:1}} = ready, {{Raw Tile|^|7:0}} = no stone loaded

=== Weapon trap ===
[[File:DFwikiCorridorWithTraps.png|thumb|right|Serrated disc trap on the left, spiked ball trap on the right]]
Weapon traps are similar in nature to stone-fall traps, and are triggered when any hostile creature steps on the trap. They contain up to 10 weapons, chosen when placing the trap, and can inflict grievous injuries. However, it takes time for the trap's weapons to trigger; enemies who move quickly across the trap may survive unscathed, as the weapons will not hit a creature which has moved off the trap.

When placing the trap you will be asked for a type of mechanism as normal, then asked to select weapons to use. The [[quality]] of a trap's mechanism influences the attack rolls of its weapons.[http://www.bay12forums.com/smf/index.php?topic=14461.msg131214#msg131214]. At this point you will get a list of all stockpiled weapons in your fortress. {{k|+}}{{k|-}} will select different weapons and pressing "Enter/Return" adds 1 of the selected weapon to the trap; you can e{{k|x}}pand the selection to choose more carefully. Up to 10 weapons can be put in each trap and all weapons in the trap will attack at once when it is triggered. When happy with your weapon selection press {{k|d}} to set the trap.

Any weapon can be used, including poor-[[quality]] efforts by your weaponsmith, training weapons and any non-dwarf weapons you have traded for or recovered from dead [[goblin]]s. Think of it as fair retribution when goblins are sliced to pieces by their own [[dagger]]s and [[whip]]s!

When you add a ranged weapon such as a [[crossbow]] to a weapon trap, appropriate ammunition is automatically added and does not need to be selected. One bolt (per crossbow) will be fired each time the trap is triggered, and when those run out, the trap will signal a "reload" order and stop firing. [[Bow]]s and [[blowgun]]s can also be used, though since your dwarves cannot produce [[arrow]]s or [[blowdart]]s themselves, you will need to harvest your ammunition from your [[War|enemies]] (or acquire them via [[trade|caravans]], in the case of arrows).

You can also use the corkscrews that are normally used in [[screw pump]]s, or any of the other specialized [[Trap_component#Trap_Weapons|trap-only weapons]]:

:: {| class="collapsible collapsed" style="border-spacing: 1"
|- style=background-color:#ccf
! colspan=3|            Trap Weapons
|- style=text-align:center
! style=padding-right:1em|[[Metalsmith's forge]] || [[Carpenter's workshop]] || [[Glass furnace]]
|- style=text-align:center;
| style="background-color: #EEE;"|menacing <metal> spike || style="background-color: #EEE;"| menacing <wooden> spike || style="background-color: #EEE;"| menacing <glass> spike
|- style=text-align:center;
|spiked <metal> ball || spiked <wooden> ball || spiked <glass> ball
|-style=text-align:center;
| style="background-color: #EEE;"|enormous <metal> corkscrew || style="background-color: #EEE;"|   enormous <wooden> corkscrew   || style="background-color: #EEE;"| enormous <glass> corkscrew
|-style=text-align:center;
|large, serrated <metal> disc || ''(not available)'' || large, serrated <glass> disc
|- style=text-align:center;
| style="background-color: #EEE;"|giant <metal> axe blade || style="background-color: #EEE;"| ''(not available)'' || style="background-color: #EEE;"| giant <glass> axe blade
|-
|}

:::* Don't know which to make? See [[Trap component]] for a full discussion.

These "trap only" weapons have all the material property advantages and disadvantages that normal weapons have, though they're massively less durable. It should be noted that the trap weapons are larger than normal dwarf weapons, meaning they should be more effective than normal weapons made of equivalent materials. When triggered, this trap will "attack" the creature with all the weapons available to it, normally doing massive damage. This can also be ''very'' messy if the trap is loaded with cutting weapons, often creating an explosion of blood and dismembered body parts. Using blunt weapons reduces the mess somewhat, and you may wish to strategically place a [[User:Uristocrat/Dwarven_Bathtub | Dwarven Bathtub]] nearby. See [[Trap component]] for a full discussion.

Weapon traps do not require slightly suicidal mechanics to reset them after each triggering but instead reset automatically after an unknown period of time. However, there is a 50% chance that a kill will result in the victim getting stuck in the mechanism and cause the trap to jam (use {{k|t}} to check the trap), requiring either a dwarf or other methods to remove the body. Whenever a trap jams, a mechanic will ''automatically'' attempt to clean it if they have a [[path]], so forbidding the body (or forbidding the trap's mechanism in advance) may be necessary to save him from the victim's friends. Note that weapon traps will only jam if they ''directly'' kill the creature – if they instead inflict a mortal wound and cause the creature to bleed out, they will not jam.

The triggering creature will defend from the trap's attacks just like from a dwarf's, by jumping away, dodging and blocking. This can be used in your favor if the trapped tile happens to be mostly surrounded by long falls into spikes, or other [[magma|welcoming gestures]].

*Shortcut: {{k|b}} {{k|t}} {{k|o}}
*Components used: [[mechanism]] and whatever [[weapon]]s you want, limit 10.
*Appearance: {{Raw Tile|^|4:1}} = ready, {{Raw Tile|^|4:0}} = jammed or out of ammo

=== Cage trap ===
[[File:DFwikiCageTrap.png|thumb|right|Cage trap, the one on the left is loaded, while the one on the right is not]]
Cage traps are different from the other trap types, in that they do not directly kill or injure invaders. Instead, they capture the creature that triggers them in a [[cage]]. Despite the unfortunate lack of violence, this is still very effective as it completely neutralizes the target so that it can be dealt with later. After a creature is captured, it's stored in an animal [[stockpile]] if the current standing order is set ({{K|o}}-{{K|a}}). The trap will then be reset by [[hauling]] an empty cage to the trap's location. This is done ''automatically'' by any dwarf with the [[Mechanic]]s labor enabled, but only when permitted by the [[Standing orders|Trap Rearming]] standing order. Cage traps will also alert you to ambushes when triggered by hidden invaders, making them a useful forward defense mechanism.

'''Most''' captured creatures do not require any nourishment and will survive being in a cage indefinitely; in fact, even submersion in water appears to have no effect on caged creatures. It is possible for dwarves to bring [[water]] to cages, but this will only occur if you have someone friendly also locked in the cage – like a dwarf child snatched by a goblin. See below for how to remove things from a cage. During [[siege]]s, caged companions of the attacking faction can be freed.

'''Magma''' can be used to 'clean' magma-safe sprung cage traps and cages that are built or stockpiled, removing non-magma safe materials (and creatures) from the cage. Non-magma safe cages are destroyed as well.

'''Cage traps will not capture every creature in the game''', so you ''will'' need alternative defenses – [[titan]]s and [[forgotten beast]]s (as well as certain [[Trapavoid#Creatures_who_avoid_traps|other types]] of creatures) are immune to traps entirely and will waltz right past all of your carefully placed cages, unless the cage has a giant cave spider web on it. Some creatures are nimble enough to avoid setting off traps, or even escape it completely once triggered. A webbed cage trap '''will''' capture nearly anything ([[Fun|including even your own dwarves]]); the only creatures it cannot capture are those immune to both cage traps and webbing, such as a web-spinning forgotten beast or a dwarf from your fortress on a Collect Webs job.

Cage traps are also useful for catching wild animals. This can be done by simply placing traps in areas where wild animals roam (this does '''not''' require a dwarf with the [[trapping]] labor enabled). The captured animals can be tamed (and sometimes trained into war animals!) at any animal training zone. See [[Animal trainer]] for more on training animals.

In the process of taming a wild animal, there is a chance that seeds will be left in the cage. Dwarves ''only'' load empty cages into traps. One way to remove the seeds and make the cage usable again is to {{K|d}}ump them. First loo{{K|k}} at the cage in your Animal [[stockpile]], then highlight the seed and press {{K|Enter}} to look at the seed, then press {{K|d}} to dump the seed.

* Shortcut: {{k|b}} {{k|t}} {{k|g}}
* Components used: [[mechanism]] and a [[cage]].
* Appearance: {{Raw Tile|^|2:1}} = ready, {{Raw Tile|^|2:0}} = no cage

The material of which a cage is made affects indirectly the speed at which it is loaded into the trap. Thus, heavier cages take longer to load. The more skilled a dwarf is in the [[Mechanics]] skill, the less time they will take to load the cage.

With exception to the latter, cage material has no effect (beyond weight for hauling, value of finished trap, and the fact that [[elf]] merchants will get angry if the cage is wooden). A glass terrarium is just as strong as a steel cage.

To release a creature from a cage, build the cage ({{k|b}} {{k|r}}) {{k|g}}) and use {{k|q}} to unassign it. You can also simply assign the creature to a pasture or pit. To release a hostile creature (or wild animal) safely from a cage, build the cage and link the cage to a [[lever]] that can be remotely triggered. If you have many cages you need to empty out quickly see [[Mass pitting]]. Cages have no current limit to the amount of beasts you can put in them, so you can build one cage and assign all the beasts to that cage. Typical caveats of dealing with wild/hostile animals apply.

As with most traps, if a dwarf goes to sleep or is knocked unconscious over a cage trap, the trap will be triggered and the dwarf will be trapped. Unlike usual creatures, a caged dwarf can starve or die from dehydration.

=== Upright spear/spike ===
[[File:DFwikiRetractedSpikes.png|thumb|right|Left is a spike trap with extended spears, the right is retracted, side by side]]
The previous 3 types of traps trigger when a hostile creature steps on them. An upright spear/spike trap is different – it must be triggered externally to cause the spears or spikes to spring up or to recede back down. Unlike the other traps, the spike trap ''does not discriminate between friend or foe'' – when the spears/spikes spring up, ''any'' creature on that tile will be subject to possible impalement by them. Note that this trap only does damage [[Time|at the exact moment]] that the spikes spring up – once up, they do nothing (unless something falls on them from a height) until they come up again.

If you simply want upright spikes on a tile, placing the upright spear/spike trap does not require a mechanism and it does not require the Mechanic labor. Static spikes only require 1 to 10 [[spear]]s or [[Trap component|spikes]]. Without a link, the trap will not operate, but can still do additional damage to anything that falls on that tile (see below).

Linking it to a [[lever]] or a [[pressure plate]] ''will'' require a mechanism and must be performed by a Mechanic. Mechanism quality has ''no effect'' on accuracy or damage. Retracting the spears/spikes does not require space in the [[z-level]] below the trap. Spike traps do not jam.

When linked to a lever or pressure plate, a close signal will cause them to spring up, while an open signal will cause the spears or spikes to recede. Most [[repeater]]s do not cycle very quickly, so, with only 1 trap, it is easily possible for a unit to walk onto the trap tile after it has sprung up (and is harmless) and then on past it before it goes down and comes up again – multiple traps in a row can be a good idea.

At the risk of stating the obvious, if you plan to recover the bodies or [[goblinite]] left by victims of an automated spike trap, you should also plan some way to turn them off during that recovery. [[Unfortunate accident|Or not]].

An often overlooked ability of an upright spike trap is that it also inflicts damage on a creature that falls onto it while it is deployed. And since they are built in the deployed state they can be quickly built to make a pit trap more lethal, without the need for extra mechanisms. However, you will still need some way to cause your victims to fall onto the spike from above in the first place, and the pit must be more than 1 z level deep for the spikes to cause damage.

* Shortcut: {{k|b}} {{k|t}} {{k|u}}
* Components used: 1-10 spears or spikes, plus further [[mechanism]]s for linking to triggers.
* Appearance: {{Raw Tile|{{!}}|0:1}} = extended, {{Raw Tile|.|7:0}} = retracted

=== Other traps ===
''Main article [[Trap design]]''

You can create [[trap design|even more elaborate traps]] with imaginative use of pits and other long falls, [[pressure plate]]s, [[lever]]s, [[grate]]s, [[support]]s, retracting [[bridge]]s, [[water]] and/or [[magma]], and other features, creating sacrificial altars (blood for the Blood God!) or whatever else your warped mind can think of. Watching those goblins try to find a way out of your drowning chamber as it begins to fill is really quite satisfying. These are best made in a large, automated, ''repeatable'' mass killing way. If you make a trap that kills a couple dozen goblins but only works once before you have to rebuild/reset it, wasting time you don't have during a [[siege]], then you're <s>not trying hard enough</s> asking for too much [[fun]].

== Trap location ==
[[File:kobold_avoid_trap_anim.gif|thumb|150px|right|A kobold harmlessly stepping over a trap without triggering it.]]Enemies will tend to take the shortest path to their target, be that your dwarves, an animal, a single valuable item or a child to be kidnapped (in the case of [[thief|thieves]]), or a door or statue (in the case of [[building destroyer]]s). Putting traps at the inner corner of a turn in a hallway, or in front of a door or the start of a stairway - or just lining* a long hall - gives you the highest chance of a victim walking over the trap.

: ''(* Remember that caravan wagons cannot pass over traps, although traders with pack animals can. Making a hall extra wide, with lots of turns, can allow you to trap the "short path" while the wagons will take the longer path outside the traps. More complicated pathing can be created as well, anything that allows the wagons access and invites invaders to the traps.)''

One of the harder targets to trap are wild animals, since they do not "target" anything, and tend to avoid dwarves. Using walls, you can construct a cross-shaped "funnel" with a gap in the center, and place one or more traps there, and hope the wandering animals will path through that gap rather than around the walls. For flyers, this can be multiple [[z-level]]s high, and may start to take on some aspects of a [[megaproject]].

You also have to think about servicing the traps. Stone traps need to be reloaded, cage traps need to be collected, and weapon traps often need to be un-jammed.. and then there's the bodies and any [[goblinite]] to collect, if only to [[dump]]. Planning the traps so they are close to (sealed?) access allows your mechanics to travel less distance to get the job done. Be aware of the possibility of building destroyers, which will laugh at your locked doors - [[Building_destroyer#Destroying_from_underneath|clever use of hatches]] and u-bends that cross [[z-level]]s can allow safe access while preventing unwelcome surprises.

Note that some building destroyers are [[werebeast]]s, which are usually immune to cages but that have to change form to wreak their havoc. Placing a cage trap in a short side hall in front of a simple wooden door as "bait" near your entry (or multiple such cage/door combinations) can catch the were-creature while they are transforming and thus vulnerable.

Be aware that it can be dangerous for mechanics to undertake maintenance while the path is open to the wide, wild world. Making ''two'' similarly trapped paths, with a [[hatch]] or [[bridge]] or other control system that limits which one is "open" to outsiders, keeps your fortress open while allowing your mechanics to safely service the other area that is currently sealed. Using [[burrow]]s may aid in controlling which areas they are allowed to access at any time.

== See also ==
* [[Mass pitting]]
* [[Trap design]]

{{Translation
| dwarven = ïggal
| elvish = abola
| goblin = stoslo
| human = losric
}}

{{buildings}}
{{Category|Traps}}

Horse

2026-09-04T15:15:58Z

Silverwing235:

{{Quality|Exceptional}}
{{Creaturelookup/0
|image=horse_sprites.png
|portrait=horse_portrait_anim.gif
|contrib=no
|bone=13
|meat=9-10
|fat=8-9
|skull=1
|skin=hide
|hoof=4
|eye=2
|lung=2
|heart=1
|intestine=1
|liver=1
|tripe=1
|sweetbread=1
|spleen=1
|kidney=2
|brain=1
|wiki=yes
}}
{{av}}
{{creaturedesc}}

'''Horses''' are common [[domestic animal|domestic pack animals]] who can often be seen in [[caravan]]s, pulling [[wagon]]s and carrying goods. In addition to producing a large amount of [[meat]], [[fat]] and [[bone]]s when [[butcher]]ed, horses can also be [[milker|milked]] and serve as a viable base for a [[cheese]] industry. [[dwarf|Dwarves]] cannot ride horses, but [[human]]s and [[elf|elves]] can. Horses require a sizable [[pasture]] to survive.

Horses can be bought before embarking, but are quite expensive. Horses are sometimes brought along by [[Immigration|immigrants]], as [[pet]]s or strays. Horses also occur very often as wild animals in herds. They are non-aggressive and will avoid dwarves, but an inexperienced [[hunter]] who engages them in melee will soon find out that they are much bigger than dwarves, and over twice as fast. As they appear quite frequently and in numbers, they are ideal targets for hunting and military practice, being also a good source of butchering products.

Some dwarves [[Preferences|like]] horses for their ''strength''.

[[File:Horsescd1l-095.jpg|thumb|400px|center|Admired for its ''strength''.]]

{{D for Dwarf}}
Horses are '''everywhere'''. That "dwarven" fortress over the distance? It's one dwarf and about 500 horses. The whole world is horses. I'm horses. Hell, you're probably horses too. Neigh.

{{Translation
| dwarven = famthut
| elvish = remìni
| goblin = smuz
| human = mimap
}}

{{Gamedata}}
{{Creatures}}
{{Category|Animals}}

Miohippus

2026-09-04T15:14:49Z

Silverwing235: Clarify grammatical confusion

{{Quality|Tattered}}
{{Creaturelookup/0
|image=miohippus_sprites.png
|portrait=miohippus_portrait_anim.gif
|contrib=no
|bone=11
|meat=13
|fat=13
|skull=1
|skin=hide
|lung=2
|heart=1
|intestine=1
|liver=1
|tripe=1
|sweetbread=1
|spleen=1
|kidney=2
|brain=1
|wiki=yes}}
{{av}}
{{creaturedesc}}

'''Miohippus''' is an [[extinct]] species of [[horse]], introduced in the [[Release_information/53.15|Dino Update]] along with other [[Creature#Extinct|prehistoric creatures]]. About the [[size]] of a [[goat]], it is much smaller than present-day horses, too small to be ridden.

Miohippus can be [[milk]]ed when [[taming|tamed]], and are in fact the only prehistoric animal in the game that produces milk.

Some dwarves [[Preferences|like]] miohippuses for their ''small size'' and ''three toes''.

{{gamedata}}
{{Creatures}}

Deinonychus

2026-08-31T22:05:02Z

Silverwing235: ref edit

{{Quality|Tattered}}
{{Creaturelookup/0
|image=deinonychus_sprites.png
|portrait=deinonychus_portrait_anim.gif
|wiki=yes}}
{{av}}
{{creaturedesc}}
'''Deinonychus''' are [[extinct]] bipedal [[dinosaur]]s from the [[wikipedia:Cretaceous|Cretaceous]] era. They are found in [[Surroundings#Savage|savage]] [[Forest|broadleaf forests]] and [[Shrubland|temperate shrubland]]s, appearing in packs of 3-5. They are large predators and can easily wipe out unarmed citizens they come across. While [[Extinction#Extinct creatures|extinct]] in real life, their appearance is dependent on the settings chosen when [[World generation#Real world extinct creatures|creating a world]]. A young deinonychus is called a ''hatchling''.

Deinonychus can be captured in [[cage]] [[trap]]s and [[Animal trainer|trained]] into exotic [[pet]]s. They can be further trained into war or hunting beasts; their bulk, quick maturity rate, and staggering clutch size make them an excellent option for quickly building an army or bodyguarding force. They are also a good choice for [[egg production]] in general. A large [[egg]] size and high yield of 10-30 eggs per clutch put them on equal footing with [[alligator]]s in terms of volume, though they lack a [[Item value|value multiplier]]. Deinonychus become adults after 1 year and reach their full size after 2.

Some dwarves [[Preferences|like]] deinonychus for their ''scything claws'' and ''feathers''.

{{D for Dwarf}}

Deinonychus seem to have a high tendency to kick [[undead]] creatures to displace them forward, for reasons yet to be uncovered.

{{gamedata}}
{{Creatures}}