Dwarf Fortress Wiki - User contributions [en]

User talk:Chinchou

2016-03-04T01:33:04Z

Chinchou: /* Colon Usage */

Welcome to the Dwarf Fortress wiki! We're always glad to have another editor fixing things around here.--[[User:Loci|Loci]] ([[User talk:Loci|talk]]) 20:07, 3 March 2016 (UTC)

== Colon Usage ==

Regarding this sentence from [[DF2014:Adamantine]]:

:"Adamantine has extreme [[material science|material properties]]: it is nigh weightless (weighing about as much as [[wikipedia:Cork (material)|cork]]), extremely strong, and razor sharp."

The characteristics following the colon describe/explain the extreme material properties stated in the first part of the sentence. It is not necessary to separate those two closely-related thoughts into two sentences. Wikipedia has [https://en.wikipedia.org/wiki/Colon_(punctuation) more information on proper colon usage].

It is also unnecessary to double-space after a period. That "rule" is an unfortunate hold-over from typewriters; modern computers can properly space sentences automatically. In fact, the wiki software completely disregards extra spaces.--[[User:Loci|Loci]] ([[User talk:Loci|talk]]) 20:07, 3 March 2016 (UTC)

The statement "modern computers can properly space sentences automatically" is misleading. While they *can* automatically correct spacing, such a task relies on scripting which is not common. Saying that full stops and their associated pauses/spacing are "an unfortunate hold-over from typewriters" is misinformation. There are two issues with the latter quoted statement: 
- First, it originated from handwriting and was carried over to typewriters. 
- Second, the spacing is indicative of whether there is a full stop or a half stop. Incorrect spacing(such as leaving one space after a full stop) leads to writing that is, at best, difficult to read. The only people I have seen who do not pause after speaking a sentence are hyper-active children - if you've listened to someone who speaks like that, you likely know that it can be quite difficult to understand them. The same holds true in written and typed messages - especially when capitalisation is ignored.
 
As for colon usage, your statement regarding breaks in ideas is irrelevant. Nowhere did I indicate that there was a break in the idea, nor did I ever indicate that it should be split into two sentences. Once again, full stops are followed by a capitalised letter, while half stops are not. Capitalisation is the issue, not whether there is a break in the idea. Capitalisation and spacing are important for any written or typed message - withoutthemwewillendupwithmessagesthatalllooklikethiswhichareverydifficulttoreadletaloneunderstandduetothelackofpunctuationspacesandcapitalisationandisinnowayproperenglish.
 
As for the wiki ignoring full-stop spacing... The wiki also ignores some line breaks, forcing me to use HTML break tags in this very message. "A piece of software does it" does not equate to "it is universally and irrefutably correct".
 
As a final note: If there is a reference for a common dialect on this specific wiki, a link to it would be appreciated. Despite a cursory search, I found no such reference. Without such a reference, I am left to assume that I should use my local dialect for all contributions. [[User:Chinchou|Chinchou]] ([[User talk:Chinchou|talk]]) 01:30, 4 March 2016 (UTC)

User talk:Chinchou

2016-03-04T01:30:43Z

Chinchou: /* Colon Usage */

Welcome to the Dwarf Fortress wiki! We're always glad to have another editor fixing things around here.--[[User:Loci|Loci]] ([[User talk:Loci|talk]]) 20:07, 3 March 2016 (UTC)

== Colon Usage ==

Regarding this sentence from [[DF2014:Adamantine]]:

:"Adamantine has extreme [[material science|material properties]]: it is nigh weightless (weighing about as much as [[wikipedia:Cork (material)|cork]]), extremely strong, and razor sharp."

The characteristics following the colon describe/explain the extreme material properties stated in the first part of the sentence. It is not necessary to separate those two closely-related thoughts into two sentences. Wikipedia has [https://en.wikipedia.org/wiki/Colon_(punctuation) more information on proper colon usage].

It is also unnecessary to double-space after a period. That "rule" is an unfortunate hold-over from typewriters; modern computers can properly space sentences automatically. In fact, the wiki software completely disregards extra spaces.--[[User:Loci|Loci]] ([[User talk:Loci|talk]]) 20:07, 3 March 2016 (UTC)

The statement "modern computers can properly space sentences automatically" is misleading. While they *can* automatically correct spacing, such a task relies on scripting which is not common. Saying that full stops and their associated pauses/spacing are "an unfortunate hold-over from typewriters" is misinformation. There are two issues with the latter quoted statement: 
- First, it originated from handwriting and was carried over to typewriters. 
- Second, the spacing is indicative of whether there is a full stop or a half stop. Incorrect spacing(such as leaving one space after a full stop) leads to writing that is, at best, difficult to read. The only people I have seen who do not pause after speaking a sentence are hyper-active children - if you've listened to someone who speaks like that, you likely know that it can be quite difficult to understand them. The same holds true in written and typed messages - especially when capitalisation is ignored.
 
As for colon usage, your statement regarding breaks in ideas is irrelevant. Nowhere did I indicate that there was a break in the idea, nor did I ever indicate that it should be split into two sentences. Once again, full stops are followed by a capitalised letter, while half stops are not. Capitalisation is the issue, not whether there is a break in the idea. Capitalisation and spacing are important for any written or typed message - withoutthemwewillendupwithmessagesthatalllooklikethiswhichareverydifficulttoreadletaloneunderstandduetothelackofpunctuationspacesandcapitalisationandisinnowayproperenglish.
 
As for the wiki ignoring full-stop spacing... The wiki also ignores some line breaks, forcing me to use HTML break tags in this very message. "A piece of software does it" does not equate to "it is universally and irrefutably correct".
 
As a final note: If there is a reference for a common dialect on this specific wiki, a link to it would be appreciated. Without such a reference, I am left to assume that I should use my local dialect for all contributions. [[User:Chinchou|Chinchou]] ([[User talk:Chinchou|talk]]) 01:30, 4 March 2016 (UTC)

Adamantine

2016-03-03T10:50:12Z

Chinchou: Colons and periods are full stops, not half stops. (Punctuation corrections.)

{{Quality|Masterwork|23:22, 27 April 2013 (UTC)}}
{{Metal|name=Adamantine|color=3:3:1
|ore=
* [[Raw adamantine]]
|properties=
* [[Material value]] 300
|uses=
* [[Weapon|Melee Weapons]]
* [[Crossbow]]s
* [[Bolt]]s
* [[Pick]]s
* [[Armor]]
* [[Anvil]]s
* [[Metalsmith's forge|Metal crafting]]
* [[Clothing]]
|wiki=Adamant}}
{{Translation
| dwarven = ebsas
| elvish = lire
| goblin = kumo
| human = medi
}}
{{av}}{{Minorspoiler}}

'''Adamantine''' is a rare, high-value [[metal]] which is impossibly lightweight, strong, and sharp. Adamantine is refined from raw adamantine, and can be woven into [[cloth]] or [[smelter|smelted]] into wafers, useful for making almost any item in the game. [[Armor]] and edged-[[weapon]]s made from adamantine are absurdly valuable and wonderfully effective.

For more information on its whereabouts and other [[Fun]] information, see '''[[raw adamantine]]'''.

== Processing ==
Unlike what a player would expect, one does not simply make adamantine wafers directly from raw adamantine. You must first extract adamantine strands from the raw adamantine, and those are then processed into wafers or cloth.

Adamantine strands are extracted from [[raw adamantine]] at a [[craftsdwarf's workshop]] by a [[strand extractor]]. Strand extraction is an extremely tedious process for an unskilled laborer, making it potentially worthwhile to focus extraction experience on one or two individual dwarves. Extracted strands are considered a special metallic form of [[thread]], and after extraction can either be woven into adamantine cloth at a [[loom]] or smelted into adamantine [[bar|wafer]]s at a [[smelter]]; thankfully these tasks are performed just as quickly as other weaving and smelting jobs.

Given this extra step of extraction before the smelting phase, most players will want to build additional craftsdwarf's workshops and stockpiles near the smelters and forges. Note that the strands of adamantine are stored in cloth/thread stockpiles. When processing adamantine it is a good idea to smelt the strands into wafers as fast as possible, as your medical dwarves may use your valuable adamantine strands for [[suturing]] wounds, since to them, it's just another type of [[thread]].

Adamantine cloth is used to make ultra high-value clothing, but it is no more resistant to [[wear]] than less exotic materials. Adamantine wafers are functionally identical to metal [[bar]]s and can be used to forge the full range of metal goods, but are far smaller in size, requiring about three times as many units of material per unit as regular metal bars:
* [[weapon token|Weapons]], [[armor token|armor/clothing]], and [[trap component token|trap components]] require the item's MATERIAL_SIZE in wafers/units of cloth
* Most types of furniture ([[door]], [[floodgate]], [[throne]], [[coffin]], [[table]], [[chest]], [[bin]], [[armor stand]], [[weapon rack]], [[cabinet]], [[statue]], [[anvil]], [[barrel]], [[pipe section]], [[hatch cover]], [[grate]], [[quern]], [[millstone]], and [[slab]]) require 9 wafers.
* [[Cage]]s, [[minecart]]s and [[wheelbarrow]]s require 6 wafers.
* [[Block]]s, [[chain]]s, and [[Siege engine|ballista]] arrowheads require 4 wafers.
* [[Animal trap]]s, [[bucket]]s, [[mechanism]]s, and [[crutch]]es require 3 wafers.
* [[Backpack]]s and [[quiver]]s require 2 units of cloth, and [[splint]]s require 2 wafers.
* All other items require 1 wafer.
* [[Strange mood]]s currently require 1 wafer, regardless of the end product.

== Application ==
Adamantine has extreme [[material science|material properties]]: It is nigh weightless (weighing about as much as [[wikipedia:Cork (material)|cork]]), extremely strong, and razor sharp. These properties make it ideal for edged [[weapon]]s and [[armor]]. These properties likewise make it near useless for blunt weapons, which will simply bounce off of foes; considering the lethality of [[hammerer]] and [[fortress guard]] beatings, this may be the point. [[Armor]] made of adamantine provides unmatched protection against slashing and piercing attacks, but blunt attacks and ranged weapons have high armor penetration capacity, so a full kit of adamantine armor is nonetheless not a recipe for combat invulnerability.

Because the metal's material properties are irrelevant in other applications and because it's so rare and hard to produce, using adamantine for other things is generally a waste. Adamantine statues are ten times as valuable as [[gold]] ones, but are prohibitively expensive to produce, requiring nine wafers per statue. Some of the highest values per wafer for a normal adamantine product can be realised by forging adamantine [[flask]]s or [[trap component|large serrated discs]]. However, by the time you have adamantine available, you're likely not to be in serious need of such valuable export products. By far, the most [[wealth]] can be generated by adding adamantine to [[artifact]]s -- a single stone, wafer, block or bolt of cloth can add hundreds of thousands of dwarfbucks in value, making your fortress the envy of all the [[forgotten beast|neighbors]].

{{gamedata}}
{{metals}}

{{spoiler}}

Unfortunately, breaching any of the tubular veins leads to the [[Hell|HFS]], for lots of [[Losing|Fun]].

==Origins of Adamantine and Slade==
{{D for Dwarf}}
Back in the mists of time, the Gods decided to create the World. To do so they had to find a way to heat it in the cold voids of space. Demonkind had already forged their own world out of the vile substance [[Slade]], a stone anathema to all creation and only able to be worked through the vile rituals they had created, for slade was truly "dead" stone, with no life in it at all.

Deciding both to imprison their greatest enemies and to create a home for their creations, the Gods poured into the skies of the Demons' world "living" stone (known to mortals as [[semi-molten rock]] - rock burning hot with the fresh life of Creation). The Gods knew that if it were not constantly heated, this living rock would cool, and yet the Demons, fools that they were, constantly attacked the living rock, not realizing that their attacks simply heated the rock again and again, keeping it alive. Unfortunately, as the Gods began to pour more and more of the rock onto their creation, they found it quickly lost its life when removed too far from the Demons. It would only remelt once it touched the living rock, creating vast seas of magma that heated the tunnels above. Worse, the living rock itself had been disturbed by this process, creating gaping holes through which the Demons escaped, killing and maiming the first creations of the Gods, warping those they could find into the terrible Forgotten Beasts, leaving the [[Titan]]s safe on the surface.

Knowing this state of affairs could not last if their weaker creations, the first mortals, were to survive, the Gods created a new substance, imbued with their power: Adamantine. The beautiful aqua-colored ore was poured into the holes, sealing the entrances that the living rock could no longer seal, preventing the Demons from escaping, for its power totally repelled Demonkind.

Unfortunately, as time passed and the first mortals began to carve their civilization from both the surface and the underworld, they discovered the vast shafts of this amazing substance and began to mine it, instantly realizing its divine potency. In doing so, they removed the great barriers the gods had placed in order to keep the Demons sealed. The Demons rose up, slaughtering thousands and escaping into the World, often rising to lead mortal civilizations, such as that of the Goblins. Upon these sites they raised towers carved from the vile Slade that only they could work. Brave adventurers and champions of the Gods forged special swords made from the divine Adamantine and ventured into these dark places to seal the Demons within hell once more. Leaving their swords buried in these places, those who survived swore to defend them for all eternity, binding themselves with oaths of such might that they surpassed death itself. They remain, even today, as zombies and skeletons, driven by their undying thought "none must take the sword!" and nothing more. These undead are totally obsessed with their duty to defend the ancient demonic structures from all interlopers and have been the death of many an unwary explorer.

In retrospect, all this could probably have been avoided if the Gods had bothered to make their all-powerful metal capable of withstanding the swing of a copper pick.

==The Great Adamantine Space Elevator==
{{D for Dwarf}}
[http://www.bay12forums.com/smf/index.php?topic=61507.0 Source]

In a great fluke, a new world was created in the midst of Armok shaving. No one quite understands why this happened, but the whisker of the holy one landed vertically. The material can only be described as a super adamantine. It is over 2000 z-levels high. And the map continues on.

Year after year, the dwarves of [SUBJECT CIVILIZATION HERE] send an expedition out into the world in order to ascertain the fate of last year's expedition. It has long-since been forgotten exactly when this series of fruitless expeditions started, but the dwarves are a sort that demand an answer.

It happens year after year, when they head northeast to the ominous shrubland that has been known only in name: "The Hill of Spit." The hill lies beyond a ruined elven settlement, a stone's throw away from a brook that has come to be known as "Troublemysteries." By the time they arrive, it is already too late.

They embark year after year, and there they stand, awe-struck with their implements of dwarven duty left undisturbed at their feet. All about them are the decrepit wagons and bleached bones of those who heralded their grim arrival -- barrels filled with rot and worm, picks covered in rust and dust. There they stand with their eyes open wide and jaws agape, and they stare upward into the dome of the heavens. What they see is beyond the ken of mortal beard. It reaches from the ground higher than any bird has flown; higher than any cloud has drifted; higher than any man, dwarf, beast or monster has ever or will ever ascend, twisting and writhing upward in ways that can only transfix the gaze of unwary observers in their fundamentally impossible geometries -- a spiraling needle of pure adamantine, ascending beyond the vanishing-point into the sky.

They stand there, motionless and breathless, and wait only for time to wear them down into the dust of the earth from whence they came, leaving that siren spire standing amidst a graveyard of wagons and barrels to call more of their bearded kind to an emaciated doom.

Another year, another expedition unheard of, another question unanswered, another expedition prepared.

Ethic

2016-03-01T20:12:26Z

Chinchou: "Eachother" is not a word. Assuming "each other" was meant and correcting accordingly.

{{Quality|Superior|15:42, 31 July 2014 (UTC)}}
{{av}}

'''Ethic''' tags are used in the [[Entity token|entity raw files]] to determine how different civilizations feel about various issues. Relationships between civilizations are based on their ethic responses in relation to each other; similar ethics result in friendship, while conflicting ethics result in animosity. Strongly conflicting ethics often trigger [[war]]s during [[world generation]].

In practice, this generally causes [[Elf|elves]] to declare war on everybody else over killing plants and making trophies, and everybody else to declare war on the elves over the devouring of sapient beings.

Some ethics also affect [[fortress mode]] features such as [[justice]] or [[trading]]. In [[adventurer mode]], ethics can affect the [[level of conflict]] (lethal, or no quarter). During [[world generation]], ethics also affect how the entity treats its kills, such as devouring them or making trophies out of them.

== Example ==
In the [[raw file]]s for entities, ethics appear as follows:
[ETHIC:LYING:PERSONAL_MATTER]

This means that the entity will treat lying as a personal matter. More technically, the value of its LYING ethic is set to PERSONAL_MATTER.

== Ethic types ==
{| {{prettytable}}
|- bgcolor="#dddddd"
!Token
!Extra Information
|-
| {{text anchor|ASSAULT}}
| The result of a tantruming citizen attacking another in fortress mode. Other effects unknown.
|-
| {{text anchor|EAT_SAPIENT_KILL}}
| This determines if the race will sometimes devour dead enemy combatants of their own race.
|-
| {{text anchor|EAT_SAPIENT_OTHER}}
| This also determines whatever or not a race is willing to butcher other sapients.
|-
| {{text anchor|KILL_ANIMAL}}
| A response between MISGUIDED and UNTHINKABLE (see below) causes the entity to refuse animal products in trade — namely, [[material token|materials]] with [IMPLIES_ANIMAL_KILL].
|-
| {{text anchor|KILL_ENEMY}}
| If REQUIRED, all lethal combat with an enemy who is an enemy of the whole entity will put the creature in [[no quarter]] mode.
|-
| {{text anchor|KILL_ENTITY_MEMBER}}
| If REQUIRED, all lethal combat with an enemy in the same entity will put the creature in [[no quarter]] mode. Determines whether and how often characters will be murdered.
|-
| {{text anchor|KILL_NEUTRAL}}
| If REQUIRED, all lethal combat with an enemy who is neutral with the entity will put the creature in [[no quarter]] mode.
|-
| {{text anchor|KILL_PLANT}}
| This determines a race's position towards wood as well — a response between MISGUIDED and UNTHINKABLE (see below) causes the entity to refuse wooden objects (except for "grown" wooden objects) in trade, and it also prohibits them from bringing caravan [[wagon]]s.
|-
| {{text anchor|LYING}}
|
|-
| {{text anchor|MAKE_TROPHY_ANIMAL}}
| This determines whether animal kills in world-gen will lead to characters with trophies.
|-
| {{text anchor|MAKE_TROPHY_SAME_RACE}}
| This determines whether kills of own race in world-gen will lead to characters with trophies.
|-
| {{text anchor|MAKE_TROPHY_SAPIENT}}
| This determines whether kills of other sapients in world-gen will lead to characters with trophies.
|-
| {{text anchor|OATH_BREAKING}}
| The result of a citizen violating noble mandates in fortress mode. Other effects unknown.
|-
| {{text anchor|SLAVERY}}
|Civilization will enslave defeated enemies and bring them back to their site.
|-
| {{text anchor|THEFT}}
| This determines whether the race will try to steal goods.
|-
| {{text anchor|TORTURE_ANIMALS}}
|
|-
| {{text anchor|TORTURE_AS_EXAMPLE}}
|
|-
| {{text anchor|TORTURE_FOR_FUN}}
|
|-
| {{text anchor|TORTURE_FOR_INFORMATION}}
|
|-
| {{text anchor|TREASON}}
| Protects position holders from being murdered like everyone else. Reason that demon overlords of goblins manage to live for centuries despite goblins killing each other being a personal matter.
|-
| {{text anchor|TRESPASSING}}
|
|-
| {{text anchor|VANDALISM}}
| The result of a tantruming citizen breaking furniture in fortress mode. Other effects unknown.
|}

==Ethic values==
As used internally (see below), roughly in order of acceptability:

{| {{prettytable}}
|- bgcolor="#dddddd"
! Num !! Token
|-
| 0 || {{text anchor|NOT_APPLICABLE}}
|-
| 1 || {{text anchor|ACCEPTABLE}}
|-
| 2 || {{text anchor|PERSONAL_MATTER}}
|-
| 3 || {{text anchor|JUSTIFIED_IF_NO_REPERCUSSIONS}}
|-
| 4 || {{text anchor|JUSTIFIED_IF_GOOD_REASON}}
|-
| 5 || {{text anchor|JUSTIFIED_IF_EXTREME_REASON}}
|-
| 6 || {{text anchor|JUSTIFIED_IF_SELF_DEFENSE}}
|-
| 7 || {{text anchor|ONLY_IF_SANCTIONED}}
|-
| 8 || {{text anchor|MISGUIDED}}
|-
| 9 || {{text anchor|SHUN}}
|-
| 10 || {{text anchor|APPALLING}}
|-
| 11 || {{text anchor|PUNISH_REPRIMAND}}
|-
| 12 || {{text anchor|PUNISH_SERIOUS}}
|-
| 13 || {{text anchor|PUNISH_EXILE}}
|-
| 14 || {{text anchor|PUNISH_CAPITAL}}
|-
| 15 || {{text anchor|UNTHINKABLE}}
|-
| 16 || {{text anchor|REQUIRED}}
|}

==Ethic value numbers in relation to each other==
The following table describes how entities respond to other cultures, with the observer on the vertical axis and their target on the horizontal axis.
If an entity's accumulated animosity towards another passes a certain threshold (determined by ruler's personality) then it will run a risk-assessment check. If passed, this will lead to a declaration of war.

In general, entities react much more strongly to actions that violate their taboos than to the outlawing of their customs in other civilisations.
For example, Civ A finds slavery Acceptable, but Civ B considers it a Capital Offence.
* Civ A will consider Civ B most unreasonable (−5) for executing people over such a non-issue.
* Civ B will be shocked and disgusted (−15) that Civ A engages in such a debased activity.
* The end result is mutual negativity. However, Civ B is 3× ''more'' offended, and much more likely to go to war over the issue — assuming, of course, they think they have a chance of winning.

{| {{prettytable}}
|- bgcolor="#dddddd"
! rowspan=2 colspan=2 |  
! colspan=16 | TARGET
|- bgcolor="#dddddd"
!| Accept. || Personal || Reperc. || Good || Extreme || Self-Def. || Sanctioned || Misguided || Shun || Appalling || Reprimand || Serious || Exile || Capital || Unthinkable || Required
|-
! rowspan=16 | {{rotate|OBSERVER}}     
! Acceptable || {{tc|blue|+1}} || {{tc|blue|+1}} || {{tc|blue|+1}} || 0 || 0 || 0 || 0 || {{tc|red|−1}} || {{tc|red|−2}} || {{tc|red|−2}} || {{tc|red|−2}} || {{tc|red|−3}} || {{tc|red|−5}} || {{tc|red|−5}} || {{tc|red|−2}} || {{tc|blue|+1}}
|-
! Personal || {{tc|blue|+1}} || {{tc|blue|+1}} || {{tc|blue|+1}} || 0 || 0 || 0 || 0 || {{tc|red|−1}} || {{tc|red|−2}} || {{tc|red|−2}} || {{tc|red|−2}} || {{tc|red|−3}} || {{tc|red|−5}} || {{tc|red|−5}} || {{tc|red|−2}} || {{tc|blue|+1}}
|-
! No Reperc. || {{tc|blue|+1}} || {{tc|blue|+1}} || {{tc|blue|+1}} || 0 || 0 || 0 || 0 || {{tc|red|−1}} || {{tc|red|−2}} || {{tc|red|−2}} || {{tc|red|−2}} || {{tc|red|−3}} || {{tc|red|−5}} || {{tc|red|−5}} || {{tc|red|−2}} || {{tc|blue|+1}}
|-
! Good Reas. || 0 || 0 || 0 || {{tc|blue|+2}} || {{tc|blue|+1}} || 0 || 0 || 0 || {{tc|red|−1}} || {{tc|red|−1}} || {{tc|red|−1}} || {{tc|red|−1}} || {{tc|red|−1}} || {{tc|red|−1}} || {{tc|red|−1}} || 0
|-
! Extreme Rs. || {{tc|red|−1}} || {{tc|red|−1}} || 0 || {{tc|blue|+1}} || {{tc|blue|+2}} || 0 || 0 || 0 || {{tc|red|−1}} || {{tc|red|−1}} || {{tc|red|−1}} || {{tc|red|−1}} || {{tc|red|−1}} || {{tc|red|−1}} || {{tc|red|−1}} || {{tc|red|−1}}
|-
! Self-Defence || {{tc|red|−2}} || {{tc|red|−2}} || {{tc|red|−1}} || 0 || {{tc|blue|+1}} || {{tc|blue|+2}} || 0 || 0 || 0 || {{tc|red|−1}} || {{tc|red|−1}} || {{tc|red|−1}} || {{tc|red|−1}} || {{tc|red|−1}} || {{tc|red|−1}} || {{tc|red|−2}}
|-
! Sanctioned || {{tc|red|−2}} || {{tc|red|−2}} || {{tc|red|−1}} || 0 || {{tc|blue|+1}} || 0 || {{tc|blue|+2}} || 0 || 0 || {{tc|red|−1}} || {{tc|red|−1}} || {{tc|red|−1}} || {{tc|red|−1}} || {{tc|red|−1}} || {{tc|red|−1}} || {{tc|red|−2}}
|-
! Misguided || {{tc|red|−1}} || {{tc|red|−1}} || 0 || 0 || 0 || 0 || 0 || {{tc|blue|+2}} || {{tc|blue|+1}} || {{tc|blue|+1}} || {{tc|blue|+1}} || 0 || 0 || {{tc|red|−1}} || {{tc|blue|+1}} || {{tc|red|−1}}
|-
! Shun || {{tc|red|−1}} || {{tc|red|−1}} || 0 || 0 || 0 || 0 || 0 || {{tc|blue|+1}} || {{tc|blue|+2}} || {{tc|blue|+1}} || {{tc|blue|+1}} || 0 || 0 || {{tc|red|−1}} || {{tc|blue|+1}} || {{tc|red|−1}}
|-
! Appalling || {{tc|red|−5}} || {{tc|red|−5}} || {{tc|red|−3}} || {{tc|red|−2}} || {{tc|red|−1}} || {{tc|red|−1}} || {{tc|red|−2}} || {{tc|blue|+1}} || {{tc|blue|+1}} || {{tc|blue|+2}} || {{tc|blue|+1}} || {{tc|blue|+1}} || {{tc|blue|+1}} || 0 || {{tc|blue|+1}} || {{tc|red|−5}}
|-
! Reprimand || {{tc|red|−5}} || {{tc|red|−5}} || {{tc|red|−3}} || {{tc|red|−2}} || {{tc|red|−1}} || {{tc|red|−1}} || {{tc|red|−2}} || {{tc|blue|+1}} || {{tc|blue|+1}} || {{tc|blue|+1}} || {{tc|blue|+2}} || {{tc|blue|+1}} || {{tc|blue|+1}} || 0 || {{tc|blue|+1}} || {{tc|red|−5}}
|-
! Serious || {{tc|red|−10}} || {{tc|red|−10}} || {{tc|red|−7}} || {{tc|red|−3}} || {{tc|red|−2}} || {{tc|red|−2}} || {{tc|red|−3}} || 0 || {{tc|blue|+1}} || {{tc|blue|+1}} || 0 || {{tc|blue|+2}} || {{tc|blue|+1}} || {{tc|blue|+1}} || {{tc|blue|+1}} || {{tc|red|−10}}
|-
! Exile || {{tc|red|−10}} || {{tc|red|−10}} || {{tc|red|−7}} || {{tc|red|−3}} || {{tc|red|−2}} || {{tc|red|−2}} || {{tc|red|−3}} || 0 || {{tc|blue|+1}} || {{tc|blue|+1}} || 0 || {{tc|blue|+1}} || {{tc|blue|+2}} || {{tc|blue|+1}} || {{tc|blue|+1}} || {{tc|red|−10}}
|-
! Capital || {{tc|red|−15}} || {{tc|red|−15}} || {{tc|red|−10}} || {{tc|red|−5}} || {{tc|red|−3}} || {{tc|red|−3}} || {{tc|red|−5}} || 0 || 0 || {{tc|blue|+1}} || 0 || {{tc|blue|+1}} || {{tc|blue|+1}} || {{tc|blue|+2}} || {{tc|blue|+1}} || {{tc|red|−15}}
|-
! Unthinkable || {{tc|red|−15}} || {{tc|red|−15}} || {{tc|red|−10}} || {{tc|red|−5}} || {{tc|red|−3}} || {{tc|red|−3}} || {{tc|red|−5}} || 0 || {{tc|blue|+1}} || {{tc|blue|+1}} || 0 || {{tc|blue|+1}} || {{tc|blue|+1}} || {{tc|blue|+1}} || {{tc|blue|+2}} || {{tc|red|−15}}
|-
! Required || {{tc|blue|+1}} || {{tc|blue|+1}} || {{tc|blue|+1}} || 0 || 0 || 0 || 0 || {{tc|red|−1}} || {{tc|red|−2}} || {{tc|red|−2}} || {{tc|red|−2}} || {{tc|red|−3}} || {{tc|red|−5}} || {{tc|red|−5}} || {{tc|red|−2}} || {{tc|blue|+1}}
|}

All above info was collected and interpreted from the data given by Toady himself at [http://www.bay12forums.com/smf/index.php?topic=22151.msg239689].

{{Category|Modding}}
{{Category|Tokens}}

Modding

2016-03-01T11:17:21Z

Chinchou: Punctuation corrections and tweaks.

{{Quality|Exceptional|14:13, 7 November 2013 (UTC)}}
{{av}}
This is intended to be a guide to inform those new to DF modding on what elements of the game can be modified, and how. After reading through this guide, a user should be capable of editing creatures, entities, materials ''et al'', and creating their own.

Generally, breaking stuff is fine - nothing that can be changed will affect the DF executable, and new additions can be easily removed.

This guide is based on [[40d:Modding guide|Teldin's guide]], originally created for version 0.27.176.39c. Per wiki tradition, it has been updated through all the major releases since then; hopefully it reflects current knowledge.

'''See also:''' [[:Category:DF2014:Modding]]

= Modding Guide =

== Token Reference ==

It's always good to refer to tokens on the wiki. Even experienced modders have to look up tokens! A list of articles about tokens can be found [http://dwarffortresswiki.org/index.php/Token here.]

== Basics of DF modding ==

All the base data that can be edited by prospective modders can be found in the \raw\ folder. This folder contains two subfolders: "graphics" (where you insert [[Graphics set repository|graphics sets]]), and "objects", which contains all the data for generally everything in the game that is not hardcoded.

Within the \raw\objects folder are a large number of text files - these are the [[raw file|raw files]], and editing them is quite easy - you can also create your own if you wish. For now, take a look at one of the existing files. For example if you open creature_standard.txt it should look something like this:

creature_standard

[OBJECT:CREATURE]

[CREATURE:DWARF]
[DESCRIPTION:A short, sturdy creature fond of drink and industry.]
[NAME:dwarf:dwarves:dwarven]
[CASTE_NAME:dwarf:dwarves:dwarven]
[CREATURE_TILE:1][COLOR:3:0:0]
[CREATURE_SOLDIER_TILE:2]
...

As you can see, each file comprises a header string stating the file name, a second header stating the type of object data it contains, followed by the contents of the file itself. These are all necessary elements of the file, and without them, the file won't be parsed correctly by the game. You may have also noticed the file naming scheme - this is also important; files containing creatures have names starting with "creature_", entity file names must begin with "entity_", etc..

Below the headers, there begins a list of entries. Each entry is made up of its own header (in this case, "[CREATURE:DWARF]"), again stating the type of object, and then the object's unique identifier - if an identifier isn't unique, the game will mess up and you'll get some serious, and potentially very trippy, errors. Below that, we have the body of the entry, which determines the entry's specific properties.

The body of an entry is made up of a series of "tokens", which are essentially flags that can be added or removed to affect the entry's attributes. Most of these effects are hardcoded: for example, it's possible to make a creature only eat meat with the [CARNIVOROUS] token, but it's impossible to create your own token detailing a specific diet for the creature.

Before we continue, a few key things to remember when modding the raw files:

* Try to avoid modifying the existing raw files when adding objects. It makes removing mods far easier.
* When adding files, all you need to include to ensure proper references are maintained is the token identifier's. The game will load up all *.txt in the raw folder, and searches through them by tokens. For example: You can add a new pair of leather boots and not even have to add it to the item_shoes.txt file, but rather make your own file, say item_shoes_new.txt and ensure you have the token listed, ex. [ITEM_SHOES:ITEM_SHOES_BOOTS_NEW], that's how the game will look for the item.
* If you want to edit an already-existing creature, always back up the files you plan on editing to a different location. Since v0.31.22, the game no longer loads backup files, but duplicate entries are still a very bad thing.
* When a new world is generated, all the raw files get copied into a \raw\ folder within the applicable save folder. If you want to change something within a world that's already been generated, you'll have to edit those files, not the ones in ~DF\raw\objects.
* There's nothing stopping you from just copying an existing creature/entity/whatever, changing the identifier, and modifying it. This can save you a lot of time, especially when it comes to entities... which are coincidentally what we'll be talking about next.

== Modding civilizations (entities) ==

Entities - the objects that determine how civilizations work - are stored in entity_default.txt (though, like all other files, you may add more). They follow the same format as any other raw file:

entity_default

[OBJECT:ENTITY]

[ENTITY:ENTITYNAME]
[CREATURE:CREATURETYPE]
[TRANSLATION:LANGUAGETYPE]
[BIOME_SUPPORT:BIOMETOKEN:FREQENCY]
...[OTHER TAGS]...

Most of the time, it doesn't matter which order these tokens are in or where they're placed so long as they're below the "ENTITY:" identifier, but there are some important exceptions in the case of other files, especially creatures, which can contain a lot of "nested" tokens.

"[CREATURE:]" links the civilization with a specific creature defined in a creature file. This is the creature that'll be making up the entity's population, and will therefore be the creature you'll be playing as in fortress or adventure mode if the entity is a playable one. For example, if you wanted to do something silly, you could switch the "CREATURE:DWARF" entry in entity_default.txt with "CREATURE:ELF" and you would be marching elves around in fortress mode, although they would still use dwarven technology and language and names and so forth.

Oh, and before you get any funny ideas - it ''is'' possible to define more than one creature for a civ, but that won't work in quite the way you probably expect; later on, in the creature section, you'll learn about castes, which will provide a much more viable alternative, so try to bear with us until then.

"[TRANSLATION:]" defines the language file that the entity will be using, which will determine what their untranslated words are for things. This doesn't determine which words they use for naming things, only the way those words are spelled. The default language files are HUMAN, DWARF, ELF, and GOBLIN.

"[BIOME_SUPPORT:]" defines the biomes that civs will attempt to settle in. The "FREQUENCY" value determines the likelihood of them building there, but also raises an important point: Most of the values you'll be setting for things are relative to each other. If one were to type:

[BIOME_SUPPORT:ANY_FOREST:1]
[BIOME_SUPPORT:SAVANNA:2]

This would have very much the same effect as:

[BIOME_SUPPORT:ANY_FOREST:5]
[BIOME_SUPPORT:SAVANNA:10]

This holds true for a lot of values throughout the files, excluding when it simply doesn't make sense, such as in materials.

You can find many details about the rest of the civilization tokens [[entity token|here]]. Besides those mentioned, some fundamental ones are the CIV_CONTROLLABLE token, which lets you control the civ in fortress mode, the INDIV_CONTROLLABLE token, which allows you to play the civ in adventure mode as an outsider, and the ADVENTURE_TIER token, which allows you to play a civ native (non-outsider) in adventure mode. Other tokens that you should pay attention to are START_BIOME and the ones regarding sites, but in general, you can just run through the aforementioned list and add or remove what you want.

If you have more than one civ with the CIV_CONTROLLABLE token, all the available civs from those entities will appear in the group selection section on the embark screen. It may not be immediately obvious from which species each civ may be - while this can be determined from legends mode, the topmost species in the "neighbors" display in the embark screen is always the same as the currently selected species; if your group is dwarven, dwarves will be topmost, whilst (say) elves will be topmost if your chosen group is elven. By default, the game seems to choose a civ (and therefore a species if there is more than one) at random.

You can also attempt to discern the civ yourself by the names it uses - this is the realm of "symbols", collections of words centered around a specific concept. The civ will use the words comprising whatever symbols are applicable to it for various things. This association might be a little obfuscating at first, so I'll run through it. Let's refer to the DWARF entity:

[SELECT_SYMBOL:WAR:NAME_WAR]
[SUBSELECT_SYMBOL:WAR:VIOLENT]
[SELECT_SYMBOL:BATTLE:NAME_BATTLE]
[SUBSELECT_SYMBOL:BATTLE:VIOLENT]
[SELECT_SYMBOL:SIEGE:NAME_SIEGE]
[SUBSELECT_SYMBOL:SIEGE:VIOLENT]

Here we can see that dwarves will generally name their wars first after words in the "NAME_WAR" symbol group, and then after words in the "VIOLENT" symbol group. This might, for example, result in a war being named "The War of Carnage". The symbols used for the other types of conflict are arrayed in a similar fashion. It would be trivial to replace the instances of VIOLENT with, say, PEACE and end up with a battle called "The Clash of Calm" or something.

[SELECT_SYMBOL:ROAD:NAME_ROAD]
[SELECT_SYMBOL:TUNNEL:NAME_TUNNEL]
[SELECT_SYMBOL:BRIDGE:NAME_BRIDGE]
[SELECT_SYMBOL:WALL:NAME_WALL]

The above applies here. Dwarves are fond of naming their roads and tunnels after roads and tunnels.

[SELECT_SYMBOL:REMAINING:ARTIFICE]
[SELECT_SYMBOL:REMAINING:EARTH]
[CULL_SYMBOL:ALL:DOMESTIC]
[CULL_SYMBOL:ALL:SUBORDINATE]
[CULL_SYMBOL:ALL:EVIL]
[CULL_SYMBOL:ALL:UNTOWARD]
[CULL_SYMBOL:ALL:FLOWERY]
[CULL_SYMBOL:ALL:NEGATIVE]
[CULL_SYMBOL:ALL:UGLY]
[CULL_SYMBOL:ALL:NEGATOR]

This section deals with everything else. The things that haven't already been dealt with (hence the "REMAINING") - such as site names, kingdom names, the names of individuals, and such - will have names from the ARTIFICE and EARTH symbol groups. After that the dwarf entity is told to cull all innapropriate symbols - this applies to everything (hence the "ALL") so if the game happens to choose a symbol associated with, say, EVIL for one of the battles, it'll scrap that name and try again. This sort of thing adds a lot of flavour to DF's entities and can account for a lot of a civ's perceived personality.

Another basic thing to note: Any entity token that's dealing with weapons, armor, clothing, etc., will state the items that the civ can build natively, not necessarily the ones they can wear or use. For example, you could create a species with no clothes specified, but then rob a clothes shop in adventurer mode and wear everything you want, or give them weapons that are too large to wield and they could sell them, but not use them.

An easy method of creating a civilization is just to copy-paste a similar one to the bottom of the entity_default.txt file and edit things to your liking. Remember to always change the civ's "ENTITY:" identifier! This can be anything so long as it's not already existing.

At the end of some of the default entries you'll find a list of positions, both ones that'll directly affect you in fort mode (such as nobles) and ones that'll primarily affect worldgen and adventure mode. A list of the tokens applicable to positions can be found [[position token|here]]; they don't require a great deal of explanation.

== Modding the creatures ==

Creature modding is great fun. You can change nearly any aspect of a creature or make your own completely from scratch.

Modding creatures is very similar to modding civs: it's just a matter of editing, adding, or removing tokens, enclosed in square brackets underneath the creature's [CREATURE:] header. The creature entries contain all of the information about each and every non-random creature in the game, from animals to dwarves to goblins to even caravan wagons. A lot of the creature tokens are fairly self-explanatory; you can find a list of such tokens [[creature token|here]]. But before you start creating your own creatures, you'll want to learn how the tissues system works.

=== Creature materials and tissues ===

In the most basic sense, a creature is a series of bodyparts. These parts are defined in their own file, and we'll talk about them later. As a specific aspect of how creatures work which throws off a lot of prospective modders is the relationship between bodyparts, tissues, and materials. We're going to show you part of the creature entry for a bronze colossus (bear with us):

...
[BODY:HUMANOID:2EYES:2EARS:NOSE:HUMANOID_JOINTS:5FINGERS:5TOES]
[NO_THOUGHT_CENTER_FOR_MOVEMENT]
[TISSUE:BRONZE]
[TISSUE_NAME:bronze:bronze]
[TISSUE_MATERIAL:INORGANIC:BRONZE]
[MUSCULAR]
[FUNCTIONAL]
[STRUCTURAL]
[RELATIVE_THICKNESS:1]
[CONNECTS]
[TISSUE_SHAPE:LAYER]
[TISSUE_LAYER:BY_CATEGORY:ALL:BRONZE]
...

At the top, we can see the "BODY:" token, followed by a list of bodyparts. As you've probably guessed, these parts make up the physical form of the colossus. But the colossus has to be made out of something - it has to have tissues. And those tissues also have to be made out of something - in this case, bronze.

Below the BODY token you'll see a TISSUE token, followed by an identifier, much like the others we've seen. The TISSUE block is determining how the tissue works, and which purposes it'll serve. As the colossus is just going to be made out of this one tissue, this tissue needs to act like bone, muscle, and everything else combined, hence the MUSCULAR, FUNCTIONAL and STRUCTURAL tokens. The tissue also references a material - INORGANIC:BRONZE - the properties of which are declared in the inorganic materials file, and the tissue is subsequently made out of this material. With us so far?

Below the tissue definition is the TISSUE_LAYER line. TISSUE_LAYER allows you to control where each tissue is applied. Its first argument defines if it's to search by bodypart category (BY_CATEGORY), bodypart type (BY_TYPE), or look for a specific part (BY_TOKEN). That's followed by the parts argument itself, which is in this case ALL (so the game's looking for parts in all categories, which is to say, every bodypart). This is followed by the tissue to be applied, BRONZE. So the TISSUE_LAYER token is telling the game to select all bodyparts in every category and make them out of the tissue "BRONZE". The colossus is now made of bronze.

By now you're probably thinking "Wow, if this was for a creature made out of however many tissues, this would be amazingly longwinded". And you're right. Luckily, there are two methods by which we can speed things up a lot.

Firstly, there are material and tissue templates. Let's say you were going to make a lot of creatures out of bronze, and you didn't want to have to copy and paste the bronze tissue all over the place. Instead, you create a tissue template. This goes, as you've probably guessed, in a tissue template file.

[TISSUE_TEMPLATE:BRONZE_TEMPLATE]
[TISSUE_NAME:bronze:bronze]
[TISSUE_MATERIAL:INORGANIC:BRONZE]
[MUSCULAR]
[FUNCTIONAL]
[STRUCTURAL]
[RELATIVE_THICKNESS:1]
[CONNECTS]
[TISSUE_SHAPE:LAYER]

Now, instead of applying the tissue to each and every bronze creature you're making, you can just refer to the template:

...
[BODY:HUMANOID:2EYES:2EARS:NOSE:HUMANOID_JOINTS:5FINGERS:5TOES]
[NO_THOUGHT_CENTER_FOR_MOVEMENT]
[USE_TISSUE_TEMPLATE:BRONZE:BRONZE_TEMPLATE]
[TISSUE_LAYER:BY_CATEGORY:ALL:BRONZE]
...

Material templates work in the same way, but refer to materials instead of tissues.

However, if we're looking at something like a dwarf, even with the templates, editing can get very slow indeed:

...
[USE_MATERIAL_TEMPLATE:SKIN:SKIN_TEMPLATE]
[USE_MATERIAL_TEMPLATE:FAT:FAT_TEMPLATE]
[USE_MATERIAL_TEMPLATE:MUSCLE:MUSCLE_TEMPLATE]
[USE_MATERIAL_TEMPLATE:BONE:BONE_TEMPLATE]
[USE_MATERIAL_TEMPLATE:CARTILAGE:CARTILAGE_TEMPLATE]
[USE_MATERIAL_TEMPLATE:HAIR:HAIR_TEMPLATE]
[USE_MATERIAL_TEMPLATE:TOOTH:TOOTH_TEMPLATE]
[USE_MATERIAL_TEMPLATE:EYE:EYE_TEMPLATE]
[USE_MATERIAL_TEMPLATE:NERVE:NERVE_TEMPLATE]
[USE_MATERIAL_TEMPLATE:BRAIN:BRAIN_TEMPLATE]
[USE_MATERIAL_TEMPLATE:LUNG:LUNG_TEMPLATE]
[USE_MATERIAL_TEMPLATE:HEART:HEART_TEMPLATE]
[USE_MATERIAL_TEMPLATE:LIVER:LIVER_TEMPLATE]
[USE_MATERIAL_TEMPLATE:GUT:GUT_TEMPLATE]
[USE_MATERIAL_TEMPLATE:STOMACH:STOMACH_TEMPLATE]
[USE_MATERIAL_TEMPLATE:PANCREAS:PANCREAS_TEMPLATE]
[USE_MATERIAL_TEMPLATE:SPLEEN:SPLEEN_TEMPLATE]
[USE_MATERIAL_TEMPLATE:KIDNEY:KIDNEY_TEMPLATE]
[USE_TISSUE_TEMPLATE:SKIN:SKIN_TEMPLATE]
[USE_TISSUE_TEMPLATE:FAT:FAT_TEMPLATE]
[USE_TISSUE_TEMPLATE:MUSCLE:MUSCLE_TEMPLATE]
...

This is where body detail plans come in. Detail plans, of course, have their own file, and they are designed to help automate some of the more common processes in creature creation. The first entry in b_detail_plan_default.txt does exactly what we've been trying to do above: it takes all the common materials and shoves them into one plan, which can be referenced with a single token.

...
[BODY_DETAIL_PLAN:STANDARD_MATERIALS]
...

Much easier. But what about the TISSUE_LAYER tokens? Will we have to type out all of those manually?

Nope, detail plans have that covered as well. It's possible to place variable arguments into a detail plan. For example:

[BODY_DETAIL_PLAN:VERTEBRATE_TISSUE_LAYERS]
[BP_LAYERS:BY_CATEGORY:BODY:ARG3:50:ARG2:5:ARG1:1]
[BP_LAYERS:BY_CATEGORY:BODY_UPPER:ARG3:50:ARG2:5:ARG1:1]
[BP_LAYERS:BY_CATEGORY:BODY_LOWER:ARG3:50:ARG2:5:ARG1:1]
[BP_LAYERS:BY_CATEGORY:ARM:ARG4:25:ARG3:25:ARG2:5:ARG1:1]
[BP_LAYERS:BY_CATEGORY:ARM_UPPER:ARG4:25:ARG3:25:ARG2:5:ARG1:1]
...
[BP_LAYERS:BY_CATEGORY:NOSE:ARG5:4:ARG1:1]
...

First an argument is placed in the plan (ARG1, ARG2 etc.), followed by the thickness of the tissue that will be inserted in place of the argument. So when we reference the VERTEBRATE_TISSUE_LAYERS plan, we'll be able to do something like this:

[BODY_DETAIL_PLAN:VERTEBRATE_TISSUE_LAYERS:SKIN:FAT:MUSCLE:BONE:CARTILAGE]

ARG1 in the detail plan is replaced by SKIN, the first tissue we entered. ARG2 is replaced by FAT, ARG3 by muscle, ARG4 by bone, and ARG5 by CARTILAGE. Hence, our creature's bodypart designated as BODY is made up of SKIN with thickness 1, FAT with thickness 5, and MUSCLE with thickness 50. Its nose is made up of SKIN (thickness 1) and CARTILAGE (thickness 4).

Things left out of the body plans aside, our dwarf's entire body, material, tissue and tissue layer tokens have been boiled down to this:

...
[BODY:HUMANOID:2EYES:2EARS:NOSE:2LUNGS:HEART:GUTS:ORGANS:HUMANOID_JOINTS:
THROAT:NECK:SPINE:BRAIN:SKULL:5FINGERS:5TOES:MOUTH:FACIAL_FEATURES:TEETH:RIBCAGE]
[BODY_DETAIL_PLAN:STANDARD_MATERIALS]
[BODY_DETAIL_PLAN:STANDARD_TISSUES]
[BODY_DETAIL_PLAN:VERTEBRATE_TISSUE_LAYERS:SKIN:FAT:MUSCLE:BONE:CARTILAGE]
...

This can save you a lot of time and space if you're making lots of changes common to many creatures. In general, if you're making a creature that's fleshy or chitinous, there're detail plans already included in the game to help you out. You should only have to resort to declaring tissues individually (like our bronze colossus) if you're doing something really out-of-the-ordinary.

Another great thing about templates (and so, detail plans) is that they can be modified after being declared. Let's say we wanted our dwarves to be perpetually on fire (don't ask). We declare the body stuff normally:

...
[BODY:HUMANOID:2EYES:2EARS:NOSE:2LUNGS:HEART:GUTS:ORGANS:HUMANOID_JOINTS:
THROAT:NECK:SPINE:BRAIN:SKULL:5FINGERS:5TOES:MOUTH:FACIAL_FEATURES:TEETH:RIBCAGE]
[BODY_DETAIL_PLAN:STANDARD_MATERIALS]
[BODY_DETAIL_PLAN:STANDARD_TISSUES]
[BODY_DETAIL_PLAN:VERTEBRATE_TISSUE_LAYERS:SKIN:FAT:MUSCLE:BONE:CARTILAGE]
...

We then select the appropriate material:

...
[BODY:HUMANOID:2EYES:2EARS:NOSE:2LUNGS:HEART:GUTS:ORGANS:HUMANOID_JOINTS:
THROAT:NECK:SPINE:BRAIN:SKULL:5FINGERS:5TOES:MOUTH:FACIAL_FEATURES:TEETH:RIBCAGE]
[BODY_DETAIL_PLAN:STANDARD_MATERIALS]
[BODY_DETAIL_PLAN:STANDARD_TISSUES]
[BODY_DETAIL_PLAN:VERTEBRATE_TISSUE_LAYERS:SKIN:FAT:MUSCLE:BONE:CARTILAGE]
[SELECT_MATERIAL:SKIN]
[MAT_FIXED_TEMP:10600]
...

We don't want them burning to death, so we'll need to stop that from happening:

...
[BODY:HUMANOID:2EYES:2EARS:NOSE:2LUNGS:HEART:GUTS:ORGANS:HUMANOID_JOINTS:
THROAT:NECK:SPINE:BRAIN:SKULL:5FINGERS:5TOES:MOUTH:FACIAL_FEATURES:TEETH:RIBCAGE]
[BODY_DETAIL_PLAN:STANDARD_MATERIALS]
[BODY_DETAIL_PLAN:STANDARD_TISSUES]
[BODY_DETAIL_PLAN:VERTEBRATE_TISSUE_LAYERS:SKIN:FAT:MUSCLE:BONE:CARTILAGE]
[SELECT_MATERIAL:SKIN]
[MAT_FIXED_TEMP:10600]
[SELECT_MATERIAL:ALL]
[HEATDAM_POINT:NONE]
...

Note that this makes use of DF's built-in temperature scale. You can read more about that [[Temperature|on this page]]. We're also referencing material tokens, which we haven't gone over yet - we'll talk about making your own materials later.

=== Creature castes ===

Another potentially extremely powerful part of the creature raws is the caste system. The caste system handles both true biological castes and lesser variations, such as sexes.

To understand the true potential of the caste system, we only need to take a look at the raws for antmen, found in creature_subterrenean.txt:

...
[CASTE:WORKER]
[CASTE_NAME:worker ant woman:worker ant women:worker ant woman]
Female, but non-breeding.
[POP_RATIO:10000]
[CASTE:SOLDIER]
[CASTE_NAME:soldier ant woman:soldier ant women:soldier ant woman]
Female, but non-breeding.
[POP_RATIO:1000]
[CASTE:DRONE]
[MALE]
[CASTE_NAME:drone ant man:drone ant men:drone ant man]
[POP_RATIO:5]
[CASTE:QUEEN]
[FEMALE]
[CASTE_NAME:queen ant woman:queen ant women:queen ant woman]
[POP_RATIO:1]
[SELECT_CASTE:WORKER]
[SELECT_ADDITIONAL_CASTE:SOLDIER]
[SELECT_ADDITIONAL_CASTE:QUEEN]
[BODY:HUMANOID_4ARMS:2EYES:HEART:GUTS:BRAIN:MOUTH]
[BODYGLOSS:INSECT_UPPERBODY:INSECT_LOWERBODY]
[SELECT_CASTE:DRONE]
[BODY:HUMANOID_4ARMS:2EYES:HEART:GUTS:BRAIN:MOUTH:2WINGS]
[BODYGLOSS:INSECT_UPPERBODY:INSECT_LOWERBODY]
[FLIER]
[SELECT_CASTE:ALL]
[BODY_DETAIL_PLAN:CHITIN_MATERIALS]
[BODY_DETAIL_PLAN:CHITIN_TISSUES]
[BODY_DETAIL_PLAN:EXOSKELETON_TISSUE_LAYERS:CHITIN:FAT:MUSCLE]
[BODY_DETAIL_PLAN:STANDARD_HEAD_POSITIONS]
[ATTACK:PUNCH:BODYPART:BY_TYPE:GRASP]
[ATTACK_SKILL:GRASP_STRIKE]
[ATTACK_VERB:punch:punches]
...

It's evident that the process of creating and editing castes is comparable to the modifications we were making to tissues and materials earlier: A caste is declared, and modifications to the base creature are made. Declared castes can be selected and subsequently modified, again, just like tissues and materials.

In this case, each caste is declared, given its own name, and a POP_RATIO, which determines how commonly a birth results in that caste - for every 10000 workers born, there'll be an average of 1000 soldiers, 5 drones and one queen. You've probably also noticed that the DRONE and QUEEN castes have the MALE and FEMALE tokens respectively - these tokens determine how breeding works. A creature without both a MALE caste and a FEMALE caste will be unable to breed (no asexual creatures yet, unfortunately). As they lack FEMALE, the workers and soldiers are unable to breed with the male drones.

After this, there are some modifications to bodyparts. In this case, the drones have wings and the FLIER token, which the other castes lack. It's entirely possible for creatures of different castes to have completely different body stuctures, even to the extent that they don't resemble each other at all. If you read the section of this guide that dealt with entities, you may remember a passing mention of multi-creature civilisations and how they don't quite work as you may think they would. The castes system is your workaround. You could create a caste that is, for all intents and purposes, a human, and another caste of the same creature that acts exactly like a giant cave spider, put the creature in a civ, and get a human-spider civ. The only flaw in this approach is that the castes will interbreed.

That's the most complex components of creature creation out of the way. You should find the rest trivial by comparison.

== Modding items ==

Items are fairly simple to deal with. By default, each item type is contained in its own file; this may help make browsing for a specific item easier, but from a purely technical point of view, it's possible to throw all items into one file. Unfortunately, item tokens don't seem to be especially well-documented (at least not as well as the other object types), but you should be able to figure out most things by way of our explanations and your assumptions.

Let's look at the entry for, of course, the thong:

[ITEM_PANTS:ITEM_PANTS_THONG]
[NAME:thong:thongs]
[LAYER:UNDER]
[COVERAGE:25]
[LAYER_SIZE:10]
[LAYER_PERMIT:30]
[MATERIAL_SIZE:1]
[SOFT]
[LEATHER]
[STRUCTURAL_ELASTICITY_WOVEN_THREAD]

Most of these are pretty obvious if one compares them to the other entries in the file. There's a layer for the item, determining where it's worn; a coverage value to determine how well it protects you from cold and other things; a size token to determine how much it counts for when it's under something else; a layer permit token to determine how much can be worn under it; and a material size token to determine how much raw material it takes to make it.

Now, if you wanted to mod these to turn them into metal thongs (ouch!), you would simply have to add [METAL] to it somewhere. Simple! These tokens work by tying into material properties - some materials are designated as suitable for making hard items, some for soft, etc..

Weapons involve a little more detail:

[ITEM_WEAPON:ITEM_WEAPON_SWORD_2H]
[NAME:two-handed sword:two-handed swords]
[SIZE:900]
[SKILL:SWORD]
[TWO_HANDED:67500]
[MINIMUM_SIZE:62500]
[MATERIAL_SIZE:5]
[ATTACK:EDGE:100000:8000:slash:slashes:NO_SUB:1250]
[ATTACK:EDGE:50:4000:stab:stabs:NO_SUB:1000]
[ATTACK:BLUNT:100000:8000:slap:slaps:flat:1250]
[ATTACK:BLUNT:100:1000:strike:strikes:pommel:1000]

SIZE determines how heavy the weapon is. This has a substantial effect on weapon effectiveness. SKILL determines which skill is used in using the weapon; a list of skills can be found [[skill token|on this page]]. MINIMUM_SIZE determines the minimum size a creature must be before the weapon can be wielded, while TWO_HANDED determines how large a creature must be in order to wield the weapon with one hand.

Attacks take a little more explanation. The first value determines the contact area of the weapon's attack; this should be high for slashing weapons and low for bludgeoning, piercing and poking ones. The second value determines how deep the weapon penetrates - for BLUNT attacks this value is ignored as they're not supposed to penetrate anyway, but in the case of EDGE attacks it should generally be lower for slashing attacks and higher for stabbing attacks.

Following these are the nouns and verb used; they should be self-explanatory. Finally, we have the velocity modifier, which has a multiplying effect on the weapon's size for the purposes of determining how powerful it is in combat.

Other, more miscellaneous items are generally simple and shouldn't require any further explanation.

Once you've made an item, you just add it to the civ entry so a civilization can actually craft it, and it's done.

== Modding language files ==

Let's say you added a whole new species. Sure, you could just swipe one of the existing translation files and steal their language for your species, but that's the lazy way! If you want to create a whole new language, it is very simple.

First, you'd need a whole new language_RACE file, such as language_LIZARDMAN.txt, along with "language_LIZARDMAN" at the top of the file proceeded by [OBJECT:LANGUAGE] and [TRANSLATION:LIZARDMAN]. After that, it's just a matter of copy-pasting one of the existing language lists and editing the finished 'translated' word. That's it! Then just add the translation link to your civ in entity_default.txt and it'll be added to the game on worldgen.

(Note that the name of the file doesn't actually matter; however, it's good form to name the file after a creature if only that creature speaks the language.)

== Modding body parts ==

Imagine you have this fantastic idea for a multi-tentacled winged spider-monster. Sounds great! But in order to make this a reality you may need to create a new set of body parts for it. That's no problem! Making body parts is easy, though it may look complicated at first.

All of the default body definitions are located in body_default.txt and then linked to a creature in the creature's entry. We've talked about how bodyparts make up creatures earlier, in the creature section. You can mix and match them in the creature entry and it makes no difference, as long as they're there: each bodypart will link itself to the appropriate connection automatically when the creature is first created.

Body parts work by sections: you can add as many sections as you want to a bodypart definition, but generally you should keep it fairly low for ease of use. Each body section entry is in the, very simple, format:

[BODY:BODYNAME]
[BP:TOKENID:name][TOKENSGOHERE][DEFAULT_RELSIZE:][CATEGORY:WHATEVER]

The most important tokens are "CONTYPE" and "CON": CONTYPE means the bodypart in question is connected to a certain ''type'' of bodypart, while CON means it's connected to a ''specific'' one. TOKENID is yet another identifier, which should be unique, as it's referenced every time something uses CON or BY_TOKEN. DEFAULT_RELSIZE defines, of course, what the bodypart's size is in relation to the other parts. CATEGORY defines a category for the part, which can be unique or shared with other parts. This is referenced whenever BY_CATEGORY is used.

A list of bodypart tokens can be found [[body token|here]].

Let's take a simple example, a head:

[BODY:BASIC_HEAD]
[BP:HD:head:STP][CONTYPE:UPPERBODY][HEAD][CATEGORY:HEAD]
[DEFAULT_RELSIZE:300]

It connects directly to an upper body.

[BODY:2EYES]
[BP:REYE:right eye:STP][CONTYPE:HEAD][SIGHT][EMBEDDED][SMALL][RIGHT][CATEGORY:EYE]
[DEFAULT_RELSIZE:5]
[BP:LEYE:left eye:STP][CONTYPE:HEAD][SIGHT][EMBEDDED][SMALL][LEFT][CATEGORY:EYE]
[DEFAULT_RELSIZE:5]

These are a pair of eyes, connecting to the head.

[BODY:HUMANOID]
[BP:UB:upper body:upper bodies][UPPERBODY][CATEGORY:BODY_UPPER]
[DEFAULT_RELSIZE:1000]
[BP:LB:lower body:lower bodies][CON:UB][LOWERBODY][CATEGORY:BODY_LOWER]
[DEFAULT_RELSIZE:1000]
[BP:HD:head:STP][CON:UB][HEAD][CATEGORY:HEAD]
[DEFAULT_RELSIZE:300]
[BP:RUA:right upper arm:STP][CON:UB][LIMB][RIGHT][CATEGORY:ARM_UPPER]
[DEFAULT_RELSIZE:200]
[BP:LUA:left upper arm:STP][CON:UB][LIMB][LEFT][CATEGORY:ARM_UPPER]
[DEFAULT_RELSIZE:200]
[BP:RLA:right lower arm:STP][CON:RUA][LIMB][RIGHT][CATEGORY:ARM_LOWER]
[DEFAULT_RELSIZE:200]
[BP:LLA:left lower arm:STP][CON:LUA][LIMB][LEFT][CATEGORY:ARM_LOWER]
[DEFAULT_RELSIZE:200]
[BP:RH:right hand:STP][CON:RLA][GRASP][RIGHT][CATEGORY:HAND]
[DEFAULT_RELSIZE:80]
[BP:LH:left hand:STP][CON:LLA][GRASP][LEFT][CATEGORY:HAND]
[DEFAULT_RELSIZE:80]
[BP:RUL:right upper leg:STP][CON:LB][LIMB][RIGHT][CATEGORY:LEG_UPPER]
[DEFAULT_RELSIZE:500]
[BP:LUL:left upper leg:STP][CON:LB][LIMB][LEFT][CATEGORY:LEG_UPPER]
[DEFAULT_RELSIZE:500]
[BP:RLL:right lower leg:STP][CON:RUL][LIMB][RIGHT][CATEGORY:LEG_LOWER]
[DEFAULT_RELSIZE:400]
[BP:LLL:left lower leg:STP][CON:LUL][LIMB][LEFT][CATEGORY:LEG_LOWER]
[DEFAULT_RELSIZE:400]
[BP:RF:right foot:right feet][CON:RLL][STANCE][RIGHT][CATEGORY:FOOT]
[DEFAULT_RELSIZE:120]
[BP:LF:left foot:left feet][CON:LLL][STANCE][LEFT][CATEGORY:FOOT]
[DEFAULT_RELSIZE:120]

An entire humanoid body. The foot bone's connected to the ankle bone...

"BODYGLOSS" entries, which you can sometimes find applied to creature entries, are simply replacement words for specific part name strings in a creature. For example, you'll find the bodygloss [BODYGLOSS:CLAW_HAND:hand:claw] in body_default.txt; you can then use this in a creature via "[BODYGLOSS:CLAW_HAND]" and it'll replace all instances of "hand" with "claw" in that creature. Be warned, however—if you were to, say make a bodygloss [BODYGLOSS:EARSTALK:ear:stalk:ears:stalk], it would not only change "ear" and "ears" to "stalk" and "stalks", it would also change "h'''ear'''t" to "h'''stalk'''t"! For all intents and purposes the body part will still function as the proper part, though.

== Modding plants ==

Plants are, again, not unlike creatures. With what you've learned so far in regard to tokens and the materials system, running through the notes included in plant_standard.txt should explain most things. [[Plant token|Here's the list of plant-specific tokens]].

Below is the [[plump helmet]] raw description:

[PLANT:MUSHROOM_HELMET_PLUMP]
[NAME:plump helmet][NAME_PLURAL:plump helmets][ADJ:plump helmet]
[USE_MATERIAL_TEMPLATE:STRUCTURAL:STRUCTURAL_PLANT_TEMPLATE]
[MATERIAL_VALUE:2]
[BASIC_MAT:LOCAL_PLANT_MAT:STRUCTURAL]
[EDIBLE_VERMIN]
[EDIBLE_RAW]
[EDIBLE_COOKED]
[PICKED_TILE:161][PICKED_COLOR:6:13:0]
[GROWDUR:300][VALUE:2]
[USE_MATERIAL_TEMPLATE:DRINK:PLANT_ALCOHOL_TEMPLATE]
[STATE_NAME_ADJ:ALL_SOLID:frozen dwarven wine]
[STATE_NAME_ADJ:LIQUID:dwarven wine]
[STATE_NAME_ADJ:GAS:boiling dwarven wine]
[MATERIAL_VALUE:2]
[DISPLAY_COLOR:5:0:0]
[EDIBLE_RAW]
[EDIBLE_COOKED]
[PREFIX:NONE]
[DRINK:LOCAL_PLANT_MAT:DRINK]

[USE_MATERIAL_TEMPLATE:SEED:SEED_TEMPLATE]
[MATERIAL_VALUE:1]
[EDIBLE_VERMIN]
[EDIBLE_COOKED]
[SEED:plump helmet spawn:plump helmet spawn:4:0:1:LOCAL_PLANT_MAT:SEED]
[SPRING][SUMMER][AUTUMN][WINTER]
[FREQUENCY:100]
[CLUSTERSIZE:5]
[PREFSTRING:rounded tops]
[WET][DRY]
[BIOME:SUBTERRANEAN_WATER]
[UNDERGROUND_DEPTH:1:3]
[SHRUB_TILE:142]
[DEAD_SHRUB_TILE:28]
[SHRUB_COLOR:5:13:0]
[DEAD_SHRUB_COLOR:5:6:0]

Let's look at this line by line: 
First, we define its file name. In this case it's MUSHROOM_HELMET_PLUMP. Next we define its in-game name (plump helmet) and its adjective for if you were to craft with it (e.g. plump helmet earrings).

[USE_MATERIAL_TEMPLATE:STRUCTURAL:STRUCTURAL_PLANT_TEMPLATE]
[MATERIAL_VALUE:2]
[BASIC_MAT:LOCAL_PLANT_MAT:STRUCTURAL]

This defines the structure and material of the plant. It references STRUCTURAL_PLANT_TEMPLATE in the first line, so if you were to say, add wings to the template, the plump helmet plant would be winged. This is for the plant itself, not the end plump helmets.

After that we get our edible tokens. These say that vermin can eat the plant, and it can be eaten raw or cooked by your dwarves. So if you wanted a plant vermin would leave alone, you'd remove the [EDIBLE_VERMIN] token.

[EDIBLE_VERMIN]
[EDIBLE_RAW]
[EDIBLE_COOKED]

Next, [PICKED_TILE:161] is the character (161 in this case) shown when the crop is harvested. See [[Main:Character table|character table]] for a table of usable tiles. [PICKED_COLOR:6:13:0] is the color used for the crop's tile when harvested. It's in a foreground:background:brightness format. See [[color]] for the colors usable.

[PICKED_TILE:161][PICKED_COLOR:6:13:0]

[GROWDUR:300] is how long it takes for your crop to grow. There are 1008 growdur units in a season. 
[VALUE:2] Is the value of harvested plant (default 1). Appears to have no effect in version 0.31.

[GROWDUR:300][VALUE:2]

This defines the plant's alcohol states. [STATE_NAME_ADJ:ALL_SOLID:] is the frozen name, followed is the actual drink name, and then its boiling name. These are achieved by either Scorching or Freezing climates. [DISPLAY_COLOR] is, of course, color, and [EDIBLE_RAW] and [EDIBLE_COOKED] are saying you can drink the alcohol raw or cooked.

[USE_MATERIAL_TEMPLATE:DRINK:PLANT_ALCOHOL_TEMPLATE]
[STATE_NAME_ADJ:ALL_SOLID:frozen dwarven wine]
[STATE_NAME_ADJ:LIQUID:dwarven wine]
[STATE_NAME_ADJ:GAS:boiling dwarven wine]
[MATERIAL_VALUE:2]
[DISPLAY_COLOR:5:0:0]
[EDIBLE_RAW]
[EDIBLE_COOKED]
[PREFIX:NONE]
[DRINK:LOCAL_PLANT_MAT:DRINK]

After that we get our seed template:

[USE_MATERIAL_TEMPLATE:SEED:SEED_TEMPLATE]
[MATERIAL_VALUE:1]
[EDIBLE_VERMIN]
[EDIBLE_COOKED]
[SEED:plump helmet spawn:plump helmet spawn:4:0:1:LOCAL_PLANT_MAT:SEED]

And all this says is that the seeds may be eaten by vermin or cooked. Then it gives the name of our plant's seed, its plural name, its foreground, background, and brightness colors, followed by its seed material; said material should have [SEED_MAT] to permit proper stockpiling.

And finally for the last chunk we have this:

[SPRING][SUMMER][AUTUMN][WINTER]
[FREQUENCY:100]
[CLUSTERSIZE:5]
[PREFSTRING:rounded tops]
[WET][DRY]
[BIOME:SUBTERRANEAN_WATER]
[UNDERGROUND_DEPTH:1:3]
[SHRUB_TILE:142]
[DEAD_SHRUB_TILE:28]
[SHRUB_COLOR:5:13:0]
[DEAD_SHRUB_COLOR:5:6:0]

First we define what season(s) the plant may grow in, then we define how frequently this plant is generated in a particular area, followed by how many harvested crop items may come from 1 plant. [PREFSTRING:] is what your dwarves like about the plant, which in this case is the rounded tops. [WET][DRY] are the conditions under which the plant can grow. Wet means it can grow close to water, dry means it can grow away from water. This does not mean you can grow the plant on dry stone however. It is just for natural spawning of the plant. 
[BIOME] Is what biome the plant grows in. [UNDERGROUND_DEPTH:Minimum:Maximum] Is the highest and lowest cavern levels that the plant can appear in if its biome is subterranean. Dwarven civilizations will only export (via the embark screen or caravans) things that available at depth 1. Defaults to 0:0 (surface only). 
Lastly, [SHRUB_TILE] is the character used for the naturally spawning shrub of this plant, [DEAD_SHRUB] is the dead shrub character. [SHRUB_COLOR] Is the shrub's color, and [DEAD_SHRUB_COLOR] is, of course, the dead shrub's color.

While this may or may not look like a lot of tokens, it's very easy. Just copy an existing plant and edit it to your new plant. 
For the rest of the tokens, see [[plant token]].

== Workshops ==

Workshops are raw-designed pretty differently from everything else in the game, being buildable structures rather than items or methods to gain items. However, they are fairly simple. For example, here's the raw for the [[soap maker's workshop]]:

[BUILDING_WORKSHOP:SOAP_MAKER]
[NAME:Soap Maker's Workshop]
[NAME_COLOR:7:0:1]
[DIM:3:3]
[WORK_LOCATION:2:2]
[BUILD_LABOR:SOAP_MAKER]
[BUILD_KEY:CUSTOM_SHIFT_S]
[BLOCK:1:0:0:1]
[BLOCK:2:0:0:1]
[BLOCK:3:0:0:0]
[TILE:0:1:' ':' ':150]
[TILE:0:2:' ':' ':'/']
[TILE:0:3:'-':' ':' ']
[COLOR:0:1:0:0:0:0:0:0:6:0:0]
[COLOR:0:2:0:0:0:0:0:0:6:0:0]
[COLOR:0:3:6:0:0:0:0:0:0:0:0]
[TILE:1:1:' ':' ':'=']
[TILE:1:2:'-':' ':8]
[TILE:1:3:' ':' ':150]
[COLOR:1:1:0:0:0:0:0:0:6:0:0]
[COLOR:1:2:6:0:0:0:0:0:6:0:0]
[COLOR:1:3:0:0:0:0:0:0:6:0:0]
[TILE:2:1:'-':' ':8]
[TILE:2:2:' ':' ':8]
[TILE:2:3:' ':150:' ']
[COLOR:2:1:6:0:0:0:0:0:6:0:0]
[COLOR:2:2:0:0:0:0:0:0:6:0:0]
[COLOR:2:3:0:0:0:6:0:0:0:0:0]
[TILE:3:1:150:' ':8]
[TILE:3:2:' ':' ':8]
[TILE:3:3:' ':240:' ']
[COLOR:3:1:6:0:0:0:0:0:6:7:0]
[COLOR:3:2:0:0:0:0:0:0:6:7:0]
[COLOR:3:3:0:0:0:7:0:1:0:0:0]
[BUILD_ITEM:1:BUCKET:NONE:NONE:NONE][EMPTY][CAN_USE_ARTIFACT]
[BUILD_ITEM:1:NONE:NONE:NONE:NONE][BUILDMAT][WORTHLESS_STONE_ONLY][CAN_USE_ARTIFACT]

A line-by-line breakdown:

[NAME:Soap Maker's Workshop]
[NAME_COLOR:7:0:1]

These are the name of the workshop ("Soap Maker's Workshop") and [[color]] of the workshop's name when examined with 'q' (White with a black background).

[DIM:3:3]
[WORK_LOCATION:2:2]

DIM refers to how large the workshop will be, in this case 3 wide, 3 tall. WORK_LOCATION tells where the creature using it (usually a dwarf) will work, numbered from the top right--in this case, 2:2, or the middle. Multiple work locations can be defined, even outside the dim.

[BUILD_LABOR:SOAP_MAKER]
[BUILD_KEY:CUSTOM_SHIFT_S]

These refer to the worker required to build it (soap maker) and the key used to build it in the workshop menu (capital S).

[BLOCK:1:0:0:1]
...
This is a bit more complex, and is where we get to the meaty part of workshop making--the tiles' properties. BLOCK refers to which tiles will be untraversable--1 means blocked, 0 means unblocked. The first number refers to row, and the next 3 refer to column, so 1:0:0:1 means that, on the first row, the first two tiles will be unblocked and the last will be blocked.

[TILE:0:1:' ':' ':150]
...
The TILE token tells which tile will go where. note, however, that there are 5 entries here instead of 4. The first number, in this case, refers to build stage, numbered from 0 to 3; 3 or 1 is fully built (depending on whether there are stages), 0 is just placed, and 2 is always an intermediate stage, while 1 is usually an intermediate stage. Whether 1 is an intermediate stage or not depends on if there are a 2 and 3 stage; if 2 and 3 exist, 1 will be intermediate. The second number and beyond are similar to BLOCK; however, instead of 1s and 0s, you must input tiles. The tiles themselves can be given in quotes (as in ' ') or given as a number, which can be looked up [[Tilesets|here]]. Here, we have 150, which is û.

[COLOR:1:1:0:0:0:0:0:0:6:0:0]
...
Color is as TILE, but with colors instead of tiles; however, colors are made up of 3 numbers each or MAT. MAT refers to the color of the material used to make it; the 3 numbers refer to foreground:background:foreground brightness, and can be looked up [[Color|here]]. For example, 4:2:1 will give you bright red with a dark green background.

[BUILD_ITEM:1:BUCKET:NONE:NONE:NONE][EMPTY][CAN_USE_ARTIFACT]
[BUILD_ITEM:1:NONE:NONE:NONE:NONE][BUILDMAT][WORTHLESS_STONE_ONLY][CAN_USE_ARTIFACT]
These refer to items required to build the building. These are in the same format as [[Reaction|reaction reagents and products]]--quantity:[[Item token|item]]:[[Material token|material]]. You'll learn more about those on the article about [[Reaction|reactions]], though. The second BUILD_ITEM is special-- it uses modifiers exclusively to determine its requirements. BUILDMAT refers to wood logs, wood blocks, stone boulders, and stone blocks; WORTHLESS_STONE_ONLY means it can't use economic stone; CAN_USE_ARTIFACT means that it... can use artifacts. EMPTY, in the bucket's case, means that the bucket must be empty.

More can be seen at the [[Building token|building tokens]] article.

== Reactions ==

An in-depth guide for reactions is available [[Reactions|here]].

== Materials ==

As we've seen when talking about creatures, materials are vital. Materials show up in two forms: material templates, which generally show up in creatures, and specific materials (designated as "inorganic"), which are (by default, at least) consigned purely to metal and stone types.

Let's take a look at METAL_TEMPLATE in material_template_default.txt. It's evident that most of the basic properties of metals are already defined in the template - it goes red and melts at a high enough temperature, it's heavy, and (as noted by the very bottom token) is a metal. We already know just how useful templates can be to creatures, and the same applies to other materials.

Now let's take a look at inorganic_metal.txt. You can see that the metals here refer to the templates, and, just like we did with creatures, then modify the properties of that template and expand upon it.

Finally, let's look at inorganic_stone_mineral.txt. Here we can see that in addition to the changes made to the template, there are also ENVIRONMENT tokens - these tell the game where to place these minerals during worldgen.

[[material definition token|Here's a list of material tokens]]. It should also help you out with any modifications you want to make regarding those creature modifications we were making a while back. See, it all ties together in the end. The beauty of the current materials system is that there's actually very little difference between, say, leather and iron - they're fundamentally the same thing, just with different properties, which is how things really should be.

== Examples ==

The Hydling by Mysteryguye (annotated, updated and separated into blocks by Putnam)

[CREATURE:HYDLING]
[DESCRIPTION:A seven-headed small hairy thing, about the size of a dog. It is very loyal to its masters, and will promptly disembowel any enemy straying too close.]
This is the description that shows up in-game when viewing the creature.

[NAME:hydling:hydlings:hydlish] If there were a civ made of hydlings, it would appear as "hydlings" in the neighbors screen.

[CASTE_NAME:hydling:hydlings:hydlish]

[CREATURE_TILE:'='][COLOR:2:0:1] Will appear as a light green "=".

[PETVALUE:78][NATURAL] Creature is known to be naturally occurring by the game. Will cost 40 embark points to buy.

[LARGE_ROAMING] Will spawn outdoors, wandering around.

[COMMON_DOMESTIC][TRAINABLE][PET] Can be bought on embark as a pet, war animal, or hunting animal.

[BONECARN] Can eat meat and bones only--no vegetables.

[PREFSTRING:loyalty] Dwarves will like it for its loyalty.

[LIKES_FIGHTING] Will attack rather than flee.

[BODY:BASIC_2PARTBODY:7HEADNECKS:BASIC_FRONTLEGS:BASIC_REARLEGS:TAIL:2EYES:NOSE:2LUNGS:HEART:GUTS:ORGANS:THROAT:SPINE:BRAIN:SKULL:3TOES_FQ_REG:3TOES_RQ_REG:MOUTH:TONGUE:GENERIC_TEETH_WITH_FANGS:RIBCAGE]

Has a lower body, upper body, 4 legs, a tail, ten eyes, ten ears, five noses, two lungs, a heart, guts, a pancreas etc., and 5 heads with all that goes with those.

[BODYGLOSS:PAW] Feet will be called "paws"

[BODY_DETAIL_PLAN:STANDARD_MATERIALS] Declares the standard materials that most creatures' tissues are made of.

[BODY_DETAIL_PLAN:STANDARD_TISSUES] This declares the tissues that the creature's tissue layers are made of.

[BODY_DETAIL_PLAN:VERTEBRATE_TISSUE_LAYERS:SKIN:FAT:MUSCLE:BONE:CARTILAGE] And this describes the tissue layers that the creature is made of.

[BODY_DETAIL_PLAN:BODY_HAIR_TISSUE_LAYERS:HAIR] Creature will be covered with a layer of fur.

[USE_MATERIAL_TEMPLATE:NAIL:NAIL_TEMPLATE] And it'll have nails.

[USE_TISSUE_TEMPLATE:NAIL:NAIL_TEMPLATE]

[TISSUE_LAYER:BY_CATEGORY:TOE:NAIL:FRONT] On the toe, specifically.

[SELECT_TISSUE_LAYER:HEART:BY_CATEGORY:HEART]
[PLUS_TISSUE_LAYER:SKIN:BY_CATEGORY:THROAT]
[TL_MAJOR_ARTERIES] Heart and throat--called above--will cause heavy bleeding if ruptured.

[BODY_DETAIL_PLAN:STANDARD_HEAD_POSITIONS] Places eyes, ears and what have you into their correct placement, so that you don't have people punching out eyes from behind.

[BODY_DETAIL_PLAN:HUMANOID_RIBCAGE_POSITIONS] Sets the ribcage as being around lungs and heart.

[USE_MATERIAL_TEMPLATE:SINEW:SINEW_TEMPLATE] Defines sinew so that...
[TENDONS:LOCAL_CREATURE_MAT:SINEW:200] Tendons
[LIGAMENTS:LOCAL_CREATURE_MAT:SINEW:200] And ligaments can be defined.

[HAS_NERVES] Creature has nerves, and as such can be disabled by severing them.

[USE_MATERIAL_TEMPLATE:BLOOD:BLOOD_TEMPLATE] Defines the material BLOOD using the template BLOOD_TEMPLATE.
[BLOOD:LOCAL_CREATURE_MAT:BLOOD:LIQUID] Defines the creature's BLOOD as being made of the above-defined BLOOD material in a LIQUID state.

[CREATURE_CLASS:GENERAL_POISON] Creature can be affected by syndromes that affect GENERAL_POISON.

[GETS_WOUND_INFECTIONS] Pretty much self-explanatory. Creature can get infected from wounds.
[GETS_INFECTIONS_FROM_ROT] And from necrosis.

[USE_MATERIAL_TEMPLATE:PUS:PUS_TEMPLATE] Defines PUS using PUS_TEMPLATE.
[PUS:LOCAL_CREATURE_MAT:PUS:LIQUID] Defines PUS as being made of PUS.

[BODY_SIZE:0:0:1000] Creature will be 1000 cubic centimeters at birth...
[BODY_SIZE:1:0:12500] 12500 cubic centimeters at 1 year old...
[BODY_SIZE:2:0:30000] and 30000 cubic centimeters at 2.

[BODY_APPEARANCE_MODIFIER:LENGTH:90:95:98:100:102:105:110] Creature can be anywhere from 90% to 110% as long as others.
[BODY_APPEARANCE_MODIFIER:HEIGHT:90:95:98:100:102:105:110] As above, but with height.
[BODY_APPEARANCE_MODIFIER:BROADNESS:90:95:98:100:102:105:110] As above, but with broadness. This puts the minimum size of the creature (when fully grown) at 21870 and the maximum size at 39930.

[MAXAGE:20:30] Creature will die of old age between the ages of 20 and 30, no later than 30, no sooner than 20.

[CAN_DO_INTERACTION:MATERIAL_EMISSION] Creature can use the MATERIAL_EMISSION interaction.
[CDI:ADV_NAME:Hurl fireball] In adventurer mode, the MATERIAL_EMISSION interaction will appear as "Hurl fireball".
[CDI:USAGE_HINT:ATTACK] Creature will use MATERIAL_EMISSION when it's attacking, on creatures that it's attacking.
[CDI:BP_REQUIRED:BY_CATEGORY:HEAD] Creature must have at least one HEAD to use MATERIAL_EMISSION.
[CDI:FLOW:FIREBALL] The MATERIAL_EMISSION will shoot a fireball.
[CDI:TARGET:C:LINE_OF_SIGHT] The target for the emission--a location--must be within the line of sight of the Hydling.
[CDI:TARGET_RANGE:C:15] And must be, at most, 15 tiles away.
[CDI:MAX_TARGET_NUMBER:C:1] The hydling can only shoot at one target at a time...
[CDI:WAIT_PERIOD:30] and only every 30 ticks (3 tenths of a second at 100 FPS)

[ATTACK:BITE:CHILD_BODYPART_GROUP:BY_CATEGORY:HEAD:BY_CATEGORY:TOOTH] Defines a BITE attack that uses teeth.
[ATTACK_SKILL:BITE] Attack uses the BITE skill.
[ATTACK_VERB:nom:noms] "The Hydling noms the Elf in the left first toe, tearing the muscle!"
[ATTACK_CONTACT_PERC:100] Will use all of the tooth. Note that this can be more than 100.
[ATTACK_PENETRATION_PERC:100] Will sink the tooth all the way in. This can also be more than 100.
[ATTACK_FLAG_EDGE] Attack is an EDGE attack.
[ATTACK_PRIORITY:MAIN] Attack is of priority MAIN. Other option is SECOND.
[ATTACK_FLAG_CANLATCH] Attack can latch.
[ATTACK_PREPARE_AND_RECOVER:3:3] Takes 3 ticks to wind up attack and 3 to recover from it.
[ATTACK_FLAG_INDEPENDENT_MULTIATTACK] Can use each head independently.

[ATTACK:SCRATCH:CHILD_TISSUE_LAYER_GROUP:BY_TYPE:STANCE:BY_CATEGORY:ALL:NAIL] As above, but for nail instead of teeth.
[ATTACK_SKILL:STANCE_STRIKE] Uses the kicking skill.
[ATTACK_VERB:slice:slices] "You slice the Elf in the left foot and the severed part sails off in an arc!"
[ATTACK_CONTACT_PERC:100] Uses the whole nail.
[ATTACK_PENETRATION_PERC:100] The whole nail goes in.
[ATTACK_FLAG_EDGE] Attack is an edge attack.
[ATTACK_PREPARE_AND_RECOVER:3:3]
[ATTACK_PRIORITY:SECOND]

[CHILD:1] Hydling will become an adult at 1 year old.

[GENERAL_CHILD_NAME:hydie:hydies] Children will appear as "hydies".

[DIURNAL] Is active during the daytime.

[HOMEOTHERM:10070] Has a body temperature of 102 Fahrenheit.

[APPLY_CREATURE_VARIATION:STANDARD_QUADRUPED_GAITS:900:730:561:351:1900:2900] Can run at 25 kph
[APPLY_CREATURE_VARIATION:STANDARD_SWIMMING_GAITS:3512:2634:1756:878:4900:6900] Can swim at 10 kph
[APPLY_CREATURE_VARIATION:STANDARD_CRAWLING_GAITS:6561:6115:5683:1755:7456:8567] Can crawl at 5 kph
[SWIMS_INNATE]Swims innately.

[CASTE:FEMALE] Defines a caste called FEMALE.
[FEMALE] FEMALE caste is female.

[CASTE:MALE] As above, but with male.
[MALE] See above.

= Modding utilities =

[http://www.bay12forums.com/smf/index.php?topic=28829.0 A list of many mods and community-developed utilities]

{{Category|Modding}}
[[Category:v0.31:Guides]]

Modding

2016-03-01T11:08:46Z

Chinchou: The word "plans" is a plural form, so we use "are", not "is".

{{Quality|Exceptional|14:13, 7 November 2013 (UTC)}}
{{av}}
This is intended to be a guide to inform those new to DF modding on what elements of the game can be modified, and how. After reading through this guide, a user should be capable of editing creatures, entities, materials ''et al'', and creating their own.

Generally, breaking stuff is fine - nothing that can be changed will affect the DF executable, and new additions can be easily removed.

This guide is based on [[40d:Modding guide|Teldin's guide]], originally created for version 0.27.176.39c. Per wiki tradition, it has been updated through all the major releases since then; hopefully it reflects current knowledge.

'''See also:''' [[:Category:DF2014:Modding]]

= Modding Guide =

== Token Reference ==

It's always good to refer to tokens on the wiki. Even experienced modders have to look up tokens! A list of articles about tokens can be found [http://dwarffortresswiki.org/index.php/Token here.]

== Basics of DF modding ==

All the base data that can be edited by prospective modders can be found in the \raw\ folder. This folder contains two subfolders: "graphics" (where you insert [[Graphics set repository|graphics sets]]), and "objects", which contains all the data for generally everything in the game that is not hardcoded.

Within the \raw\objects folder are a large number of text files - these are the [[raw file|raw files]], and editing them is quite easy - you can also create your own if you wish. For now, take a look at one of the existing files. For example if you open creature_standard.txt it should look something like this:

creature_standard

[OBJECT:CREATURE]

[CREATURE:DWARF]
[DESCRIPTION:A short, sturdy creature fond of drink and industry.]
[NAME:dwarf:dwarves:dwarven]
[CASTE_NAME:dwarf:dwarves:dwarven]
[CREATURE_TILE:1][COLOR:3:0:0]
[CREATURE_SOLDIER_TILE:2]
...

As you can see, each file comprises a header string stating the file name, a second header stating the type of object data it contains, followed by the contents of the file itself. These are all necessary elements of the file, and without them, the file won't be parsed correctly by the game. You may have also noticed the file naming scheme - this is also important; files containing creatures have names starting with "creature_", entity file names must begin with "entity_", etc..

Below the headers, there begins a list of entries. Each entry is made up of its own header (in this case, "[CREATURE:DWARF]"), again stating the type of object, and then the object's unique identifier - if an identifier isn't unique, the game will mess up and you'll get some serious, and potentially very trippy, errors. Below that, we have the body of the entry, which determines the entry's specific properties.

The body of an entry is made up of a series of "tokens", which are essentially flags that can be added or removed to affect the entry's attributes. Most of these effects are hardcoded: for example, it's possible to make a creature only eat meat with the [CARNIVOROUS] token, but it's impossible to create your own token detailing a specific diet for the creature.

Before we continue, a few key things to remember when modding the raw files:

* Try to avoid modifying the existing raw files when adding objects. It makes removing mods far easier.
* When adding files, all you need to include to ensure proper references are maintained is the token identifier's. The game will load up all *.txt in the raw folder, and searches through them by tokens. For example: You can add a new pair of leather boots and not even have to add it to the item_shoes.txt file, but rather make your own file, say item_shoes_new.txt and ensure you have the token listed, ex. [ITEM_SHOES:ITEM_SHOES_BOOTS_NEW], that's how the game will look for the item.
* If you want to edit an already-existing creature, always back up the files you plan on editing to a different location. Since v0.31.22, the game no longer loads backup files, but duplicate entries are still a very bad thing.
* When a new world is generated, all the raw files get copied into a \raw\ folder within the applicable save folder. If you want to change something within a world that's already been generated, you'll have to edit those files, not the ones in ~DF\raw\objects.
* There's nothing stopping you from just copying an existing creature/entity/whatever, changing the identifier, and modifying it. This can save you a lot of time, especially when it comes to entities... which are coincidentally what we'll be talking about next.

== Modding civilizations (entities) ==

Entities - the objects that determine how civilizations work - are stored in entity_default.txt (though, like all other files, you may add more). They follow the same format as any other raw file:

entity_default

[OBJECT:ENTITY]

[ENTITY:ENTITYNAME]
[CREATURE:CREATURETYPE]
[TRANSLATION:LANGUAGETYPE]
[BIOME_SUPPORT:BIOMETOKEN:FREQENCY]
...[OTHER TAGS]...

Most of the time, it doesn't matter which order these tokens are in or where they're placed so long as they're below the "ENTITY:" identifier, but there are some important exceptions in the case of other files, especially creatures, which can contain a lot of "nested" tokens.

"[CREATURE:]" links the civilization with a specific creature defined in a creature file. This is the creature that'll be making up the entity's population, and will therefore be the creature you'll be playing as in fortress or adventure mode if the entity is a playable one. For example, if you wanted to do something silly, you could switch the "CREATURE:DWARF" entry in entity_default.txt with "CREATURE:ELF" and you would be marching elves around in fortress mode, although they would still use dwarven technology and language and names and so forth.

Oh, and before you get any funny ideas - it ''is'' possible to define more than one creature for a civ, but that won't work in quite the way you probably expect; later on, in the creature section, you'll learn about castes, which will provide a much more viable alternative, so try to bear with us until then.

"[TRANSLATION:]" defines the language file that the entity will be using, which will determine what their untranslated words are for things. This doesn't determine which words they use for naming things, only the way those words are spelled. The default language files are HUMAN, DWARF, ELF, and GOBLIN.

"[BIOME_SUPPORT:]" defines the biomes that civs will attempt to settle in. The "FREQUENCY" value determines the likelihood of them building there, but also raises an important point: Most of the values you'll be setting for things are relative to each other. If one were to type:

[BIOME_SUPPORT:ANY_FOREST:1]
[BIOME_SUPPORT:SAVANNA:2]

This would have very much the same effect as:

[BIOME_SUPPORT:ANY_FOREST:5]
[BIOME_SUPPORT:SAVANNA:10]

This holds true for a lot of values throughout the files, excluding when it simply doesn't make sense, such as in materials.

You can find many details about the rest of the civilization tokens [[entity token|here]]. Besides those mentioned, some fundamental ones are the CIV_CONTROLLABLE token, which lets you control the civ in fortress mode, the INDIV_CONTROLLABLE token, which allows you to play the civ in adventure mode as an outsider, and the ADVENTURE_TIER token, which allows you to play a civ native (non-outsider) in adventure mode. Other tokens that you should pay attention to are START_BIOME and the ones regarding sites, but in general, you can just run through the aforementioned list and add or remove what you want.

If you have more than one civ with the CIV_CONTROLLABLE token, all the available civs from those entities will appear in the group selection section on the embark screen. It may not be immediately obvious from which species each civ may be - while this can be determined from legends mode, the topmost species in the "neighbors" display in the embark screen is always the same as the currently selected species; if your group is dwarven, dwarves will be topmost, whilst (say) elves will be topmost if your chosen group is elven. By default, the game seems to choose a civ (and therefore a species if there is more than one) at random.

You can also attempt to discern the civ yourself by the names it uses - this is the realm of "symbols", collections of words centered around a specific concept. The civ will use the words comprising whatever symbols are applicable to it for various things. This association might be a little obfuscating at first, so I'll run through it. Let's refer to the DWARF entity:

[SELECT_SYMBOL:WAR:NAME_WAR]
[SUBSELECT_SYMBOL:WAR:VIOLENT]
[SELECT_SYMBOL:BATTLE:NAME_BATTLE]
[SUBSELECT_SYMBOL:BATTLE:VIOLENT]
[SELECT_SYMBOL:SIEGE:NAME_SIEGE]
[SUBSELECT_SYMBOL:SIEGE:VIOLENT]

Here we can see that dwarves will generally name their wars first after words in the "NAME_WAR" symbol group, and then after words in the "VIOLENT" symbol group. This might, for example, result in a war being named "The War of Carnage". The symbols used for the other types of conflict are arrayed in a similar fashion. It would be trivial to replace the instances of VIOLENT with, say, PEACE and end up with a battle called "The Clash of Calm" or something.

[SELECT_SYMBOL:ROAD:NAME_ROAD]
[SELECT_SYMBOL:TUNNEL:NAME_TUNNEL]
[SELECT_SYMBOL:BRIDGE:NAME_BRIDGE]
[SELECT_SYMBOL:WALL:NAME_WALL]

The above applies here. Dwarves are fond of naming their roads and tunnels after roads and tunnels.

[SELECT_SYMBOL:REMAINING:ARTIFICE]
[SELECT_SYMBOL:REMAINING:EARTH]
[CULL_SYMBOL:ALL:DOMESTIC]
[CULL_SYMBOL:ALL:SUBORDINATE]
[CULL_SYMBOL:ALL:EVIL]
[CULL_SYMBOL:ALL:UNTOWARD]
[CULL_SYMBOL:ALL:FLOWERY]
[CULL_SYMBOL:ALL:NEGATIVE]
[CULL_SYMBOL:ALL:UGLY]
[CULL_SYMBOL:ALL:NEGATOR]

This section deals with everything else. The things that haven't already been dealt with (hence the "REMAINING") - such as site names, kingdom names, the names of individuals, and such - will have names from the ARTIFICE and EARTH symbol groups. After that the dwarf entity is told to cull all innapropriate symbols - this applies to everything (hence the "ALL") so if the game happens to choose a symbol associated with, say, EVIL for one of the battles, it'll scrap that name and try again. This sort of thing adds a lot of flavour to DF's entities and can account for a lot of a civ's perceived personality.

Another basic thing to note: Any entity token that's dealing with weapons, armor, clothing, etc., will state the items that the civ can build natively, not necessarily the ones they can wear or use. For example, you could create a species with no clothes specified, but then rob a clothes shop in adventurer mode and wear everything you want, or give them weapons that are too large to wield and they could sell them, but not use them.

An easy method of creating a civilization is just to copy-paste a similar one to the bottom of the entity_default.txt file and edit things to your liking. Remember to always change the civ's "ENTITY:" identifier! This can be anything so long as it's not already existing.

At the end of some of the default entries you'll find a list of positions, both ones that'll directly affect you in fort mode (such as nobles) and ones that'll primarily affect worldgen and adventure mode. A list of the tokens applicable to positions can be found [[position token|here]]; they don't require a great deal of explanation.

== Modding the creatures ==

Creature modding is great fun. You can change nearly any aspect of a creature or make your own completely from scratch.

Modding creatures is very similar to modding civs: it's just a matter of editing, adding, or removing tokens, enclosed in square brackets underneath the creature's [CREATURE:] header. The creature entries contain all of the information about each and every non-random creature in the game, from animals to dwarves to goblins to even caravan wagons. A lot of the creature tokens are fairly self-explanatory; you can find a list of such tokens [[creature token|here]]. But before you start creating your own creatures, you'll want to learn how the tissues system works.

=== Creature materials and tissues ===

In the most basic sense, a creature is a series of bodyparts. These parts are defined in their own file, and we'll talk about them later. As a specific aspect of how creatures work which throws off a lot of prospective modders is the relationship between bodyparts, tissues, and materials. We're going to show you part of the creature entry for a bronze colossus (bear with us):

...
[BODY:HUMANOID:2EYES:2EARS:NOSE:HUMANOID_JOINTS:5FINGERS:5TOES]
[NO_THOUGHT_CENTER_FOR_MOVEMENT]
[TISSUE:BRONZE]
[TISSUE_NAME:bronze:bronze]
[TISSUE_MATERIAL:INORGANIC:BRONZE]
[MUSCULAR]
[FUNCTIONAL]
[STRUCTURAL]
[RELATIVE_THICKNESS:1]
[CONNECTS]
[TISSUE_SHAPE:LAYER]
[TISSUE_LAYER:BY_CATEGORY:ALL:BRONZE]
...

At the top, we can see the "BODY:" token, followed by a list of bodyparts. As you've probably guessed, these parts make up the physical form of the colossus. But the colossus has to be made out of something - it has to have tissues. And those tissues also have to be made out of something - in this case, bronze.

Below the BODY token you'll see a TISSUE token, followed by an identifier, much like the others we've seen. The TISSUE block is determining how the tissue works, and which purposes it'll serve. As the colossus is just going to be made out of this one tissue, this tissue needs to act like bone, muscle, and everything else combined, hence the MUSCULAR, FUNCTIONAL and STRUCTURAL tokens. The tissue also references a material - INORGANIC:BRONZE - the properties of which are declared in the inorganic materials file, and the tissue is subsequently made out of this material. With us so far?

Below the tissue definition is the TISSUE_LAYER line. TISSUE_LAYER allows you to control where each tissue is applied. Its first argument defines if it's to search by bodypart category (BY_CATEGORY), bodypart type (BY_TYPE), or look for a specific part (BY_TOKEN). That's followed by the parts argument itself, which is in this case ALL (so the game's looking for parts in all categories, which is to say, every bodypart). This is followed by the tissue to be applied, BRONZE. So the TISSUE_LAYER token is telling the game to select all bodyparts in every category and make them out of the tissue "BRONZE". The colossus is now made of bronze.

By now you're probably thinking "Wow, if this was for a creature made out of however many tissues, this would be amazingly longwinded". And you're right. Luckily, there are two methods by which we can speed things up a lot.

Firstly, there are material and tissue templates. Let's say you were going to make a lot of creatures out of bronze, and you didn't want to have to copy and paste the bronze tissue all over the place. Instead, you create a tissue template. This goes, as you've probably guessed, in a tissue template file.

[TISSUE_TEMPLATE:BRONZE_TEMPLATE]
[TISSUE_NAME:bronze:bronze]
[TISSUE_MATERIAL:INORGANIC:BRONZE]
[MUSCULAR]
[FUNCTIONAL]
[STRUCTURAL]
[RELATIVE_THICKNESS:1]
[CONNECTS]
[TISSUE_SHAPE:LAYER]

Now, instead of applying the tissue to each and every bronze creature you're making, you can just refer to the template:

...
[BODY:HUMANOID:2EYES:2EARS:NOSE:HUMANOID_JOINTS:5FINGERS:5TOES]
[NO_THOUGHT_CENTER_FOR_MOVEMENT]
[USE_TISSUE_TEMPLATE:BRONZE:BRONZE_TEMPLATE]
[TISSUE_LAYER:BY_CATEGORY:ALL:BRONZE]
...

Material templates work in the same way, but refer to materials instead of tissues.

However, if we're looking at something like a dwarf, even with the templates, editing can get very slow indeed:

...
[USE_MATERIAL_TEMPLATE:SKIN:SKIN_TEMPLATE]
[USE_MATERIAL_TEMPLATE:FAT:FAT_TEMPLATE]
[USE_MATERIAL_TEMPLATE:MUSCLE:MUSCLE_TEMPLATE]
[USE_MATERIAL_TEMPLATE:BONE:BONE_TEMPLATE]
[USE_MATERIAL_TEMPLATE:CARTILAGE:CARTILAGE_TEMPLATE]
[USE_MATERIAL_TEMPLATE:HAIR:HAIR_TEMPLATE]
[USE_MATERIAL_TEMPLATE:TOOTH:TOOTH_TEMPLATE]
[USE_MATERIAL_TEMPLATE:EYE:EYE_TEMPLATE]
[USE_MATERIAL_TEMPLATE:NERVE:NERVE_TEMPLATE]
[USE_MATERIAL_TEMPLATE:BRAIN:BRAIN_TEMPLATE]
[USE_MATERIAL_TEMPLATE:LUNG:LUNG_TEMPLATE]
[USE_MATERIAL_TEMPLATE:HEART:HEART_TEMPLATE]
[USE_MATERIAL_TEMPLATE:LIVER:LIVER_TEMPLATE]
[USE_MATERIAL_TEMPLATE:GUT:GUT_TEMPLATE]
[USE_MATERIAL_TEMPLATE:STOMACH:STOMACH_TEMPLATE]
[USE_MATERIAL_TEMPLATE:PANCREAS:PANCREAS_TEMPLATE]
[USE_MATERIAL_TEMPLATE:SPLEEN:SPLEEN_TEMPLATE]
[USE_MATERIAL_TEMPLATE:KIDNEY:KIDNEY_TEMPLATE]
[USE_TISSUE_TEMPLATE:SKIN:SKIN_TEMPLATE]
[USE_TISSUE_TEMPLATE:FAT:FAT_TEMPLATE]
[USE_TISSUE_TEMPLATE:MUSCLE:MUSCLE_TEMPLATE]
...

This is where body detail plans come in. Detail plans, of course, have their own file, and they are designed to help automate some of the more common processes in creature creation. The first entry in b_detail_plan_default.txt does exactly what we've been trying to do above: it takes all the common materials and shoves them into one plan, which can be referenced with a single token.

...
[BODY_DETAIL_PLAN:STANDARD_MATERIALS]
...

Much easier. But what about the TISSUE_LAYER tokens? Will we have to type out all of those manually?

Nope, detail plans have that covered as well. It's possible to place variable arguments into a detail plan. For example:

[BODY_DETAIL_PLAN:VERTEBRATE_TISSUE_LAYERS]
[BP_LAYERS:BY_CATEGORY:BODY:ARG3:50:ARG2:5:ARG1:1]
[BP_LAYERS:BY_CATEGORY:BODY_UPPER:ARG3:50:ARG2:5:ARG1:1]
[BP_LAYERS:BY_CATEGORY:BODY_LOWER:ARG3:50:ARG2:5:ARG1:1]
[BP_LAYERS:BY_CATEGORY:ARM:ARG4:25:ARG3:25:ARG2:5:ARG1:1]
[BP_LAYERS:BY_CATEGORY:ARM_UPPER:ARG4:25:ARG3:25:ARG2:5:ARG1:1]
...
[BP_LAYERS:BY_CATEGORY:NOSE:ARG5:4:ARG1:1]
...

First an argument is placed in the plan (ARG1, ARG2 etc.), followed by the thickness of the tissue that will be inserted in place of the argument. So when we reference the VERTEBRATE_TISSUE_LAYERS plan, we'll be able to do something like this:

[BODY_DETAIL_PLAN:VERTEBRATE_TISSUE_LAYERS:SKIN:FAT:MUSCLE:BONE:CARTILAGE]

ARG1 in the detail plan is replaced by SKIN, the first tissue we entered. ARG2 is replaced by FAT, ARG3 by muscle, ARG4 by bone, and ARG5 by CARTILAGE. Hence, our creature's bodypart designated as BODY is made up of SKIN with thickness 1, FAT with thickness 5, and MUSCLE with thickness 50. Its nose is made up of SKIN (thickness 1) and CARTILAGE (thickness 4).

Things left out of the body plans aside, our dwarf's entire body, material, tissue and tissue layer tokens have been boiled down to this:

...
[BODY:HUMANOID:2EYES:2EARS:NOSE:2LUNGS:HEART:GUTS:ORGANS:HUMANOID_JOINTS:
THROAT:NECK:SPINE:BRAIN:SKULL:5FINGERS:5TOES:MOUTH:FACIAL_FEATURES:TEETH:RIBCAGE]
[BODY_DETAIL_PLAN:STANDARD_MATERIALS]
[BODY_DETAIL_PLAN:STANDARD_TISSUES]
[BODY_DETAIL_PLAN:VERTEBRATE_TISSUE_LAYERS:SKIN:FAT:MUSCLE:BONE:CARTILAGE]
...

This can save you a lot of time and space if you're making lots of changes common to many creatures. In general, if you're making a creature that's fleshy or chitinous, there're detail plans already included in the game to help you out. You should only have to resort to declaring tissues individually (like our bronze colossus) if you're doing something really out-of-the-ordinary.

Another great thing about templates (and so, detail plans) is that they can be modified after being declared. Let's say we wanted our dwarves to be perpetually on fire (don't ask). We declare the body stuff normally:

...
[BODY:HUMANOID:2EYES:2EARS:NOSE:2LUNGS:HEART:GUTS:ORGANS:HUMANOID_JOINTS:
THROAT:NECK:SPINE:BRAIN:SKULL:5FINGERS:5TOES:MOUTH:FACIAL_FEATURES:TEETH:RIBCAGE]
[BODY_DETAIL_PLAN:STANDARD_MATERIALS]
[BODY_DETAIL_PLAN:STANDARD_TISSUES]
[BODY_DETAIL_PLAN:VERTEBRATE_TISSUE_LAYERS:SKIN:FAT:MUSCLE:BONE:CARTILAGE]
...

We then select the appropriate material:

...
[BODY:HUMANOID:2EYES:2EARS:NOSE:2LUNGS:HEART:GUTS:ORGANS:HUMANOID_JOINTS:
THROAT:NECK:SPINE:BRAIN:SKULL:5FINGERS:5TOES:MOUTH:FACIAL_FEATURES:TEETH:RIBCAGE]
[BODY_DETAIL_PLAN:STANDARD_MATERIALS]
[BODY_DETAIL_PLAN:STANDARD_TISSUES]
[BODY_DETAIL_PLAN:VERTEBRATE_TISSUE_LAYERS:SKIN:FAT:MUSCLE:BONE:CARTILAGE]
[SELECT_MATERIAL:SKIN]
[MAT_FIXED_TEMP:10600]
...

We don't want them burning to death, so we'll need to stop that from happening:

...
[BODY:HUMANOID:2EYES:2EARS:NOSE:2LUNGS:HEART:GUTS:ORGANS:HUMANOID_JOINTS:
THROAT:NECK:SPINE:BRAIN:SKULL:5FINGERS:5TOES:MOUTH:FACIAL_FEATURES:TEETH:RIBCAGE]
[BODY_DETAIL_PLAN:STANDARD_MATERIALS]
[BODY_DETAIL_PLAN:STANDARD_TISSUES]
[BODY_DETAIL_PLAN:VERTEBRATE_TISSUE_LAYERS:SKIN:FAT:MUSCLE:BONE:CARTILAGE]
[SELECT_MATERIAL:SKIN]
[MAT_FIXED_TEMP:10600]
[SELECT_MATERIAL:ALL]
[HEATDAM_POINT:NONE]
...

Note that this makes use of DF's built-in temperature scale. You can read more about that [[Temperature|on this page]]. We're also referencing material tokens, which we haven't gone over yet - we'll talk about making your own materials later.

=== Creature castes ===

Another potentially extremely powerful part of the creature raws is the caste system. The caste system handles both true biological castes and lesser variations, such as sexes.

To understand the true potential of the caste system, we only need to take a look at the raws for antmen, found in creature_subterrenean.txt:

...
[CASTE:WORKER]
[CASTE_NAME:worker ant woman:worker ant women:worker ant woman]
Female, but non-breeding.
[POP_RATIO:10000]
[CASTE:SOLDIER]
[CASTE_NAME:soldier ant woman:soldier ant women:soldier ant woman]
Female, but non-breeding.
[POP_RATIO:1000]
[CASTE:DRONE]
[MALE]
[CASTE_NAME:drone ant man:drone ant men:drone ant man]
[POP_RATIO:5]
[CASTE:QUEEN]
[FEMALE]
[CASTE_NAME:queen ant woman:queen ant women:queen ant woman]
[POP_RATIO:1]
[SELECT_CASTE:WORKER]
[SELECT_ADDITIONAL_CASTE:SOLDIER]
[SELECT_ADDITIONAL_CASTE:QUEEN]
[BODY:HUMANOID_4ARMS:2EYES:HEART:GUTS:BRAIN:MOUTH]
[BODYGLOSS:INSECT_UPPERBODY:INSECT_LOWERBODY]
[SELECT_CASTE:DRONE]
[BODY:HUMANOID_4ARMS:2EYES:HEART:GUTS:BRAIN:MOUTH:2WINGS]
[BODYGLOSS:INSECT_UPPERBODY:INSECT_LOWERBODY]
[FLIER]
[SELECT_CASTE:ALL]
[BODY_DETAIL_PLAN:CHITIN_MATERIALS]
[BODY_DETAIL_PLAN:CHITIN_TISSUES]
[BODY_DETAIL_PLAN:EXOSKELETON_TISSUE_LAYERS:CHITIN:FAT:MUSCLE]
[BODY_DETAIL_PLAN:STANDARD_HEAD_POSITIONS]
[ATTACK:PUNCH:BODYPART:BY_TYPE:GRASP]
[ATTACK_SKILL:GRASP_STRIKE]
[ATTACK_VERB:punch:punches]
...

It's evident that the process of creating and editing castes is comparable to the modifications we were making to tissues and materials earlier: A caste is declared, and modifications to the base creature are made. Declared castes can be selected and subsequently modified, again, just like tissues and materials.

In this case, each caste is declared, given its own name, and a POP_RATIO, which determines how commonly a birth results in that caste - for every 10000 workers born, there'll be an average of 1000 soldiers, 5 drones and one queen. You've probably also noticed that the DRONE and QUEEN castes have the MALE and FEMALE tokens respectively - these tokens determine how breeding works. A creature without both a MALE caste and a FEMALE caste will be unable to breed (no asexual creatures yet, unfortunately). As they lack FEMALE, the workers and soldiers are unable to breed with the male drones.

After this, there are some modifications to bodyparts. In this case, the drones have wings and the FLIER token, which the other castes lack. It's entirely possible for creatures of different castes to have completely different body stuctures, even to the extent that they don't resemble each other at all. If you read the section of this guide that dealt with entities, you may remember a passing mention of multi-creature civilisations and how they don't quite work as you may think they would. The castes system is your workaround. You could create a caste that is, for all intents and purposes, a human, and another caste of the same creature that acts exactly like a giant cave spider, put the creature in a civ, and get a human-spider civ. The only flaw in this approach is that the castes will interbreed.

That's the most complex components of creature creation out of the way. You should find the rest trivial by comparison.

== Modding items ==

Items are fairly simple to deal with. By default, each item type is contained in its own file; this may help make browsing for a specific item easier, but from a purely technical point of view, it's possible to throw all items into one file. Unfortunately, item tokens don't seem to be especially well-documented (at least not as well as the other object types), but you should be able to figure out most things by way of our explanations and your assumptions.

Let's look at the entry for, of course, the thong:

[ITEM_PANTS:ITEM_PANTS_THONG]
[NAME:thong:thongs]
[LAYER:UNDER]
[COVERAGE:25]
[LAYER_SIZE:10]
[LAYER_PERMIT:30]
[MATERIAL_SIZE:1]
[SOFT]
[LEATHER]
[STRUCTURAL_ELASTICITY_WOVEN_THREAD]

Most of these are pretty obvious if one compares them to the other entries in the file. There's a layer for the item, determining where it's worn; a coverage value to determine how well it protects you from cold and other things; a size token to determine how much it counts for when it's under something else; a layer permit token to determine how much can be worn under it; and a material size token to determine how much raw material it takes to make it.

Now, if you wanted to mod these to turn them into metal thongs (ouch!), you would simply have to add [METAL] to it somewhere. Simple! These tokens work by tying into material properties - some materials are designated as suitable for making hard items, some for soft, etc..

Weapons involve a little more detail:

[ITEM_WEAPON:ITEM_WEAPON_SWORD_2H]
[NAME:two-handed sword:two-handed swords]
[SIZE:900]
[SKILL:SWORD]
[TWO_HANDED:67500]
[MINIMUM_SIZE:62500]
[MATERIAL_SIZE:5]
[ATTACK:EDGE:100000:8000:slash:slashes:NO_SUB:1250]
[ATTACK:EDGE:50:4000:stab:stabs:NO_SUB:1000]
[ATTACK:BLUNT:100000:8000:slap:slaps:flat:1250]
[ATTACK:BLUNT:100:1000:strike:strikes:pommel:1000]

SIZE determines how heavy the weapon is. This has a substantial effect on weapon effectiveness. SKILL determines which skill is used in using the weapon; a list of skills can be found [[skill token|on this page]]. MINIMUM_SIZE determines the minimum size a creature must be before the weapon can be wielded, while TWO_HANDED determines how large a creature must be in order to wield the weapon with one hand.

Attacks take a little more explanation. The first value determines the contact area of the weapon's attack; this should be high for slashing weapons and low for bludgeoning, piercing and poking ones. The second value determines how deep the weapon penetrates - for BLUNT attacks this value is ignored as they're not supposed to penetrate anyway, but in the case of EDGE attacks it should generally be lower for slashing attacks and higher for stabbing attacks.

Following these are the nouns and verb used; they should be self-explanatory. Finally, we have the velocity modifier, which has a multiplying effect on the weapon's size for the purposes of determining how powerful it is in combat.

Other, more miscellaneous items are generally simple and shouldn't require any further explanation.

Once you've made an item, you just add it to the civ entry so a civilization can actually craft it, and it's done.

== Modding language files ==

Let's say you added a whole new species. Sure, you could just swipe one of the existing translation files and steal their language for your species, but that's the lazy way! If you want to create a whole new language, it's very simple.

First, you'd need a whole new language_RACE file, such as language_LIZARDMAN.txt, along with "language_LIZARDMAN" at the top of the file proceeded by [OBJECT:LANGUAGE] and [TRANSLATION:LIZARDMAN]. After that, it's just a matter of copy-pasting one of the existing language lists and editing the finished 'translated' word. That's it! Then just add the translation link to your civ in entity_default.txt and it'll be added to the game on worldgen.

(Note that the name of the file doesn't actually matter; however, it's good form to name the file after a creature if only that creature speaks the language)

== Modding body parts ==

Imagine you have this fantastic idea for a multi-tentacled winged spider-monster. Sounds great! But in order to make this a reality you may need to create a new set of body parts for it. That's no problem! Making body parts is easy, though it may look complicated at first.

All of the default body definitions are located in body_default.txt and then linked to a creature in the creature's entry. We've talked about how bodyparts make up creatures earlier, in the creature section. You can mix and match them in the creature entry and it makes no difference, as long as they're there: each bodypart will link itself to the appropriate connection automatically when the creature is first created.

Body parts work by sections: you can add as many sections as you want to a bodypart definition, but generally you should keep it fairly low for ease of use. Each body section entry is in the, very simple, format:

[BODY:BODYNAME]
[BP:TOKENID:name][TOKENSGOHERE][DEFAULT_RELSIZE:][CATEGORY:WHATEVER]

The most important tokens are "CONTYPE" and "CON": CONTYPE means the bodypart in question is connected to a certain ''type'' of bodypart, while CON means it's connected to a ''specific'' one. TOKENID is yet another identifier, which should be unique, as it's referenced every time something uses CON or BY_TOKEN. DEFAULT_RELSIZE defines, of course, what the bodypart's size is in relation to the other parts. CATEGORY defines a category for the part, which can be unique or shared with other parts. This is referenced whenever BY_CATEGORY is used.

A list of bodypart tokens can be found [[body token|here]].

Let's take a simple example, a head:

[BODY:BASIC_HEAD]
[BP:HD:head:STP][CONTYPE:UPPERBODY][HEAD][CATEGORY:HEAD]
[DEFAULT_RELSIZE:300]

It connects directly to an upper body.

[BODY:2EYES]
[BP:REYE:right eye:STP][CONTYPE:HEAD][SIGHT][EMBEDDED][SMALL][RIGHT][CATEGORY:EYE]
[DEFAULT_RELSIZE:5]
[BP:LEYE:left eye:STP][CONTYPE:HEAD][SIGHT][EMBEDDED][SMALL][LEFT][CATEGORY:EYE]
[DEFAULT_RELSIZE:5]

These are a pair of eyes, connecting to the head.

[BODY:HUMANOID]
[BP:UB:upper body:upper bodies][UPPERBODY][CATEGORY:BODY_UPPER]
[DEFAULT_RELSIZE:1000]
[BP:LB:lower body:lower bodies][CON:UB][LOWERBODY][CATEGORY:BODY_LOWER]
[DEFAULT_RELSIZE:1000]
[BP:HD:head:STP][CON:UB][HEAD][CATEGORY:HEAD]
[DEFAULT_RELSIZE:300]
[BP:RUA:right upper arm:STP][CON:UB][LIMB][RIGHT][CATEGORY:ARM_UPPER]
[DEFAULT_RELSIZE:200]
[BP:LUA:left upper arm:STP][CON:UB][LIMB][LEFT][CATEGORY:ARM_UPPER]
[DEFAULT_RELSIZE:200]
[BP:RLA:right lower arm:STP][CON:RUA][LIMB][RIGHT][CATEGORY:ARM_LOWER]
[DEFAULT_RELSIZE:200]
[BP:LLA:left lower arm:STP][CON:LUA][LIMB][LEFT][CATEGORY:ARM_LOWER]
[DEFAULT_RELSIZE:200]
[BP:RH:right hand:STP][CON:RLA][GRASP][RIGHT][CATEGORY:HAND]
[DEFAULT_RELSIZE:80]
[BP:LH:left hand:STP][CON:LLA][GRASP][LEFT][CATEGORY:HAND]
[DEFAULT_RELSIZE:80]
[BP:RUL:right upper leg:STP][CON:LB][LIMB][RIGHT][CATEGORY:LEG_UPPER]
[DEFAULT_RELSIZE:500]
[BP:LUL:left upper leg:STP][CON:LB][LIMB][LEFT][CATEGORY:LEG_UPPER]
[DEFAULT_RELSIZE:500]
[BP:RLL:right lower leg:STP][CON:RUL][LIMB][RIGHT][CATEGORY:LEG_LOWER]
[DEFAULT_RELSIZE:400]
[BP:LLL:left lower leg:STP][CON:LUL][LIMB][LEFT][CATEGORY:LEG_LOWER]
[DEFAULT_RELSIZE:400]
[BP:RF:right foot:right feet][CON:RLL][STANCE][RIGHT][CATEGORY:FOOT]
[DEFAULT_RELSIZE:120]
[BP:LF:left foot:left feet][CON:LLL][STANCE][LEFT][CATEGORY:FOOT]
[DEFAULT_RELSIZE:120]

An entire humanoid body. The foot bone's connected to the ankle bone...

"BODYGLOSS" entries, which you can sometimes find applied to creature entries, are simply replacement words for specific part name strings in a creature. For example, you'll find the bodygloss [BODYGLOSS:CLAW_HAND:hand:claw] in body_default.txt; you can then use this in a creature via "[BODYGLOSS:CLAW_HAND]" and it'll replace all instances of "hand" with "claw" in that creature. Be warned, however—if you were to, say make a bodygloss [BODYGLOSS:EARSTALK:ear:stalk:ears:stalk], it would not only change "ear" and "ears" to "stalk" and "stalks", it would also change "h'''ear'''t" to "h'''stalk'''t"! For all intents and purposes the body part will still function as the proper part, though.

== Modding plants ==

Plants are, again, not unlike creatures. With what you've learned so far in regard to tokens and the materials system, running through the notes included in plant_standard.txt should explain most things. [[Plant token|Here's the list of plant-specific tokens]].

Below is the [[plump helmet]] raw description:

[PLANT:MUSHROOM_HELMET_PLUMP]
[NAME:plump helmet][NAME_PLURAL:plump helmets][ADJ:plump helmet]
[USE_MATERIAL_TEMPLATE:STRUCTURAL:STRUCTURAL_PLANT_TEMPLATE]
[MATERIAL_VALUE:2]
[BASIC_MAT:LOCAL_PLANT_MAT:STRUCTURAL]
[EDIBLE_VERMIN]
[EDIBLE_RAW]
[EDIBLE_COOKED]
[PICKED_TILE:161][PICKED_COLOR:6:13:0]
[GROWDUR:300][VALUE:2]
[USE_MATERIAL_TEMPLATE:DRINK:PLANT_ALCOHOL_TEMPLATE]
[STATE_NAME_ADJ:ALL_SOLID:frozen dwarven wine]
[STATE_NAME_ADJ:LIQUID:dwarven wine]
[STATE_NAME_ADJ:GAS:boiling dwarven wine]
[MATERIAL_VALUE:2]
[DISPLAY_COLOR:5:0:0]
[EDIBLE_RAW]
[EDIBLE_COOKED]
[PREFIX:NONE]
[DRINK:LOCAL_PLANT_MAT:DRINK]

[USE_MATERIAL_TEMPLATE:SEED:SEED_TEMPLATE]
[MATERIAL_VALUE:1]
[EDIBLE_VERMIN]
[EDIBLE_COOKED]
[SEED:plump helmet spawn:plump helmet spawn:4:0:1:LOCAL_PLANT_MAT:SEED]
[SPRING][SUMMER][AUTUMN][WINTER]
[FREQUENCY:100]
[CLUSTERSIZE:5]
[PREFSTRING:rounded tops]
[WET][DRY]
[BIOME:SUBTERRANEAN_WATER]
[UNDERGROUND_DEPTH:1:3]
[SHRUB_TILE:142]
[DEAD_SHRUB_TILE:28]
[SHRUB_COLOR:5:13:0]
[DEAD_SHRUB_COLOR:5:6:0]

Let's look at this line by line: 
First, we define its file name. In this case it's MUSHROOM_HELMET_PLUMP. Next we define its in-game name (plump helmet) and its adjective for if you were to craft with it (e.g. plump helmet earrings).

[USE_MATERIAL_TEMPLATE:STRUCTURAL:STRUCTURAL_PLANT_TEMPLATE]
[MATERIAL_VALUE:2]
[BASIC_MAT:LOCAL_PLANT_MAT:STRUCTURAL]

This defines the structure and material of the plant. It references STRUCTURAL_PLANT_TEMPLATE in the first line, so if you were to say, add wings to the template, the plump helmet plant would be winged. This is for the plant itself, not the end plump helmets.

After that we get our edible tokens. These say that vermin can eat the plant, and it can be eaten raw or cooked by your dwarves. So if you wanted a plant vermin would leave alone, you'd remove the [EDIBLE_VERMIN] token.

[EDIBLE_VERMIN]
[EDIBLE_RAW]
[EDIBLE_COOKED]

Next, [PICKED_TILE:161] is the character (161 in this case) shown when the crop is harvested. See [[Main:Character table|character table]] for a table of usable tiles. [PICKED_COLOR:6:13:0] is the color used for the crop's tile when harvested. It's in a foreground:background:brightness format. See [[color]] for the colors usable.

[PICKED_TILE:161][PICKED_COLOR:6:13:0]

[GROWDUR:300] is how long it takes for your crop to grow. There are 1008 growdur units in a season. 
[VALUE:2] Is the value of harvested plant (default 1). Appears to have no effect in version 0.31.

[GROWDUR:300][VALUE:2]

This defines the plant's alcohol states. [STATE_NAME_ADJ:ALL_SOLID:] is the frozen name, followed is the actual drink name, and then its boiling name. These are achieved by either Scorching or Freezing climates. [DISPLAY_COLOR] is, of course, color, and [EDIBLE_RAW] and [EDIBLE_COOKED] are saying you can drink the alcohol raw or cooked.

[USE_MATERIAL_TEMPLATE:DRINK:PLANT_ALCOHOL_TEMPLATE]
[STATE_NAME_ADJ:ALL_SOLID:frozen dwarven wine]
[STATE_NAME_ADJ:LIQUID:dwarven wine]
[STATE_NAME_ADJ:GAS:boiling dwarven wine]
[MATERIAL_VALUE:2]
[DISPLAY_COLOR:5:0:0]
[EDIBLE_RAW]
[EDIBLE_COOKED]
[PREFIX:NONE]
[DRINK:LOCAL_PLANT_MAT:DRINK]

After that we get our seed template:

[USE_MATERIAL_TEMPLATE:SEED:SEED_TEMPLATE]
[MATERIAL_VALUE:1]
[EDIBLE_VERMIN]
[EDIBLE_COOKED]
[SEED:plump helmet spawn:plump helmet spawn:4:0:1:LOCAL_PLANT_MAT:SEED]

And all this says is that the seeds may be eaten by vermin or cooked. Then it gives the name of our plant's seed, its plural name, its foreground, background, and brightness colors, followed by its seed material; said material should have [SEED_MAT] to permit proper stockpiling.

And finally for the last chunk we have this:

[SPRING][SUMMER][AUTUMN][WINTER]
[FREQUENCY:100]
[CLUSTERSIZE:5]
[PREFSTRING:rounded tops]
[WET][DRY]
[BIOME:SUBTERRANEAN_WATER]
[UNDERGROUND_DEPTH:1:3]
[SHRUB_TILE:142]
[DEAD_SHRUB_TILE:28]
[SHRUB_COLOR:5:13:0]
[DEAD_SHRUB_COLOR:5:6:0]

First we define what season(s) the plant may grow in, then we define how frequently this plant is generated in a particular area, followed by how many harvested crop items may come from 1 plant. [PREFSTRING:] is what your dwarves like about the plant, which in this case is the rounded tops. [WET][DRY] are the conditions under which the plant can grow. Wet means it can grow close to water, dry means it can grow away from water. This does not mean you can grow the plant on dry stone however. It is just for natural spawning of the plant. 
[BIOME] Is what biome the plant grows in. [UNDERGROUND_DEPTH:Minimum:Maximum] Is the highest and lowest cavern levels that the plant can appear in if its biome is subterranean. Dwarven civilizations will only export (via the embark screen or caravans) things that available at depth 1. Defaults to 0:0 (surface only). 
Lastly, [SHRUB_TILE] is the character used for the naturally spawning shrub of this plant, [DEAD_SHRUB] is the dead shrub character. [SHRUB_COLOR] Is the shrub's color, and [DEAD_SHRUB_COLOR] is, of course, the dead shrub's color.

While this may or may not look like a lot of tokens, it's very easy. Just copy an existing plant and edit it to your new plant. 
For the rest of the tokens, see [[plant token]].

== Workshops ==

Workshops are raw-designed pretty differently from everything else in the game, being buildable structures rather than items or methods to gain items. However, they are fairly simple. For example, here's the raw for the [[soap maker's workshop]]:

[BUILDING_WORKSHOP:SOAP_MAKER]
[NAME:Soap Maker's Workshop]
[NAME_COLOR:7:0:1]
[DIM:3:3]
[WORK_LOCATION:2:2]
[BUILD_LABOR:SOAP_MAKER]
[BUILD_KEY:CUSTOM_SHIFT_S]
[BLOCK:1:0:0:1]
[BLOCK:2:0:0:1]
[BLOCK:3:0:0:0]
[TILE:0:1:' ':' ':150]
[TILE:0:2:' ':' ':'/']
[TILE:0:3:'-':' ':' ']
[COLOR:0:1:0:0:0:0:0:0:6:0:0]
[COLOR:0:2:0:0:0:0:0:0:6:0:0]
[COLOR:0:3:6:0:0:0:0:0:0:0:0]
[TILE:1:1:' ':' ':'=']
[TILE:1:2:'-':' ':8]
[TILE:1:3:' ':' ':150]
[COLOR:1:1:0:0:0:0:0:0:6:0:0]
[COLOR:1:2:6:0:0:0:0:0:6:0:0]
[COLOR:1:3:0:0:0:0:0:0:6:0:0]
[TILE:2:1:'-':' ':8]
[TILE:2:2:' ':' ':8]
[TILE:2:3:' ':150:' ']
[COLOR:2:1:6:0:0:0:0:0:6:0:0]
[COLOR:2:2:0:0:0:0:0:0:6:0:0]
[COLOR:2:3:0:0:0:6:0:0:0:0:0]
[TILE:3:1:150:' ':8]
[TILE:3:2:' ':' ':8]
[TILE:3:3:' ':240:' ']
[COLOR:3:1:6:0:0:0:0:0:6:7:0]
[COLOR:3:2:0:0:0:0:0:0:6:7:0]
[COLOR:3:3:0:0:0:7:0:1:0:0:0]
[BUILD_ITEM:1:BUCKET:NONE:NONE:NONE][EMPTY][CAN_USE_ARTIFACT]
[BUILD_ITEM:1:NONE:NONE:NONE:NONE][BUILDMAT][WORTHLESS_STONE_ONLY][CAN_USE_ARTIFACT]

A line-by-line breakdown:

[NAME:Soap Maker's Workshop]
[NAME_COLOR:7:0:1]

These are the name of the workshop ("Soap Maker's Workshop") and [[color]] of the workshop's name when examined with 'q' (White with a black background).

[DIM:3:3]
[WORK_LOCATION:2:2]

DIM refers to how large the workshop will be, in this case 3 wide, 3 tall. WORK_LOCATION tells where the creature using it (usually a dwarf) will work, numbered from the top right--in this case, 2:2, or the middle. Multiple work locations can be defined, even outside the dim.

[BUILD_LABOR:SOAP_MAKER]
[BUILD_KEY:CUSTOM_SHIFT_S]

These refer to the worker required to build it (soap maker) and the key used to build it in the workshop menu (capital S).

[BLOCK:1:0:0:1]
...
This is a bit more complex, and is where we get to the meaty part of workshop making--the tiles' properties. BLOCK refers to which tiles will be untraversable--1 means blocked, 0 means unblocked. The first number refers to row, and the next 3 refer to column, so 1:0:0:1 means that, on the first row, the first two tiles will be unblocked and the last will be blocked.

[TILE:0:1:' ':' ':150]
...
The TILE token tells which tile will go where. note, however, that there are 5 entries here instead of 4. The first number, in this case, refers to build stage, numbered from 0 to 3; 3 or 1 is fully built (depending on whether there are stages), 0 is just placed, and 2 is always an intermediate stage, while 1 is usually an intermediate stage. Whether 1 is an intermediate stage or not depends on if there are a 2 and 3 stage; if 2 and 3 exist, 1 will be intermediate. The second number and beyond are similar to BLOCK; however, instead of 1s and 0s, you must input tiles. The tiles themselves can be given in quotes (as in ' ') or given as a number, which can be looked up [[Tilesets|here]]. Here, we have 150, which is û.

[COLOR:1:1:0:0:0:0:0:0:6:0:0]
...
Color is as TILE, but with colors instead of tiles; however, colors are made up of 3 numbers each or MAT. MAT refers to the color of the material used to make it; the 3 numbers refer to foreground:background:foreground brightness, and can be looked up [[Color|here]]. For example, 4:2:1 will give you bright red with a dark green background.

[BUILD_ITEM:1:BUCKET:NONE:NONE:NONE][EMPTY][CAN_USE_ARTIFACT]
[BUILD_ITEM:1:NONE:NONE:NONE:NONE][BUILDMAT][WORTHLESS_STONE_ONLY][CAN_USE_ARTIFACT]
These refer to items required to build the building. These are in the same format as [[Reaction|reaction reagents and products]]--quantity:[[Item token|item]]:[[Material token|material]]. You'll learn more about those on the article about [[Reaction|reactions]], though. The second BUILD_ITEM is special-- it uses modifiers exclusively to determine its requirements. BUILDMAT refers to wood logs, wood blocks, stone boulders, and stone blocks; WORTHLESS_STONE_ONLY means it can't use economic stone; CAN_USE_ARTIFACT means that it... can use artifacts. EMPTY, in the bucket's case, means that the bucket must be empty.

More can be seen at the [[Building token|building tokens]] article.

== Reactions ==

An in-depth guide for reactions is available [[Reactions|here]].

== Materials ==

As we've seen when talking about creatures, materials are vital. Materials show up in two forms: material templates, which generally show up in creatures, and specific materials (designated as "inorganic"), which are (by default, at least) consigned purely to metal and stone types.

Let's take a look at METAL_TEMPLATE in material_template_default.txt. It's evident that most of the basic properties of metals are already defined in the template - it goes red and melts at a high enough temperature, it's heavy, and (as noted by the very bottom token) is a metal. We already know just how useful templates can be to creatures, and the same applies to other materials.

Now let's take a look at inorganic_metal.txt. You can see that the metals here refer to the templates, and, just like we did with creatures, then modify the properties of that template and expand upon it.

Finally, let's look at inorganic_stone_mineral.txt. Here we can see that in addition to the changes made to the template, there are also ENVIRONMENT tokens - these tell the game where to place these minerals during worldgen.

[[material definition token|Here's a list of material tokens]]. It should also help you out with any modifications you want to make regarding those creature modifications we were making a while back. See, it all ties together in the end. The beauty of the current materials system is that there's actually very little difference between, say, leather and iron - they're fundamentally the same thing, just with different properties, which is how things really should be.

== Examples ==

The Hydling by Mysteryguye (annotated, updated and separated into blocks by Putnam)

[CREATURE:HYDLING]
[DESCRIPTION:A seven-headed small hairy thing, about the size of a dog. It is very loyal to its masters, and will promptly disembowel any enemy straying too close.]
This is the description that shows up in-game when viewing the creature.

[NAME:hydling:hydlings:hydlish] If there were a civ made of hydlings, it would appear as "hydlings" in the neighbors screen.

[CASTE_NAME:hydling:hydlings:hydlish]

[CREATURE_TILE:'='][COLOR:2:0:1] Will appear as a light green "=".

[PETVALUE:78][NATURAL] Creature is known to be naturally occurring by the game. Will cost 40 embark points to buy.

[LARGE_ROAMING] Will spawn outdoors, wandering around.

[COMMON_DOMESTIC][TRAINABLE][PET] Can be bought on embark as a pet, war animal, or hunting animal.

[BONECARN] Can eat meat and bones only--no vegetables.

[PREFSTRING:loyalty] Dwarves will like it for its loyalty.

[LIKES_FIGHTING] Will attack rather than flee.

[BODY:BASIC_2PARTBODY:7HEADNECKS:BASIC_FRONTLEGS:BASIC_REARLEGS:TAIL:2EYES:NOSE:2LUNGS:HEART:GUTS:ORGANS:THROAT:SPINE:BRAIN:SKULL:3TOES_FQ_REG:3TOES_RQ_REG:MOUTH:TONGUE:GENERIC_TEETH_WITH_FANGS:RIBCAGE]

Has a lower body, upper body, 4 legs, a tail, ten eyes, ten ears, five noses, two lungs, a heart, guts, a pancreas etc., and 5 heads with all that goes with those.

[BODYGLOSS:PAW] Feet will be called "paws"

[BODY_DETAIL_PLAN:STANDARD_MATERIALS] Declares the standard materials that most creatures' tissues are made of.

[BODY_DETAIL_PLAN:STANDARD_TISSUES] This declares the tissues that the creature's tissue layers are made of.

[BODY_DETAIL_PLAN:VERTEBRATE_TISSUE_LAYERS:SKIN:FAT:MUSCLE:BONE:CARTILAGE] And this describes the tissue layers that the creature is made of.

[BODY_DETAIL_PLAN:BODY_HAIR_TISSUE_LAYERS:HAIR] Creature will be covered with a layer of fur.

[USE_MATERIAL_TEMPLATE:NAIL:NAIL_TEMPLATE] And it'll have nails.

[USE_TISSUE_TEMPLATE:NAIL:NAIL_TEMPLATE]

[TISSUE_LAYER:BY_CATEGORY:TOE:NAIL:FRONT] On the toe, specifically.

[SELECT_TISSUE_LAYER:HEART:BY_CATEGORY:HEART]
[PLUS_TISSUE_LAYER:SKIN:BY_CATEGORY:THROAT]
[TL_MAJOR_ARTERIES] Heart and throat--called above--will cause heavy bleeding if ruptured.

[BODY_DETAIL_PLAN:STANDARD_HEAD_POSITIONS] Places eyes, ears and what have you into their correct placement, so that you don't have people punching out eyes from behind.

[BODY_DETAIL_PLAN:HUMANOID_RIBCAGE_POSITIONS] Sets the ribcage as being around lungs and heart.

[USE_MATERIAL_TEMPLATE:SINEW:SINEW_TEMPLATE] Defines sinew so that...
[TENDONS:LOCAL_CREATURE_MAT:SINEW:200] Tendons
[LIGAMENTS:LOCAL_CREATURE_MAT:SINEW:200] And ligaments can be defined.

[HAS_NERVES] Creature has nerves, and as such can be disabled by severing them.

[USE_MATERIAL_TEMPLATE:BLOOD:BLOOD_TEMPLATE] Defines the material BLOOD using the template BLOOD_TEMPLATE.
[BLOOD:LOCAL_CREATURE_MAT:BLOOD:LIQUID] Defines the creature's BLOOD as being made of the above-defined BLOOD material in a LIQUID state.

[CREATURE_CLASS:GENERAL_POISON] Creature can be affected by syndromes that affect GENERAL_POISON.

[GETS_WOUND_INFECTIONS] Pretty much self-explanatory. Creature can get infected from wounds.
[GETS_INFECTIONS_FROM_ROT] And from necrosis.

[USE_MATERIAL_TEMPLATE:PUS:PUS_TEMPLATE] Defines PUS using PUS_TEMPLATE.
[PUS:LOCAL_CREATURE_MAT:PUS:LIQUID] Defines PUS as being made of PUS.

[BODY_SIZE:0:0:1000] Creature will be 1000 cubic centimeters at birth...
[BODY_SIZE:1:0:12500] 12500 cubic centimeters at 1 year old...
[BODY_SIZE:2:0:30000] and 30000 cubic centimeters at 2.

[BODY_APPEARANCE_MODIFIER:LENGTH:90:95:98:100:102:105:110] Creature can be anywhere from 90% to 110% as long as others.
[BODY_APPEARANCE_MODIFIER:HEIGHT:90:95:98:100:102:105:110] As above, but with height.
[BODY_APPEARANCE_MODIFIER:BROADNESS:90:95:98:100:102:105:110] As above, but with broadness. This puts the minimum size of the creature (when fully grown) at 21870 and the maximum size at 39930.

[MAXAGE:20:30] Creature will die of old age between the ages of 20 and 30, no later than 30, no sooner than 20.

[CAN_DO_INTERACTION:MATERIAL_EMISSION] Creature can use the MATERIAL_EMISSION interaction.
[CDI:ADV_NAME:Hurl fireball] In adventurer mode, the MATERIAL_EMISSION interaction will appear as "Hurl fireball".
[CDI:USAGE_HINT:ATTACK] Creature will use MATERIAL_EMISSION when it's attacking, on creatures that it's attacking.
[CDI:BP_REQUIRED:BY_CATEGORY:HEAD] Creature must have at least one HEAD to use MATERIAL_EMISSION.
[CDI:FLOW:FIREBALL] The MATERIAL_EMISSION will shoot a fireball.
[CDI:TARGET:C:LINE_OF_SIGHT] The target for the emission--a location--must be within the line of sight of the Hydling.
[CDI:TARGET_RANGE:C:15] And must be, at most, 15 tiles away.
[CDI:MAX_TARGET_NUMBER:C:1] The hydling can only shoot at one target at a time...
[CDI:WAIT_PERIOD:30] and only every 30 ticks (3 tenths of a second at 100 FPS)

[ATTACK:BITE:CHILD_BODYPART_GROUP:BY_CATEGORY:HEAD:BY_CATEGORY:TOOTH] Defines a BITE attack that uses teeth.
[ATTACK_SKILL:BITE] Attack uses the BITE skill.
[ATTACK_VERB:nom:noms] "The Hydling noms the Elf in the left first toe, tearing the muscle!"
[ATTACK_CONTACT_PERC:100] Will use all of the tooth. Note that this can be more than 100.
[ATTACK_PENETRATION_PERC:100] Will sink the tooth all the way in. This can also be more than 100.
[ATTACK_FLAG_EDGE] Attack is an EDGE attack.
[ATTACK_PRIORITY:MAIN] Attack is of priority MAIN. Other option is SECOND.
[ATTACK_FLAG_CANLATCH] Attack can latch.
[ATTACK_PREPARE_AND_RECOVER:3:3] Takes 3 ticks to wind up attack and 3 to recover from it.
[ATTACK_FLAG_INDEPENDENT_MULTIATTACK] Can use each head independently.

[ATTACK:SCRATCH:CHILD_TISSUE_LAYER_GROUP:BY_TYPE:STANCE:BY_CATEGORY:ALL:NAIL] As above, but for nail instead of teeth.
[ATTACK_SKILL:STANCE_STRIKE] Uses the kicking skill.
[ATTACK_VERB:slice:slices] "You slice the Elf in the left foot and the severed part sails off in an arc!"
[ATTACK_CONTACT_PERC:100] Uses the whole nail.
[ATTACK_PENETRATION_PERC:100] The whole nail goes in.
[ATTACK_FLAG_EDGE] Attack is an edge attack.
[ATTACK_PREPARE_AND_RECOVER:3:3]
[ATTACK_PRIORITY:SECOND]

[CHILD:1] Hydling will become an adult at 1 year old.

[GENERAL_CHILD_NAME:hydie:hydies] Children will appear as "hydies".

[DIURNAL] Is active during the daytime.

[HOMEOTHERM:10070] Has a body temperature of 102 Fahrenheit.

[APPLY_CREATURE_VARIATION:STANDARD_QUADRUPED_GAITS:900:730:561:351:1900:2900] Can run at 25 kph
[APPLY_CREATURE_VARIATION:STANDARD_SWIMMING_GAITS:3512:2634:1756:878:4900:6900] Can swim at 10 kph
[APPLY_CREATURE_VARIATION:STANDARD_CRAWLING_GAITS:6561:6115:5683:1755:7456:8567] Can crawl at 5 kph
[SWIMS_INNATE]Swims innately.

[CASTE:FEMALE] Defines a caste called FEMALE.
[FEMALE] FEMALE caste is female.

[CASTE:MALE] As above, but with male.
[MALE] See above.

= Modding utilities =

[http://www.bay12forums.com/smf/index.php?topic=28829.0 A list of many mods and community-developed utilities]

{{Category|Modding}}
[[Category:v0.31:Guides]]

Modding

2016-03-01T10:36:57Z

Chinchou: Colons are full-stops, not half-stops. Miscellaneous grammatical corrections were also made.

{{Quality|Exceptional|14:13, 7 November 2013 (UTC)}}
{{av}}
This is intended to be a guide to inform those new to DF modding on what elements of the game can be modified, and how. After reading through this guide, a user should be capable of editing creatures, entities, materials ''et al'', and creating their own.

Generally, breaking stuff is fine - nothing that can be changed will affect the DF executable, and new additions can be easily removed.

This guide is based on [[40d:Modding guide|Teldin's guide]], originally created for version 0.27.176.39c. Per wiki tradition, it has been updated through all the major releases since then; hopefully it reflects current knowledge.

'''See also:''' [[:Category:DF2014:Modding]]

= Modding Guide =

== Token Reference ==

It's always good to refer to tokens on the wiki. Even experienced modders have to look up tokens! A list of articles about tokens can be found [http://dwarffortresswiki.org/index.php/Token here.]

== Basics of DF modding ==

All the base data that can be edited by prospective modders can be found in the \raw\ folder. This folder contains two subfolders: "graphics" (where you insert [[Graphics set repository|graphics sets]]), and "objects", which contains all the data for generally everything in the game that is not hardcoded.

Within the \raw\objects folder are a large number of text files - these are the [[raw file|raw files]], and editing them is quite easy - you can also create your own if you wish. For now, take a look at one of the existing files. For example if you open creature_standard.txt it should look something like this:

creature_standard

[OBJECT:CREATURE]

[CREATURE:DWARF]
[DESCRIPTION:A short, sturdy creature fond of drink and industry.]
[NAME:dwarf:dwarves:dwarven]
[CASTE_NAME:dwarf:dwarves:dwarven]
[CREATURE_TILE:1][COLOR:3:0:0]
[CREATURE_SOLDIER_TILE:2]
...

As you can see, each file comprises a header string stating the file name, a second header stating the type of object data it contains, followed by the contents of the file itself. These are all necessary elements of the file, and without them, the file won't be parsed correctly by the game. You may have also noticed the file naming scheme - this is also important; files containing creatures have names starting with "creature_", entity file names must begin with "entity_", etc..

Below the headers, there begins a list of entries. Each entry is made up of its own header (in this case, "[CREATURE:DWARF]"), again stating the type of object, and then the object's unique identifier - if an identifier isn't unique, the game will mess up and you'll get some serious, and potentially very trippy, errors. Below that, we have the body of the entry, which determines the entry's specific properties.

The body of an entry is made up of a series of "tokens", which are essentially flags that can be added or removed to affect the entry's attributes. Most of these effects are hardcoded: for example, it's possible to make a creature only eat meat with the [CARNIVOROUS] token, but it's impossible to create your own token detailing a specific diet for the creature.

Before we continue, a few key things to remember when modding the raw files:

* Try to avoid modifying the existing raw files when adding objects. It makes removing mods far easier.
* When adding files, all you need to include to ensure proper references are maintained is the token identifier's. The game will load up all *.txt in the raw folder, and searches through them by tokens. For example: You can add a new pair of leather boots and not even have to add it to the item_shoes.txt file, but rather make your own file, say item_shoes_new.txt and ensure you have the token listed, ex. [ITEM_SHOES:ITEM_SHOES_BOOTS_NEW], that's how the game will look for the item.
* If you want to edit an already-existing creature, always back up the files you plan on editing to a different location. Since v0.31.22, the game no longer loads backup files, but duplicate entries are still a very bad thing.
* When a new world is generated, all the raw files get copied into a \raw\ folder within the applicable save folder. If you want to change something within a world that's already been generated, you'll have to edit those files, not the ones in ~DF\raw\objects.
* There's nothing stopping you from just copying an existing creature/entity/whatever, changing the identifier, and modifying it. This can save you a lot of time, especially when it comes to entities... which are coincidentally what we'll be talking about next.

== Modding civilizations (entities) ==

Entities - the objects that determine how civilizations work - are stored in entity_default.txt (though, like all other files, you may add more). They follow the same format as any other raw file:

entity_default

[OBJECT:ENTITY]

[ENTITY:ENTITYNAME]
[CREATURE:CREATURETYPE]
[TRANSLATION:LANGUAGETYPE]
[BIOME_SUPPORT:BIOMETOKEN:FREQENCY]
...[OTHER TAGS]...

Most of the time, it doesn't matter which order these tokens are in or where they're placed so long as they're below the "ENTITY:" identifier, but there are some important exceptions in the case of other files, especially creatures, which can contain a lot of "nested" tokens.

"[CREATURE:]" links the civilization with a specific creature defined in a creature file. This is the creature that'll be making up the entity's population, and will therefore be the creature you'll be playing as in fortress or adventure mode if the entity is a playable one. For example, if you wanted to do something silly, you could switch the "CREATURE:DWARF" entry in entity_default.txt with "CREATURE:ELF" and you would be marching elves around in fortress mode, although they would still use dwarven technology and language and names and so forth.

Oh, and before you get any funny ideas - it ''is'' possible to define more than one creature for a civ, but that won't work in quite the way you probably expect; later on, in the creature section, you'll learn about castes, which will provide a much more viable alternative, so try to bear with us until then.

"[TRANSLATION:]" defines the language file that the entity will be using, which will determine what their untranslated words are for things. This doesn't determine which words they use for naming things, only the way those words are spelled. The default language files are HUMAN, DWARF, ELF, and GOBLIN.

"[BIOME_SUPPORT:]" defines the biomes that civs will attempt to settle in. The "FREQUENCY" value determines the likelihood of them building there, but also raises an important point: Most of the values you'll be setting for things are relative to each other. If one were to type:

[BIOME_SUPPORT:ANY_FOREST:1]
[BIOME_SUPPORT:SAVANNA:2]

This would have very much the same effect as:

[BIOME_SUPPORT:ANY_FOREST:5]
[BIOME_SUPPORT:SAVANNA:10]

This holds true for a lot of values throughout the files, excluding when it simply doesn't make sense, such as in materials.

You can find many details about the rest of the civilization tokens [[entity token|here]]. Besides those mentioned, some fundamental ones are the CIV_CONTROLLABLE token, which lets you control the civ in fortress mode, the INDIV_CONTROLLABLE token, which allows you to play the civ in adventure mode as an outsider, and the ADVENTURE_TIER token, which allows you to play a civ native (non-outsider) in adventure mode. Other tokens that you should pay attention to are START_BIOME and the ones regarding sites, but in general, you can just run through the aforementioned list and add or remove what you want.

If you have more than one civ with the CIV_CONTROLLABLE token, all the available civs from those entities will appear in the group selection section on the embark screen. It may not be immediately obvious from which species each civ may be - while this can be determined from legends mode, the topmost species in the "neighbors" display in the embark screen is always the same as the currently selected species; if your group is dwarven, dwarves will be topmost, whilst (say) elves will be topmost if your chosen group is elven. By default, the game seems to choose a civ (and therefore a species if there is more than one) at random.

You can also attempt to discern the civ yourself by the names it uses - this is the realm of "symbols", collections of words centered around a specific concept. The civ will use the words comprising whatever symbols are applicable to it for various things. This association might be a little obfuscating at first, so I'll run through it. Let's refer to the DWARF entity:

[SELECT_SYMBOL:WAR:NAME_WAR]
[SUBSELECT_SYMBOL:WAR:VIOLENT]
[SELECT_SYMBOL:BATTLE:NAME_BATTLE]
[SUBSELECT_SYMBOL:BATTLE:VIOLENT]
[SELECT_SYMBOL:SIEGE:NAME_SIEGE]
[SUBSELECT_SYMBOL:SIEGE:VIOLENT]

Here we can see that dwarves will generally name their wars first after words in the "NAME_WAR" symbol group, and then after words in the "VIOLENT" symbol group. This might, for example, result in a war being named "The War of Carnage". The symbols used for the other types of conflict are arrayed in a similar fashion. It would be trivial to replace the instances of VIOLENT with, say, PEACE and end up with a battle called "The Clash of Calm" or something.

[SELECT_SYMBOL:ROAD:NAME_ROAD]
[SELECT_SYMBOL:TUNNEL:NAME_TUNNEL]
[SELECT_SYMBOL:BRIDGE:NAME_BRIDGE]
[SELECT_SYMBOL:WALL:NAME_WALL]

The above applies here. Dwarves are fond of naming their roads and tunnels after roads and tunnels.

[SELECT_SYMBOL:REMAINING:ARTIFICE]
[SELECT_SYMBOL:REMAINING:EARTH]
[CULL_SYMBOL:ALL:DOMESTIC]
[CULL_SYMBOL:ALL:SUBORDINATE]
[CULL_SYMBOL:ALL:EVIL]
[CULL_SYMBOL:ALL:UNTOWARD]
[CULL_SYMBOL:ALL:FLOWERY]
[CULL_SYMBOL:ALL:NEGATIVE]
[CULL_SYMBOL:ALL:UGLY]
[CULL_SYMBOL:ALL:NEGATOR]

This section deals with everything else. The things that haven't already been dealt with (hence the "REMAINING") - such as site names, kingdom names, the names of individuals, and such - will have names from the ARTIFICE and EARTH symbol groups. After that the dwarf entity is told to cull all innapropriate symbols - this applies to everything (hence the "ALL") so if the game happens to choose a symbol associated with, say, EVIL for one of the battles, it'll scrap that name and try again. This sort of thing adds a lot of flavour to DF's entities and can account for a lot of a civ's perceived personality.

Another basic thing to note: Any entity token that's dealing with weapons, armor, clothing, etc., will state the items that the civ can build natively, not necessarily the ones they can wear or use. For example, you could create a species with no clothes specified, but then rob a clothes shop in adventurer mode and wear everything you want, or give them weapons that are too large to wield and they could sell them, but not use them.

An easy method of creating a civilization is just to copy-paste a similar one to the bottom of the entity_default.txt file and edit things to your liking. Remember to always change the civ's "ENTITY:" identifier! This can be anything so long as it's not already existing.

At the end of some of the default entries you'll find a list of positions, both ones that'll directly affect you in fort mode (such as nobles) and ones that'll primarily affect worldgen and adventure mode. A list of the tokens applicable to positions can be found [[position token|here]]; they don't require a great deal of explanation.

== Modding the creatures ==

Creature modding is great fun. You can change nearly any aspect of a creature or make your own completely from scratch.

Modding creatures is very similar to modding civs: it's just a matter of editing, adding, or removing tokens, enclosed in square brackets underneath the creature's [CREATURE:] header. The creature entries contain all of the information about each and every non-random creature in the game, from animals to dwarves to goblins to even caravan wagons. A lot of the creature tokens are fairly self-explanatory; you can find a list of such tokens [[creature token|here]]. But before you start creating your own creatures, you'll want to learn how the tissues system works.

=== Creature materials and tissues ===

In the most basic sense, a creature is a series of bodyparts. These parts are defined in their own file, and we'll talk about them later. As a specific aspect of how creatures work which throws off a lot of prospective modders is the relationship between bodyparts, tissues, and materials. We're going to show you part of the creature entry for a bronze colossus (bear with us):

...
[BODY:HUMANOID:2EYES:2EARS:NOSE:HUMANOID_JOINTS:5FINGERS:5TOES]
[NO_THOUGHT_CENTER_FOR_MOVEMENT]
[TISSUE:BRONZE]
[TISSUE_NAME:bronze:bronze]
[TISSUE_MATERIAL:INORGANIC:BRONZE]
[MUSCULAR]
[FUNCTIONAL]
[STRUCTURAL]
[RELATIVE_THICKNESS:1]
[CONNECTS]
[TISSUE_SHAPE:LAYER]
[TISSUE_LAYER:BY_CATEGORY:ALL:BRONZE]
...

At the top, we can see the "BODY:" token, followed by a list of bodyparts. As you've probably guessed, these parts make up the physical form of the colossus. But the colossus has to be made out of something - it has to have tissues. And those tissues also have to be made out of something - in this case, bronze.

Below the BODY token you'll see a TISSUE token, followed by an identifier, much like the others we've seen. The TISSUE block is determining how the tissue works, and which purposes it'll serve. As the colossus is just going to be made out of this one tissue, this tissue needs to act like bone, muscle, and everything else combined, hence the MUSCULAR, FUNCTIONAL and STRUCTURAL tokens. The tissue also references a material - INORGANIC:BRONZE - the properties of which are declared in the inorganic materials file, and the tissue is subsequently made out of this material. With us so far?

Below the tissue definition is the TISSUE_LAYER line. TISSUE_LAYER allows you to control where each tissue is applied. Its first argument defines if it's to search by bodypart category (BY_CATEGORY), bodypart type (BY_TYPE), or look for a specific part (BY_TOKEN). That's followed by the parts argument itself, which is in this case ALL (so the game's looking for parts in all categories, which is to say, every bodypart). This is followed by the tissue to be applied, BRONZE. So the TISSUE_LAYER token is telling the game to select all bodyparts in every category and make them out of the tissue "BRONZE". The colossus is now made of bronze.

By now you're probably thinking "Wow, if this was for a creature made out of however many tissues, this would be amazingly longwinded". And you're right. Luckily, there are two methods by which we can speed things up a lot.

Firstly, there are material and tissue templates. Let's say you were going to make a lot of creatures out of bronze, and you didn't want to have to copy and paste the bronze tissue all over the place. Instead, you create a tissue template. This goes, as you've probably guessed, in a tissue template file.

[TISSUE_TEMPLATE:BRONZE_TEMPLATE]
[TISSUE_NAME:bronze:bronze]
[TISSUE_MATERIAL:INORGANIC:BRONZE]
[MUSCULAR]
[FUNCTIONAL]
[STRUCTURAL]
[RELATIVE_THICKNESS:1]
[CONNECTS]
[TISSUE_SHAPE:LAYER]

Now, instead of applying the tissue to each and every bronze creature you're making, you can just refer to the template:

...
[BODY:HUMANOID:2EYES:2EARS:NOSE:HUMANOID_JOINTS:5FINGERS:5TOES]
[NO_THOUGHT_CENTER_FOR_MOVEMENT]
[USE_TISSUE_TEMPLATE:BRONZE:BRONZE_TEMPLATE]
[TISSUE_LAYER:BY_CATEGORY:ALL:BRONZE]
...

Material templates work in the same way, but refer to materials instead of tissues.

However, if we're looking at something like a dwarf, even with the templates, editing can get very slow indeed:

...
[USE_MATERIAL_TEMPLATE:SKIN:SKIN_TEMPLATE]
[USE_MATERIAL_TEMPLATE:FAT:FAT_TEMPLATE]
[USE_MATERIAL_TEMPLATE:MUSCLE:MUSCLE_TEMPLATE]
[USE_MATERIAL_TEMPLATE:BONE:BONE_TEMPLATE]
[USE_MATERIAL_TEMPLATE:CARTILAGE:CARTILAGE_TEMPLATE]
[USE_MATERIAL_TEMPLATE:HAIR:HAIR_TEMPLATE]
[USE_MATERIAL_TEMPLATE:TOOTH:TOOTH_TEMPLATE]
[USE_MATERIAL_TEMPLATE:EYE:EYE_TEMPLATE]
[USE_MATERIAL_TEMPLATE:NERVE:NERVE_TEMPLATE]
[USE_MATERIAL_TEMPLATE:BRAIN:BRAIN_TEMPLATE]
[USE_MATERIAL_TEMPLATE:LUNG:LUNG_TEMPLATE]
[USE_MATERIAL_TEMPLATE:HEART:HEART_TEMPLATE]
[USE_MATERIAL_TEMPLATE:LIVER:LIVER_TEMPLATE]
[USE_MATERIAL_TEMPLATE:GUT:GUT_TEMPLATE]
[USE_MATERIAL_TEMPLATE:STOMACH:STOMACH_TEMPLATE]
[USE_MATERIAL_TEMPLATE:PANCREAS:PANCREAS_TEMPLATE]
[USE_MATERIAL_TEMPLATE:SPLEEN:SPLEEN_TEMPLATE]
[USE_MATERIAL_TEMPLATE:KIDNEY:KIDNEY_TEMPLATE]
[USE_TISSUE_TEMPLATE:SKIN:SKIN_TEMPLATE]
[USE_TISSUE_TEMPLATE:FAT:FAT_TEMPLATE]
[USE_TISSUE_TEMPLATE:MUSCLE:MUSCLE_TEMPLATE]
...

This is where body detail plans come in. Detail plans, of course, have their own file, and they are designed to help automate some of the more common processes in creature creation. The first entry in b_detail_plan_default.txt does exactly what we've been trying to do above: it takes all the common materials and shoves them into one plan, which can be referenced with a single token.

...
[BODY_DETAIL_PLAN:STANDARD_MATERIALS]
...

Much easier. But what about the TISSUE_LAYER tokens? Will we have to type out all of those manually?

Nope, detail plans have that covered as well. It's possible to place variable arguments into a detail plan. For example:

[BODY_DETAIL_PLAN:VERTEBRATE_TISSUE_LAYERS]
[BP_LAYERS:BY_CATEGORY:BODY:ARG3:50:ARG2:5:ARG1:1]
[BP_LAYERS:BY_CATEGORY:BODY_UPPER:ARG3:50:ARG2:5:ARG1:1]
[BP_LAYERS:BY_CATEGORY:BODY_LOWER:ARG3:50:ARG2:5:ARG1:1]
[BP_LAYERS:BY_CATEGORY:ARM:ARG4:25:ARG3:25:ARG2:5:ARG1:1]
[BP_LAYERS:BY_CATEGORY:ARM_UPPER:ARG4:25:ARG3:25:ARG2:5:ARG1:1]
...
[BP_LAYERS:BY_CATEGORY:NOSE:ARG5:4:ARG1:1]
...

First an argument is placed in the plan (ARG1, ARG2 etc.), followed by the thickness of the tissue that will be inserted in place of the argument. So when we reference the VERTEBRATE_TISSUE_LAYERS plan, we'll be able to do something like this:

[BODY_DETAIL_PLAN:VERTEBRATE_TISSUE_LAYERS:SKIN:FAT:MUSCLE:BONE:CARTILAGE]

ARG1 in the detail plan is replaced by SKIN, the first tissue we entered. ARG2 is replaced by FAT, ARG3 by muscle, ARG4 by bone, and ARG5 by CARTILAGE. Hence, our creature's bodypart designated as BODY is made up of SKIN with thickness 1, FAT with thickness 5, and MUSCLE with thickness 50. Its nose is made up of SKIN (thickness 1) and CARTILAGE (thickness 4).

Things left out of the body plans aside, our dwarf's entire body, material, tissue and tissue layer tokens have been boiled down to this:

...
[BODY:HUMANOID:2EYES:2EARS:NOSE:2LUNGS:HEART:GUTS:ORGANS:HUMANOID_JOINTS:
THROAT:NECK:SPINE:BRAIN:SKULL:5FINGERS:5TOES:MOUTH:FACIAL_FEATURES:TEETH:RIBCAGE]
[BODY_DETAIL_PLAN:STANDARD_MATERIALS]
[BODY_DETAIL_PLAN:STANDARD_TISSUES]
[BODY_DETAIL_PLAN:VERTEBRATE_TISSUE_LAYERS:SKIN:FAT:MUSCLE:BONE:CARTILAGE]
...

This can save you a lot of time and space if you're making lots of changes common to many creatures. In general, if you're making a creature that's fleshy or chitinous, there's detail plans already included in the game to help you out. You should only have to resort to declaring tissues individually (like our bronze colossus) if you're doing something really out-of-the-ordinary.

Another great thing about templates (and so, detail plans) is that they can be modified after being declared. Let's say we wanted our dwarves to be perpetually on fire (don't ask). We declare the body stuff normally:

...
[BODY:HUMANOID:2EYES:2EARS:NOSE:2LUNGS:HEART:GUTS:ORGANS:HUMANOID_JOINTS:
THROAT:NECK:SPINE:BRAIN:SKULL:5FINGERS:5TOES:MOUTH:FACIAL_FEATURES:TEETH:RIBCAGE]
[BODY_DETAIL_PLAN:STANDARD_MATERIALS]
[BODY_DETAIL_PLAN:STANDARD_TISSUES]
[BODY_DETAIL_PLAN:VERTEBRATE_TISSUE_LAYERS:SKIN:FAT:MUSCLE:BONE:CARTILAGE]
...

We then select the appropriate material:

...
[BODY:HUMANOID:2EYES:2EARS:NOSE:2LUNGS:HEART:GUTS:ORGANS:HUMANOID_JOINTS:
THROAT:NECK:SPINE:BRAIN:SKULL:5FINGERS:5TOES:MOUTH:FACIAL_FEATURES:TEETH:RIBCAGE]
[BODY_DETAIL_PLAN:STANDARD_MATERIALS]
[BODY_DETAIL_PLAN:STANDARD_TISSUES]
[BODY_DETAIL_PLAN:VERTEBRATE_TISSUE_LAYERS:SKIN:FAT:MUSCLE:BONE:CARTILAGE]
[SELECT_MATERIAL:SKIN]
[MAT_FIXED_TEMP:10600]
...

We don't want them burning to death, so we'll need to stop that from happening:

...
[BODY:HUMANOID:2EYES:2EARS:NOSE:2LUNGS:HEART:GUTS:ORGANS:HUMANOID_JOINTS:
THROAT:NECK:SPINE:BRAIN:SKULL:5FINGERS:5TOES:MOUTH:FACIAL_FEATURES:TEETH:RIBCAGE]
[BODY_DETAIL_PLAN:STANDARD_MATERIALS]
[BODY_DETAIL_PLAN:STANDARD_TISSUES]
[BODY_DETAIL_PLAN:VERTEBRATE_TISSUE_LAYERS:SKIN:FAT:MUSCLE:BONE:CARTILAGE]
[SELECT_MATERIAL:SKIN]
[MAT_FIXED_TEMP:10600]
[SELECT_MATERIAL:ALL]
[HEATDAM_POINT:NONE]
...

Note that this makes use of DF's built-in temperature scale. You can read more about that [[Temperature|on this page]]. We're also referencing material tokens, which we haven't gone over yet - we'll talk about making your own materials later.

=== Creature castes ===

Another potentially extremely powerful part of the creature raws is the caste system. The caste system handles both true biological castes and lesser variations, such as sexes.

To understand the true potential of the caste system, we only need to take a look at the raws for antmen, found in creature_subterrenean.txt:

...
[CASTE:WORKER]
[CASTE_NAME:worker ant woman:worker ant women:worker ant woman]
Female, but non-breeding.
[POP_RATIO:10000]
[CASTE:SOLDIER]
[CASTE_NAME:soldier ant woman:soldier ant women:soldier ant woman]
Female, but non-breeding.
[POP_RATIO:1000]
[CASTE:DRONE]
[MALE]
[CASTE_NAME:drone ant man:drone ant men:drone ant man]
[POP_RATIO:5]
[CASTE:QUEEN]
[FEMALE]
[CASTE_NAME:queen ant woman:queen ant women:queen ant woman]
[POP_RATIO:1]
[SELECT_CASTE:WORKER]
[SELECT_ADDITIONAL_CASTE:SOLDIER]
[SELECT_ADDITIONAL_CASTE:QUEEN]
[BODY:HUMANOID_4ARMS:2EYES:HEART:GUTS:BRAIN:MOUTH]
[BODYGLOSS:INSECT_UPPERBODY:INSECT_LOWERBODY]
[SELECT_CASTE:DRONE]
[BODY:HUMANOID_4ARMS:2EYES:HEART:GUTS:BRAIN:MOUTH:2WINGS]
[BODYGLOSS:INSECT_UPPERBODY:INSECT_LOWERBODY]
[FLIER]
[SELECT_CASTE:ALL]
[BODY_DETAIL_PLAN:CHITIN_MATERIALS]
[BODY_DETAIL_PLAN:CHITIN_TISSUES]
[BODY_DETAIL_PLAN:EXOSKELETON_TISSUE_LAYERS:CHITIN:FAT:MUSCLE]
[BODY_DETAIL_PLAN:STANDARD_HEAD_POSITIONS]
[ATTACK:PUNCH:BODYPART:BY_TYPE:GRASP]
[ATTACK_SKILL:GRASP_STRIKE]
[ATTACK_VERB:punch:punches]
...

It's evident that the process of creating and editing castes is comparable to the modifications we were making to tissues and materials earlier: A caste is declared, and modifications to the base creature are made. Declared castes can be selected and subsequently modified, again, just like tissues and materials.

In this case, each caste is declared, given its own name, and a POP_RATIO, which determines how commonly a birth results in that caste - for every 10000 workers born, there'll be an average of 1000 soldiers, 5 drones and one queen. You've probably also noticed that the DRONE and QUEEN castes have the MALE and FEMALE tokens respectively - these tokens determine how breeding works. A creature without both a MALE caste and a FEMALE caste will be unable to breed (no asexual creatures yet, unfortunately). As they lack FEMALE, the workers and soldiers are unable to breed with the male drones.

After this, there are some modifications to bodyparts. In this case, the drones have wings and the FLIER token, which the other castes lack. It's entirely possible for creatures of different castes to have completely different body stuctures, even to the extent that they don't resemble each other at all. If you read the section of this guide that dealt with entities, you may remember a passing mention of multi-creature civilisations and how they don't quite work as you may think they would. The castes system is your workaround. You could create a caste that is, for all intents and purposes, a human, and another caste of the same creature that acts exactly like a giant cave spider, put the creature in a civ, and get a human-spider civ. The only flaw in this approach is that the castes will interbreed.

That's the most complex components of creature creation out of the way. You should find the rest trivial by comparison.

== Modding items ==

Items are fairly simple to deal with. By default, each item type is contained in its own file; this may help make browsing for a specific item easier, but from a purely technical point of view, it's possible to throw all items into one file. Unfortunately, item tokens don't seem to be especially well-documented (at least not as well as the other object types), but you should be able to figure out most things by way of our explanations and your assumptions.

Let's look at the entry for, of course, the thong:

[ITEM_PANTS:ITEM_PANTS_THONG]
[NAME:thong:thongs]
[LAYER:UNDER]
[COVERAGE:25]
[LAYER_SIZE:10]
[LAYER_PERMIT:30]
[MATERIAL_SIZE:1]
[SOFT]
[LEATHER]
[STRUCTURAL_ELASTICITY_WOVEN_THREAD]

Most of these are pretty obvious if one compares them to the other entries in the file. There's a layer for the item, determining where it's worn; a coverage value to determine how well it protects you from cold and other things; a size token to determine how much it counts for when it's under something else; a layer permit token to determine how much can be worn under it; and a material size token to determine how much raw material it takes to make it.

Now, if you wanted to mod these to turn them into metal thongs (ouch!), you would simply have to add [METAL] to it somewhere. Simple! These tokens work by tying into material properties - some materials are designated as suitable for making hard items, some for soft, etc..

Weapons involve a little more detail:

[ITEM_WEAPON:ITEM_WEAPON_SWORD_2H]
[NAME:two-handed sword:two-handed swords]
[SIZE:900]
[SKILL:SWORD]
[TWO_HANDED:67500]
[MINIMUM_SIZE:62500]
[MATERIAL_SIZE:5]
[ATTACK:EDGE:100000:8000:slash:slashes:NO_SUB:1250]
[ATTACK:EDGE:50:4000:stab:stabs:NO_SUB:1000]
[ATTACK:BLUNT:100000:8000:slap:slaps:flat:1250]
[ATTACK:BLUNT:100:1000:strike:strikes:pommel:1000]

SIZE determines how heavy the weapon is. This has a substantial effect on weapon effectiveness. SKILL determines which skill is used in using the weapon; a list of skills can be found [[skill token|on this page]]. MINIMUM_SIZE determines the minimum size a creature must be before the weapon can be wielded, while TWO_HANDED determines how large a creature must be in order to wield the weapon with one hand.

Attacks take a little more explanation. The first value determines the contact area of the weapon's attack; this should be high for slashing weapons and low for bludgeoning, piercing and poking ones. The second value determines how deep the weapon penetrates - for BLUNT attacks this value is ignored as they're not supposed to penetrate anyway, but in the case of EDGE attacks it should generally be lower for slashing attacks and higher for stabbing attacks.

Following these are the nouns and verb used; they should be self-explanatory. Finally, we have the velocity modifier, which has a multiplying effect on the weapon's size for the purposes of determining how powerful it is in combat.

Other, more miscellaneous items are generally simple and shouldn't require any further explanation.

Once you've made an item, you just add it to the civ entry so a civilization can actually craft it, and it's done.

== Modding language files ==

Let's say you added a whole new species. Sure, you could just swipe one of the existing translation files and steal their language for your species, but that's the lazy way! If you want to create a whole new language, it's very simple.

First, you'd need a whole new language_RACE file, such as language_LIZARDMAN.txt, along with "language_LIZARDMAN" at the top of the file proceeded by [OBJECT:LANGUAGE] and [TRANSLATION:LIZARDMAN]. After that, it's just a matter of copy-pasting one of the existing language lists and editing the finished 'translated' word. That's it! Then just add the translation link to your civ in entity_default.txt and it'll be added to the game on worldgen.

(Note that the name of the file doesn't actually matter; however, it's good form to name the file after a creature if only that creature speaks the language)

== Modding body parts ==

Imagine you have this fantastic idea for a multi-tentacled winged spider-monster. Sounds great! But in order to make this a reality you may need to create a new set of body parts for it. That's no problem! Making body parts is easy, though it may look complicated at first.

All of the default body definitions are located in body_default.txt and then linked to a creature in the creature's entry. We've talked about how bodyparts make up creatures earlier, in the creature section. You can mix and match them in the creature entry and it makes no difference, as long as they're there: each bodypart will link itself to the appropriate connection automatically when the creature is first created.

Body parts work by sections: you can add as many sections as you want to a bodypart definition, but generally you should keep it fairly low for ease of use. Each body section entry is in the, very simple, format:

[BODY:BODYNAME]
[BP:TOKENID:name][TOKENSGOHERE][DEFAULT_RELSIZE:][CATEGORY:WHATEVER]

The most important tokens are "CONTYPE" and "CON": CONTYPE means the bodypart in question is connected to a certain ''type'' of bodypart, while CON means it's connected to a ''specific'' one. TOKENID is yet another identifier, which should be unique, as it's referenced every time something uses CON or BY_TOKEN. DEFAULT_RELSIZE defines, of course, what the bodypart's size is in relation to the other parts. CATEGORY defines a category for the part, which can be unique or shared with other parts. This is referenced whenever BY_CATEGORY is used.

A list of bodypart tokens can be found [[body token|here]].

Let's take a simple example, a head:

[BODY:BASIC_HEAD]
[BP:HD:head:STP][CONTYPE:UPPERBODY][HEAD][CATEGORY:HEAD]
[DEFAULT_RELSIZE:300]

It connects directly to an upper body.

[BODY:2EYES]
[BP:REYE:right eye:STP][CONTYPE:HEAD][SIGHT][EMBEDDED][SMALL][RIGHT][CATEGORY:EYE]
[DEFAULT_RELSIZE:5]
[BP:LEYE:left eye:STP][CONTYPE:HEAD][SIGHT][EMBEDDED][SMALL][LEFT][CATEGORY:EYE]
[DEFAULT_RELSIZE:5]

These are a pair of eyes, connecting to the head.

[BODY:HUMANOID]
[BP:UB:upper body:upper bodies][UPPERBODY][CATEGORY:BODY_UPPER]
[DEFAULT_RELSIZE:1000]
[BP:LB:lower body:lower bodies][CON:UB][LOWERBODY][CATEGORY:BODY_LOWER]
[DEFAULT_RELSIZE:1000]
[BP:HD:head:STP][CON:UB][HEAD][CATEGORY:HEAD]
[DEFAULT_RELSIZE:300]
[BP:RUA:right upper arm:STP][CON:UB][LIMB][RIGHT][CATEGORY:ARM_UPPER]
[DEFAULT_RELSIZE:200]
[BP:LUA:left upper arm:STP][CON:UB][LIMB][LEFT][CATEGORY:ARM_UPPER]
[DEFAULT_RELSIZE:200]
[BP:RLA:right lower arm:STP][CON:RUA][LIMB][RIGHT][CATEGORY:ARM_LOWER]
[DEFAULT_RELSIZE:200]
[BP:LLA:left lower arm:STP][CON:LUA][LIMB][LEFT][CATEGORY:ARM_LOWER]
[DEFAULT_RELSIZE:200]
[BP:RH:right hand:STP][CON:RLA][GRASP][RIGHT][CATEGORY:HAND]
[DEFAULT_RELSIZE:80]
[BP:LH:left hand:STP][CON:LLA][GRASP][LEFT][CATEGORY:HAND]
[DEFAULT_RELSIZE:80]
[BP:RUL:right upper leg:STP][CON:LB][LIMB][RIGHT][CATEGORY:LEG_UPPER]
[DEFAULT_RELSIZE:500]
[BP:LUL:left upper leg:STP][CON:LB][LIMB][LEFT][CATEGORY:LEG_UPPER]
[DEFAULT_RELSIZE:500]
[BP:RLL:right lower leg:STP][CON:RUL][LIMB][RIGHT][CATEGORY:LEG_LOWER]
[DEFAULT_RELSIZE:400]
[BP:LLL:left lower leg:STP][CON:LUL][LIMB][LEFT][CATEGORY:LEG_LOWER]
[DEFAULT_RELSIZE:400]
[BP:RF:right foot:right feet][CON:RLL][STANCE][RIGHT][CATEGORY:FOOT]
[DEFAULT_RELSIZE:120]
[BP:LF:left foot:left feet][CON:LLL][STANCE][LEFT][CATEGORY:FOOT]
[DEFAULT_RELSIZE:120]

An entire humanoid body. The foot bone's connected to the ankle bone...

"BODYGLOSS" entries, which you can sometimes find applied to creature entries, are simply replacement words for specific part name strings in a creature. For example, you'll find the bodygloss [BODYGLOSS:CLAW_HAND:hand:claw] in body_default.txt; you can then use this in a creature via "[BODYGLOSS:CLAW_HAND]" and it'll replace all instances of "hand" with "claw" in that creature. Be warned, however—if you were to, say make a bodygloss [BODYGLOSS:EARSTALK:ear:stalk:ears:stalk], it would not only change "ear" and "ears" to "stalk" and "stalks", it would also change "h'''ear'''t" to "h'''stalk'''t"! For all intents and purposes the body part will still function as the proper part, though.

== Modding plants ==

Plants are, again, not unlike creatures. With what you've learned so far in regard to tokens and the materials system, running through the notes included in plant_standard.txt should explain most things. [[Plant token|Here's the list of plant-specific tokens]].

Below is the [[plump helmet]] raw description:

[PLANT:MUSHROOM_HELMET_PLUMP]
[NAME:plump helmet][NAME_PLURAL:plump helmets][ADJ:plump helmet]
[USE_MATERIAL_TEMPLATE:STRUCTURAL:STRUCTURAL_PLANT_TEMPLATE]
[MATERIAL_VALUE:2]
[BASIC_MAT:LOCAL_PLANT_MAT:STRUCTURAL]
[EDIBLE_VERMIN]
[EDIBLE_RAW]
[EDIBLE_COOKED]
[PICKED_TILE:161][PICKED_COLOR:6:13:0]
[GROWDUR:300][VALUE:2]
[USE_MATERIAL_TEMPLATE:DRINK:PLANT_ALCOHOL_TEMPLATE]
[STATE_NAME_ADJ:ALL_SOLID:frozen dwarven wine]
[STATE_NAME_ADJ:LIQUID:dwarven wine]
[STATE_NAME_ADJ:GAS:boiling dwarven wine]
[MATERIAL_VALUE:2]
[DISPLAY_COLOR:5:0:0]
[EDIBLE_RAW]
[EDIBLE_COOKED]
[PREFIX:NONE]
[DRINK:LOCAL_PLANT_MAT:DRINK]

[USE_MATERIAL_TEMPLATE:SEED:SEED_TEMPLATE]
[MATERIAL_VALUE:1]
[EDIBLE_VERMIN]
[EDIBLE_COOKED]
[SEED:plump helmet spawn:plump helmet spawn:4:0:1:LOCAL_PLANT_MAT:SEED]
[SPRING][SUMMER][AUTUMN][WINTER]
[FREQUENCY:100]
[CLUSTERSIZE:5]
[PREFSTRING:rounded tops]
[WET][DRY]
[BIOME:SUBTERRANEAN_WATER]
[UNDERGROUND_DEPTH:1:3]
[SHRUB_TILE:142]
[DEAD_SHRUB_TILE:28]
[SHRUB_COLOR:5:13:0]
[DEAD_SHRUB_COLOR:5:6:0]

Let's look at this line by line: 
First, we define its file name. In this case it's MUSHROOM_HELMET_PLUMP. Next we define its in-game name (plump helmet) and its adjective for if you were to craft with it (e.g. plump helmet earrings).

[USE_MATERIAL_TEMPLATE:STRUCTURAL:STRUCTURAL_PLANT_TEMPLATE]
[MATERIAL_VALUE:2]
[BASIC_MAT:LOCAL_PLANT_MAT:STRUCTURAL]

This defines the structure and material of the plant. It references STRUCTURAL_PLANT_TEMPLATE in the first line, so if you were to say, add wings to the template, the plump helmet plant would be winged. This is for the plant itself, not the end plump helmets.

After that we get our edible tokens. These say that vermin can eat the plant, and it can be eaten raw or cooked by your dwarves. So if you wanted a plant vermin would leave alone, you'd remove the [EDIBLE_VERMIN] token.

[EDIBLE_VERMIN]
[EDIBLE_RAW]
[EDIBLE_COOKED]

Next, [PICKED_TILE:161] is the character (161 in this case) shown when the crop is harvested. See [[Main:Character table|character table]] for a table of usable tiles. [PICKED_COLOR:6:13:0] is the color used for the crop's tile when harvested. It's in a foreground:background:brightness format. See [[color]] for the colors usable.

[PICKED_TILE:161][PICKED_COLOR:6:13:0]

[GROWDUR:300] is how long it takes for your crop to grow. There are 1008 growdur units in a season. 
[VALUE:2] Is the value of harvested plant (default 1). Appears to have no effect in version 0.31.

[GROWDUR:300][VALUE:2]

This defines the plant's alcohol states. [STATE_NAME_ADJ:ALL_SOLID:] is the frozen name, followed is the actual drink name, and then its boiling name. These are achieved by either Scorching or Freezing climates. [DISPLAY_COLOR] is, of course, color, and [EDIBLE_RAW] and [EDIBLE_COOKED] are saying you can drink the alcohol raw or cooked.

[USE_MATERIAL_TEMPLATE:DRINK:PLANT_ALCOHOL_TEMPLATE]
[STATE_NAME_ADJ:ALL_SOLID:frozen dwarven wine]
[STATE_NAME_ADJ:LIQUID:dwarven wine]
[STATE_NAME_ADJ:GAS:boiling dwarven wine]
[MATERIAL_VALUE:2]
[DISPLAY_COLOR:5:0:0]
[EDIBLE_RAW]
[EDIBLE_COOKED]
[PREFIX:NONE]
[DRINK:LOCAL_PLANT_MAT:DRINK]

After that we get our seed template:

[USE_MATERIAL_TEMPLATE:SEED:SEED_TEMPLATE]
[MATERIAL_VALUE:1]
[EDIBLE_VERMIN]
[EDIBLE_COOKED]
[SEED:plump helmet spawn:plump helmet spawn:4:0:1:LOCAL_PLANT_MAT:SEED]

And all this says is that the seeds may be eaten by vermin or cooked. Then it gives the name of our plant's seed, its plural name, its foreground, background, and brightness colors, followed by its seed material; said material should have [SEED_MAT] to permit proper stockpiling.

And finally for the last chunk we have this:

[SPRING][SUMMER][AUTUMN][WINTER]
[FREQUENCY:100]
[CLUSTERSIZE:5]
[PREFSTRING:rounded tops]
[WET][DRY]
[BIOME:SUBTERRANEAN_WATER]
[UNDERGROUND_DEPTH:1:3]
[SHRUB_TILE:142]
[DEAD_SHRUB_TILE:28]
[SHRUB_COLOR:5:13:0]
[DEAD_SHRUB_COLOR:5:6:0]

First we define what season(s) the plant may grow in, then we define how frequently this plant is generated in a particular area, followed by how many harvested crop items may come from 1 plant. [PREFSTRING:] is what your dwarves like about the plant, which in this case is the rounded tops. [WET][DRY] are the conditions under which the plant can grow. Wet means it can grow close to water, dry means it can grow away from water. This does not mean you can grow the plant on dry stone however. It is just for natural spawning of the plant. 
[BIOME] Is what biome the plant grows in. [UNDERGROUND_DEPTH:Minimum:Maximum] Is the highest and lowest cavern levels that the plant can appear in if its biome is subterranean. Dwarven civilizations will only export (via the embark screen or caravans) things that available at depth 1. Defaults to 0:0 (surface only). 
Lastly, [SHRUB_TILE] is the character used for the naturally spawning shrub of this plant, [DEAD_SHRUB] is the dead shrub character. [SHRUB_COLOR] Is the shrub's color, and [DEAD_SHRUB_COLOR] is, of course, the dead shrub's color.

While this may or may not look like a lot of tokens, it's very easy. Just copy an existing plant and edit it to your new plant. 
For the rest of the tokens, see [[plant token]].

== Workshops ==

Workshops are raw-designed pretty differently from everything else in the game, being buildable structures rather than items or methods to gain items. However, they are fairly simple. For example, here's the raw for the [[soap maker's workshop]]:

[BUILDING_WORKSHOP:SOAP_MAKER]
[NAME:Soap Maker's Workshop]
[NAME_COLOR:7:0:1]
[DIM:3:3]
[WORK_LOCATION:2:2]
[BUILD_LABOR:SOAP_MAKER]
[BUILD_KEY:CUSTOM_SHIFT_S]
[BLOCK:1:0:0:1]
[BLOCK:2:0:0:1]
[BLOCK:3:0:0:0]
[TILE:0:1:' ':' ':150]
[TILE:0:2:' ':' ':'/']
[TILE:0:3:'-':' ':' ']
[COLOR:0:1:0:0:0:0:0:0:6:0:0]
[COLOR:0:2:0:0:0:0:0:0:6:0:0]
[COLOR:0:3:6:0:0:0:0:0:0:0:0]
[TILE:1:1:' ':' ':'=']
[TILE:1:2:'-':' ':8]
[TILE:1:3:' ':' ':150]
[COLOR:1:1:0:0:0:0:0:0:6:0:0]
[COLOR:1:2:6:0:0:0:0:0:6:0:0]
[COLOR:1:3:0:0:0:0:0:0:6:0:0]
[TILE:2:1:'-':' ':8]
[TILE:2:2:' ':' ':8]
[TILE:2:3:' ':150:' ']
[COLOR:2:1:6:0:0:0:0:0:6:0:0]
[COLOR:2:2:0:0:0:0:0:0:6:0:0]
[COLOR:2:3:0:0:0:6:0:0:0:0:0]
[TILE:3:1:150:' ':8]
[TILE:3:2:' ':' ':8]
[TILE:3:3:' ':240:' ']
[COLOR:3:1:6:0:0:0:0:0:6:7:0]
[COLOR:3:2:0:0:0:0:0:0:6:7:0]
[COLOR:3:3:0:0:0:7:0:1:0:0:0]
[BUILD_ITEM:1:BUCKET:NONE:NONE:NONE][EMPTY][CAN_USE_ARTIFACT]
[BUILD_ITEM:1:NONE:NONE:NONE:NONE][BUILDMAT][WORTHLESS_STONE_ONLY][CAN_USE_ARTIFACT]

A line-by-line breakdown:

[NAME:Soap Maker's Workshop]
[NAME_COLOR:7:0:1]

These are the name of the workshop ("Soap Maker's Workshop") and [[color]] of the workshop's name when examined with 'q' (White with a black background).

[DIM:3:3]
[WORK_LOCATION:2:2]

DIM refers to how large the workshop will be, in this case 3 wide, 3 tall. WORK_LOCATION tells where the creature using it (usually a dwarf) will work, numbered from the top right--in this case, 2:2, or the middle. Multiple work locations can be defined, even outside the dim.

[BUILD_LABOR:SOAP_MAKER]
[BUILD_KEY:CUSTOM_SHIFT_S]

These refer to the worker required to build it (soap maker) and the key used to build it in the workshop menu (capital S).

[BLOCK:1:0:0:1]
...
This is a bit more complex, and is where we get to the meaty part of workshop making--the tiles' properties. BLOCK refers to which tiles will be untraversable--1 means blocked, 0 means unblocked. The first number refers to row, and the next 3 refer to column, so 1:0:0:1 means that, on the first row, the first two tiles will be unblocked and the last will be blocked.

[TILE:0:1:' ':' ':150]
...
The TILE token tells which tile will go where. note, however, that there are 5 entries here instead of 4. The first number, in this case, refers to build stage, numbered from 0 to 3; 3 or 1 is fully built (depending on whether there are stages), 0 is just placed, and 2 is always an intermediate stage, while 1 is usually an intermediate stage. Whether 1 is an intermediate stage or not depends on if there are a 2 and 3 stage; if 2 and 3 exist, 1 will be intermediate. The second number and beyond are similar to BLOCK; however, instead of 1s and 0s, you must input tiles. The tiles themselves can be given in quotes (as in ' ') or given as a number, which can be looked up [[Tilesets|here]]. Here, we have 150, which is û.

[COLOR:1:1:0:0:0:0:0:0:6:0:0]
...
Color is as TILE, but with colors instead of tiles; however, colors are made up of 3 numbers each or MAT. MAT refers to the color of the material used to make it; the 3 numbers refer to foreground:background:foreground brightness, and can be looked up [[Color|here]]. For example, 4:2:1 will give you bright red with a dark green background.

[BUILD_ITEM:1:BUCKET:NONE:NONE:NONE][EMPTY][CAN_USE_ARTIFACT]
[BUILD_ITEM:1:NONE:NONE:NONE:NONE][BUILDMAT][WORTHLESS_STONE_ONLY][CAN_USE_ARTIFACT]
These refer to items required to build the building. These are in the same format as [[Reaction|reaction reagents and products]]--quantity:[[Item token|item]]:[[Material token|material]]. You'll learn more about those on the article about [[Reaction|reactions]], though. The second BUILD_ITEM is special-- it uses modifiers exclusively to determine its requirements. BUILDMAT refers to wood logs, wood blocks, stone boulders, and stone blocks; WORTHLESS_STONE_ONLY means it can't use economic stone; CAN_USE_ARTIFACT means that it... can use artifacts. EMPTY, in the bucket's case, means that the bucket must be empty.

More can be seen at the [[Building token|building tokens]] article.

== Reactions ==

An in-depth guide for reactions is available [[Reactions|here]].

== Materials ==

As we've seen when talking about creatures, materials are vital. Materials show up in two forms: material templates, which generally show up in creatures, and specific materials (designated as "inorganic"), which are (by default, at least) consigned purely to metal and stone types.

Let's take a look at METAL_TEMPLATE in material_template_default.txt. It's evident that most of the basic properties of metals are already defined in the template - it goes red and melts at a high enough temperature, it's heavy, and (as noted by the very bottom token) is a metal. We already know just how useful templates can be to creatures, and the same applies to other materials.

Now let's take a look at inorganic_metal.txt. You can see that the metals here refer to the templates, and, just like we did with creatures, then modify the properties of that template and expand upon it.

Finally, let's look at inorganic_stone_mineral.txt. Here we can see that in addition to the changes made to the template, there are also ENVIRONMENT tokens - these tell the game where to place these minerals during worldgen.

[[material definition token|Here's a list of material tokens]]. It should also help you out with any modifications you want to make regarding those creature modifications we were making a while back. See, it all ties together in the end. The beauty of the current materials system is that there's actually very little difference between, say, leather and iron - they're fundamentally the same thing, just with different properties, which is how things really should be.

== Examples ==

The Hydling by Mysteryguye (annotated, updated and separated into blocks by Putnam)

[CREATURE:HYDLING]
[DESCRIPTION:A seven-headed small hairy thing, about the size of a dog. It is very loyal to its masters, and will promptly disembowel any enemy straying too close.]
This is the description that shows up in-game when viewing the creature.

[NAME:hydling:hydlings:hydlish] If there were a civ made of hydlings, it would appear as "hydlings" in the neighbors screen.

[CASTE_NAME:hydling:hydlings:hydlish]

[CREATURE_TILE:'='][COLOR:2:0:1] Will appear as a light green "=".

[PETVALUE:78][NATURAL] Creature is known to be naturally occurring by the game. Will cost 40 embark points to buy.

[LARGE_ROAMING] Will spawn outdoors, wandering around.

[COMMON_DOMESTIC][TRAINABLE][PET] Can be bought on embark as a pet, war animal, or hunting animal.

[BONECARN] Can eat meat and bones only--no vegetables.

[PREFSTRING:loyalty] Dwarves will like it for its loyalty.

[LIKES_FIGHTING] Will attack rather than flee.

[BODY:BASIC_2PARTBODY:7HEADNECKS:BASIC_FRONTLEGS:BASIC_REARLEGS:TAIL:2EYES:NOSE:2LUNGS:HEART:GUTS:ORGANS:THROAT:SPINE:BRAIN:SKULL:3TOES_FQ_REG:3TOES_RQ_REG:MOUTH:TONGUE:GENERIC_TEETH_WITH_FANGS:RIBCAGE]

Has a lower body, upper body, 4 legs, a tail, ten eyes, ten ears, five noses, two lungs, a heart, guts, a pancreas etc., and 5 heads with all that goes with those.

[BODYGLOSS:PAW] Feet will be called "paws"

[BODY_DETAIL_PLAN:STANDARD_MATERIALS] Declares the standard materials that most creatures' tissues are made of.

[BODY_DETAIL_PLAN:STANDARD_TISSUES] This declares the tissues that the creature's tissue layers are made of.

[BODY_DETAIL_PLAN:VERTEBRATE_TISSUE_LAYERS:SKIN:FAT:MUSCLE:BONE:CARTILAGE] And this describes the tissue layers that the creature is made of.

[BODY_DETAIL_PLAN:BODY_HAIR_TISSUE_LAYERS:HAIR] Creature will be covered with a layer of fur.

[USE_MATERIAL_TEMPLATE:NAIL:NAIL_TEMPLATE] And it'll have nails.

[USE_TISSUE_TEMPLATE:NAIL:NAIL_TEMPLATE]

[TISSUE_LAYER:BY_CATEGORY:TOE:NAIL:FRONT] On the toe, specifically.

[SELECT_TISSUE_LAYER:HEART:BY_CATEGORY:HEART]
[PLUS_TISSUE_LAYER:SKIN:BY_CATEGORY:THROAT]
[TL_MAJOR_ARTERIES] Heart and throat--called above--will cause heavy bleeding if ruptured.

[BODY_DETAIL_PLAN:STANDARD_HEAD_POSITIONS] Places eyes, ears and what have you into their correct placement, so that you don't have people punching out eyes from behind.

[BODY_DETAIL_PLAN:HUMANOID_RIBCAGE_POSITIONS] Sets the ribcage as being around lungs and heart.

[USE_MATERIAL_TEMPLATE:SINEW:SINEW_TEMPLATE] Defines sinew so that...
[TENDONS:LOCAL_CREATURE_MAT:SINEW:200] Tendons
[LIGAMENTS:LOCAL_CREATURE_MAT:SINEW:200] And ligaments can be defined.

[HAS_NERVES] Creature has nerves, and as such can be disabled by severing them.

[USE_MATERIAL_TEMPLATE:BLOOD:BLOOD_TEMPLATE] Defines the material BLOOD using the template BLOOD_TEMPLATE.
[BLOOD:LOCAL_CREATURE_MAT:BLOOD:LIQUID] Defines the creature's BLOOD as being made of the above-defined BLOOD material in a LIQUID state.

[CREATURE_CLASS:GENERAL_POISON] Creature can be affected by syndromes that affect GENERAL_POISON.

[GETS_WOUND_INFECTIONS] Pretty much self-explanatory. Creature can get infected from wounds.
[GETS_INFECTIONS_FROM_ROT] And from necrosis.

[USE_MATERIAL_TEMPLATE:PUS:PUS_TEMPLATE] Defines PUS using PUS_TEMPLATE.
[PUS:LOCAL_CREATURE_MAT:PUS:LIQUID] Defines PUS as being made of PUS.

[BODY_SIZE:0:0:1000] Creature will be 1000 cubic centimeters at birth...
[BODY_SIZE:1:0:12500] 12500 cubic centimeters at 1 year old...
[BODY_SIZE:2:0:30000] and 30000 cubic centimeters at 2.

[BODY_APPEARANCE_MODIFIER:LENGTH:90:95:98:100:102:105:110] Creature can be anywhere from 90% to 110% as long as others.
[BODY_APPEARANCE_MODIFIER:HEIGHT:90:95:98:100:102:105:110] As above, but with height.
[BODY_APPEARANCE_MODIFIER:BROADNESS:90:95:98:100:102:105:110] As above, but with broadness. This puts the minimum size of the creature (when fully grown) at 21870 and the maximum size at 39930.

[MAXAGE:20:30] Creature will die of old age between the ages of 20 and 30, no later than 30, no sooner than 20.

[CAN_DO_INTERACTION:MATERIAL_EMISSION] Creature can use the MATERIAL_EMISSION interaction.
[CDI:ADV_NAME:Hurl fireball] In adventurer mode, the MATERIAL_EMISSION interaction will appear as "Hurl fireball".
[CDI:USAGE_HINT:ATTACK] Creature will use MATERIAL_EMISSION when it's attacking, on creatures that it's attacking.
[CDI:BP_REQUIRED:BY_CATEGORY:HEAD] Creature must have at least one HEAD to use MATERIAL_EMISSION.
[CDI:FLOW:FIREBALL] The MATERIAL_EMISSION will shoot a fireball.
[CDI:TARGET:C:LINE_OF_SIGHT] The target for the emission--a location--must be within the line of sight of the Hydling.
[CDI:TARGET_RANGE:C:15] And must be, at most, 15 tiles away.
[CDI:MAX_TARGET_NUMBER:C:1] The hydling can only shoot at one target at a time...
[CDI:WAIT_PERIOD:30] and only every 30 ticks (3 tenths of a second at 100 FPS)

[ATTACK:BITE:CHILD_BODYPART_GROUP:BY_CATEGORY:HEAD:BY_CATEGORY:TOOTH] Defines a BITE attack that uses teeth.
[ATTACK_SKILL:BITE] Attack uses the BITE skill.
[ATTACK_VERB:nom:noms] "The Hydling noms the Elf in the left first toe, tearing the muscle!"
[ATTACK_CONTACT_PERC:100] Will use all of the tooth. Note that this can be more than 100.
[ATTACK_PENETRATION_PERC:100] Will sink the tooth all the way in. This can also be more than 100.
[ATTACK_FLAG_EDGE] Attack is an EDGE attack.
[ATTACK_PRIORITY:MAIN] Attack is of priority MAIN. Other option is SECOND.
[ATTACK_FLAG_CANLATCH] Attack can latch.
[ATTACK_PREPARE_AND_RECOVER:3:3] Takes 3 ticks to wind up attack and 3 to recover from it.
[ATTACK_FLAG_INDEPENDENT_MULTIATTACK] Can use each head independently.

[ATTACK:SCRATCH:CHILD_TISSUE_LAYER_GROUP:BY_TYPE:STANCE:BY_CATEGORY:ALL:NAIL] As above, but for nail instead of teeth.
[ATTACK_SKILL:STANCE_STRIKE] Uses the kicking skill.
[ATTACK_VERB:slice:slices] "You slice the Elf in the left foot and the severed part sails off in an arc!"
[ATTACK_CONTACT_PERC:100] Uses the whole nail.
[ATTACK_PENETRATION_PERC:100] The whole nail goes in.
[ATTACK_FLAG_EDGE] Attack is an edge attack.
[ATTACK_PREPARE_AND_RECOVER:3:3]
[ATTACK_PRIORITY:SECOND]

[CHILD:1] Hydling will become an adult at 1 year old.

[GENERAL_CHILD_NAME:hydie:hydies] Children will appear as "hydies".

[DIURNAL] Is active during the daytime.

[HOMEOTHERM:10070] Has a body temperature of 102 Fahrenheit.

[APPLY_CREATURE_VARIATION:STANDARD_QUADRUPED_GAITS:900:730:561:351:1900:2900] Can run at 25 kph
[APPLY_CREATURE_VARIATION:STANDARD_SWIMMING_GAITS:3512:2634:1756:878:4900:6900] Can swim at 10 kph
[APPLY_CREATURE_VARIATION:STANDARD_CRAWLING_GAITS:6561:6115:5683:1755:7456:8567] Can crawl at 5 kph
[SWIMS_INNATE]Swims innately.

[CASTE:FEMALE] Defines a caste called FEMALE.
[FEMALE] FEMALE caste is female.

[CASTE:MALE] As above, but with male.
[MALE] See above.

= Modding utilities =

[http://www.bay12forums.com/smf/index.php?topic=28829.0 A list of many mods and community-developed utilities]

{{Category|Modding}}
[[Category:v0.31:Guides]]

Modding

2016-03-01T10:33:34Z

Chinchou: Colons are full-stops, not half-stops.

{{Quality|Exceptional|14:13, 7 November 2013 (UTC)}}
{{av}}
This is intended to be a guide to inform those new to DF modding on what elements of the game can be modified, and how. After reading through this guide, a user should be capable of editing creatures, entities, materials ''et al'', and creating their own.

Generally, breaking stuff is fine - nothing that can be changed will affect the DF executable, and new additions can be easily removed.

This guide is based on [[40d:Modding guide|Teldin's guide]], originally created for version 0.27.176.39c. Per wiki tradition, it has been updated through all the major releases since then; hopefully it reflects current knowledge.

'''See also:''' [[:Category:DF2014:Modding]]

= Modding Guide =

== Token Reference ==

It's always good to refer to tokens on the wiki. Even experienced modders have to look up tokens! A list of articles about tokens can be found [http://dwarffortresswiki.org/index.php/Token here.]

== Basics of DF modding ==

All the base data that can be edited by prospective modders can be found in the \raw\ folder. This folder contains two subfolders: "graphics" (where you insert [[Graphics set repository|graphics sets]]), and "objects", which contains all the data for generally everything in the game that is not hardcoded.

Within the \raw\objects folder are a large number of text files - these are the [[raw file|raw files]], and editing them is quite easy - you can also create your own if you wish. For now, take a look at one of the existing files. For example if you open creature_standard.txt it should look something like this:

creature_standard

[OBJECT:CREATURE]

[CREATURE:DWARF]
[DESCRIPTION:A short, sturdy creature fond of drink and industry.]
[NAME:dwarf:dwarves:dwarven]
[CASTE_NAME:dwarf:dwarves:dwarven]
[CREATURE_TILE:1][COLOR:3:0:0]
[CREATURE_SOLDIER_TILE:2]
...

As you can see, each file comprises a header string stating the file name, a second header stating the type of object data it contains, followed by the contents of the file itself. These are all necessary elements of the file, and without them, the file won't be parsed correctly by the game. You may have also noticed the file naming scheme - this is also important; files containing creatures have names starting with "creature_", entity file names must begin with "entity_", etc..

Below the headers, there begins a list of entries. Each entry is made up of its own header (in this case, "[CREATURE:DWARF]"), again stating the type of object, and then the object's unique identifier - if an identifier isn't unique, the game will mess up and you'll get some serious, and potentially very trippy, errors. Below that, we have the body of the entry, which determines the entry's specific properties.

The body of an entry is made up of a series of "tokens", which are essentially flags that can be added or removed to affect the entry's attributes. Most of these effects are hardcoded: for example, it's possible to make a creature only eat meat with the [CARNIVOROUS] token, but it's impossible to create your own token detailing a specific diet for the creature.

Before we continue, a few key things to remember when modding the raw files:

* Try to avoid modifying the existing raw files when adding objects. It makes removing mods far easier.
* When adding files, all you need to include to ensure proper references are maintained is the token identifier's. The game will load up all *.txt in the raw folder, and searches through them by tokens. For example: You can add a new pair of leather boots and not even have to add it to the item_shoes.txt file, but rather make your own file, say item_shoes_new.txt and ensure you have the token listed, ex. [ITEM_SHOES:ITEM_SHOES_BOOTS_NEW], that's how the game will look for the item.
* If you want to edit an already-existing creature, always back up the files you plan on editing to a different location. Since v0.31.22, the game no longer loads backup files, but duplicate entries are still a very bad thing.
* When a new world is generated, all the raw files get copied into a \raw\ folder within the applicable save folder. If you want to change something within a world that's already been generated, you'll have to edit those files, not the ones in ~DF\raw\objects.
* There's nothing stopping you from just copying an existing creature/entity/whatever, changing the identifier, and modifying it. This can save you a lot of time, especially when it comes to entities... which are coincidentally what we'll be talking about next.

== Modding civilizations (entities) ==

Entities - the objects that determine how civilizations work - are stored in entity_default.txt (though, like all other files, you may add more). They follow the same format as any other raw file:

entity_default

[OBJECT:ENTITY]

[ENTITY:ENTITYNAME]
[CREATURE:CREATURETYPE]
[TRANSLATION:LANGUAGETYPE]
[BIOME_SUPPORT:BIOMETOKEN:FREQENCY]
...[OTHER TAGS]...

Most of the time, it doesn't matter which order these tokens are in or where they're placed so long as they're below the "ENTITY:" identifier, but there are some important exceptions in the case of other files, especially creatures, which can contain a lot of "nested" tokens.

"[CREATURE:]" links the civilization with a specific creature defined in a creature file. This is the creature that'll be making up the entity's population, and will therefore be the creature you'll be playing as in fortress or adventure mode if the entity is a playable one. For example, if you wanted to do something silly, you could switch the "CREATURE:DWARF" entry in entity_default.txt with "CREATURE:ELF" and you would be marching elves around in fortress mode, although they would still use dwarven technology and language and names and so forth.

Oh, and before you get any funny ideas - it ''is'' possible to define more than one creature for a civ, but that won't work in quite the way you probably expect; later on, in the creature section, you'll learn about castes, which will provide a much more viable alternative, so try to bear with us until then.

"[TRANSLATION:]" defines the language file that the entity will be using, which will determine what their untranslated words are for things. This doesn't determine which words they use for naming things, only the way those words are spelled. The default language files are HUMAN, DWARF, ELF, and GOBLIN.

"[BIOME_SUPPORT:]" defines the biomes that civs will attempt to settle in. The "FREQUENCY" value determines the likelihood of them building there, but also raises an important point: most of the values you'll be setting for things are relative to each other. If one was to type:

[BIOME_SUPPORT:ANY_FOREST:1]
[BIOME_SUPPORT:SAVANNA:2]

This would have very much the same effect as:

[BIOME_SUPPORT:ANY_FOREST:5]
[BIOME_SUPPORT:SAVANNA:10]

This holds true for a lot of values throughout the files, excluding when it simply doesn't make sense, such as in materials.

You can find many details about the rest of the civilization tokens [[entity token|here]]. Besides those mentioned, some fundamental ones are the CIV_CONTROLLABLE token, which lets you control the civ in fortress mode, the INDIV_CONTROLLABLE token, which allows you to play the civ in adventure mode as an outsider, and the ADVENTURE_TIER token, which allows you to play a civ native (non-outsider) in adventure mode. Other tokens that you should pay attention to are START_BIOME and the ones regarding sites, but in general, you can just run through the aforementioned list and add or remove what you want.

If you have more than one civ with the CIV_CONTROLLABLE token, all the available civs from those entities will appear in the group selection section on the embark screen. It may not be immediately obvious from which species each civ may be - while this can be determined from legends mode, the topmost species in the "neighbors" display in the embark screen is always the same as the currently selected species; if your group is dwarven, dwarves will be topmost, whilst (say) elves will be topmost if your chosen group is elven. By default, the game seems to choose a civ (and therefore a species if there is more than one) at random.

You can also attempt to discern the civ yourself by the names it uses - this is the realm of "symbols", collections of words centered around a specific concept. The civ will use the words comprising whatever symbols are applicable to it for various things. This association might be a little obfuscating at first, so I'll run through it. Let's refer to the DWARF entity:

[SELECT_SYMBOL:WAR:NAME_WAR]
[SUBSELECT_SYMBOL:WAR:VIOLENT]
[SELECT_SYMBOL:BATTLE:NAME_BATTLE]
[SUBSELECT_SYMBOL:BATTLE:VIOLENT]
[SELECT_SYMBOL:SIEGE:NAME_SIEGE]
[SUBSELECT_SYMBOL:SIEGE:VIOLENT]

Here we can see that dwarves will generally name their wars first after words in the "NAME_WAR" symbol group, and then after words in the "VIOLENT" symbol group. This might, for example, result in a war being named "The War of Carnage". The symbols used for the other types of conflict are arrayed in a similar fashion. It would be trivial to replace the instances of VIOLENT with, say, PEACE and end up with a battle called "The Clash of Calm" or something.

[SELECT_SYMBOL:ROAD:NAME_ROAD]
[SELECT_SYMBOL:TUNNEL:NAME_TUNNEL]
[SELECT_SYMBOL:BRIDGE:NAME_BRIDGE]
[SELECT_SYMBOL:WALL:NAME_WALL]

The above applies here. Dwarves are fond of naming their roads and tunnels after roads and tunnels.

[SELECT_SYMBOL:REMAINING:ARTIFICE]
[SELECT_SYMBOL:REMAINING:EARTH]
[CULL_SYMBOL:ALL:DOMESTIC]
[CULL_SYMBOL:ALL:SUBORDINATE]
[CULL_SYMBOL:ALL:EVIL]
[CULL_SYMBOL:ALL:UNTOWARD]
[CULL_SYMBOL:ALL:FLOWERY]
[CULL_SYMBOL:ALL:NEGATIVE]
[CULL_SYMBOL:ALL:UGLY]
[CULL_SYMBOL:ALL:NEGATOR]

This section deals with everything else. The things that haven't already been dealt with (hence the "REMAINING") - such as site names, kingdom names, the names of individuals, and such - will have names from the ARTIFICE and EARTH symbol groups. After that the dwarf entity is told to cull all innapropriate symbols - this applies to everything (hence the "ALL") so if the game happens to choose a symbol associated with, say, EVIL for one of the battles, it'll scrap that name and try again. This sort of thing adds a lot of flavour to DF's entities and can account for a lot of a civ's perceived personality.

Another basic thing to note: any entity token that's dealing with weapons, armor, clothing, etc., will state the items that the civ can build natively, not necessarily the ones they can wear or use. For example, you could create a species with no clothes specified, but then rob a clothes shop in adventurer mode and wear everything you want, or give them weapons that are too large to wield and they could sell them, but not use them.

An easy method of creating a civilization is just to copy-paste a similar one to the bottom of the entity_default.txt file and edit things to your liking. Remember to always change the civ's "ENTITY:" identifier! This can be anything so long as it's not already existing.

At the end of some of the default entries you'll find a list of positions, both ones that'll directly affect you in fort mode (such as nobles) and ones that'll primarily affect worldgen and adventure mode. A list of the tokens applicable to positions can be found [[position token|here]]; they don't require a great deal of explanation.

== Modding the creatures ==

Creature modding is great fun. You can change nearly any aspect of a creature or make your own completely from scratch.

Modding creatures is very similar to modding civs: it's just a matter of editing, adding, or removing tokens, enclosed in square brackets underneath the creature's [CREATURE:] header. The creature entries contain all of the information about each and every non-random creature in the game, from animals to dwarves to goblins to even caravan wagons. A lot of the creature tokens are fairly self-explanatory; you can find a list of such tokens [[creature token|here]]. But before you start creating your own creatures, you'll want to learn how the tissues system works.

=== Creature materials and tissues ===

In the most basic sense, a creature is a series of bodyparts. These parts are defined in their own file, and we'll talk about them later. As a specific aspect of how creatures work which throws off a lot of prospective modders is the relationship between bodyparts, tissues, and materials. We're going to show you part of the creature entry for a bronze colossus (bear with us):

...
[BODY:HUMANOID:2EYES:2EARS:NOSE:HUMANOID_JOINTS:5FINGERS:5TOES]
[NO_THOUGHT_CENTER_FOR_MOVEMENT]
[TISSUE:BRONZE]
[TISSUE_NAME:bronze:bronze]
[TISSUE_MATERIAL:INORGANIC:BRONZE]
[MUSCULAR]
[FUNCTIONAL]
[STRUCTURAL]
[RELATIVE_THICKNESS:1]
[CONNECTS]
[TISSUE_SHAPE:LAYER]
[TISSUE_LAYER:BY_CATEGORY:ALL:BRONZE]
...

At the top, we can see the "BODY:" token, followed by a list of bodyparts. As you've probably guessed, these parts make up the physical form of the colossus. But the colossus has to be made out of something - it has to have tissues. And those tissues also have to be made out of something - in this case, bronze.

Below the BODY token you'll see a TISSUE token, followed by an identifier, much like the others we've seen. The TISSUE block is determining how the tissue works, and which purposes it'll serve. As the colossus is just going to be made out of this one tissue, this tissue needs to act like bone, muscle, and everything else combined, hence the MUSCULAR, FUNCTIONAL and STRUCTURAL tokens. The tissue also references a material - INORGANIC:BRONZE - the properties of which are declared in the inorganic materials file, and the tissue is subsequently made out of this material. With us so far?

Below the tissue definition is the TISSUE_LAYER line. TISSUE_LAYER allows you to control where each tissue is applied. Its first argument defines if it's to search by bodypart category (BY_CATEGORY), bodypart type (BY_TYPE), or look for a specific part (BY_TOKEN). That's followed by the parts argument itself, which is in this case ALL (so the game's looking for parts in all categories, which is to say, every bodypart). This is followed by the tissue to be applied, BRONZE. So the TISSUE_LAYER token is telling the game to select all bodyparts in every category and make them out of the tissue "BRONZE". The colossus is now made of bronze.

By now you're probably thinking "Wow, if this was for a creature made out of however many tissues, this would be amazingly longwinded". And you're right. Luckily, there are two methods by which we can speed things up a lot.

Firstly, there are material and tissue templates. Let's say you were going to make a lot of creatures out of bronze, and you didn't want to have to copy and paste the bronze tissue all over the place. Instead, you create a tissue template. This goes, as you've probably guessed, in a tissue template file.

[TISSUE_TEMPLATE:BRONZE_TEMPLATE]
[TISSUE_NAME:bronze:bronze]
[TISSUE_MATERIAL:INORGANIC:BRONZE]
[MUSCULAR]
[FUNCTIONAL]
[STRUCTURAL]
[RELATIVE_THICKNESS:1]
[CONNECTS]
[TISSUE_SHAPE:LAYER]

Now, instead of applying the tissue to each and every bronze creature you're making, you can just refer to the template:

...
[BODY:HUMANOID:2EYES:2EARS:NOSE:HUMANOID_JOINTS:5FINGERS:5TOES]
[NO_THOUGHT_CENTER_FOR_MOVEMENT]
[USE_TISSUE_TEMPLATE:BRONZE:BRONZE_TEMPLATE]
[TISSUE_LAYER:BY_CATEGORY:ALL:BRONZE]
...

Material templates work in the same way, but refer to materials instead of tissues.

However, if we're looking at something like a dwarf, even with the templates, editing can get very slow indeed:

...
[USE_MATERIAL_TEMPLATE:SKIN:SKIN_TEMPLATE]
[USE_MATERIAL_TEMPLATE:FAT:FAT_TEMPLATE]
[USE_MATERIAL_TEMPLATE:MUSCLE:MUSCLE_TEMPLATE]
[USE_MATERIAL_TEMPLATE:BONE:BONE_TEMPLATE]
[USE_MATERIAL_TEMPLATE:CARTILAGE:CARTILAGE_TEMPLATE]
[USE_MATERIAL_TEMPLATE:HAIR:HAIR_TEMPLATE]
[USE_MATERIAL_TEMPLATE:TOOTH:TOOTH_TEMPLATE]
[USE_MATERIAL_TEMPLATE:EYE:EYE_TEMPLATE]
[USE_MATERIAL_TEMPLATE:NERVE:NERVE_TEMPLATE]
[USE_MATERIAL_TEMPLATE:BRAIN:BRAIN_TEMPLATE]
[USE_MATERIAL_TEMPLATE:LUNG:LUNG_TEMPLATE]
[USE_MATERIAL_TEMPLATE:HEART:HEART_TEMPLATE]
[USE_MATERIAL_TEMPLATE:LIVER:LIVER_TEMPLATE]
[USE_MATERIAL_TEMPLATE:GUT:GUT_TEMPLATE]
[USE_MATERIAL_TEMPLATE:STOMACH:STOMACH_TEMPLATE]
[USE_MATERIAL_TEMPLATE:PANCREAS:PANCREAS_TEMPLATE]
[USE_MATERIAL_TEMPLATE:SPLEEN:SPLEEN_TEMPLATE]
[USE_MATERIAL_TEMPLATE:KIDNEY:KIDNEY_TEMPLATE]
[USE_TISSUE_TEMPLATE:SKIN:SKIN_TEMPLATE]
[USE_TISSUE_TEMPLATE:FAT:FAT_TEMPLATE]
[USE_TISSUE_TEMPLATE:MUSCLE:MUSCLE_TEMPLATE]
...

This is where body detail plans come in. Detail plans, of course, have their own file, and they are designed to help automate some of the more common processes in creature creation. The first entry in b_detail_plan_default.txt does exactly what we've been trying to do above: it takes all the common materials and shoves them into one plan, which can be referenced with a single token.

...
[BODY_DETAIL_PLAN:STANDARD_MATERIALS]
...

Much easier. But what about the TISSUE_LAYER tokens? Will we have to type out all of those manually?

Nope, detail plans have that covered as well. It's possible to place variable arguments into a detail plan. For example:

[BODY_DETAIL_PLAN:VERTEBRATE_TISSUE_LAYERS]
[BP_LAYERS:BY_CATEGORY:BODY:ARG3:50:ARG2:5:ARG1:1]
[BP_LAYERS:BY_CATEGORY:BODY_UPPER:ARG3:50:ARG2:5:ARG1:1]
[BP_LAYERS:BY_CATEGORY:BODY_LOWER:ARG3:50:ARG2:5:ARG1:1]
[BP_LAYERS:BY_CATEGORY:ARM:ARG4:25:ARG3:25:ARG2:5:ARG1:1]
[BP_LAYERS:BY_CATEGORY:ARM_UPPER:ARG4:25:ARG3:25:ARG2:5:ARG1:1]
...
[BP_LAYERS:BY_CATEGORY:NOSE:ARG5:4:ARG1:1]
...

First an argument is placed in the plan (ARG1, ARG2 etc.), followed by the thickness of the tissue that will be inserted in place of the argument. So when we reference the VERTEBRATE_TISSUE_LAYERS plan, we'll be able to do something like this:

[BODY_DETAIL_PLAN:VERTEBRATE_TISSUE_LAYERS:SKIN:FAT:MUSCLE:BONE:CARTILAGE]

ARG1 in the detail plan is replaced by SKIN, the first tissue we entered. ARG2 is replaced by FAT, ARG3 by muscle, ARG4 by bone, and ARG5 by CARTILAGE. Hence, our creature's bodypart designated as BODY is made up of SKIN with thickness 1, FAT with thickness 5, and MUSCLE with thickness 50. Its nose is made up of SKIN (thickness 1) and CARTILAGE (thickness 4).

Things left out of the body plans aside, our dwarf's entire body, material, tissue and tissue layer tokens have been boiled down to this:

...
[BODY:HUMANOID:2EYES:2EARS:NOSE:2LUNGS:HEART:GUTS:ORGANS:HUMANOID_JOINTS:
THROAT:NECK:SPINE:BRAIN:SKULL:5FINGERS:5TOES:MOUTH:FACIAL_FEATURES:TEETH:RIBCAGE]
[BODY_DETAIL_PLAN:STANDARD_MATERIALS]
[BODY_DETAIL_PLAN:STANDARD_TISSUES]
[BODY_DETAIL_PLAN:VERTEBRATE_TISSUE_LAYERS:SKIN:FAT:MUSCLE:BONE:CARTILAGE]
...

This can save you a lot of time and space if you're making lots of changes common to many creatures. In general, if you're making a creature that's fleshy or chitinous, there's detail plans already included in the game to help you out. You should only have to resort to declaring tissues individually (like our bronze colossus) if you're doing something really out-of-the-ordinary.

Another great thing about templates (and so, detail plans) is that they can be modified after being declared. Let's say we wanted our dwarves to be perpetually on fire (don't ask). We declare the body stuff normally:

...
[BODY:HUMANOID:2EYES:2EARS:NOSE:2LUNGS:HEART:GUTS:ORGANS:HUMANOID_JOINTS:
THROAT:NECK:SPINE:BRAIN:SKULL:5FINGERS:5TOES:MOUTH:FACIAL_FEATURES:TEETH:RIBCAGE]
[BODY_DETAIL_PLAN:STANDARD_MATERIALS]
[BODY_DETAIL_PLAN:STANDARD_TISSUES]
[BODY_DETAIL_PLAN:VERTEBRATE_TISSUE_LAYERS:SKIN:FAT:MUSCLE:BONE:CARTILAGE]
...

We then select the appropriate material:

...
[BODY:HUMANOID:2EYES:2EARS:NOSE:2LUNGS:HEART:GUTS:ORGANS:HUMANOID_JOINTS:
THROAT:NECK:SPINE:BRAIN:SKULL:5FINGERS:5TOES:MOUTH:FACIAL_FEATURES:TEETH:RIBCAGE]
[BODY_DETAIL_PLAN:STANDARD_MATERIALS]
[BODY_DETAIL_PLAN:STANDARD_TISSUES]
[BODY_DETAIL_PLAN:VERTEBRATE_TISSUE_LAYERS:SKIN:FAT:MUSCLE:BONE:CARTILAGE]
[SELECT_MATERIAL:SKIN]
[MAT_FIXED_TEMP:10600]
...

We don't want them burning to death, so we'll need to stop that from happening:

...
[BODY:HUMANOID:2EYES:2EARS:NOSE:2LUNGS:HEART:GUTS:ORGANS:HUMANOID_JOINTS:
THROAT:NECK:SPINE:BRAIN:SKULL:5FINGERS:5TOES:MOUTH:FACIAL_FEATURES:TEETH:RIBCAGE]
[BODY_DETAIL_PLAN:STANDARD_MATERIALS]
[BODY_DETAIL_PLAN:STANDARD_TISSUES]
[BODY_DETAIL_PLAN:VERTEBRATE_TISSUE_LAYERS:SKIN:FAT:MUSCLE:BONE:CARTILAGE]
[SELECT_MATERIAL:SKIN]
[MAT_FIXED_TEMP:10600]
[SELECT_MATERIAL:ALL]
[HEATDAM_POINT:NONE]
...

Note that this makes use of DF's built-in temperature scale. You can read more about that [[Temperature|on this page]]. We're also referencing material tokens, which we haven't gone over yet - we'll talk about making your own materials later.

=== Creature castes ===

Another potentially extremely powerful part of the creature raws is the caste system. The caste system handles both true biological castes and lesser variations, such as sexes.

To understand the true potential of the caste system, we only need to take a look at the raws for antmen, found in creature_subterrenean.txt:

...
[CASTE:WORKER]
[CASTE_NAME:worker ant woman:worker ant women:worker ant woman]
Female, but non-breeding.
[POP_RATIO:10000]
[CASTE:SOLDIER]
[CASTE_NAME:soldier ant woman:soldier ant women:soldier ant woman]
Female, but non-breeding.
[POP_RATIO:1000]
[CASTE:DRONE]
[MALE]
[CASTE_NAME:drone ant man:drone ant men:drone ant man]
[POP_RATIO:5]
[CASTE:QUEEN]
[FEMALE]
[CASTE_NAME:queen ant woman:queen ant women:queen ant woman]
[POP_RATIO:1]
[SELECT_CASTE:WORKER]
[SELECT_ADDITIONAL_CASTE:SOLDIER]
[SELECT_ADDITIONAL_CASTE:QUEEN]
[BODY:HUMANOID_4ARMS:2EYES:HEART:GUTS:BRAIN:MOUTH]
[BODYGLOSS:INSECT_UPPERBODY:INSECT_LOWERBODY]
[SELECT_CASTE:DRONE]
[BODY:HUMANOID_4ARMS:2EYES:HEART:GUTS:BRAIN:MOUTH:2WINGS]
[BODYGLOSS:INSECT_UPPERBODY:INSECT_LOWERBODY]
[FLIER]
[SELECT_CASTE:ALL]
[BODY_DETAIL_PLAN:CHITIN_MATERIALS]
[BODY_DETAIL_PLAN:CHITIN_TISSUES]
[BODY_DETAIL_PLAN:EXOSKELETON_TISSUE_LAYERS:CHITIN:FAT:MUSCLE]
[BODY_DETAIL_PLAN:STANDARD_HEAD_POSITIONS]
[ATTACK:PUNCH:BODYPART:BY_TYPE:GRASP]
[ATTACK_SKILL:GRASP_STRIKE]
[ATTACK_VERB:punch:punches]
...

It's evident that the process of creating and editing castes is comparable to the modifications we were making to tissues and materials earlier: A caste is declared, and modifications to the base creature are made. Declared castes can be selected and subsequently modified, again, just like tissues and materials.

In this case, each caste is declared, given its own name, and a POP_RATIO, which determines how commonly a birth results in that caste - for every 10000 workers born, there'll be an average of 1000 soldiers, 5 drones and one queen. You've probably also noticed that the DRONE and QUEEN castes have the MALE and FEMALE tokens respectively - these tokens determine how breeding works. A creature without both a MALE caste and a FEMALE caste will be unable to breed (no asexual creatures yet, unfortunately). As they lack FEMALE, the workers and soldiers are unable to breed with the male drones.

After this, there are some modifications to bodyparts. In this case, the drones have wings and the FLIER token, which the other castes lack. It's entirely possible for creatures of different castes to have completely different body stuctures, even to the extent that they don't resemble each other at all. If you read the section of this guide that dealt with entities, you may remember a passing mention of multi-creature civilisations and how they don't quite work as you may think they would. The castes system is your workaround. You could create a caste that is, for all intents and purposes, a human, and another caste of the same creature that acts exactly like a giant cave spider, put the creature in a civ, and get a human-spider civ. The only flaw in this approach is that the castes will interbreed.

That's the most complex components of creature creation out of the way. You should find the rest trivial by comparison.

== Modding items ==

Items are fairly simple to deal with. By default, each item type is contained in its own file; this may help make browsing for a specific item easier, but from a purely technical point of view, it's possible to throw all items into one file. Unfortunately, item tokens don't seem to be especially well-documented (at least not as well as the other object types), but you should be able to figure out most things by way of our explanations and your assumptions.

Let's look at the entry for, of course, the thong:

[ITEM_PANTS:ITEM_PANTS_THONG]
[NAME:thong:thongs]
[LAYER:UNDER]
[COVERAGE:25]
[LAYER_SIZE:10]
[LAYER_PERMIT:30]
[MATERIAL_SIZE:1]
[SOFT]
[LEATHER]
[STRUCTURAL_ELASTICITY_WOVEN_THREAD]

Most of these are pretty obvious if one compares them to the other entries in the file. There's a layer for the item, determining where it's worn; a coverage value to determine how well it protects you from cold and other things; a size token to determine how much it counts for when it's under something else; a layer permit token to determine how much can be worn under it; and a material size token to determine how much raw material it takes to make it.

Now, if you wanted to mod these to turn them into metal thongs (ouch!), you would simply have to add [METAL] to it somewhere. Simple! These tokens work by tying into material properties - some materials are designated as suitable for making hard items, some for soft, etc..

Weapons involve a little more detail:

[ITEM_WEAPON:ITEM_WEAPON_SWORD_2H]
[NAME:two-handed sword:two-handed swords]
[SIZE:900]
[SKILL:SWORD]
[TWO_HANDED:67500]
[MINIMUM_SIZE:62500]
[MATERIAL_SIZE:5]
[ATTACK:EDGE:100000:8000:slash:slashes:NO_SUB:1250]
[ATTACK:EDGE:50:4000:stab:stabs:NO_SUB:1000]
[ATTACK:BLUNT:100000:8000:slap:slaps:flat:1250]
[ATTACK:BLUNT:100:1000:strike:strikes:pommel:1000]

SIZE determines how heavy the weapon is. This has a substantial effect on weapon effectiveness. SKILL determines which skill is used in using the weapon; a list of skills can be found [[skill token|on this page]]. MINIMUM_SIZE determines the minimum size a creature must be before the weapon can be wielded, while TWO_HANDED determines how large a creature must be in order to wield the weapon with one hand.

Attacks take a little more explanation. The first value determines the contact area of the weapon's attack; this should be high for slashing weapons and low for bludgeoning, piercing and poking ones. The second value determines how deep the weapon penetrates - for BLUNT attacks this value is ignored as they're not supposed to penetrate anyway, but in the case of EDGE attacks it should generally be lower for slashing attacks and higher for stabbing attacks.

Following these are the nouns and verb used; they should be self-explanatory. Finally, we have the velocity modifier, which has a multiplying effect on the weapon's size for the purposes of determining how powerful it is in combat.

Other, more miscellaneous items are generally simple and shouldn't require any further explanation.

Once you've made an item, you just add it to the civ entry so a civilization can actually craft it, and it's done.

== Modding language files ==

Let's say you added a whole new species. Sure, you could just swipe one of the existing translation files and steal their language for your species, but that's the lazy way! If you want to create a whole new language, it's very simple.

First, you'd need a whole new language_RACE file, such as language_LIZARDMAN.txt, along with "language_LIZARDMAN" at the top of the file proceeded by [OBJECT:LANGUAGE] and [TRANSLATION:LIZARDMAN]. After that, it's just a matter of copy-pasting one of the existing language lists and editing the finished 'translated' word. That's it! Then just add the translation link to your civ in entity_default.txt and it'll be added to the game on worldgen.

(Note that the name of the file doesn't actually matter; however, it's good form to name the file after a creature if only that creature speaks the language)

== Modding body parts ==

Imagine you have this fantastic idea for a multi-tentacled winged spider-monster. Sounds great! But in order to make this a reality you may need to create a new set of body parts for it. That's no problem! Making body parts is easy, though it may look complicated at first.

All of the default body definitions are located in body_default.txt and then linked to a creature in the creature's entry. We've talked about how bodyparts make up creatures earlier, in the creature section. You can mix and match them in the creature entry and it makes no difference, as long as they're there: each bodypart will link itself to the appropriate connection automatically when the creature is first created.

Body parts work by sections: you can add as many sections as you want to a bodypart definition, but generally you should keep it fairly low for ease of use. Each body section entry is in the, very simple, format:

[BODY:BODYNAME]
[BP:TOKENID:name][TOKENSGOHERE][DEFAULT_RELSIZE:][CATEGORY:WHATEVER]

The most important tokens are "CONTYPE" and "CON": CONTYPE means the bodypart in question is connected to a certain ''type'' of bodypart, while CON means it's connected to a ''specific'' one. TOKENID is yet another identifier, which should be unique, as it's referenced every time something uses CON or BY_TOKEN. DEFAULT_RELSIZE defines, of course, what the bodypart's size is in relation to the other parts. CATEGORY defines a category for the part, which can be unique or shared with other parts. This is referenced whenever BY_CATEGORY is used.

A list of bodypart tokens can be found [[body token|here]].

Let's take a simple example, a head:

[BODY:BASIC_HEAD]
[BP:HD:head:STP][CONTYPE:UPPERBODY][HEAD][CATEGORY:HEAD]
[DEFAULT_RELSIZE:300]

It connects directly to an upper body.

[BODY:2EYES]
[BP:REYE:right eye:STP][CONTYPE:HEAD][SIGHT][EMBEDDED][SMALL][RIGHT][CATEGORY:EYE]
[DEFAULT_RELSIZE:5]
[BP:LEYE:left eye:STP][CONTYPE:HEAD][SIGHT][EMBEDDED][SMALL][LEFT][CATEGORY:EYE]
[DEFAULT_RELSIZE:5]

These are a pair of eyes, connecting to the head.

[BODY:HUMANOID]
[BP:UB:upper body:upper bodies][UPPERBODY][CATEGORY:BODY_UPPER]
[DEFAULT_RELSIZE:1000]
[BP:LB:lower body:lower bodies][CON:UB][LOWERBODY][CATEGORY:BODY_LOWER]
[DEFAULT_RELSIZE:1000]
[BP:HD:head:STP][CON:UB][HEAD][CATEGORY:HEAD]
[DEFAULT_RELSIZE:300]
[BP:RUA:right upper arm:STP][CON:UB][LIMB][RIGHT][CATEGORY:ARM_UPPER]
[DEFAULT_RELSIZE:200]
[BP:LUA:left upper arm:STP][CON:UB][LIMB][LEFT][CATEGORY:ARM_UPPER]
[DEFAULT_RELSIZE:200]
[BP:RLA:right lower arm:STP][CON:RUA][LIMB][RIGHT][CATEGORY:ARM_LOWER]
[DEFAULT_RELSIZE:200]
[BP:LLA:left lower arm:STP][CON:LUA][LIMB][LEFT][CATEGORY:ARM_LOWER]
[DEFAULT_RELSIZE:200]
[BP:RH:right hand:STP][CON:RLA][GRASP][RIGHT][CATEGORY:HAND]
[DEFAULT_RELSIZE:80]
[BP:LH:left hand:STP][CON:LLA][GRASP][LEFT][CATEGORY:HAND]
[DEFAULT_RELSIZE:80]
[BP:RUL:right upper leg:STP][CON:LB][LIMB][RIGHT][CATEGORY:LEG_UPPER]
[DEFAULT_RELSIZE:500]
[BP:LUL:left upper leg:STP][CON:LB][LIMB][LEFT][CATEGORY:LEG_UPPER]
[DEFAULT_RELSIZE:500]
[BP:RLL:right lower leg:STP][CON:RUL][LIMB][RIGHT][CATEGORY:LEG_LOWER]
[DEFAULT_RELSIZE:400]
[BP:LLL:left lower leg:STP][CON:LUL][LIMB][LEFT][CATEGORY:LEG_LOWER]
[DEFAULT_RELSIZE:400]
[BP:RF:right foot:right feet][CON:RLL][STANCE][RIGHT][CATEGORY:FOOT]
[DEFAULT_RELSIZE:120]
[BP:LF:left foot:left feet][CON:LLL][STANCE][LEFT][CATEGORY:FOOT]
[DEFAULT_RELSIZE:120]

An entire humanoid body. The foot bone's connected to the ankle bone...

"BODYGLOSS" entries, which you can sometimes find applied to creature entries, are simply replacement words for specific part name strings in a creature. For example, you'll find the bodygloss [BODYGLOSS:CLAW_HAND:hand:claw] in body_default.txt; you can then use this in a creature via "[BODYGLOSS:CLAW_HAND]" and it'll replace all instances of "hand" with "claw" in that creature. Be warned, however—if you were to, say make a bodygloss [BODYGLOSS:EARSTALK:ear:stalk:ears:stalk], it would not only change "ear" and "ears" to "stalk" and "stalks", it would also change "h'''ear'''t" to "h'''stalk'''t"! For all intents and purposes the body part will still function as the proper part, though.

== Modding plants ==

Plants are, again, not unlike creatures. With what you've learned so far in regard to tokens and the materials system, running through the notes included in plant_standard.txt should explain most things. [[Plant token|Here's the list of plant-specific tokens]].

Below is the [[plump helmet]] raw description:

[PLANT:MUSHROOM_HELMET_PLUMP]
[NAME:plump helmet][NAME_PLURAL:plump helmets][ADJ:plump helmet]
[USE_MATERIAL_TEMPLATE:STRUCTURAL:STRUCTURAL_PLANT_TEMPLATE]
[MATERIAL_VALUE:2]
[BASIC_MAT:LOCAL_PLANT_MAT:STRUCTURAL]
[EDIBLE_VERMIN]
[EDIBLE_RAW]
[EDIBLE_COOKED]
[PICKED_TILE:161][PICKED_COLOR:6:13:0]
[GROWDUR:300][VALUE:2]
[USE_MATERIAL_TEMPLATE:DRINK:PLANT_ALCOHOL_TEMPLATE]
[STATE_NAME_ADJ:ALL_SOLID:frozen dwarven wine]
[STATE_NAME_ADJ:LIQUID:dwarven wine]
[STATE_NAME_ADJ:GAS:boiling dwarven wine]
[MATERIAL_VALUE:2]
[DISPLAY_COLOR:5:0:0]
[EDIBLE_RAW]
[EDIBLE_COOKED]
[PREFIX:NONE]
[DRINK:LOCAL_PLANT_MAT:DRINK]

[USE_MATERIAL_TEMPLATE:SEED:SEED_TEMPLATE]
[MATERIAL_VALUE:1]
[EDIBLE_VERMIN]
[EDIBLE_COOKED]
[SEED:plump helmet spawn:plump helmet spawn:4:0:1:LOCAL_PLANT_MAT:SEED]
[SPRING][SUMMER][AUTUMN][WINTER]
[FREQUENCY:100]
[CLUSTERSIZE:5]
[PREFSTRING:rounded tops]
[WET][DRY]
[BIOME:SUBTERRANEAN_WATER]
[UNDERGROUND_DEPTH:1:3]
[SHRUB_TILE:142]
[DEAD_SHRUB_TILE:28]
[SHRUB_COLOR:5:13:0]
[DEAD_SHRUB_COLOR:5:6:0]

Let's look at this line by line: 
First, we define its file name. In this case it's MUSHROOM_HELMET_PLUMP. Next we define its in-game name (plump helmet) and its adjective for if you were to craft with it (e.g. plump helmet earrings).

[USE_MATERIAL_TEMPLATE:STRUCTURAL:STRUCTURAL_PLANT_TEMPLATE]
[MATERIAL_VALUE:2]
[BASIC_MAT:LOCAL_PLANT_MAT:STRUCTURAL]

This defines the structure and material of the plant. It references STRUCTURAL_PLANT_TEMPLATE in the first line, so if you were to say, add wings to the template, the plump helmet plant would be winged. This is for the plant itself, not the end plump helmets.

After that we get our edible tokens. These say that vermin can eat the plant, and it can be eaten raw or cooked by your dwarves. So if you wanted a plant vermin would leave alone, you'd remove the [EDIBLE_VERMIN] token.

[EDIBLE_VERMIN]
[EDIBLE_RAW]
[EDIBLE_COOKED]

Next, [PICKED_TILE:161] is the character (161 in this case) shown when the crop is harvested. See [[Main:Character table|character table]] for a table of usable tiles. [PICKED_COLOR:6:13:0] is the color used for the crop's tile when harvested. It's in a foreground:background:brightness format. See [[color]] for the colors usable.

[PICKED_TILE:161][PICKED_COLOR:6:13:0]

[GROWDUR:300] is how long it takes for your crop to grow. There are 1008 growdur units in a season. 
[VALUE:2] Is the value of harvested plant (default 1). Appears to have no effect in version 0.31.

[GROWDUR:300][VALUE:2]

This defines the plant's alcohol states. [STATE_NAME_ADJ:ALL_SOLID:] is the frozen name, followed is the actual drink name, and then its boiling name. These are achieved by either Scorching or Freezing climates. [DISPLAY_COLOR] is, of course, color, and [EDIBLE_RAW] and [EDIBLE_COOKED] are saying you can drink the alcohol raw or cooked.

[USE_MATERIAL_TEMPLATE:DRINK:PLANT_ALCOHOL_TEMPLATE]
[STATE_NAME_ADJ:ALL_SOLID:frozen dwarven wine]
[STATE_NAME_ADJ:LIQUID:dwarven wine]
[STATE_NAME_ADJ:GAS:boiling dwarven wine]
[MATERIAL_VALUE:2]
[DISPLAY_COLOR:5:0:0]
[EDIBLE_RAW]
[EDIBLE_COOKED]
[PREFIX:NONE]
[DRINK:LOCAL_PLANT_MAT:DRINK]

After that we get our seed template:

[USE_MATERIAL_TEMPLATE:SEED:SEED_TEMPLATE]
[MATERIAL_VALUE:1]
[EDIBLE_VERMIN]
[EDIBLE_COOKED]
[SEED:plump helmet spawn:plump helmet spawn:4:0:1:LOCAL_PLANT_MAT:SEED]

And all this says is that the seeds may be eaten by vermin or cooked. Then it gives the name of our plant's seed, its plural name, its foreground, background, and brightness colors, followed by its seed material; said material should have [SEED_MAT] to permit proper stockpiling.

And finally for the last chunk we have this:

[SPRING][SUMMER][AUTUMN][WINTER]
[FREQUENCY:100]
[CLUSTERSIZE:5]
[PREFSTRING:rounded tops]
[WET][DRY]
[BIOME:SUBTERRANEAN_WATER]
[UNDERGROUND_DEPTH:1:3]
[SHRUB_TILE:142]
[DEAD_SHRUB_TILE:28]
[SHRUB_COLOR:5:13:0]
[DEAD_SHRUB_COLOR:5:6:0]

First we define what season(s) the plant may grow in, then we define how frequently this plant is generated in a particular area, followed by how many harvested crop items may come from 1 plant. [PREFSTRING:] is what your dwarves like about the plant, which in this case is the rounded tops. [WET][DRY] are the conditions under which the plant can grow. Wet means it can grow close to water, dry means it can grow away from water. This does not mean you can grow the plant on dry stone however. It is just for natural spawning of the plant. 
[BIOME] Is what biome the plant grows in. [UNDERGROUND_DEPTH:Minimum:Maximum] Is the highest and lowest cavern levels that the plant can appear in if its biome is subterranean. Dwarven civilizations will only export (via the embark screen or caravans) things that available at depth 1. Defaults to 0:0 (surface only). 
Lastly, [SHRUB_TILE] is the character used for the naturally spawning shrub of this plant, [DEAD_SHRUB] is the dead shrub character. [SHRUB_COLOR] Is the shrub's color, and [DEAD_SHRUB_COLOR] is, of course, the dead shrub's color.

While this may or may not look like a lot of tokens, it's very easy. Just copy an existing plant and edit it to your new plant. 
For the rest of the tokens, see [[plant token]].

== Workshops ==

Workshops are raw-designed pretty differently from everything else in the game, being buildable structures rather than items or methods to gain items. However, they are fairly simple. For example, here's the raw for the [[soap maker's workshop]]:

[BUILDING_WORKSHOP:SOAP_MAKER]
[NAME:Soap Maker's Workshop]
[NAME_COLOR:7:0:1]
[DIM:3:3]
[WORK_LOCATION:2:2]
[BUILD_LABOR:SOAP_MAKER]
[BUILD_KEY:CUSTOM_SHIFT_S]
[BLOCK:1:0:0:1]
[BLOCK:2:0:0:1]
[BLOCK:3:0:0:0]
[TILE:0:1:' ':' ':150]
[TILE:0:2:' ':' ':'/']
[TILE:0:3:'-':' ':' ']
[COLOR:0:1:0:0:0:0:0:0:6:0:0]
[COLOR:0:2:0:0:0:0:0:0:6:0:0]
[COLOR:0:3:6:0:0:0:0:0:0:0:0]
[TILE:1:1:' ':' ':'=']
[TILE:1:2:'-':' ':8]
[TILE:1:3:' ':' ':150]
[COLOR:1:1:0:0:0:0:0:0:6:0:0]
[COLOR:1:2:6:0:0:0:0:0:6:0:0]
[COLOR:1:3:0:0:0:0:0:0:6:0:0]
[TILE:2:1:'-':' ':8]
[TILE:2:2:' ':' ':8]
[TILE:2:3:' ':150:' ']
[COLOR:2:1:6:0:0:0:0:0:6:0:0]
[COLOR:2:2:0:0:0:0:0:0:6:0:0]
[COLOR:2:3:0:0:0:6:0:0:0:0:0]
[TILE:3:1:150:' ':8]
[TILE:3:2:' ':' ':8]
[TILE:3:3:' ':240:' ']
[COLOR:3:1:6:0:0:0:0:0:6:7:0]
[COLOR:3:2:0:0:0:0:0:0:6:7:0]
[COLOR:3:3:0:0:0:7:0:1:0:0:0]
[BUILD_ITEM:1:BUCKET:NONE:NONE:NONE][EMPTY][CAN_USE_ARTIFACT]
[BUILD_ITEM:1:NONE:NONE:NONE:NONE][BUILDMAT][WORTHLESS_STONE_ONLY][CAN_USE_ARTIFACT]

A line-by-line breakdown:

[NAME:Soap Maker's Workshop]
[NAME_COLOR:7:0:1]

These are the name of the workshop ("Soap Maker's Workshop") and [[color]] of the workshop's name when examined with 'q' (White with a black background).

[DIM:3:3]
[WORK_LOCATION:2:2]

DIM refers to how large the workshop will be, in this case 3 wide, 3 tall. WORK_LOCATION tells where the creature using it (usually a dwarf) will work, numbered from the top right--in this case, 2:2, or the middle. Multiple work locations can be defined, even outside the dim.

[BUILD_LABOR:SOAP_MAKER]
[BUILD_KEY:CUSTOM_SHIFT_S]

These refer to the worker required to build it (soap maker) and the key used to build it in the workshop menu (capital S).

[BLOCK:1:0:0:1]
...
This is a bit more complex, and is where we get to the meaty part of workshop making--the tiles' properties. BLOCK refers to which tiles will be untraversable--1 means blocked, 0 means unblocked. The first number refers to row, and the next 3 refer to column, so 1:0:0:1 means that, on the first row, the first two tiles will be unblocked and the last will be blocked.

[TILE:0:1:' ':' ':150]
...
The TILE token tells which tile will go where. note, however, that there are 5 entries here instead of 4. The first number, in this case, refers to build stage, numbered from 0 to 3; 3 or 1 is fully built (depending on whether there are stages), 0 is just placed, and 2 is always an intermediate stage, while 1 is usually an intermediate stage. Whether 1 is an intermediate stage or not depends on if there are a 2 and 3 stage; if 2 and 3 exist, 1 will be intermediate. The second number and beyond are similar to BLOCK; however, instead of 1s and 0s, you must input tiles. The tiles themselves can be given in quotes (as in ' ') or given as a number, which can be looked up [[Tilesets|here]]. Here, we have 150, which is û.

[COLOR:1:1:0:0:0:0:0:0:6:0:0]
...
Color is as TILE, but with colors instead of tiles; however, colors are made up of 3 numbers each or MAT. MAT refers to the color of the material used to make it; the 3 numbers refer to foreground:background:foreground brightness, and can be looked up [[Color|here]]. For example, 4:2:1 will give you bright red with a dark green background.

[BUILD_ITEM:1:BUCKET:NONE:NONE:NONE][EMPTY][CAN_USE_ARTIFACT]
[BUILD_ITEM:1:NONE:NONE:NONE:NONE][BUILDMAT][WORTHLESS_STONE_ONLY][CAN_USE_ARTIFACT]
These refer to items required to build the building. These are in the same format as [[Reaction|reaction reagents and products]]--quantity:[[Item token|item]]:[[Material token|material]]. You'll learn more about those on the article about [[Reaction|reactions]], though. The second BUILD_ITEM is special-- it uses modifiers exclusively to determine its requirements. BUILDMAT refers to wood logs, wood blocks, stone boulders, and stone blocks; WORTHLESS_STONE_ONLY means it can't use economic stone; CAN_USE_ARTIFACT means that it... can use artifacts. EMPTY, in the bucket's case, means that the bucket must be empty.

More can be seen at the [[Building token|building tokens]] article.

== Reactions ==

An in-depth guide for reactions is available [[Reactions|here]].

== Materials ==

As we've seen when talking about creatures, materials are vital. Materials show up in two forms: material templates, which generally show up in creatures, and specific materials (designated as "inorganic"), which are (by default, at least) consigned purely to metal and stone types.

Let's take a look at METAL_TEMPLATE in material_template_default.txt. It's evident that most of the basic properties of metals are already defined in the template - it goes red and melts at a high enough temperature, it's heavy, and (as noted by the very bottom token) is a metal. We already know just how useful templates can be to creatures, and the same applies to other materials.

Now let's take a look at inorganic_metal.txt. You can see that the metals here refer to the templates, and, just like we did with creatures, then modify the properties of that template and expand upon it.

Finally, let's look at inorganic_stone_mineral.txt. Here we can see that in addition to the changes made to the template, there are also ENVIRONMENT tokens - these tell the game where to place these minerals during worldgen.

[[material definition token|Here's a list of material tokens]]. It should also help you out with any modifications you want to make regarding those creature modifications we were making a while back. See, it all ties together in the end. The beauty of the current materials system is that there's actually very little difference between, say, leather and iron - they're fundamentally the same thing, just with different properties, which is how things really should be.

== Examples ==

The Hydling by Mysteryguye (annotated, updated and separated into blocks by Putnam)

[CREATURE:HYDLING]
[DESCRIPTION:A seven-headed small hairy thing, about the size of a dog. It is very loyal to its masters, and will promptly disembowel any enemy straying too close.]
This is the description that shows up in-game when viewing the creature.

[NAME:hydling:hydlings:hydlish] If there were a civ made of hydlings, it would appear as "hydlings" in the neighbors screen.

[CASTE_NAME:hydling:hydlings:hydlish]

[CREATURE_TILE:'='][COLOR:2:0:1] Will appear as a light green "=".

[PETVALUE:78][NATURAL] Creature is known to be naturally occurring by the game. Will cost 40 embark points to buy.

[LARGE_ROAMING] Will spawn outdoors, wandering around.

[COMMON_DOMESTIC][TRAINABLE][PET] Can be bought on embark as a pet, war animal, or hunting animal.

[BONECARN] Can eat meat and bones only--no vegetables.

[PREFSTRING:loyalty] Dwarves will like it for its loyalty.

[LIKES_FIGHTING] Will attack rather than flee.

[BODY:BASIC_2PARTBODY:7HEADNECKS:BASIC_FRONTLEGS:BASIC_REARLEGS:TAIL:2EYES:NOSE:2LUNGS:HEART:GUTS:ORGANS:THROAT:SPINE:BRAIN:SKULL:3TOES_FQ_REG:3TOES_RQ_REG:MOUTH:TONGUE:GENERIC_TEETH_WITH_FANGS:RIBCAGE]

Has a lower body, upper body, 4 legs, a tail, ten eyes, ten ears, five noses, two lungs, a heart, guts, a pancreas etc., and 5 heads with all that goes with those.

[BODYGLOSS:PAW] Feet will be called "paws"

[BODY_DETAIL_PLAN:STANDARD_MATERIALS] Declares the standard materials that most creatures' tissues are made of.

[BODY_DETAIL_PLAN:STANDARD_TISSUES] This declares the tissues that the creature's tissue layers are made of.

[BODY_DETAIL_PLAN:VERTEBRATE_TISSUE_LAYERS:SKIN:FAT:MUSCLE:BONE:CARTILAGE] And this describes the tissue layers that the creature is made of.

[BODY_DETAIL_PLAN:BODY_HAIR_TISSUE_LAYERS:HAIR] Creature will be covered with a layer of fur.

[USE_MATERIAL_TEMPLATE:NAIL:NAIL_TEMPLATE] And it'll have nails.

[USE_TISSUE_TEMPLATE:NAIL:NAIL_TEMPLATE]

[TISSUE_LAYER:BY_CATEGORY:TOE:NAIL:FRONT] On the toe, specifically.

[SELECT_TISSUE_LAYER:HEART:BY_CATEGORY:HEART]
[PLUS_TISSUE_LAYER:SKIN:BY_CATEGORY:THROAT]
[TL_MAJOR_ARTERIES] Heart and throat--called above--will cause heavy bleeding if ruptured.

[BODY_DETAIL_PLAN:STANDARD_HEAD_POSITIONS] Places eyes, ears and what have you into their correct placement, so that you don't have people punching out eyes from behind.

[BODY_DETAIL_PLAN:HUMANOID_RIBCAGE_POSITIONS] Sets the ribcage as being around lungs and heart.

[USE_MATERIAL_TEMPLATE:SINEW:SINEW_TEMPLATE] Defines sinew so that...
[TENDONS:LOCAL_CREATURE_MAT:SINEW:200] Tendons
[LIGAMENTS:LOCAL_CREATURE_MAT:SINEW:200] And ligaments can be defined.

[HAS_NERVES] Creature has nerves, and as such can be disabled by severing them.

[USE_MATERIAL_TEMPLATE:BLOOD:BLOOD_TEMPLATE] Defines the material BLOOD using the template BLOOD_TEMPLATE.
[BLOOD:LOCAL_CREATURE_MAT:BLOOD:LIQUID] Defines the creature's BLOOD as being made of the above-defined BLOOD material in a LIQUID state.

[CREATURE_CLASS:GENERAL_POISON] Creature can be affected by syndromes that affect GENERAL_POISON.

[GETS_WOUND_INFECTIONS] Pretty much self-explanatory. Creature can get infected from wounds.
[GETS_INFECTIONS_FROM_ROT] And from necrosis.

[USE_MATERIAL_TEMPLATE:PUS:PUS_TEMPLATE] Defines PUS using PUS_TEMPLATE.
[PUS:LOCAL_CREATURE_MAT:PUS:LIQUID] Defines PUS as being made of PUS.

[BODY_SIZE:0:0:1000] Creature will be 1000 cubic centimeters at birth...
[BODY_SIZE:1:0:12500] 12500 cubic centimeters at 1 year old...
[BODY_SIZE:2:0:30000] and 30000 cubic centimeters at 2.

[BODY_APPEARANCE_MODIFIER:LENGTH:90:95:98:100:102:105:110] Creature can be anywhere from 90% to 110% as long as others.
[BODY_APPEARANCE_MODIFIER:HEIGHT:90:95:98:100:102:105:110] As above, but with height.
[BODY_APPEARANCE_MODIFIER:BROADNESS:90:95:98:100:102:105:110] As above, but with broadness. This puts the minimum size of the creature (when fully grown) at 21870 and the maximum size at 39930.

[MAXAGE:20:30] Creature will die of old age between the ages of 20 and 30, no later than 30, no sooner than 20.

[CAN_DO_INTERACTION:MATERIAL_EMISSION] Creature can use the MATERIAL_EMISSION interaction.
[CDI:ADV_NAME:Hurl fireball] In adventurer mode, the MATERIAL_EMISSION interaction will appear as "Hurl fireball".
[CDI:USAGE_HINT:ATTACK] Creature will use MATERIAL_EMISSION when it's attacking, on creatures that it's attacking.
[CDI:BP_REQUIRED:BY_CATEGORY:HEAD] Creature must have at least one HEAD to use MATERIAL_EMISSION.
[CDI:FLOW:FIREBALL] The MATERIAL_EMISSION will shoot a fireball.
[CDI:TARGET:C:LINE_OF_SIGHT] The target for the emission--a location--must be within the line of sight of the Hydling.
[CDI:TARGET_RANGE:C:15] And must be, at most, 15 tiles away.
[CDI:MAX_TARGET_NUMBER:C:1] The hydling can only shoot at one target at a time...
[CDI:WAIT_PERIOD:30] and only every 30 ticks (3 tenths of a second at 100 FPS)

[ATTACK:BITE:CHILD_BODYPART_GROUP:BY_CATEGORY:HEAD:BY_CATEGORY:TOOTH] Defines a BITE attack that uses teeth.
[ATTACK_SKILL:BITE] Attack uses the BITE skill.
[ATTACK_VERB:nom:noms] "The Hydling noms the Elf in the left first toe, tearing the muscle!"
[ATTACK_CONTACT_PERC:100] Will use all of the tooth. Note that this can be more than 100.
[ATTACK_PENETRATION_PERC:100] Will sink the tooth all the way in. This can also be more than 100.
[ATTACK_FLAG_EDGE] Attack is an EDGE attack.
[ATTACK_PRIORITY:MAIN] Attack is of priority MAIN. Other option is SECOND.
[ATTACK_FLAG_CANLATCH] Attack can latch.
[ATTACK_PREPARE_AND_RECOVER:3:3] Takes 3 ticks to wind up attack and 3 to recover from it.
[ATTACK_FLAG_INDEPENDENT_MULTIATTACK] Can use each head independently.

[ATTACK:SCRATCH:CHILD_TISSUE_LAYER_GROUP:BY_TYPE:STANCE:BY_CATEGORY:ALL:NAIL] As above, but for nail instead of teeth.
[ATTACK_SKILL:STANCE_STRIKE] Uses the kicking skill.
[ATTACK_VERB:slice:slices] "You slice the Elf in the left foot and the severed part sails off in an arc!"
[ATTACK_CONTACT_PERC:100] Uses the whole nail.
[ATTACK_PENETRATION_PERC:100] The whole nail goes in.
[ATTACK_FLAG_EDGE] Attack is an edge attack.
[ATTACK_PREPARE_AND_RECOVER:3:3]
[ATTACK_PRIORITY:SECOND]

[CHILD:1] Hydling will become an adult at 1 year old.

[GENERAL_CHILD_NAME:hydie:hydies] Children will appear as "hydies".

[DIURNAL] Is active during the daytime.

[HOMEOTHERM:10070] Has a body temperature of 102 Fahrenheit.

[APPLY_CREATURE_VARIATION:STANDARD_QUADRUPED_GAITS:900:730:561:351:1900:2900] Can run at 25 kph
[APPLY_CREATURE_VARIATION:STANDARD_SWIMMING_GAITS:3512:2634:1756:878:4900:6900] Can swim at 10 kph
[APPLY_CREATURE_VARIATION:STANDARD_CRAWLING_GAITS:6561:6115:5683:1755:7456:8567] Can crawl at 5 kph
[SWIMS_INNATE]Swims innately.

[CASTE:FEMALE] Defines a caste called FEMALE.
[FEMALE] FEMALE caste is female.

[CASTE:MALE] As above, but with male.
[MALE] See above.

= Modding utilities =

[http://www.bay12forums.com/smf/index.php?topic=28829.0 A list of many mods and community-developed utilities]

{{Category|Modding}}
[[Category:v0.31:Guides]]

Advanced world generation

2016-02-29T10:56:12Z

Chinchou: Punctuation/capitalisation corrections(commas and semicolons are not full stops, colons and periods are).

{{Quality|Exceptional|18:16, 23 August 2014 (UTC)}}
{{av}}
{{old}}

:''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.''
:''See [[World rejection]] for information on solving problems related to worlds always being rejected.''
:''See [[Worldgen examples]] for example worlds.''

When you want more control of what your world looks like, it's time for '''advanced world generation'''. A detailed reference with advice is provided below. This article assumes that you are already familiar with [[World generation|'''basic''' world generation]]. If you are not then please read about that first.

Once you select {{DFtext|Design New World With Advanced Parameters}} from the main menu, a screen that looks something like this will appear:

[[File:AdvancedWorldGen.png‎]]

This screen is relatively intuitive but some parts could use some explanation.

== Parameter sets ==

The list of already defined parameter sets is in the upper right corner. You can select the current set that you want to work with using the up and down directional keys.

Hitting {{K|a}} will add a new set to the end of the list. You can also {{K|c}}opy an existing set to a new one allowing you to base a new set on an existing one. Using {{K|t}} you can change the name of the parameter set but note that this will not affect the name of the world that is generated.

Parameter sets are stored in the <tt>data/init/world_gen.txt</tt> file in the main DF directory. The {{K|F1}} and {{K|F6}} keys will load and save '''all''' of the parameter sets to this file. You will need to save the world gen parameters to this file before you hit {{K|Enter}} to generate the world.

The <tt>world_gen.txt</tt> file can also be edited with a text editor. This is particularly useful because people will often post their parameter sets on the forum or wiki in text form. (See below for more info.) The {{K|F1}} key comes in handy when editing this file while the game is still running.

To get the parameters used to generate a world you are already playing press {{K|ESC}} then choose export images; exporting any image will also create the world generation parameter file, for more information see this [http://www.bay12forums.com/smf/index.php?topic=101280.msg4512541#msg4512541 post].

The tokens used in <tt>world_gen.txt</tt> are at the bottom of each parameter description. Here's the one for title.

{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[TITLE: <name>]</nowiki></tt>
| <tt><nowiki>[TITLE:MEDIUM ISLAND]</nowiki></tt>
| Required
|}

== World name ==

As previously mentioned, the title of the parameter set doesn't affect the name of the world. You can force a particular name for your world using {{K|n}} or set it back to the default random setting using {{K|N}}.

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

== World dimensions ==

The size of the map to be generated can be selected with {{K|u}} {{K|i}} {{K|o}} {{K|p}}. Larger maps take longer to generate and may limit [[Frames per second|FPS]] in game.

Changing the dimensions of the world will reset the parameters because many of them have different defaults depending on the surface area available.

Creating larger worlds does not necessarily mean longer world generation time. The essential factor for the duration is the history. If you restrict the number of historical events you can significantly speed up the process.

{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[DIM:<width>:<height>]</nowiki></tt>
| <tt><nowiki>[DIM:129:129]</nowiki></tt>
| Valid values are 17, 33, 65, 129, and 257. Others may not work.
|}

== Seed values ==

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 older versions, the same seed value(s) produced identical worlds on every computer at any time (if other parameters were identical, too). 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 cumulating to an different world-history at all. It seems like the history is random somhow and not completely connected to the seed. Keep this in mind if you want to regenerate a particular world.

A specific seed value can be entered with {{K|s}}. This will change '''all''' of the seed values to the value you enter. If you need to enter different seed values for each type of seed, use {{K|e}}.

In order to find out what seed values were used for the last world you generated you can look at this screen. If you want to be able to tell someone else how to generate exactly the same world that you just generated, they will need all of the seed value listed under Last Param Set.

When generating a world using a seed, the way that the world is generated is also based at least in part on certain world tokens. As such 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. Saying that, 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 appear to be involved in the implementation of the seed and are not safe to change:

* [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 and the world generation process comes up with seed values based on some sort of "true" random information from things like random values in uninitialized memory, the current date/time, etc. If you have entered a seed value you can revert to all seeds being random using {{K|S}}.

== Generating a world ==

Unless you're using an already defined parameter set you will probably want to {{K|e}}dit the parameters. Select the set you want to edit using the up/down directional keys and press {{K|e}}. Information about each parameter is documented below.

Once you are happy with the parameters you have set, hit {{K|Esc}} to get back to this screen, hit {{K|F6}} to save the values you just edited, and hit {{K|Enter}} to start. The rest of the process is the same as basic [[World generation]].

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

== World painter ==
:''Main article: [[World painter]]
The '''world painter''' tool allows you to paint features onto a map that is then used when generating a world. It is very difficult to use properly, and tends to result in endless rejected worlds, unless you loosen or remove the restrictions placed on biomes and civilizations in the advanced settings. That being said it is also a very powerful tool, and allows you to generate worlds more to your liking.

To access the world painter, hit {{k|e}} to start editing the advanced parameters and finally hit {{k|p}} to open world painter. How to use the world painter is not entirely obvious so please check out the [[World painter]] documentation to avoid frustration. (Losing may be fun, but frustration is not.)

== Editing the parameters init file ==

Parameter sets are stored in the ''data/init/[[world_gen.txt]]'' file, using [[world token]]s. You can copy and paste other player's sets of parameters into your ''world_gen.txt'' to use their parameter sets, and some are provided at [[Main:Pregenerated worlds|Pregenerated worlds]]. Another place to find parameter sets is the [http://www.bay12forums.com/smf/index.php?topic=101280.0 Worldgen cookbook] thread on the official forums.

== Advanced parameters ==

To access advanced parameters, press {{key|e}} when at the screen for creating new worlds with parameters screen. This will bring you to an editable list of various guidelines the world-gen process will use when creating your new world.

The parameters are described below in the order that they appear in the list in the UI, not necessarily the other they appear in the configuration file. See [[world token]] for an index that will help you look things up by token name.

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. Minima and maxima 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. It can be used to set the specific distribution of different elevations or rainfall areas for example.

Rejection Parameters, Dwarf Fortress has 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 isn't right! 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 an re-randomised. Also see [http://dwarffortresswiki.org/index.php/DF2012:World_rejection World Rejection]

The are also the feature placing options such as rivers, mountain peaks, volcanoes and oceans. These can cause rejections if the terrain parameters don't allow enough suitable locations for the features to be placed.

If you are experimenting with world design, one method would be to disable the rejection parameters and use the first two control types. Otherwise any significant change will likely result in endless rejections.

=== Seed values ===

Here you can enter specific seed values for different parts of the world generation process. Different sequences of pseudorandom numbers are used for different parts, so you can use this to reproduce only the particular part of world generation from some previously generated world if you want.

Normally you will want to leave all of these set to Random unless you're specifically trying to reproduce the results of another world generation run.

{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[SEED:<number>]</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.
|-
| <tt><nowiki>[HISTORY_SEED:<number>]</nowiki></tt>
| <tt><nowiki>[HISTORY_SEED:31337]</nowiki></tt>
|-
| <tt><nowiki>[NAME_SEED:<number>]</nowiki></tt>
| <tt><nowiki>[NAME_SEED:31337]</nowiki></tt>
|-
| <tt><nowiki>[CREATURE_SEED:<number>]</nowiki></tt>
| <tt><nowiki>[CREATURE_SEED:31337]</nowiki></tt>
|}

=== Embark Points ===

This controls the number of points that you have for skills and equipment when you embark in fortress mode. Turning this value up will allow games started in this world to start with more skilled dwarves with better equipment. Normally you can do just fine by leaving this value set to default, but you might want to up it for experimental/testing purposes or to help dwarves survive in a particularly evil world.

{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[EMBARK_POINTS:<number>]</nowiki></tt>
| <tt><nowiki>[EMBARK_POINTS:1504]</nowiki></tt>
| Required
|}

=== End year ===

This is how many years of history are generated for the world. This is basically the same as the History parameter in basic world gen, except that you can enter an exact value for number of years. See [[World_generation#History|History]] for more info.

History is divided into "ages" which are determined by the ''percentage'' of megabeasts and semi-megabeasts killed at various points. One can attempt to make a world go through the ages more quickly by pumping up the ratio of semimegabeast to megabeast caves, the former of which are usually more killable than the regular megabeasts. This will net you more "Age of Legends", "Age of Heroes", etc.

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:1050]</nowiki></tt>
| Required
|}

=== Population cap after civ creation ===

This determines the maximum possible population of civilization member historical figures alive at a given time during worldgen. Not all members of a civilization are historical figures. This tag does not directly influence the total population of civilized beings as it once did when populations were all historical figures, so the description is a bit confusing. You can enter -1 to make the historical population unlimited.

Each race may have up to 100 civilizations each, and each civilization a maximum population of 10,000. Civilizations, known as ''entities'' in the [[Raw file|raw files]], have 3 or 4 basic variables that will greatly affect their final placement on the world map. See [[Entity_token#Population|Population (Entity Token)]] for more information on interpreting/editing the raws if you need more precise control of civilization placement and total population numbers.

Huge historical figure populations can cause the size of history data to explode, cause history generation to take forever, lower FPS, and generally slow down the game.

{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[TOTAL_CIV_POPULATION:<number>]</nowiki></tt>
| <tt><nowiki>[TOTAL_CIV_POPULATION:15000]</nowiki></tt>
| Required
|}

=== Site cap after civ creation ===

This controls the maximum number of towns and similar sites on the entire map. Raising the number will allow for more towns, etc. though the number of sites will ultimately still be limited by things like space, terrain, and population cap.

Note that '''this parameter controls only "civilization" sites''' like towns. Other sites such as lairs will be added on to this maximum. After civilizations reach this cap, they will not spread out anymore to place new cities.

By default, the raws limit each civilization site to a population of 120 regardless of the race of the civilization. Therefore, without editing the raws, the total population on the map can't go above site cap x 120.

Increasing this too high can slow worldgen down by a lot, beware. Another effect can be goblins (or other civs) sometimes overwelming all other civs and/or flooding the world with their homes leaving no good places to build your fortress. If you choose a low cap to hasten world generation, the cap will be reached within years stopping expanson of all civs. If you want a good and long history you will have to adjust cap of sites and population as the number of civs many times to find one fullfilling your needs.

{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[SITE_CAP:<number>]</nowiki></tt>
| <tt><nowiki>[SITE_CAP:1040]</nowiki></tt>
| Required
|}

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

If you want to end the creation of your world at the beginning at 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 megabeasts and titans 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 megabeasts and titans 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 meagabeasts and titans 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 ===

Whether or not the game ignores unimportant figures in history generation. The culling is many CPU-intensive steps in history generation but it saves memory and will speed up loading/saving games a bit. This does mean that the "unimportant" figures will not appear in Legends mode or in things like dwarf engravings, but they might not appear in engravings anyway.

Unimportant figures are people or creatures who suffer early deaths, never having offspring or killing anything named during history generation. For example, residents of goblin towers may get murdered by demons at a young age. After culling unimportant figures, Legends mode would say something like the demon has killed "a creature at Eviltower in the year 102."

{| {{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 all information about the history of the world in Legends mode. 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 determine how random values for terrain elevation, rainfall, temperature, drainage, volcanism, and savagery 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. Changing these can cause the occurrence of certain [[Biome|biomes]] to become impossible, so modify these with care. Because of this problem, you may want to use [[#Weighted Ranges|Weighted Ranges]] instead.

By ''subtly'' tweaking the min and max values, vastly different maps can be made.

==== 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.
* River start locations need a minimum elevation of 300. Therefore, a world with a maximum elevation of 299 everywhere prevents river generation, but rivers can still occur if maximum elevation is set to 300.
*Mountain peaks can only form in squares with an elevation of 400.

==== Rainfall ====

Controls the amount of rainfall in each map square/area. Setting the minimum too high or the maximum too low can make the formation of certain biomes impossible. Rainfall causes it to [[Rain]] more in a given area, which can have various effects.

Also makes more rivers appear on the world map.

Note that 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 the specified minimum can occur in the shadow of a mountain. If you want the minimum and maximum for this parameter to be absolutely respected you must turn off the orographic precipitation option.

==== 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. See [[Climate]] for more info.

[[Temperature]] is always influenced by elevation and, if [[Advanced_world_generation#Poles|Poles]] are enabled, latitude. So, the value from the temperature rolling process is ''not the absolute temperature value the region will get, but rather local variation.'' The "base" temperature for an area is derived from its latitude and elevation, and then the random value determined by these parameters are applied to it to make it vary a bit. The default values for the local variation are fairly small compared to the base temperature, which appears to be hard coded.

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

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|Layers]], 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 minimum to 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 too high of a 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 Weights ===

These parameters make it possible to influence the number of squares in a particular range without making conditions outside of that range impossible. For example, you can make it possible for many more low elevation squares to exist without making it impossible for high elevations to form. Changing these parameters is often preferable to simply changing the min/max values.

The basic steps of applying weighted ranges are as follows:

# Create a grid with 2''MeshSize'' - 1 tiles in both X and Y direction.
# Set the intersection points of the grid lines to a random value according to the weighted ranges.
# Smooth out the area between the intersection points.
# Add noise according to the variance parameters.

Where ''MeshSize'' is the raw parameter value found in the world_gen.txt. See the image on the right for an example.

[[File:World_map-large-32x32-elevation-mesh.png|thumb|300px|A large world generated with an Elevation Mesh Size of 32x32 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 or very low and the space between them is smoothed out.]]

==== Mesh Size ====

Mesh size determines how many grid tiles there will be. Setting this to Ignore will cause the weighted range settings to be ignored for that terrain characteristic. As an example, setting it to 2x2 means the grid will be 2 times 2 tiles large and there will be 3 times 3 for a total of 9 intersection points. On a pocket world this means one grid tile will be 8 * 8 world tiles large whereas on a large world one grid tile will be 128 * 128 world tiles. Note that the highest possible value for a given world size will always make the grid tiles 8 * 8 world tiles large.

==== Weighted Ranges ====

If mesh size is set to something other than Ignore, these weights will be applied at the granularity of the selected mesh size for purposes of generating random values in each range. This allows random number generation to be non-linear for the given terrain characteristic.

For example, if the Elevation Weighted Range parameters were set to (starting with the 0-20 range) 60:10:10:10:10 (these values do not have to add up to any particular number) and elevation min and max are set to 1 and 400 respectively then about 60% of the grid line intersection points (on average) 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.

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 Mesh Size and Variance ====

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 large the noise it adds can completely negate the effect of the weighted ranges. For instance, with a 2x2 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 2x2 mesh and barely visible at all with a 8x8 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 2x2 mesh will look essentially the same as a pocket world with a 2x2 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>[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>[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>[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.

{| {{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. 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 but other than that they don't appear to "do" anything special. 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.

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

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 and 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 ===

Worlds with less than this number of volcanoes will be rejected. Note that this will not just create this many volcanoes at random; there must be at least this many squares with a Volcanism of 100. Therefore adjusting Weighted Range for 80-100 to some higher value is recommended if you want to facilitate a large number of volcanoes. In addition, Maximum Volcanism must be set to 100 or squares with volcanism of 100 will be impossible making volcanoes impossible.

{| {{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 lower will increase the amount of ore present on a map, the number of different types of ore, and the number/types of gems. The default value will result in a maximum of 2-4 metal ores per map (assuming you choose a good embark location) which may be limiting until the economy is fully implemented and desired metals can be traded for.

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

{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[MINERAL_SCARCITY:<number>]</nowiki></tt>
| <tt><nowiki>[MINERAL_SCARCITY:2500]</nowiki></tt>
| Range: 100 to 100,000

|}
'''Note:''' as of v0.34, low mineral scarcity settings do not cause rejections.

=== Max Megabeasts Caves ===

This is the number of megabeasts placed at the beginning of history. Megabeasts are hydras, bronze colossuses, rocs and dragons 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-megabeasts placed at the beginning of history. Semi-megabeasts are giants, ettins, minotaurs, and cyclopes, 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 BEAST_END_YEAR calculation.
|}

=== Titan Parameters ===

==== Number ====

This controls the number of titans 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 ====

Megabeasts 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 ====

Megabeasts will begin to attack your fort once you have exported at least this many [[Currency|dwarfbucks]] worth of merchandise, regardless of whether or not any other criteria have been met. This parameter defaults to None (disabled).

==== Created Wealth Requirement ====

Megabeasts 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|Demons]] are similar to titans and forgotten beasts in that they are procedurally generated, but unlike titans they are not unique. Thus many different types of demons will exist in the world but there will be many members of each type. Setting this to zero means no demons will exist, limiting the amount of fun you can have. Thanks to [[Underworld spire|certain fun things]], no demons also means no goblins.

{| {{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|night trolls]] that will exist in the world. These are also procedurally generated. Setting this to zero means that the world will have no night trolls.

{| {{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|bogeyman]] forms that will exist in the world. Bogeyman are procedurally generated, though their forms do not vary by much. Setting this to zero, means that the world will have no bogeyman. Additionally setting this to zero will not allow custom bogeymen to appear in the world.

{| {{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 Vampire Curse Types ===

The number of different [[Vampire|vampires]] that will exist in the world. Although they too are generated at the start of a new world, they generally no different from one another, with the biggest difference being what stat bonuses their vampirism gives {{verify}}. 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
|}

=== Number of Werebeast Curse Types ===

The number of different [[Werebeast|werebeasts]] 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 as different species of animal beasts. From lizards, to wolves, to maybe even bears. Setting this to zero means no werebeasts will exist.

{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[WEREBEAST_NUMBER:<number>]</nowiki></tt>
| <tt><nowiki>[WEREBEAST_NUMBER:58]</nowiki></tt>
| 0 to 1000
|}

=== 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 necromancers. Setting this to zero means that no [[necromancer]]s will appear.

{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[SECRET_NUMBER:<number>]</nowiki></tt>
| <tt><nowiki>[SECRET_NUMBER:44]</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]] {{verify}} that can exist in the world. Setting this to zero, while being as pointless as is, (since you're never forced to enter a tomb anyway), will most likely prevent any toilet roll spooks from appearing, but it may or may not also prevent the existence of the pyramids which house them too.

{| {{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 Types ===

This number specifies [[Weather#Evil weather|the total amount of 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. I'd 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
|}

=== Number of Evil Rain Types ===

The lesser of a relatively large group of evils... evil rain. This 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 liquids 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 vaults.

{| {{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
|}

=== 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 exact size of small, medium, and large are: Small is 1-24, medium is 25-99, and large is 100+, for any map size. The counts used here will always be restricted to regions of the given size no matter how large the number. 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 exists 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 can not 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 an early extincion of many civilizations.

{| {{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 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 ====

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
|-
| 17x17
| 289
|-
| 33x33
| 1089
|-
| 65x65
| 4225
|-
| 129x129
| 16614
|-
| 257x257
| 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}} The rain shadows will always be created as if the wind is blowing from west to east.

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.

==== Cavern Layer Number ====

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

'''Warning:'''
*Disabling caverns by setting this to 0 will make it impossible to grow any underground plants, as none will exist for your civilization to cultivate. (Underground plants will not be available on embark.)

{| {{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 =====

This 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>
|}

See [http://www.bay12forums.com/smf/index.php?topic=76355.0 this forum thread] for more information on openness and density including many more images.

===== Layer Water min\max =====

Determines how many caverns will have water at the bottom. Note that, even at 100, there will be some amount of ground in caverns, but each cavern 'bubble' will contain some amount of water.

At 0, there will be no water in your caverns. This may impact future underground plant growth, although maps will still start with underground flora.{{Verify}}

{| {{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 have 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. (Unknown whether this has any impact on occurrence of HFS "temple".){{Verify}}

{| {{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. 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'' this 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 for 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 very top of second cavern and very bottom of 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 very top of third cavern and very bottom of 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 very highest magma and very bottom of 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 has no impact. Values larger than default results in strange things.
|}

Some implications:
* The number of surface layers (e.g. soil), at this time, can not 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 temple, 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 temples, 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 values can cause strange things to happen. Even more true for small values.

=== Cave Parameters ===

Caves are sort of like caverns except that they have a passage to the surface and are generally much smaller. Caves can connect to caverns if they are sufficiently deep.

==== Minimum/Maximum Natural Cave Size ====

These parameters appear to control the length and depth of caves.

{| {{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 (Non-)Mountain Caves ====

The number of caves that will be generated. Lurking kobolds set up shop in caves and store stolen items here. A setting of 0 in both will stop kobold civilizations from appearing. Special note: a cave is not a 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>
|}

==== 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 as {{Raw Tile|•|#808080|#00DD00}} symbols 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 ===

This parameter doesn't do anything.

{| {{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 civilizations will be placed on the map before history generation begins. These civilizations may later die out due to historical events. The five races are dwarf, elf, human, goblin, and kobold; they will be placed in equal numbers until the quota has been reached. 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].

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. These 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 your 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.

== Default Worldgen Parameters ==

There is no single default for each parameter. Several advanced world generation profiles come with the game by default. See [[world_gen.txt|Default world_gen.txt]] to take a look at this file.

== Parameter Set Examples ==

If you're trying to do something specific then the [[Worldgen examples|Worldgen examples]] might be helpful. These are complete parameter sets that can be copied directly into your ''world_gen.txt'' file and customized as desired.
If they have nothing for you try [[Worldgen Tricks|Worldgen Tricks]], for known tricks 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]

{{World}}

Advanced world generation

2016-02-29T10:51:09Z

Chinchou: "Many" is not a location. Miscellaneous spelling and grammar-related corrections.

{{Quality|Exceptional|18:16, 23 August 2014 (UTC)}}
{{av}}
{{old}}

:''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.''
:''See [[World rejection]] for information on solving problems related to worlds always being rejected.''
:''See [[Worldgen examples]] for example worlds.''

When you want more control of what your world looks like, it's time for '''advanced world generation'''. A detailed reference with advice is provided below. This article assumes that you are already familiar with [[World generation|'''basic''' world generation]]. If you are not then please read about that first.

Once you select {{DFtext|Design New World With Advanced Parameters}} from the main menu, a screen that looks something like this will appear:

[[File:AdvancedWorldGen.png‎]]

This screen is relatively intuitive but some parts could use some explanation.

== Parameter sets ==

The list of already defined parameter sets is in the upper right corner. You can select the current set that you want to work with using the up and down directional keys.

Hitting {{K|a}} will add a new set to the end of the list. You can also {{K|c}}opy an existing set to a new one allowing you to base a new set on an existing one. Using {{K|t}} you can change the name of the parameter set but note that this will not affect the name of the world that is generated.

Parameter sets are stored in the <tt>data/init/world_gen.txt</tt> file in the main DF directory. The {{K|F1}} and {{K|F6}} keys will load and save '''all''' of the parameter sets to this file. You will need to save the world gen parameters to this file before you hit {{K|Enter}} to generate the world.

The <tt>world_gen.txt</tt> file can also be edited with a text editor. This is particularly useful because people will often post their parameter sets on the forum or wiki in text form. (See below for more info.) The {{K|F1}} key comes in handy when editing this file while the game is still running.

To get the parameters used to generate a world you are already playing press {{K|ESC}} then choose export images; exporting any image will also create the world generation parameter file, for more information see this [http://www.bay12forums.com/smf/index.php?topic=101280.msg4512541#msg4512541 post].

The tokens used in <tt>world_gen.txt</tt> are at the bottom of each parameter description. Here's the one for title.

{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[TITLE: <name>]</nowiki></tt>
| <tt><nowiki>[TITLE:MEDIUM ISLAND]</nowiki></tt>
| Required
|}

== World name ==

As previously mentioned, the title of the parameter set doesn't affect the name of the world. You can force a particular name for your world using {{K|n}} or set it back to the default random setting using {{K|N}}.

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

== World dimensions ==

The size of the map to be generated can be selected with {{K|u}} {{K|i}} {{K|o}} {{K|p}}. Larger maps take longer to generate and may limit [[Frames per second|FPS]] in game.

Changing the dimensions of the world will reset the parameters because many of them have different defaults depending on the surface area available.

Creating larger worlds does not necessarily mean longer world generation time. The essential factor for the duration is the history. If you restrict the number of historical events you can significantly speed up the process.

{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[DIM:<width>:<height>]</nowiki></tt>
| <tt><nowiki>[DIM:129:129]</nowiki></tt>
| Valid values are 17, 33, 65, 129, and 257. Others may not work.
|}

== Seed values ==

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 older versions, the same seed value(s) produced identical worlds on every computer at any time (if other parameters were identical, too). 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 cumulating to an different world-history at all. It seems like the history is random somhow and not completely connected to the seed. Keep this in mind if you want to regenerate a particular world.

A specific seed value can be entered with {{K|s}}. This will change '''all''' of the seed values to the value you enter. If you need to enter different seed values for each type of seed, use {{K|e}}.

In order to find out what seed values were used for the last world you generated you can look at this screen. If you want to be able to tell someone else how to generate exactly the same world that you just generated, they will need all of the seed value listed under Last Param Set.

When generating a world using a seed, the way that the world is generated is also based at least in part on certain world tokens. As such 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. Saying that, 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 appear to be involved in the implementation of the seed and are not safe to change:

* [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 and the world generation process comes up with seed values based on some sort of "true" random information from things like random values in uninitialized memory, the current date/time, etc. If you have entered a seed value you can revert to all seeds being random using {{K|S}}.

== Generating a world ==

Unless you're using an already defined parameter set you will probably want to {{K|e}}dit the parameters. Select the set you want to edit using the up/down directional keys and press {{K|e}}. Information about each parameter is documented below.

Once you are happy with the parameters you have set, hit {{K|Esc}} to get back to this screen, hit {{K|F6}} to save the values you just edited, and hit {{K|Enter}} to start. The rest of the process is the same as basic [[World generation]].

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

== World painter ==
:''Main article: [[World painter]]
The '''world painter''' tool allows you to paint features onto a map that is then used when generating a world. It is very difficult to use properly, and tends to result in endless rejected worlds, unless you loosen or remove the restrictions placed on biomes and civilizations in the advanced settings. That being said it is also a very powerful tool, and allows you to generate worlds more to your liking.

To access the world painter, hit {{k|e}} to start editing the advanced parameters and finally hit {{k|p}} to open world painter. How to use the world painter is not entirely obvious so please check out the [[World painter]] documentation to avoid frustration. (Losing may be fun, but frustration is not.)

== Editing the parameters init file ==

Parameter sets are stored in the ''data/init/[[world_gen.txt]]'' file, using [[world token]]s. You can copy and paste other player's sets of parameters into your ''world_gen.txt'' to use their parameter sets, and some are provided at [[Main:Pregenerated worlds|Pregenerated worlds]]. Another place to find parameter sets is the [http://www.bay12forums.com/smf/index.php?topic=101280.0 Worldgen cookbook] thread on the official forums.

== Advanced parameters ==

To access advanced parameters, press {{key|e}} when at the screen for creating new worlds with parameters screen. This will bring you to an editable list of various guidelines the world-gen process will use when creating your new world.

The parameters are described below in the order that they appear in the list in the UI, not necessarily the other they appear in the configuration file. See [[world token]] for an index that will help you look things up by token name.

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. Minima and maxima 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. It can be used to set the specific distribution of different elevations or rainfall areas for example.

Rejection Parameters, Dwarf Fortress has 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 isn't right! 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 an re-randomised. Also see [http://dwarffortresswiki.org/index.php/DF2012:World_rejection World Rejection]

The are also the feature placing options such as rivers, mountain peaks, volcanoes and oceans. These can cause rejections if the terrain parameters don't allow enough suitable locations for the features to be placed.

If you are experimenting with world design, one method would be to disable the rejection parameters and use the first two control types. Otherwise any significant change will likely result in endless rejections.

=== Seed values ===

Here you can enter specific seed values for different parts of the world generation process. Different sequences of pseudorandom numbers are used for different parts, so you can use this to reproduce only the particular part of world generation from some previously generated world if you want.

Normally you will want to leave all of these set to Random unless you're specifically trying to reproduce the results of another world generation run.

{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[SEED:<number>]</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.
|-
| <tt><nowiki>[HISTORY_SEED:<number>]</nowiki></tt>
| <tt><nowiki>[HISTORY_SEED:31337]</nowiki></tt>
|-
| <tt><nowiki>[NAME_SEED:<number>]</nowiki></tt>
| <tt><nowiki>[NAME_SEED:31337]</nowiki></tt>
|-
| <tt><nowiki>[CREATURE_SEED:<number>]</nowiki></tt>
| <tt><nowiki>[CREATURE_SEED:31337]</nowiki></tt>
|}

=== Embark Points ===

This controls the number of points that you have for skills and equipment when you embark in fortress mode. Turning this value up will allow games started in this world to start with more skilled dwarves with better equipment. Normally you can do just fine by leaving this value set to default, but you might want to up it for experimental/testing purposes or to help dwarves survive in a particularly evil world.

{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[EMBARK_POINTS:<number>]</nowiki></tt>
| <tt><nowiki>[EMBARK_POINTS:1504]</nowiki></tt>
| Required
|}

=== End year ===

This is how many years of history are generated for the world. This is basically the same as the History parameter in basic world gen, except that you can enter an exact value for number of years. See [[World_generation#History|History]] for more info.

History is divided into "ages" which are determined by the ''percentage'' of megabeasts and semi-megabeasts killed at various points. One can attempt to make a world go through the ages more quickly by pumping up the ratio of semimegabeast to megabeast caves, the former of which are usually more killable than the regular megabeasts. This will net you more "Age of Legends", "Age of Heroes", etc.

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:1050]</nowiki></tt>
| Required
|}

=== Population cap after civ creation ===

This determines the maximum possible population of civilization member historical figures alive at a given time during worldgen. Not all members of a civilization are historical figures. This tag does not directly influence the total population of civilized beings as it once did when populations were all historical figures, so the description is a bit confusing. You can enter -1 to make the historical population unlimited.

Each race may have up to 100 civilizations each, and each civilization a maximum population of 10,000. Civilizations, known as ''entities'' in the [[Raw file|raw files]], have 3 or 4 basic variables that will greatly affect their final placement on the world map. See [[Entity_token#Population|Population (Entity Token)]] for more information on interpreting/editing the raws if you need more precise control of civilization placement and total population numbers.

Huge historical figure populations can cause the size of history data to explode, cause history generation to take forever, lower FPS, and generally slow down the game.

{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[TOTAL_CIV_POPULATION:<number>]</nowiki></tt>
| <tt><nowiki>[TOTAL_CIV_POPULATION:15000]</nowiki></tt>
| Required
|}

=== Site cap after civ creation ===

This controls the maximum number of towns and similar sites on the entire map. Raising the number will allow for more towns, etc. though the number of sites will ultimately still be limited by things like space, terrain, and population cap.

Note that '''this parameter controls only "civilization" sites''' like towns. Other sites such as lairs will be added on to this maximum. After civilizations reach this cap, they will not spread out anymore to place new cities.

By default, the raws limit each civilization site to a population of 120 regardless of the race of the civilization. Therefore, without editing the raws, the total population on the map can't go above site cap x 120.

Increasing this too high can slow worldgen down by a lot, beware. Another effect can be goblins (or other civs) sometimes overwelming all other civs and/or flooding the world with their homes leaving no good places to build your fortress. If you choose a low cap to hasten world generation, the cap will be reached within years stopping expanson of all civs. If you want a good and long history you will have to adjust cap of sites and population as the number of civs many times to find one fullfilling your needs.

{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[SITE_CAP:<number>]</nowiki></tt>
| <tt><nowiki>[SITE_CAP:1040]</nowiki></tt>
| Required
|}

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

If you want to end the creation of your world at the beginning at 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 megabeasts and titans 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 megabeasts and titans 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 meagabeasts and titans 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 ===

Whether or not the game ignores unimportant figures in history generation. The culling is many CPU-intensive steps in history generation but it saves memory and will speed up loading/saving games a bit. This does mean that the "unimportant" figures will not appear in Legends mode or in things like dwarf engravings, but they might not appear in engravings anyway.

Unimportant figures are people or creatures who suffer early deaths, never having offspring or killing anything named during history generation. For example, residents of goblin towers may get murdered by demons at a young age. After culling unimportant figures, Legends mode would say something like the demon has killed "a creature at Eviltower in the year 102."

{| {{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 all information about the history of the world in Legends mode. 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 determine how random values for terrain elevation, rainfall, temperature, drainage, volcanism, and savagery 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. Changing these can cause the occurrence of certain [[Biome|biomes]] to become impossible, so modify these with care. Because of this problem, you may want to use [[#Weighted Ranges|Weighted Ranges]] instead.

By ''subtly'' tweaking the min and max values, vastly different maps can be made.

==== 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.
* River start locations need a minimum elevation of 300. Therefore, a world with a maximum elevation of 299 everywhere prevents river generation, but rivers can still occur if maximum elevation is set to 300.
*Mountain peaks can only form in squares with an elevation of 400.

==== Rainfall ====

Controls the amount of rainfall in each map square/area. Setting the minimum too high or the maximum too low can make the formation of certain biomes impossible. Rainfall causes it to [[Rain]] more in a given area, which can have various effects.

Also makes more rivers appear on the world map.

Note that 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 the specified minimum can occur in the shadow of a mountain. If you want the minimum and maximum for this parameter to be absolutely respected you must turn off the orographic precipitation option.

==== 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. See [[Climate]] for more info.

[[Temperature]] is always influenced by elevation and, if [[Advanced_world_generation#Poles|Poles]] are enabled, latitude. So, the value from the temperature rolling process is ''not the absolute temperature value the region will get, but rather local variation.'' The "base" temperature for an area is derived from its latitude and elevation, and then the random value determined by these parameters are applied to it to make it vary a bit. The default values for the local variation are fairly small compared to the base temperature, which appears to be hard coded.

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

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|Layers]], 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 minimum to 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 too high of a 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 Weights ===

These parameters make it possible to influence the number of squares in a particular range without making conditions outside of that range impossible. For example, you can make it possible for many more low elevation squares to exist without making it impossible for high elevations to form. Changing these parameters is often preferable to simply changing the min/max values.

The basic steps of applying weighted ranges are as follows:

# Create a grid with 2''MeshSize'' - 1 tiles in both X and Y direction.
# Set the intersection points of the grid lines to a random value according to the weighted ranges.
# Smooth out the area between the intersection points.
# Add noise according to the variance parameters.

Where ''MeshSize'' is the raw parameter value found in the world_gen.txt. See the image on the right for an example.

[[File:World_map-large-32x32-elevation-mesh.png|thumb|300px|A large world generated with an Elevation Mesh Size of 32x32 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 or very low and the space between them is smoothed out.]]

==== Mesh Size ====

Mesh size determines how many grid tiles there will be. Setting this to Ignore will cause the weighted range settings to be ignored for that terrain characteristic. As an example, setting it to 2x2 means the grid will be 2 times 2 tiles large and there will be 3 times 3 for a total of 9 intersection points. On a pocket world this means one grid tile will be 8 * 8 world tiles large whereas on a large world one grid tile will be 128 * 128 world tiles. Note that the highest possible value for a given world size will always make the grid tiles 8 * 8 world tiles large.

==== Weighted Ranges ====

If mesh size is set to something other than Ignore, these weights will be applied at the granularity of the selected mesh size for purposes of generating random values in each range. This allows random number generation to be non-linear for the given terrain characteristic.

For example, if the Elevation Weighted Range parameters were set to (starting with the 0-20 range) 60:10:10:10:10 (these values do not have to add up to any particular number) and elevation min and max are set to 1 and 400 respectively then about 60% of the grid line intersection points (on average) 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.

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 Mesh Size and Variance ====

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 large the noise it adds can completely negate the effect of the weighted ranges. For instance, with a 2x2 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 2x2 mesh and barely visible at all with a 8x8 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 2x2 mesh will look essentially the same as a pocket world with a 2x2 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>[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>[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>[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.

{| {{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. 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 but other than that they don't appear to "do" anything special. 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.

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

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 and 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 ===

Worlds with less than this number of volcanoes will be rejected. Note that this will not just create this many volcanoes at random; there must be at least this many squares with a Volcanism of 100. Therefore adjusting Weighted Range for 80-100 to some higher value is recommended if you want to facilitate a large number of volcanoes. In addition, Maximum Volcanism must be set to 100 or squares with volcanism of 100 will be impossible making volcanoes impossible.

{| {{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 lower will increase the amount of ore present on a map, the number of different types of ore, and the number/types of gems. The default value will result in a maximum of 2-4 metal ores per map (assuming you choose a good embark location) which may be limiting until the economy is fully implemented and desired metals can be traded for.

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

{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[MINERAL_SCARCITY:<number>]</nowiki></tt>
| <tt><nowiki>[MINERAL_SCARCITY:2500]</nowiki></tt>
| Range: 100 to 100,000

|}
'''Note:''' as of v0.34, low mineral scarcity settings do not cause rejections.

=== Max Megabeasts Caves ===

This is the number of megabeasts placed at the beginning of history. Megabeasts are hydras, bronze colossuses, rocs and dragons 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-megabeasts placed at the beginning of history. Semi-megabeasts are giants, ettins, minotaurs, and cyclopes, 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 BEAST_END_YEAR calculation.
|}

=== Titan Parameters ===

==== Number ====

This controls the number of titans 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 ====

Megabeasts 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 ====

Megabeasts will begin to attack your fort once you have exported at least this many [[Currency|dwarfbucks]] worth of merchandise, regardless of whether or not any other criteria have been met. This parameter defaults to None (disabled).

==== Created Wealth Requirement ====

Megabeasts 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|Demons]] are similar to titans and forgotten beasts in that they are procedurally generated, but unlike titans they are not unique. Thus many different types of demons will exist in the world but there will be many members of each type. Setting this to zero means no demons will exist, limiting the amount of fun you can have. Thanks to [[Underworld spire|certain fun things]], no demons also means no goblins.

{| {{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|night trolls]] that will exist in the world. These are also procedurally generated. Setting this to zero means that the world will have no night trolls.

{| {{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|bogeyman]] forms that will exist in the world. Bogeyman are procedurally generated, though their forms do not vary by much. Setting this to zero, means that the world will have no bogeyman. Additionally setting this to zero will not allow custom bogeymen to appear in the world.

{| {{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 Vampire Curse Types ===

The number of different [[Vampire|vampires]] that will exist in the world. Although they too are generated at the start of a new world, they generally no different from one another, with the biggest difference being what stat bonuses their vampirism gives {{verify}}. 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
|}

=== Number of Werebeast Curse Types ===

The number of different [[Werebeast|werebeasts]] 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 as different species of animal beasts. From lizards, to wolves, to maybe even bears. Setting this to zero means no werebeasts will exist.

{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[WEREBEAST_NUMBER:<number>]</nowiki></tt>
| <tt><nowiki>[WEREBEAST_NUMBER:58]</nowiki></tt>
| 0 to 1000
|}

=== 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 necromancers. Setting this to zero means that no [[necromancer]]s will appear.

{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[SECRET_NUMBER:<number>]</nowiki></tt>
| <tt><nowiki>[SECRET_NUMBER:44]</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]] {{verify}} that can exist in the world. Setting this to zero, while being as pointless as is, (since you're never forced to enter a tomb anyway), will most likely prevent any toilet roll spooks from appearing, but it may or may not also prevent the existence of the pyramids which house them too.

{| {{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 Types ===

This number specifies [[Weather#Evil weather|the total amount of 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. I'd 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
|}

=== Number of Evil Rain Types ===

The lesser of a relatively large group of evils... evil rain. This 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 liquids 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 vaults.

{| {{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
|}

=== 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 exact size of small, medium, and large are: small is 1-24, medium is 25-99, and large is 100+, for any map size. The counts used here will always be restricted to regions of the given size no matter how large the number. 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 exists 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 can not 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 an early extincion of many civilizations.

{| {{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 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 ====

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
|-
| 17x17
| 289
|-
| 33x33
| 1089
|-
| 65x65
| 4225
|-
| 129x129
| 16614
|-
| 257x257
| 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}} The rain shadows will always be created as if the wind is blowing from west to east.

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.

==== Cavern Layer Number ====

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

'''Warning:'''
*Disabling caverns by setting this to 0 will make it impossible to grow any underground plants, as none will exist for your civilization to cultivate. (Underground plants will not be available on embark.)

{| {{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 =====

This 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>
|}

See [http://www.bay12forums.com/smf/index.php?topic=76355.0 this forum thread] for more information on openness and density including many more images.

===== Layer Water min\max =====

Determines how many caverns will have water at the bottom. Note that, even at 100, there will be some amount of ground in caverns, but each cavern 'bubble' will contain some amount of water.

At 0, there will be no water in your caverns. This may impact future underground plant growth, although maps will still start with underground flora.{{Verify}}

{| {{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 have 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. (Unknown whether this has any impact on occurrence of HFS "temple".){{Verify}}

{| {{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. 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'' this 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 for 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 very top of second cavern and very bottom of 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 very top of third cavern and very bottom of 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 very highest magma and very bottom of 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 has no impact. Values larger than default results in strange things.
|}

Some implications:
* The number of surface layers (e.g. soil), at this time, can not 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 temple, 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 temples, 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 values can cause strange things to happen. Even more true for small values.

=== Cave Parameters ===

Caves are sort of like caverns except that they have a passage to the surface and are generally much smaller. Caves can connect to caverns if they are sufficiently deep.

==== Minimum/Maximum Natural Cave Size ====

These parameters appear to control the length and depth of caves.

{| {{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 (Non-)Mountain Caves ====

The number of caves that will be generated. Lurking kobolds set up shop in caves and store stolen items here. A setting of 0 in both will stop kobold civilizations from appearing. Special note: a cave is not a 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>
|}

==== 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 as {{Raw Tile|•|#808080|#00DD00}} symbols 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 ===

This parameter doesn't do anything.

{| {{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 civilizations will be placed on the map before history generation begins. These civilizations may later die out due to historical events. The five races are dwarf, elf, human, goblin, and kobold; they will be placed in equal numbers until the quota has been reached. 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].

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. These 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 your 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.

== Default Worldgen Parameters ==

There is no single default for each parameter. Several advanced world generation profiles come with the game by default. See [[world_gen.txt|Default world_gen.txt]] to take a look at this file.

== Parameter Set Examples ==

If you're trying to do something specific then the [[Worldgen examples|Worldgen examples]] might be helpful. These are complete parameter sets that can be copied directly into your ''world_gen.txt'' file and customized as desired.
If they have nothing for you try [[Worldgen Tricks|Worldgen Tricks]], for known tricks 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]

{{World}}

Magma-safe

2016-02-25T10:23:47Z

Chinchou: The job in the workshop doesn't need to be "active", merely listed.

{{Quality|Exceptional|01:12, 4 February 2015 (UTC)}}
{{av}}
{{Material properties}}
'''Magma-safe materials''' are materials which will not melt, burn, evaporate, or otherwise take damage when in close contact with [[magma]]. Most frequently, this comes into play when using [[floodgate]]s operated by [[mechanism]]s, or when operating a [[screw pump|magma pump]].

For [[reaction]]s and custom buildings using the [MAGMA_BUILD_SAFE] token, only a material which is solid and stable at the temperature {{ct|12000}} (i.e. MELTING_POINT/BOILING_POINT/IGNITE_POINT/HEATDAM_POINT greater than 12000 and COLDDAM_POINT less than 12000) is considered magma-safe.

In order to construct mechanisms, blocks or other pump components from a magma-safe material, you have several choices:
# You can specify a magma-safe rock for your [[mechanisms]] and other components at the workshops by highlighting a listed job and selecting {{k|d}}etail.{{version|0.42.06}}
# Build your mechanisms out of [[iron]] or [[steel]].
# Build your pump components out of iron, steel, [[glass]], or [[nether-cap]].
# Place a [[stockpile]] with the desired stones around your [[mechanic's workshop]] and set it to "Give To a Pile/Workshop".
# Use a [[burrow]] that contains only the workshop and the desired materials.
# Simply ensure that the desired materials are the closest available to your worker. This does not always work, but is usually good enough if you request several jobs, hoping that at least one uses the correct material.

When linking a trigger to an object, the ''first'' mechanism selected is attached to the object, and the ''second'' is attached to the trigger. Unless the trigger itself will be submerged in magma (as could be the case with a [[pressure plate]]), only the first mechanism (attached to the object that will be submerged) needs to be magma-safe. If you do not have any magma-safe stones available, you can also work around floodgate-based flow control by using [[screw pump]]s to pump the magma over [[wall]]-barriers, or using water to form [[obsidian]] to plug flows and channel through them to reopen them (necessity and invention and all that).

This property is also relevant when choosing the appropriate method for disposing of unneeded items, which can impact [[FPS]] when in large numbers. Items made of non magma-safe materials can be simply dumped into magma, which is the easiest disposal method; however, magma-safe items will need more [[Dwarven atom smasher|drastic]] measures.

Constructions that resist magma are:

* Constructions ([[Wall]], [[Floor]], [[Ramp]], and [[Stairs]]) of any material can never melt or burn - there is nothing wrong with a [[wood]]en magma reservoir. Natural (i.e. non-constructed) [[ice]] walls/floors/ramps/stairs will melt if exposed to sufficient heat.
* [[Fortification]]s will allow the passage of [[magma]]; however, if fortifications fill up to 7/7 depth, magma creatures will be able to swim freely through them.
* If not submerged (that is, not opened to let magma flow over/past/around them), [[door]]s, [[floodgate]]s, and raised [[bridge]]s (provided that there is no magma on the space the bridge would occupy when lowered) of non-magma-safe stone or metal are safe. So long as they are just in contact with magma, only acting as a passive "wall", they are fine. If opened, they will melt.
** Raised drawbridges have a notable exception, in that allowing magma to flow over the center of the area that the bridge would normally occupy when lowered ''will'' cause the bridge's components to heat up and potentially melt.
* A [[pump]] made with magma-safe material for pipes, screws and blocks is fully magma-safe, and will not melt even when submerged in magma. Pumps containing any item that is not magma safe will be destroyed after prolonged operation.

== Game calculations ==
In the game, magma's temperature is exactly {{ct|12000}}.

The chance of striking a magma-safe stone is roughly around 32%, not including the natural abundance of certain stone. It is important to note whether or not your fortress may already have access to magma-safe resources before attempting to deliberately find some.

==Magma-safe material==

The following materials will not melt when submerged in magma. Although true for any item/construction, it's worth specifically mentioning that this includes [[door]]s, [[floor hatch]]es, [[floodgate]]s, [[bridge]]s, [[screw pump]]s, [[pipe section]]s, and [[mechanism]]s.


{{MS table head}}

{{MS table row|Type=Stone|Matl=[[Alunite]]|Appear={{Raw Tile|`|7:7:1}} {{Raw Tile|•|7:1}}|Temp=13,690°U (3722°F/2051°C)|Where=All [[Igneous extrusive layer|Igneous extrusive]]'''(L)''', [[Kaolinite]]'''(L)'''}}

{{MS table row|Type=Stone|Matl=[[Anhydrite]]|Appear={{Raw Tile|v|7:7:1}} {{Raw Tile|•|7:0}}|Temp=12,610°U (2642°F/1450°C)|Where=[[Gypsum]]'''(S)''', [[Satinspar]]'''(1)''', [[Alabaster]]'''(1)''', [[Selenite]]'''(1)'''}}

{{MS table row|Type=Stone|Matl=[[Basalt]]|Appear={{Raw Tile|#|0:7:1}} {{Raw Tile|•|0:1}}|Temp=12,160°U (2192°F/1200°C)|Where=[[Igneous extrusive layer|Igneous extrusive]] layer stone}}

{{MS table row|Type=Stone|Matl=[[Bauxite]]|Appear={{Raw Tile|+|4:7:0}} {{Raw Tile|•|4:0}}|Temp=13,600°U (3632°F/2000°C)|Where=All [[Sedimentary layer|Sedimentary]]'''(L)'''|Notes=dark red}}

{{MS table row|Type=Stone|Matl=[[Calcite]]|Appear={{Raw Tile|"|7:7:1}} {{Raw Tile|•|7:1}}|Temp=12,902°U (2934°F/1613°C)|Where=[[Limestone]]'''(S)''', [[Marble]]'''(S)'''|Notes=[[flux]] stone}}

{{MS table row|Type=Stone|Matl=[[Chert]]|Appear={{Raw Tile|=|6:7:0}} {{Raw Tile|•|6:0}}|Temp=13,101°U (3133°F/1723°C)|Where=[[Sedimentary layer|Sedimentary]] layer stone}}

{{MS table row|Type=Stone|Matl=[[Chromite]]|Appear={{Raw Tile|=|0:7:1}} {{Raw Tile|•|0:1}}|Temp=13,645°U (3677°F/2026°C)|Where=[[Olivine]]'''(V)'''}}

{{MS table row|Type=Stone|Matl=[[Dolomite]]|Appear={{Raw Tile|`|7:7:1}} {{Raw Tile|•|7:1}}|Temp=16,507°U (6539°F/3619°C)|Where=[[Sedimentary layer|Sedimentary]] layer stone|Notes=[[Flux]], Highest melting point of any common stone.}}

{{MS table row|Type=Stone|Matl=[[Gabbro]]|Appear={{Raw Tile|▒|0:7:1}} {{Raw Tile|•|0:1}}|Temp=12,160°U (2192°F/1200°C)|Where=[[Igneous intrusive layer|Igneous intrusive]] layer stone}}

{{MS table row|Type=Stone|Matl=[[Ilmenite]]|Appear={{Raw Tile|.|0:7:1}} {{Raw Tile|•|0:1}}|Temp=12,457°U (2489°F/1365°C)|Where=[[Gabbro]]'''(S)'''}}

{{MS table row|Type=Stone|Matl=[[Kaolinite]]|Appear={{Raw Tile|=|4:7:0}} {{Raw Tile|•|4:0}}|Temp=13,150°U (3182°F/1751°C)|Where=All [[Sedimentary layer|Sedimentary]]'''(L)'''|Notes=dark red, [[porcelain]]}}

{{MS table row|Type=Stone|Matl=[[Mica]]|Appear={{Raw Tile|v|0:7:1}} {{Raw Tile|•|0:1}}|Temp=12,295°U (2327°F/1275°C)|Where=All [[Metamorphic]]'''(L)''', [[Granite]]'''(L)'''}}

{{MS table row|Type=Stone|Matl=[[Obsidian]]|Appear={{Raw Tile|▒|0:7:1}} {{Raw Tile|•|0:1}}|Temp=13,600°U (3632°F/2001°C)|Where=[[Igneous extrusive layer|Igneous extrusive]] layer stone|Notes=value 3, can be "[[obsidian farming|manufactured]]"}}

{{MS table row|Type=Stone|Matl=[[Olivine]]|Appear={{Raw Tile|%|2:7:0}} {{Raw Tile|•|2:0}}|Temp=13,168°U (3200°F/1761°C)|Where=[[Gabbro]]'''(L)'''|Notes=green}}

{{MS table row|Type=Stone|Matl=[[Orthoclase]]|Appear={{Raw Tile|%|6:7:1}} {{Raw Tile|•|6:1}}|Temp=12,250°U (2282°F/1250°C)|Where=All [[Igneous intrusive layer|Igneous intrusive]]'''(L)''', All [[Metamorphic]]'''(L)'''|Notes=yellow}}

{{MS table row|Type=Stone|Matl=[[Periclase]]|Appear={{Raw Tile|,|7:7:1}} {{Raw Tile|•|7:1}}|Temp=15,040°U (5072°F/2803°C)|Where=[[Marble]]'''(S)'''}}

{{MS table row|Type=Stone|Matl=[[Petrified wood]]|Appear={{Raw Tile|%|4:7:1}} {{Raw Tile|•|4:1}}|Temp=12,970°U (3002°F/1650°C)|Where=All [[Sedimentary layer|Sedimentary]]'''(S)'''|Notes=bright red, least dense magma-safe non-economic stone}}

{{MS table row|Type=Stone|Matl=[[Pitchblende]]|Appear={{Raw Tile|*|5:7:0}} {{Raw Tile|•|5:0}}|Temp=12,070°U (2102°F/1149°C)|Where=[[Granite]]'''(S)'''|Notes=purple}}

{{MS table row|Type=Stone|Matl=[[Quartzite]]|Appear={{Raw Tile|-|7:7:1}} {{Raw Tile|•|7:1}}|Temp=12,970°U (3002°F/1650°C)|Where=[[Metamorphic]] layer stone}}

{{MS table row|Type=Stone|Matl=[[Rutile]]|Appear={{Raw Tile|`|5:7:0}} {{Raw Tile|•|5:0}}|Temp=13,285°U (3214°F/1826°C)|Where=All [[Metamorphic]]'''(S)''', [[Granite]]'''(S)'''|Notes=purple}}

{{MS table row|Type=Stone|Matl=[[Sandstone]]|Appear={{Raw Tile|#|6:7:0}} {{Raw Tile|•|6:0}}|Temp=12,070°U (2102°F/1149°C)|Where=[[Sedimentary layer|Sedimentary]] layer stone}}

{{MS table row|Type=Stone|Matl=[[Talc]]|Appear={{Raw Tile|||7:7:1}} {{Raw Tile|•|7:1}}|Temp=12,700°U (2732°F/1500°C)|Where=[[Dolomite]]'''(L)'''}}

{{MS table row|Type=Metal|Matl=[[Adamantine]]|Appear={{Raw Tile|X|3:3:1}} {{Raw Tile|≡|3:1}}|Temp=25,000°U (15,032°F/8333°C)|Notes=Highest value/utility material in game}}

{{MS table row|Type=Metal|Matl=[[Iron]]|Appear={{Raw Tile|X|0:7:1}} {{Raw Tile|≡|0:1}}|Temp=12,768°U (2800°F/1538°C)}}

{{MS table row|Type=Metal|Matl=[[Nickel]]|Appear={{Raw Tile|X|7:3:0}} {{Raw Tile|≡|7:0}}|Temp=12,619°U (2651°F/1455°C)}}

{{MS table row|Type=Metal|Matl=[[Pig iron]]|Appear={{Raw Tile|X|0:7:1}} {{Raw Tile|≡|0:1}}|Temp=12,106°U (2138°F/1170°C)|Notes=used in steel making process}}

{{MS table row|Type=Metal|Matl=[[Platinum]]|Appear={{Raw Tile|X|7:7:1}} {{Raw Tile|≡|7:1}}|Temp=13,182°U (3214°F/1768°C)|Notes=High value metal}}

{{MS table row|Type=Metal|Matl=[[Steel]]|Appear={{Raw Tile|X|0:7:1}} {{Raw Tile|≡|0:1}}|Temp=12,718°U (2750°F/1510°C)|Notes=Armor/weapons}}

{{MS table row|Type=Ore|Matl=[[Cassiterite]]|Appear={{Raw Tile|£|6:7:0}} {{Raw Tile|*|6:0}}|Temp=12,025°U (2057°F/1124°C)|Where=[[Granite]]'''(V)'''|Notes=Ore of [[tin]]}}

{{MS table row|Type=Ore|Matl=[[Galena]]|Appear={{Raw Tile|£|7:7:1}} {{Raw Tile|*|7:1}}|Temp=12,005°U (2037°F/1113°C)|Where=All [[Igneous extrusive layer|Igneous extrusive]]'''(V)''', All [[Metamorphic]]'''(V)''', [[Granite]]'''(V)''', [[Limestone]]'''(V)'''|Notes=Ore of [[lead]] and [[silver]]}}

{{MS table row|Type=Ore|Matl=[[Hematite]]3|Appear={{Raw Tile|£|4:7:0}} {{Raw Tile|*|4:0}}|Temp=12,736°U (2768°F/1520°C)|Where=All [[Sedimentary layer|Sedimentary]]'''(V)''', All [[Igneous extrusive layer|Igneous extrusive]]'''(V)'''|Notes=Ore of [[iron]]3}}

{{MS table row|Type=Ore|Matl=[[Magnetite]]3|Appear={{Raw Tile|~|0:7:1}} {{Raw Tile|*|0:1}}|Temp=12,768°U (2800°F/1538°C)|Where=All [[Sedimentary layer|Sedimentary]]'''(L)'''|Notes=Ore of [[iron]]3}}

{{MS table row|Type=Ore|Matl=[[Native platinum]]|Appear={{Raw Tile|£|7:7:1}} {{Raw Tile|*|7:1}}|Temp=13,182°U (3214°F/1768°C)|Where=[[Olivine]]'''(V)''', [[Magnetite]]'''(V)''', [[Chromite]]'''(S)'''|Notes=Ore of [[platinum]]}}

{{MS table row|Type=Ore|Matl=''[[Sphalerite]]''4|Appear={{Raw Tile|£|0:7:1}} {{Raw Tile|*|0:1}}|Temp=''12,133°U (2165°F/1185°C)''|Where=All [[Metamorphic]]'''(V)'''|Notes=Ore of [[zinc]]4}}

{{MS table row|Type=Wood|Matl=[[Nether-cap]]5|Appear={{Raw Tile|♠|1:0:0}} {{Raw Tile|▬|1:0:0}}|Temp=N/A|Where=[[Cavern]] (depth 3)|Notes=Naturally cold5}}

{{MS table row|Type=Special|Matl=[[Raw adamantine]]|Appear={{Raw Tile|£|3:7:1}} {{Raw Tile|*|3:1}}|Temp=25,000°U (15,032°F/8333°C)|Where=The depths|Notes=Ore of [[adamantine]]}}

{{MS table row|Type=Leather|Matl=[[Fire imp]]|Appear=|Temp=15,000°U (5032°F/2780°C)|Notes=}}
{{MS table row|Type=Leather|Matl=[[Dragon]]|Appear=|Temp=55,000°U (45032°F/25,044°C)|Notes=Dragon scales actually cannot be tanned}}

{{MS table row|Type=Bone|Matl=[[Fire imp]]|Appear=|Temp=15,000°U (5032°F/2780°C)|Notes=}}
{{MS table row|Type=Bone|Matl=[[Dragon]]|Appear=|Temp=55,000°U (45032°F/25,044°C)|Notes=}}

{{MS table row|Type=Glass|Matl=[[Glass|Green glass]]|Appear={{Raw Tile|X|2:2:1}} {{Raw Tile|■|2:0}}|Temp=13,600°U (3632°F/2001°C)|Notes=}}
{{MS table row|Type=Glass|Matl=[[Glass|Clear glass]]|Appear={{Raw Tile|X|3:3:1}} {{Raw Tile|■|3:0}}|Temp=13,600°U (3632°F/2001°C)|Notes=}}
{{MS table row|Type=Glass|Matl=[[Glass|Crystal glass]]|Appear={{Raw Tile|X|7:7:1}} {{Raw Tile|■|7:1}}|Temp=13,600°U (3632°F/2001°C)|Notes=}}

|}

'''Notes:'''
:1. Each stone is one of 16 [[color scheme|colors]] in the game. Different un-mined stone of the same color have a different symbol to distinguish between them. Once mined, the individual stones themselves can sometimes look identical if the color is the same. Use {{k|k}} to loo{{k|k}} at items or the terrain for specific information.
:2. '''°U''' = degrees in [[Main:Urist|Urist]], the measure of temperature within the Dwarf Fortress world. As far as is known, there is no functional difference between a material that melts at {{ct|12005}} or {{ct|55000}} — they are both equally "magma safe".
:3. There are three iron ores in the game (four if you count [[Goblinite]]). Of these, only [[hematite]] and [[magnetite]] are magma safe.
:4. Sphalerite has ''no'' melting point, but ''sublimates'' at {{ct|12133}}. This still qualifies as being magma-safe.
:5. [[Nether-cap]] logs have a fixed temperature of {{ct|10000}}, rendering them fully magma safe, except that nether-cap products [[dump]]ed into magma are destroyed.

{{Magma FAQ}}
{{Category|Physics}}
{{Category|Magma safe materials}}

Magma-safe

2016-02-18T05:31:13Z

Chinchou: Clarified that it is the "Detail" option and not "designate" for selecting specific materials. The previous wording may have led to confusion.

{{Quality|Exceptional|01:12, 4 February 2015 (UTC)}}
{{av}}
{{Material properties}}
'''Magma-safe materials''' are materials which will not melt, burn, evaporate, or otherwise take damage when in close contact with [[magma]]. Most frequently, this comes into play when using [[floodgate]]s operated by [[mechanism]]s, or when operating a [[screw pump|magma pump]].

For [[reaction]]s and custom buildings using the [MAGMA_BUILD_SAFE] token, only a material which is solid and stable at the temperature {{ct|12000}} (i.e. MELTING_POINT/BOILING_POINT/IGNITE_POINT/HEATDAM_POINT greater than 12000 and COLDDAM_POINT less than 12000) is considered magma-safe.

In order to construct mechanisms, blocks or other pump components from a magma-safe material, you have several choices:
# You can specify a magma-safe rock for your [[mechanisms]] and other components at the workshops by highlighting an active job and selecting {{k|d}}etail.
# Build your mechanisms out of [[iron]] or [[steel]].
# Build your pump components out of iron, steel, [[glass]], or [[nether-cap]].
# Place a [[stockpile]] with the desired stones around your [[mechanic's workshop]] and set it to "Give To a Pile/Workshop".
# Use a [[burrow]] that contains only the workshop and the desired materials.
# Simply ensure that the desired materials are the closest available to your worker. This does not always work, but is usually good enough if you request several jobs, hoping that at least one uses the correct material.

When linking a trigger to an object, the ''first'' mechanism selected is attached to the object, and the ''second'' is attached to the trigger. Unless the trigger itself will be submerged in magma (as could be the case with a [[pressure plate]]), only the first mechanism (attached to the object that will be submerged) needs to be magma-safe. If you do not have any magma-safe stones available, you can also work around floodgate-based flow control by using [[screw pump]]s to pump the magma over [[wall]]-barriers, or using water to form [[obsidian]] to plug flows and channel through them to reopen them (necessity and invention and all that).

This property is also relevant when choosing the appropriate method for disposing of unneeded items, which can impact [[FPS]] when in large numbers. Items made of non magma-safe materials can be simply dumped into magma, which is the easiest disposal method; however, magma-safe items will need more [[Dwarven atom smasher|drastic]] measures.

Constructions that resist magma are:

* Constructions ([[Wall]], [[Floor]], [[Ramp]], and [[Stairs]]) of any material can never melt or burn - there is nothing wrong with a [[wood]]en magma reservoir. Natural (i.e. non-constructed) [[ice]] walls/floors/ramps/stairs will melt if exposed to sufficient heat.
* [[Fortification]]s will allow the passage of [[magma]]; however, if fortifications fill up to 7/7 depth, magma creatures will be able to swim freely through them.
* If not submerged (that is, not opened to let magma flow over/past/around them), [[door]]s, [[floodgate]]s, and raised [[bridge]]s (provided that there is no magma on the space the bridge would occupy when lowered) of non-magma-safe stone or metal are safe. So long as they are just in contact with magma, only acting as a passive "wall", they are fine. If opened, they will melt.
** Raised drawbridges have a notable exception, in that allowing magma to flow over the center of the area that the bridge would normally occupy when lowered ''will'' cause the bridge's components to heat up and potentially melt.
* A [[pump]] made with magma-safe material for pipes, screws and blocks is fully magma-safe, and will not melt even when submerged in magma. Pumps containing any item that is not magma safe will be destroyed after prolonged operation.

== Game calculations ==
In the game, magma's temperature is exactly {{ct|12000}}.

The chance of striking a magma-safe stone is roughly around 32%, not including the natural abundance of certain stone. It is important to note whether or not your fortress may already have access to magma-safe resources before attempting to deliberately find some.

==Magma-safe material==

The following materials will not melt when submerged in magma. Although true for any item/construction, it's worth specifically mentioning that this includes [[door]]s, [[floor hatch]]es, [[floodgate]]s, [[bridge]]s, [[screw pump]]s, [[pipe section]]s, and [[mechanism]]s.


{{MS table head}}

{{MS table row|Type=Stone|Matl=[[Alunite]]|Appear={{Raw Tile|`|7:7:1}} {{Raw Tile|•|7:1}}|Temp=13,690°U (3722°F/2051°C)|Where=All [[Igneous extrusive layer|Igneous extrusive]]'''(L)''', [[Kaolinite]]'''(L)'''}}

{{MS table row|Type=Stone|Matl=[[Anhydrite]]|Appear={{Raw Tile|v|7:7:1}} {{Raw Tile|•|7:0}}|Temp=12,610°U (2642°F/1450°C)|Where=[[Gypsum]]'''(S)''', [[Satinspar]]'''(1)''', [[Alabaster]]'''(1)''', [[Selenite]]'''(1)'''}}

{{MS table row|Type=Stone|Matl=[[Basalt]]|Appear={{Raw Tile|#|0:7:1}} {{Raw Tile|•|0:1}}|Temp=12,160°U (2192°F/1200°C)|Where=[[Igneous extrusive layer|Igneous extrusive]] layer stone}}

{{MS table row|Type=Stone|Matl=[[Bauxite]]|Appear={{Raw Tile|+|4:7:0}} {{Raw Tile|•|4:0}}|Temp=13,600°U (3632°F/2000°C)|Where=All [[Sedimentary layer|Sedimentary]]'''(L)'''|Notes=dark red}}

{{MS table row|Type=Stone|Matl=[[Calcite]]|Appear={{Raw Tile|"|7:7:1}} {{Raw Tile|•|7:1}}|Temp=12,902°U (2934°F/1613°C)|Where=[[Limestone]]'''(S)''', [[Marble]]'''(S)'''|Notes=[[flux]] stone}}

{{MS table row|Type=Stone|Matl=[[Chert]]|Appear={{Raw Tile|=|6:7:0}} {{Raw Tile|•|6:0}}|Temp=13,101°U (3133°F/1723°C)|Where=[[Sedimentary layer|Sedimentary]] layer stone}}

{{MS table row|Type=Stone|Matl=[[Chromite]]|Appear={{Raw Tile|=|0:7:1}} {{Raw Tile|•|0:1}}|Temp=13,645°U (3677°F/2026°C)|Where=[[Olivine]]'''(V)'''}}

{{MS table row|Type=Stone|Matl=[[Dolomite]]|Appear={{Raw Tile|`|7:7:1}} {{Raw Tile|•|7:1}}|Temp=16,507°U (6539°F/3619°C)|Where=[[Sedimentary layer|Sedimentary]] layer stone|Notes=[[Flux]], Highest melting point of any common stone.}}

{{MS table row|Type=Stone|Matl=[[Gabbro]]|Appear={{Raw Tile|▒|0:7:1}} {{Raw Tile|•|0:1}}|Temp=12,160°U (2192°F/1200°C)|Where=[[Igneous intrusive layer|Igneous intrusive]] layer stone}}

{{MS table row|Type=Stone|Matl=[[Ilmenite]]|Appear={{Raw Tile|.|0:7:1}} {{Raw Tile|•|0:1}}|Temp=12,457°U (2489°F/1365°C)|Where=[[Gabbro]]'''(S)'''}}

{{MS table row|Type=Stone|Matl=[[Kaolinite]]|Appear={{Raw Tile|=|4:7:0}} {{Raw Tile|•|4:0}}|Temp=13,150°U (3182°F/1751°C)|Where=All [[Sedimentary layer|Sedimentary]]'''(L)'''|Notes=dark red, [[porcelain]]}}

{{MS table row|Type=Stone|Matl=[[Mica]]|Appear={{Raw Tile|v|0:7:1}} {{Raw Tile|•|0:1}}|Temp=12,295°U (2327°F/1275°C)|Where=All [[Metamorphic]]'''(L)''', [[Granite]]'''(L)'''}}

{{MS table row|Type=Stone|Matl=[[Obsidian]]|Appear={{Raw Tile|▒|0:7:1}} {{Raw Tile|•|0:1}}|Temp=13,600°U (3632°F/2001°C)|Where=[[Igneous extrusive layer|Igneous extrusive]] layer stone|Notes=value 3, can be "[[obsidian farming|manufactured]]"}}

{{MS table row|Type=Stone|Matl=[[Olivine]]|Appear={{Raw Tile|%|2:7:0}} {{Raw Tile|•|2:0}}|Temp=13,168°U (3200°F/1761°C)|Where=[[Gabbro]]'''(L)'''|Notes=green}}

{{MS table row|Type=Stone|Matl=[[Orthoclase]]|Appear={{Raw Tile|%|6:7:1}} {{Raw Tile|•|6:1}}|Temp=12,250°U (2282°F/1250°C)|Where=All [[Igneous intrusive layer|Igneous intrusive]]'''(L)''', All [[Metamorphic]]'''(L)'''|Notes=yellow}}

{{MS table row|Type=Stone|Matl=[[Periclase]]|Appear={{Raw Tile|,|7:7:1}} {{Raw Tile|•|7:1}}|Temp=15,040°U (5072°F/2803°C)|Where=[[Marble]]'''(S)'''}}

{{MS table row|Type=Stone|Matl=[[Petrified wood]]|Appear={{Raw Tile|%|4:7:1}} {{Raw Tile|•|4:1}}|Temp=12,970°U (3002°F/1650°C)|Where=All [[Sedimentary layer|Sedimentary]]'''(S)'''|Notes=bright red, least dense magma-safe non-economic stone}}

{{MS table row|Type=Stone|Matl=[[Pitchblende]]|Appear={{Raw Tile|*|5:7:0}} {{Raw Tile|•|5:0}}|Temp=12,070°U (2102°F/1149°C)|Where=[[Granite]]'''(S)'''|Notes=purple}}

{{MS table row|Type=Stone|Matl=[[Quartzite]]|Appear={{Raw Tile|-|7:7:1}} {{Raw Tile|•|7:1}}|Temp=12,970°U (3002°F/1650°C)|Where=[[Metamorphic]] layer stone}}

{{MS table row|Type=Stone|Matl=[[Rutile]]|Appear={{Raw Tile|`|5:7:0}} {{Raw Tile|•|5:0}}|Temp=13,285°U (3214°F/1826°C)|Where=All [[Metamorphic]]'''(S)''', [[Granite]]'''(S)'''|Notes=purple}}

{{MS table row|Type=Stone|Matl=[[Sandstone]]|Appear={{Raw Tile|#|6:7:0}} {{Raw Tile|•|6:0}}|Temp=12,070°U (2102°F/1149°C)|Where=[[Sedimentary layer|Sedimentary]] layer stone}}

{{MS table row|Type=Stone|Matl=[[Talc]]|Appear={{Raw Tile|||7:7:1}} {{Raw Tile|•|7:1}}|Temp=12,700°U (2732°F/1500°C)|Where=[[Dolomite]]'''(L)'''}}

{{MS table row|Type=Metal|Matl=[[Adamantine]]|Appear={{Raw Tile|X|3:3:1}} {{Raw Tile|≡|3:1}}|Temp=25,000°U (15,032°F/8333°C)|Notes=Highest value/utility material in game}}

{{MS table row|Type=Metal|Matl=[[Iron]]|Appear={{Raw Tile|X|0:7:1}} {{Raw Tile|≡|0:1}}|Temp=12,768°U (2800°F/1538°C)}}

{{MS table row|Type=Metal|Matl=[[Nickel]]|Appear={{Raw Tile|X|7:3:0}} {{Raw Tile|≡|7:0}}|Temp=12,619°U (2651°F/1455°C)}}

{{MS table row|Type=Metal|Matl=[[Pig iron]]|Appear={{Raw Tile|X|0:7:1}} {{Raw Tile|≡|0:1}}|Temp=12,106°U (2138°F/1170°C)|Notes=used in steel making process}}

{{MS table row|Type=Metal|Matl=[[Platinum]]|Appear={{Raw Tile|X|7:7:1}} {{Raw Tile|≡|7:1}}|Temp=13,182°U (3214°F/1768°C)|Notes=High value metal}}

{{MS table row|Type=Metal|Matl=[[Steel]]|Appear={{Raw Tile|X|0:7:1}} {{Raw Tile|≡|0:1}}|Temp=12,718°U (2750°F/1510°C)|Notes=Armor/weapons}}

{{MS table row|Type=Ore|Matl=[[Cassiterite]]|Appear={{Raw Tile|£|6:7:0}} {{Raw Tile|*|6:0}}|Temp=12,025°U (2057°F/1124°C)|Where=[[Granite]]'''(V)'''|Notes=Ore of [[tin]]}}

{{MS table row|Type=Ore|Matl=[[Galena]]|Appear={{Raw Tile|£|7:7:1}} {{Raw Tile|*|7:1}}|Temp=12,005°U (2037°F/1113°C)|Where=All [[Igneous extrusive layer|Igneous extrusive]]'''(V)''', All [[Metamorphic]]'''(V)''', [[Granite]]'''(V)''', [[Limestone]]'''(V)'''|Notes=Ore of [[lead]] and [[silver]]}}

{{MS table row|Type=Ore|Matl=[[Hematite]]3|Appear={{Raw Tile|£|4:7:0}} {{Raw Tile|*|4:0}}|Temp=12,736°U (2768°F/1520°C)|Where=All [[Sedimentary layer|Sedimentary]]'''(V)''', All [[Igneous extrusive layer|Igneous extrusive]]'''(V)'''|Notes=Ore of [[iron]]3}}

{{MS table row|Type=Ore|Matl=[[Magnetite]]3|Appear={{Raw Tile|~|0:7:1}} {{Raw Tile|*|0:1}}|Temp=12,768°U (2800°F/1538°C)|Where=All [[Sedimentary layer|Sedimentary]]'''(L)'''|Notes=Ore of [[iron]]3}}

{{MS table row|Type=Ore|Matl=[[Native platinum]]|Appear={{Raw Tile|£|7:7:1}} {{Raw Tile|*|7:1}}|Temp=13,182°U (3214°F/1768°C)|Where=[[Olivine]]'''(V)''', [[Magnetite]]'''(V)''', [[Chromite]]'''(S)'''|Notes=Ore of [[platinum]]}}

{{MS table row|Type=Ore|Matl=''[[Sphalerite]]''4|Appear={{Raw Tile|£|0:7:1}} {{Raw Tile|*|0:1}}|Temp=''12,133°U (2165°F/1185°C)''|Where=All [[Metamorphic]]'''(V)'''|Notes=Ore of [[zinc]]4}}

{{MS table row|Type=Wood|Matl=[[Nether-cap]]5|Appear={{Raw Tile|♠|1:0:0}} {{Raw Tile|▬|1:0:0}}|Temp=N/A|Where=[[Cavern]] (depth 3)|Notes=Naturally cold5}}

{{MS table row|Type=Special|Matl=[[Raw adamantine]]|Appear={{Raw Tile|£|3:7:1}} {{Raw Tile|*|3:1}}|Temp=25,000°U (15,032°F/8333°C)|Where=The depths|Notes=Ore of [[adamantine]]}}

{{MS table row|Type=Leather|Matl=[[Fire imp]]|Appear=|Temp=15,000°U (5032°F/2780°C)|Notes=}}
{{MS table row|Type=Leather|Matl=[[Dragon]]|Appear=|Temp=55,000°U (45032°F/25,044°C)|Notes=Dragon scales actually cannot be tanned}}

{{MS table row|Type=Bone|Matl=[[Fire imp]]|Appear=|Temp=15,000°U (5032°F/2780°C)|Notes=}}
{{MS table row|Type=Bone|Matl=[[Dragon]]|Appear=|Temp=55,000°U (45032°F/25,044°C)|Notes=}}

{{MS table row|Type=Glass|Matl=[[Glass|Green glass]]|Appear={{Raw Tile|X|2:2:1}} {{Raw Tile|■|2:0}}|Temp=13,600°U (3632°F/2001°C)|Notes=}}
{{MS table row|Type=Glass|Matl=[[Glass|Clear glass]]|Appear={{Raw Tile|X|3:3:1}} {{Raw Tile|■|3:0}}|Temp=13,600°U (3632°F/2001°C)|Notes=}}
{{MS table row|Type=Glass|Matl=[[Glass|Crystal glass]]|Appear={{Raw Tile|X|7:7:1}} {{Raw Tile|■|7:1}}|Temp=13,600°U (3632°F/2001°C)|Notes=}}

|}

'''Notes:'''
:1. Each stone is one of 16 [[color scheme|colors]] in the game. Different un-mined stone of the same color have a different symbol to distinguish between them. Once mined, the individual stones themselves can sometimes look identical if the color is the same. Use {{k|k}} to loo{{k|k}} at items or the terrain for specific information.
:2. '''°U''' = degrees in [[Main:Urist|Urist]], the measure of temperature within the Dwarf Fortress world. As far as is known, there is no functional difference between a material that melts at {{ct|12005}} or {{ct|55000}} — they are both equally "magma safe".
:3. There are three iron ores in the game (four if you count [[Goblinite]]). Of these, only [[hematite]] and [[magnetite]] are magma safe.
:4. Sphalerite has ''no'' melting point, but ''sublimates'' at {{ct|12133}}. This still qualifies as being magma-safe.
:5. [[Nether-cap]] logs have a fixed temperature of {{ct|10000}}, rendering them fully magma safe, except that nether-cap products [[dump]]ed into magma are destroyed.

{{Magma FAQ}}
{{Category|Physics}}
{{Category|Magma safe materials}}

Magma-safe

2016-02-16T08:26:10Z

Chinchou: Materials can be specified as of 0.42.06. "In order to make magma-safe components" updated accordingly.

{{Quality|Exceptional|01:12, 4 February 2015 (UTC)}}
{{av}}
{{Material properties}}
'''Magma-safe materials''' are materials which will not melt, burn, evaporate, or otherwise take damage when in close contact with [[magma]]. Most frequently, this comes into play when using [[floodgate]]s operated by [[mechanism]]s, or when operating a [[screw pump|magma pump]].

For [[reaction]]s and custom buildings using the [MAGMA_BUILD_SAFE] token, only a material which is solid and stable at the temperature {{ct|12000}} (i.e. MELTING_POINT/BOILING_POINT/IGNITE_POINT/HEATDAM_POINT greater than 12000 and COLDDAM_POINT less than 12000) is considered magma-safe.

In order to construct mechanisms, blocks or other pump components from a magma-safe material, you have several choices:
# You can {{k|d}}esignate a magma-safe rock for your [[mechanisms]] and other components at the workshops.
# Build your mechanisms out of [[iron]] or [[steel]].
# Build your pump components out of iron, steel, [[glass]], or [[nether-cap]].
# Place a [[stockpile]] with the desired stones around your [[mechanic's workshop]] and set it to "Give To a Pile/Workshop".
# Use a [[burrow]] that contains only the workshop and the desired materials.
# Simply ensure that the desired materials are the closest available to your worker. This does not always work, but is usually good enough if you request several jobs, hoping that at least one uses the correct material.

When linking a trigger to an object, the ''first'' mechanism selected is attached to the object, and the ''second'' is attached to the trigger. Unless the trigger itself will be submerged in magma (as could be the case with a [[pressure plate]]), only the first mechanism (attached to the object that will be submerged) needs to be magma-safe. If you do not have any magma-safe stones available, you can also work around floodgate-based flow control by using [[screw pump]]s to pump the magma over [[wall]]-barriers, or using water to form [[obsidian]] to plug flows and channel through them to reopen them (necessity and invention and all that).

This property is also relevant when choosing the appropriate method for disposing of unneeded items, which can impact [[FPS]] when in large numbers. Items made of non magma-safe materials can be simply dumped into magma, which is the easiest disposal method; however, magma-safe items will need more [[Dwarven atom smasher|drastic]] measures.

Constructions that resist magma are:

* Constructions ([[Wall]], [[Floor]], [[Ramp]], and [[Stairs]]) of any material can never melt or burn - there is nothing wrong with a [[wood]]en magma reservoir. Natural (i.e. non-constructed) [[ice]] walls/floors/ramps/stairs will melt if exposed to sufficient heat.
* [[Fortification]]s will allow the passage of [[magma]]; however, if fortifications fill up to 7/7 depth, magma creatures will be able to swim freely through them.
* If not submerged (that is, not opened to let magma flow over/past/around them), [[door]]s, [[floodgate]]s, and raised [[bridge]]s (provided that there is no magma on the space the bridge would occupy when lowered) of non-magma-safe stone or metal are safe. So long as they are just in contact with magma, only acting as a passive "wall", they are fine. If opened, they will melt.
** Raised drawbridges have a notable exception, in that allowing magma to flow over the center of the area that the bridge would normally occupy when lowered ''will'' cause the bridge's components to heat up and potentially melt.
* A [[pump]] made with magma-safe material for pipes, screws and blocks is fully magma-safe, and will not melt even when submerged in magma. Pumps containing any item that is not magma safe will be destroyed after prolonged operation.

== Game calculations ==
In the game, magma's temperature is exactly {{ct|12000}}.

The chance of striking a magma-safe stone is roughly around 32%, not including the natural abundance of certain stone. It is important to note whether or not your fortress may already have access to magma-safe resources before attempting to deliberately find some.

==Magma-safe material==

The following materials will not melt when submerged in magma. Although true for any item/construction, it's worth specifically mentioning that this includes [[door]]s, [[floor hatch]]es, [[floodgate]]s, [[bridge]]s, [[screw pump]]s, [[pipe section]]s, and [[mechanism]]s.


{{MS table head}}

{{MS table row|Type=Stone|Matl=[[Alunite]]|Appear={{Raw Tile|`|7:7:1}} {{Raw Tile|•|7:1}}|Temp=13,690°U (3722°F/2051°C)|Where=All [[Igneous extrusive layer|Igneous extrusive]]'''(L)''', [[Kaolinite]]'''(L)'''}}

{{MS table row|Type=Stone|Matl=[[Anhydrite]]|Appear={{Raw Tile|v|7:7:1}} {{Raw Tile|•|7:0}}|Temp=12,610°U (2642°F/1450°C)|Where=[[Gypsum]]'''(S)''', [[Satinspar]]'''(1)''', [[Alabaster]]'''(1)''', [[Selenite]]'''(1)'''}}

{{MS table row|Type=Stone|Matl=[[Basalt]]|Appear={{Raw Tile|#|0:7:1}} {{Raw Tile|•|0:1}}|Temp=12,160°U (2192°F/1200°C)|Where=[[Igneous extrusive layer|Igneous extrusive]] layer stone}}

{{MS table row|Type=Stone|Matl=[[Bauxite]]|Appear={{Raw Tile|+|4:7:0}} {{Raw Tile|•|4:0}}|Temp=13,600°U (3632°F/2000°C)|Where=All [[Sedimentary layer|Sedimentary]]'''(L)'''|Notes=dark red}}

{{MS table row|Type=Stone|Matl=[[Calcite]]|Appear={{Raw Tile|"|7:7:1}} {{Raw Tile|•|7:1}}|Temp=12,902°U (2934°F/1613°C)|Where=[[Limestone]]'''(S)''', [[Marble]]'''(S)'''|Notes=[[flux]] stone}}

{{MS table row|Type=Stone|Matl=[[Chert]]|Appear={{Raw Tile|=|6:7:0}} {{Raw Tile|•|6:0}}|Temp=13,101°U (3133°F/1723°C)|Where=[[Sedimentary layer|Sedimentary]] layer stone}}

{{MS table row|Type=Stone|Matl=[[Chromite]]|Appear={{Raw Tile|=|0:7:1}} {{Raw Tile|•|0:1}}|Temp=13,645°U (3677°F/2026°C)|Where=[[Olivine]]'''(V)'''}}

{{MS table row|Type=Stone|Matl=[[Dolomite]]|Appear={{Raw Tile|`|7:7:1}} {{Raw Tile|•|7:1}}|Temp=16,507°U (6539°F/3619°C)|Where=[[Sedimentary layer|Sedimentary]] layer stone|Notes=[[Flux]], Highest melting point of any common stone.}}

{{MS table row|Type=Stone|Matl=[[Gabbro]]|Appear={{Raw Tile|▒|0:7:1}} {{Raw Tile|•|0:1}}|Temp=12,160°U (2192°F/1200°C)|Where=[[Igneous intrusive layer|Igneous intrusive]] layer stone}}

{{MS table row|Type=Stone|Matl=[[Ilmenite]]|Appear={{Raw Tile|.|0:7:1}} {{Raw Tile|•|0:1}}|Temp=12,457°U (2489°F/1365°C)|Where=[[Gabbro]]'''(S)'''}}

{{MS table row|Type=Stone|Matl=[[Kaolinite]]|Appear={{Raw Tile|=|4:7:0}} {{Raw Tile|•|4:0}}|Temp=13,150°U (3182°F/1751°C)|Where=All [[Sedimentary layer|Sedimentary]]'''(L)'''|Notes=dark red, [[porcelain]]}}

{{MS table row|Type=Stone|Matl=[[Mica]]|Appear={{Raw Tile|v|0:7:1}} {{Raw Tile|•|0:1}}|Temp=12,295°U (2327°F/1275°C)|Where=All [[Metamorphic]]'''(L)''', [[Granite]]'''(L)'''}}

{{MS table row|Type=Stone|Matl=[[Obsidian]]|Appear={{Raw Tile|▒|0:7:1}} {{Raw Tile|•|0:1}}|Temp=13,600°U (3632°F/2001°C)|Where=[[Igneous extrusive layer|Igneous extrusive]] layer stone|Notes=value 3, can be "[[obsidian farming|manufactured]]"}}

{{MS table row|Type=Stone|Matl=[[Olivine]]|Appear={{Raw Tile|%|2:7:0}} {{Raw Tile|•|2:0}}|Temp=13,168°U (3200°F/1761°C)|Where=[[Gabbro]]'''(L)'''|Notes=green}}

{{MS table row|Type=Stone|Matl=[[Orthoclase]]|Appear={{Raw Tile|%|6:7:1}} {{Raw Tile|•|6:1}}|Temp=12,250°U (2282°F/1250°C)|Where=All [[Igneous intrusive layer|Igneous intrusive]]'''(L)''', All [[Metamorphic]]'''(L)'''|Notes=yellow}}

{{MS table row|Type=Stone|Matl=[[Periclase]]|Appear={{Raw Tile|,|7:7:1}} {{Raw Tile|•|7:1}}|Temp=15,040°U (5072°F/2803°C)|Where=[[Marble]]'''(S)'''}}

{{MS table row|Type=Stone|Matl=[[Petrified wood]]|Appear={{Raw Tile|%|4:7:1}} {{Raw Tile|•|4:1}}|Temp=12,970°U (3002°F/1650°C)|Where=All [[Sedimentary layer|Sedimentary]]'''(S)'''|Notes=bright red, least dense magma-safe non-economic stone}}

{{MS table row|Type=Stone|Matl=[[Pitchblende]]|Appear={{Raw Tile|*|5:7:0}} {{Raw Tile|•|5:0}}|Temp=12,070°U (2102°F/1149°C)|Where=[[Granite]]'''(S)'''|Notes=purple}}

{{MS table row|Type=Stone|Matl=[[Quartzite]]|Appear={{Raw Tile|-|7:7:1}} {{Raw Tile|•|7:1}}|Temp=12,970°U (3002°F/1650°C)|Where=[[Metamorphic]] layer stone}}

{{MS table row|Type=Stone|Matl=[[Rutile]]|Appear={{Raw Tile|`|5:7:0}} {{Raw Tile|•|5:0}}|Temp=13,285°U (3214°F/1826°C)|Where=All [[Metamorphic]]'''(S)''', [[Granite]]'''(S)'''|Notes=purple}}

{{MS table row|Type=Stone|Matl=[[Sandstone]]|Appear={{Raw Tile|#|6:7:0}} {{Raw Tile|•|6:0}}|Temp=12,070°U (2102°F/1149°C)|Where=[[Sedimentary layer|Sedimentary]] layer stone}}

{{MS table row|Type=Stone|Matl=[[Talc]]|Appear={{Raw Tile|||7:7:1}} {{Raw Tile|•|7:1}}|Temp=12,700°U (2732°F/1500°C)|Where=[[Dolomite]]'''(L)'''}}

{{MS table row|Type=Metal|Matl=[[Adamantine]]|Appear={{Raw Tile|X|3:3:1}} {{Raw Tile|≡|3:1}}|Temp=25,000°U (15,032°F/8333°C)|Notes=Highest value/utility material in game}}

{{MS table row|Type=Metal|Matl=[[Iron]]|Appear={{Raw Tile|X|0:7:1}} {{Raw Tile|≡|0:1}}|Temp=12,768°U (2800°F/1538°C)}}

{{MS table row|Type=Metal|Matl=[[Nickel]]|Appear={{Raw Tile|X|7:3:0}} {{Raw Tile|≡|7:0}}|Temp=12,619°U (2651°F/1455°C)}}

{{MS table row|Type=Metal|Matl=[[Pig iron]]|Appear={{Raw Tile|X|0:7:1}} {{Raw Tile|≡|0:1}}|Temp=12,106°U (2138°F/1170°C)|Notes=used in steel making process}}

{{MS table row|Type=Metal|Matl=[[Platinum]]|Appear={{Raw Tile|X|7:7:1}} {{Raw Tile|≡|7:1}}|Temp=13,182°U (3214°F/1768°C)|Notes=High value metal}}

{{MS table row|Type=Metal|Matl=[[Steel]]|Appear={{Raw Tile|X|0:7:1}} {{Raw Tile|≡|0:1}}|Temp=12,718°U (2750°F/1510°C)|Notes=Armor/weapons}}

{{MS table row|Type=Ore|Matl=[[Cassiterite]]|Appear={{Raw Tile|£|6:7:0}} {{Raw Tile|*|6:0}}|Temp=12,025°U (2057°F/1124°C)|Where=[[Granite]]'''(V)'''|Notes=Ore of [[tin]]}}

{{MS table row|Type=Ore|Matl=[[Galena]]|Appear={{Raw Tile|£|7:7:1}} {{Raw Tile|*|7:1}}|Temp=12,005°U (2037°F/1113°C)|Where=All [[Igneous extrusive layer|Igneous extrusive]]'''(V)''', All [[Metamorphic]]'''(V)''', [[Granite]]'''(V)''', [[Limestone]]'''(V)'''|Notes=Ore of [[lead]] and [[silver]]}}

{{MS table row|Type=Ore|Matl=[[Hematite]]3|Appear={{Raw Tile|£|4:7:0}} {{Raw Tile|*|4:0}}|Temp=12,736°U (2768°F/1520°C)|Where=All [[Sedimentary layer|Sedimentary]]'''(V)''', All [[Igneous extrusive layer|Igneous extrusive]]'''(V)'''|Notes=Ore of [[iron]]3}}

{{MS table row|Type=Ore|Matl=[[Magnetite]]3|Appear={{Raw Tile|~|0:7:1}} {{Raw Tile|*|0:1}}|Temp=12,768°U (2800°F/1538°C)|Where=All [[Sedimentary layer|Sedimentary]]'''(L)'''|Notes=Ore of [[iron]]3}}

{{MS table row|Type=Ore|Matl=[[Native platinum]]|Appear={{Raw Tile|£|7:7:1}} {{Raw Tile|*|7:1}}|Temp=13,182°U (3214°F/1768°C)|Where=[[Olivine]]'''(V)''', [[Magnetite]]'''(V)''', [[Chromite]]'''(S)'''|Notes=Ore of [[platinum]]}}

{{MS table row|Type=Ore|Matl=''[[Sphalerite]]''4|Appear={{Raw Tile|£|0:7:1}} {{Raw Tile|*|0:1}}|Temp=''12,133°U (2165°F/1185°C)''|Where=All [[Metamorphic]]'''(V)'''|Notes=Ore of [[zinc]]4}}

{{MS table row|Type=Wood|Matl=[[Nether-cap]]5|Appear={{Raw Tile|♠|1:0:0}} {{Raw Tile|▬|1:0:0}}|Temp=N/A|Where=[[Cavern]] (depth 3)|Notes=Naturally cold5}}

{{MS table row|Type=Special|Matl=[[Raw adamantine]]|Appear={{Raw Tile|£|3:7:1}} {{Raw Tile|*|3:1}}|Temp=25,000°U (15,032°F/8333°C)|Where=The depths|Notes=Ore of [[adamantine]]}}

{{MS table row|Type=Leather|Matl=[[Fire imp]]|Appear=|Temp=15,000°U (5032°F/2780°C)|Notes=}}
{{MS table row|Type=Leather|Matl=[[Dragon]]|Appear=|Temp=55,000°U (45032°F/25,044°C)|Notes=Dragon scales actually cannot be tanned}}

{{MS table row|Type=Bone|Matl=[[Fire imp]]|Appear=|Temp=15,000°U (5032°F/2780°C)|Notes=}}
{{MS table row|Type=Bone|Matl=[[Dragon]]|Appear=|Temp=55,000°U (45032°F/25,044°C)|Notes=}}

{{MS table row|Type=Glass|Matl=[[Glass|Green glass]]|Appear={{Raw Tile|X|2:2:1}} {{Raw Tile|■|2:0}}|Temp=13,600°U (3632°F/2001°C)|Notes=}}
{{MS table row|Type=Glass|Matl=[[Glass|Clear glass]]|Appear={{Raw Tile|X|3:3:1}} {{Raw Tile|■|3:0}}|Temp=13,600°U (3632°F/2001°C)|Notes=}}
{{MS table row|Type=Glass|Matl=[[Glass|Crystal glass]]|Appear={{Raw Tile|X|7:7:1}} {{Raw Tile|■|7:1}}|Temp=13,600°U (3632°F/2001°C)|Notes=}}

|}

'''Notes:'''
:1. Each stone is one of 16 [[color scheme|colors]] in the game. Different un-mined stone of the same color have a different symbol to distinguish between them. Once mined, the individual stones themselves can sometimes look identical if the color is the same. Use {{k|k}} to loo{{k|k}} at items or the terrain for specific information.
:2. '''°U''' = degrees in [[Main:Urist|Urist]], the measure of temperature within the Dwarf Fortress world. As far as is known, there is no functional difference between a material that melts at {{ct|12005}} or {{ct|55000}} — they are both equally "magma safe".
:3. There are three iron ores in the game (four if you count [[Goblinite]]). Of these, only [[hematite]] and [[magnetite]] are magma safe.
:4. Sphalerite has ''no'' melting point, but ''sublimates'' at {{ct|12133}}. This still qualifies as being magma-safe.
:5. [[Nether-cap]] logs have a fixed temperature of {{ct|10000}}, rendering them fully magma safe, except that nether-cap products [[dump]]ed into magma are destroyed.

{{Magma FAQ}}
{{Category|Physics}}
{{Category|Magma safe materials}}

Clutter

2016-02-16T05:55:46Z

Chinchou: /* Benefits */ Minor punctuation correction.

{{Quality|Exceptional|10:25, 18 May 2015 (UTC)}}
{{av}}
Workshops will get cluttered when they become full of goods that are not hauled away to stockpiles. A workshop that is cluttered will display (CLT) when viewed via the q or t menus. t, "View Items in Buildings," will show you what items are cluttering the workshop.

Dwarves working in cluttered workshops will work more slowly: even the lowest level of clutter '''(CLT)''' doubles the time a workshop task takes. Each successive level of clutter increases the multiplier by one, so tasks performed in a completely cluttered workshop will take ten times as long.

== Clutter levels ==
The amount of clutter generated by a single item is determined by its base [[weight]]. All items generate a minimum of 1200 units of clutter.

{| style="margin: 0 auto; text-align: center; border-spacing: 4px"
|+ style="margin: 0 auto" | '''Levels of Clutter'''
|-
! {{Raw Tile|(CLT)|0:0:1}}
| 90000 units
| : 2x slower
|-
! {{Raw Tile|(CLT)|7:0:0}}
| 120000 units
| : 3x slower
|-
! {{Raw Tile|(CLT)|7:0:1}}
| 150000 units
| : 4x slower
|-
! {{Raw Tile|(CLT)|6:0:1}}
| 180000 units
| : 5x slower
|-
! {{Raw Tile|(CLT)|4:0:0}}
| 210000 units
| : 6x slower
|-
! {{Raw Tile|(CLT)|4:0:1}}
| 240000 units
| : 7x slower
|-
! {{Raw Tile|(CLT)|5:0:1}}
| 270000 units
| : 8x slower
|-
! {{Raw Tile|*CLT*|5:0:1}}
| 300000 units
| : 9x slower
|-
! {{Raw Tile|☼CLT☼|5:0:1}}
| 330000 units
| : 10x slower
|}

== Occurrence ==
During normal play, it is unlikely to ever observe workshop clutter outside of the [[butcher's shop]] - even [[slab]]s and [[statue]]s, the largest finished goods, will only clutter a mason's workshop to the ''first'' level once there are 15 of them inside and waiting for storage.

== Remedy ==

To remedy clutter, be sure to have enough stockpile space of the appropriate kind (using [[bin|bins]] will increase stockpile efficiency), and employ enough dwarves with the appropriate [[hauling]] jobs (food/furniture/item/refuse/etc.) to get rid of the junk. The dwarf working at the workshop could also have the relevant hauling job enabled, pausing from time to time to move around goods. In case of inexperienced cooks, order only one or two meals at a time, and check clutter before issuing new orders. An alternate clutter control method is to build new workshops, optionally destroying the old ones (from the {{k|q}} or {{k|t}} menu).

== Benefits ==

There is one upside to clutter, depending on your viewpoint and playstyle. As a workshop's production is slowed, so is their consumption of raw materials and their output if there is little demand. If there is sudden spike of demand, the workshop is easily uncluttered and can work at full speed. The benefit of this is that tasks can be left in repeat mode with no supervision and will not produce much unwanted extras or consume more resources than needed.

A [[still]], for example, can eventually get to the rate where dwarves consume booze at same speed as the cluttered workshops produce it.

[[Wood furnace|Wood furnaces]] similarly will eventually be brought to a point where they produce fuel at same rate as other workshops consume it.

If [[stockpile|stockpiles]] are used with this method, they must all be kept completely full, so that the workshop remains cluttered. Your stockpile will become a sort of buffer to compensate for large spikes in demand. The larger your booze stockpile is, the larger of a spike in demand it can compensate for when, say, a tantrum spiral erupts.

== Bugs ==

* Individual body parts from large animals (like an elephant's tusk) can instantly clutter a workshop. {{Bug|1489}}
* [[Cook]]ing with [[egg]]s creates extreme [[kitchen]] clutter. {{Bug|3994}}

== Production Equilibrium ==
{{Template:D for dwarf}}
The unique dwarven economic system, which has been called 'confusing' at best and 'insane' at worst by most other species, has at least one benefit. The fact that items are rarely moved from where they were made until needed leads to much clutter around workshops. As the clutter builds and makes it more difficult to move around the workshop, production slows more and more. If demand suddenly spikes, the clutter is removed and production rises again. Some scientists see this as an instinctual supply and demand device. Others see it as dumb luck.

{{Translation
| dwarven = om
| elvish = ifeta
| goblin = ozma
| human = rufo
}}

{{Workshops}}
{{Category|Workshops}}

Advanced world generation

2016-02-16T04:10:33Z

Chinchou: A few grammar and spelling fixes.

{{Quality|Exceptional|18:16, 23 August 2014 (UTC)}}
{{av}}
{{old}}

:''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.''
:''See [[World rejection]] for information on solving problems related to worlds always being rejected.''
:''See [[Worldgen examples]] for example worlds.''

When you want more control of what your world looks like, it's time for '''advanced world generation'''. A detailed reference with advice is provided below. This article assumes that you are already familiar with [[World generation|'''basic''' world generation]]. If you are not then please read about that first.

Once you select {{DFtext|Design New World With Advanced Parameters}} from the main menu, a screen that looks something like this will appear:

[[File:AdvancedWorldGen.png‎]]

This screen is relatively intuitive but some parts could use some explanation.

== Parameter sets ==

The list of already defined parameter sets is in the upper right corner. You can select the current set that you want to work with using the up and down directional keys.

Hitting {{K|a}} will add a new set to the end of the list. You can also {{K|c}}opy an existing set to a new one allowing you to base a new set on an existing one. Using {{K|t}} you can change the name of the parameter set but note that this will not affect the name of the world that is generated.

Parameter sets are stored in the <tt>data/init/world_gen.txt</tt> file in the main DF directory. The {{K|F1}} and {{K|F6}} keys will load and save '''all''' of the parameter sets to this file. You will need to save the world gen parameters to this file before you hit {{K|Enter}} to generate the world.

The <tt>world_gen.txt</tt> file can also be edited with a text editor. This is particularly useful because people will often post their parameter sets on the forum or wiki in text form. (See below for more info.) The {{K|F1}} key comes in handy when editing this file while the game is still running.

To get the parameters used to generate a world you are already playing press {{K|ESC}} then choose export images; exporting any image will also create the world generation parameter file, for more information see this [http://www.bay12forums.com/smf/index.php?topic=101280.msg4512541#msg4512541 post].

The tokens used in <tt>world_gen.txt</tt> are at the bottom of each parameter description. Here's the one for title.

{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[TITLE: <name>]</nowiki></tt>
| <tt><nowiki>[TITLE:MEDIUM ISLAND]</nowiki></tt>
| Required
|}

== World name ==

As previously mentioned, the title of the parameter set doesn't affect the name of the world. You can force a particular name for your world using {{K|n}} or set it back to the default random setting using {{K|N}}.

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

== World dimensions ==

The size of the map to be generated can be selected with {{K|u}} {{K|i}} {{K|o}} {{K|p}}. Larger maps take longer to generate and may limit [[Frames per second|FPS]] in game.

Changing the dimensions of the world will reset the parameters because many of them have different defaults depending on the surface area available.

Creating larger worlds does not necessarily mean longer world generation time. The essential factor for the duration is the history. If you restrict the number of historical events you can significantly speed up the process.

{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[DIM:<width>:<height>]</nowiki></tt>
| <tt><nowiki>[DIM:129:129]</nowiki></tt>
| Valid values are 17, 33, 65, 129, and 257. Others may not work.
|}

== Seed values ==

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 older versions, the same seed value(s) produced identical worlds on every computer at any time (if other parameters were identical, too). 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 cumulating to an different world-history at all. It seems like the history is random somhow and not completely connected to the seed. Keep this in mind if you want to regenerate a particular world.

A specific seed value can be entered with {{K|s}}. This will change '''all''' of the seed values to the value you enter. If you need to enter different seed values for each type of seed, use {{K|e}}.

In order to find out what seed values were used for the last world you generated you can look at this screen. If you want to be able to tell someone else how to generate exactly the same world that you just generated, they will need all of the seed value listed under Last Param Set.

When generating a world using a seed, the way that the world is generated is also based at least in part on certain world tokens. As such 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. Saying that, 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 appear to be involved in the implementation of the seed and are not safe to change:

* [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 and the world generation process comes up with seed values based on some sort of "true" random information from things like random values in uninitialized memory, the current date/time, etc. If you have entered a seed value you can revert to all seeds being random using {{K|S}}.

== Generating a world ==

Unless you're using an already defined parameter set you will probably want to {{K|e}}dit the parameters. Select the set you want to edit using the up/down directional keys and press {{K|e}}. Information about each parameter is documented below.

Once you are happy with the parameters you have set, hit {{K|Esc}} to get back to this screen, hit {{K|F6}} to save the values you just edited, and hit {{K|Enter}} to start. The rest of the process is the same as basic [[World generation]].

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

== World painter ==
:''Main article: [[World painter]]
The '''world painter''' tool allows you to paint features onto a map that is then used when generating a world. It is very difficult to use properly, and tends to result in endless rejected worlds, unless you loosen or remove the restrictions placed on biomes and civilizations in the advanced settings. That being said it is also a very powerful tool, and allows you to generate worlds more to your liking.

To access the world painter, hit {{k|e}} to start editing the advanced parameters and finally hit {{k|p}} to open world painter. How to use the world painter is not entirely obvious so please check out the [[World painter]] documentation to avoid frustration. (Losing may be fun, but frustration is not.)

== Editing the parameters init file ==

Parameter sets are stored in the ''data/init/[[world_gen.txt]]'' file, using [[world token]]s. You can copy and paste other player's sets of parameters into your ''world_gen.txt'' to use their parameter sets, and some are provided at [[Main:Pregenerated worlds|Pregenerated worlds]]. Another place to find parameter sets is the [http://www.bay12forums.com/smf/index.php?topic=101280.0 Worldgen cookbook] thread on the official forums.

== Advanced parameters ==

To access advanced parameters, press {{key|e}} when at the screen for creating new worlds with parameters screen. This will bring you to an editable list of various guidelines the world-gen process will use when creating your new world.

The parameters are described below in the order that they appear in the list in the UI, not necessarily the other they appear in the configuration file. See [[world token]] for an index that will help you look things up by token name.

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. Minima and maxima 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. It can be used to set the specific distribution of different elevations or rainfall areas for example.

Rejection Parameters, Dwarf Fortress has 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 isn't right! 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 an re-randomised. Also see [http://dwarffortresswiki.org/index.php/DF2012:World_rejection World Rejection]

The are also the feature placing options such as rivers, mountain peaks, volcanoes and oceans. These can cause rejections if the terrain parameters don't allow enough suitable locations for the features to be placed.

If you are experimenting with world design, one method would be to disable the rejection parameters and use the first two control types. Otherwise any significant change will likely result in endless rejections.

=== Seed values ===

Here you can enter specific seed values for different parts of the world generation process. Different sequences of pseudorandom numbers are used for different parts, so you can use this to reproduce only the particular part of world generation from some previously generated world if you want.

Normally you will want to leave all of these set to Random unless you're specifically trying to reproduce the results of another world generation run.

{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[SEED:<number>]</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.
|-
| <tt><nowiki>[HISTORY_SEED:<number>]</nowiki></tt>
| <tt><nowiki>[HISTORY_SEED:31337]</nowiki></tt>
|-
| <tt><nowiki>[NAME_SEED:<number>]</nowiki></tt>
| <tt><nowiki>[NAME_SEED:31337]</nowiki></tt>
|-
| <tt><nowiki>[CREATURE_SEED:<number>]</nowiki></tt>
| <tt><nowiki>[CREATURE_SEED:31337]</nowiki></tt>
|}

=== Embark Points ===

This controls the number of points that you have for skills and equipment when you embark in fortress mode. Turning this value up will allow games started in this world to start with more skilled dwarves with better equipment. Normally you can do just fine by leaving this value set to default, but you might want to up it for experimental/testing purposes or to help dwarves survive in a particularly evil world.

{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[EMBARK_POINTS:<number>]</nowiki></tt>
| <tt><nowiki>[EMBARK_POINTS:1504]</nowiki></tt>
| Required
|}

=== End year ===

This is how many years of history are generated for the world. This is basically the same as the History parameter in basic world gen, except that you can enter an exact value for number of years. See [[World_generation#History|History]] for more info.

History is divided into "ages" which are determined by the ''percentage'' of megabeasts and semi-megabeasts killed at various points. One can attempt to make a world go through the ages more quickly by pumping up the ratio of semimegabeast to megabeast caves, the former of which are usually more killable than the regular megabeasts. This will net you more "Age of Legends", "Age of Heroes", etc.

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:1050]</nowiki></tt>
| Required
|}

=== Population cap after civ creation ===

This determines the maximum possible population of civilization member historical figures alive at a given time during worldgen. Not all members of a civilization are historical figures. This tag does not directly influence the total population of civilized beings as it once did when populations were all historical figures, so the description is a bit confusing. You can enter -1 to make the historical population unlimited.

Each race may have up to 100 civilizations each, and each civilization a maximum population of 10,000. Civilizations, known as ''entities'' in the [[Raw file|raw files]], have 3 or 4 basic variables that will greatly affect their final placement on the world map. See [[Entity_token#Population|Population (Entity Token)]] for more information on interpreting/editing the raws if you need more precise control of civilization placement and total population numbers.

Huge historical figure populations can cause the size of history data to explode, cause history generation to take forever, lower FPS, and generally slow down the game.

{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[TOTAL_CIV_POPULATION:<number>]</nowiki></tt>
| <tt><nowiki>[TOTAL_CIV_POPULATION:15000]</nowiki></tt>
| Required
|}

=== Site cap after civ creation ===

This controls the maximum number of towns and similar sites on the entire map. Raising the number will allow for more towns, etc. though the number of sites will ultimately still be limited by things like space, terrain, and population cap.

Note that '''this parameter controls only "civilization" sites''' like towns. Other sites such as lairs will be added on to this maximum. After civilizations reach this cap, they will not spread out anymore to place new cities.

By default, the raws limit each civilization site to a population of 120 regardless of the race of the civilization. Therefore, without editing the raws, the total population on the map can't go above site cap x 120.

Increasing this too high can slow worldgen down by a lot, beware. Another effect can be goblins (or other civs) sometimes overwelming all other civs and/or flooding the world with their homes leaving no good places to build your fortress. If you choose a low cap to hasten world generation, the cap will be reached within years stopping expanson of all civs. If you want a good and long history you will have to adjust cap of sites and population as the number of civs many times to find one fullfilling your needs.

{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[SITE_CAP:<number>]</nowiki></tt>
| <tt><nowiki>[SITE_CAP:1040]</nowiki></tt>
| Required
|}

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

If you want to end the creation of your world at the beginning at 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 megabeasts and titans 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 megabeasts and titans 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 meagabeasts and titans 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 ===

Whether or not the game ignores unimportant figures in history generation. The culling is many CPU-intensive steps in history generation but it saves memory and will speed up loading/saving games a bit. This does mean that the "unimportant" figures will not appear in Legends mode or in things like dwarf engravings, but they might not appear in engravings anyway.

Unimportant figures are people or creatures who suffer early deaths, never having offspring or killing anything named during history generation. For example, residents of goblin towers may get murdered by demons at a young age. After culling unimportant figures, Legends mode would say something like the demon has killed "a creature at Eviltower in the year 102."

{| {{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 all information about the history of the world in Legends mode. 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 determine how random values for terrain elevation, rainfall, temperature, drainage, volcanism, and savagery 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. Changing these can cause the occurrence of certain [[Biome|biomes]] to become impossible, so modify these with care. Because of this problem, you may want to use [[#Weighted Ranges|Weighted Ranges]] instead.

By ''subtly'' tweaking the min and max values, vastly different maps can be made.

==== 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.
* River start locations need a minimum elevation of 300. Therefore, a world with a maximum elevation of 299 everywhere prevents river generation, but rivers can still occur if maximum elevation is set to 300.
*Mountain peaks can only form in squares with an elevation of 400.

==== Rainfall ====

Controls the amount of rainfall in each map square/area. Setting the minimum too high or the maximum too low can make the formation of certain biomes impossible. Rainfall causes it to [[Rain]] more in a given area, which can have various effects.

Also makes more rivers appear on the world map.

Note that 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 the specified minimum can occur in the shadow of a mountain. If you want the minimum and maximum for this parameter to be absolutely respected you must turn off the orographic precipitation option.

==== 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. See [[Climate]] for more info.

[[Temperature]] is always influenced by elevation and, if [[Advanced_world_generation#Poles|Poles]] are enabled, latitude. So, the value from the temperature rolling process is ''not the absolute temperature value the region will get, but rather local variation.'' The "base" temperature for an area is derived from its latitude and elevation, and then the random value determined by these parameters are applied to it to make it vary a bit. The default values for the local variation are fairly small compared to the base temperature, which appears to be hard coded.

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

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|Layers]], 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 minimum to 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 too high of a 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 Weights ===

These parameters make it possible to influence the number of squares in a particular range without making conditions outside of that range impossible. For example, you can make it possible for many more low elevation squares to exist without making it impossible for high elevations to form. Changing these parameters is often preferable to simply changing the min/max values.

The basic steps of applying weighted ranges are as follows:

# Create a grid with 2''MeshSize'' - 1 tiles in both X and Y direction.
# Set the intersection points of the grid lines to a random value according to the weighted ranges.
# Smooth out the area between the intersection points.
# Add noise according to the variance parameters.

Where ''MeshSize'' is the raw parameter value found in the world_gen.txt. See the image on the right for an example.

[[File:World_map-large-32x32-elevation-mesh.png|thumb|300px|A large world generated with an Elevation Mesh Size of 32x32 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 or very low and the space between them is smoothed out.]]

==== Mesh Size ====

Mesh size determines how many grid tiles there will be. Setting this to Ignore will cause the weighted range settings to be ignored for that terrain characteristic. As an example, setting it to 2x2 means the grid will be 2 times 2 tiles large and there will be 3 times 3 for a total of 9 intersection points. On a pocket world this means one grid tile will be 8 * 8 world tiles large whereas on a large world one grid tile will be 128 * 128 world tiles. Note that the highest possible value for a given world size will always make the grid tiles 8 * 8 world tiles large.

==== Weighted Ranges ====

If mesh size is set to something other than Ignore, these weights will be applied at the granularity of the selected mesh size for purposes of generating random values in each range. This allows random number generation to be non-linear for the given terrain characteristic.

For example, if the Elevation Weighted Range parameters were set to (starting with the 0-20 range) 60:10:10:10:10 (these values do not have to add up to any particular number) and elevation min and max are set to 1 and 400 respectively then about 60% of the grid line intersection points (on average) 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.

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 Mesh Size and Variance ====

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 large the noise it adds can completely negate the effect of the weighted ranges. For instance, with a 2x2 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 2x2 mesh and barely visible at all with a 8x8 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 2x2 mesh will look essentially the same as a pocket world with a 2x2 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>[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>[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>[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.

{| {{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. 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 but other than that they don't appear to "do" anything special. 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.

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

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 and 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 ===

Worlds with less than this number of volcanoes will be rejected. Note that this will not just create this many volcanoes at random; there must be at least this many squares with a Volcanism of 100. Therefore adjusting Weighted Range for 80-100 to some higher value is recommended if you want to facilitate a large number of volcanoes. In addition, Maximum Volcanism must be set to 100 or squares with volcanism of 100 will be impossible making volcanoes impossible.

{| {{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 lower will increase the amount of ore present on a map, the number of different types of ore, and the number/types of gems. The default value will result in a maximum of 2-4 metal ores per map (assuming you choose a good embark location) which may be limiting until the economy is fully implemented and desired metals can be traded for.

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

{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[MINERAL_SCARCITY:<number>]</nowiki></tt>
| <tt><nowiki>[MINERAL_SCARCITY:2500]</nowiki></tt>
| Range: 100 to 100,000

|}
'''Note:''' as of v0.34, low mineral scarcity settings do not cause rejections.

=== Max Megabeasts Caves ===

This is the number of megabeasts placed at the beginning of history. Megabeasts are hydras, bronze colossuses, rocs and dragons 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-megabeasts placed at the beginning of history. Semi-megabeasts are giants, ettins, minotaurs, and cyclopes, 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 BEAST_END_YEAR calculation.
|}

=== Titan Parameters ===

==== Number ====

This controls the number of titans 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 ====

Megabeasts 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 ====

Megabeasts will begin to attack your fort once you have exported at least this many [[Currency|dwarfbucks]] worth of merchandise, regardless of whether or not any other criteria have been met. This parameter defaults to None (disabled).

==== Created Wealth Requirement ====

Megabeasts 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|Demons]] are similar to titans and forgotten beasts in that they are procedurally generated, but unlike titans they are not unique. Thus many different types of demons will exist in the world but there will be many members of each type. Setting this to zero means no demons will exist, limiting the amount of fun you can have. Thanks to [[Underworld spire|certain fun things]], no demons also means no goblins.

{| {{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|night trolls]] that will exist in the world. These are also procedurally generated. Setting this to zero means that the world will have no night trolls.

{| {{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|bogeyman]] forms that will exist in the world. Bogeyman are procedurally generated, though their forms do not vary by much. Setting this to zero, means that the world will have no bogeyman. Additionally setting this to zero will not allow custom bogeymen to appear in the world.

{| {{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 Vampire Curse Types ===

The number of different [[Vampire|vampires]] that will exist in the world. Although they too are generated at the start of a new world, they generally no different from one another, with the biggest difference being what stat bonuses their vampirism gives {{verify}}. 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
|}

=== Number of Werebeast Curse Types ===

The number of different [[Werebeast|werebeasts]] 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 as different species of animal beasts. From lizards, to wolves, to maybe even bears. Setting this to zero means no werebeasts will exist.

{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[WEREBEAST_NUMBER:<number>]</nowiki></tt>
| <tt><nowiki>[WEREBEAST_NUMBER:58]</nowiki></tt>
| 0 to 1000
|}

=== 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 necromancers. Setting this to zero means that no [[necromancer]]s will appear.

{| {{prettytable}}
|- bgcolor="#dddddd"
! Token
! Example
! Notes
|-
| <tt><nowiki>[SECRET_NUMBER:<number>]</nowiki></tt>
| <tt><nowiki>[SECRET_NUMBER:44]</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]] {{verify}} that can exist in the world. Setting this to zero, while being as pointless as is, (since you're never forced to enter a tomb anyway), will most likely prevent any toilet roll spooks from appearing, but it may or may not also prevent the existence of the pyramids which house them too.

{| {{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 Types ===

This number specifies [[Weather#Evil weather|the total amount of 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. I'd 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
|}

=== Number of Evil Rain Types ===

The lesser of a relatively large group of evils... evil rain. This 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 liquids 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 vaults.

{| {{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
|}

=== 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 exact size of small, medium, and large are: small is 1-24, medium is 25-99, and large is 100+, for any map size. The counts used here will always be restricted to regions of the given size no matter how large the number. 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 exists 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 can not 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 to many evil biomes seem to lead to the danger of an early extincion of many civilizations.

{| {{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 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 ====

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
|-
| 17x17
| 289
|-
| 33x33
| 1089
|-
| 65x65
| 4225
|-
| 129x129
| 16614
|-
| 257x257
| 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}} The rain shadows will always be created as if the wind is blowing from west to east.

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.

==== Cavern Layer Number ====

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

'''Warning:'''
*Disabling caverns by setting this to 0 will make it impossible to grow any underground plants, as none will exist for your civilization to cultivate. (Underground plants will not be available on embark.)

{| {{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 =====

This 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>
|}

See [http://www.bay12forums.com/smf/index.php?topic=76355.0 this forum thread] for more information on openness and density including many more images.

===== Layer Water min\max =====

Determines how many caverns will have water at the bottom. Note that, even at 100, there will be some amount of ground in caverns, but each cavern 'bubble' will contain some amount of water.

At 0, there will be no water in your caverns. This may impact future underground plant growth, although maps will still start with underground flora.{{Verify}}

{| {{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 have 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. (Unknown whether this has any impact on occurrence of HFS "temple".){{Verify}}

{| {{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. 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'' this 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 for 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 very top of second cavern and very bottom of 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 very top of third cavern and very bottom of 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 very highest magma and very bottom of 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 has no impact. Values larger than default results in strange things.
|}

Some implications:
* The number of surface layers (e.g. soil), at this time, can not 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 temple, 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 temples, 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 values can cause strange things to happen. Even more true for small values.

=== Cave Parameters ===

Caves are sort of like caverns except that they have a passage to the surface and are generally much smaller. Caves can connect to caverns if they are sufficiently deep.

==== Minimum/Maximum Natural Cave Size ====

These parameters appear to control the length and depth of caves.

{| {{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 (Non-)Mountain Caves ====

The number of caves that will be generated. Lurking kobolds set up shop in caves and store stolen items here. A setting of 0 in both will stop kobold civilizations from appearing. Special note: a cave is not a 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>
|}

==== 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 as {{Raw Tile|•|#808080|#00DD00}} symbols 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 ===

This parameter doesn't do anything.

{| {{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 civilizations will be placed on the map before history generation begins. These civilizations may later die out due to historical events. The five races are dwarf, elf, human, goblin, and kobold; they will be placed in equal numbers until the quota has been reached. 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].

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. These 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 your 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.

== Default Worldgen Parameters ==

There is no single default for each parameter. Several advanced world generation profiles come with the game by default. See [[world_gen.txt|Default world_gen.txt]] to take a look at this file.

== Parameter Set Examples ==

If you're trying to do something specific then the [[Worldgen examples|Worldgen examples]] might be helpful. These are complete parameter sets that can be copied directly into your ''world_gen.txt'' file and customized as desired.
If they have nothing for you try [[Worldgen Tricks|Worldgen Tricks]], for known tricks 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]

{{World}}