Dwarf Fortress Wiki - User contributions [en]

v0.31:Dwarf

2010-04-14T17:06:30Z

Tfaal: Copied over all the info I could be sure of.

{{av}}
{{elven}}
'''Dwarves''' are "intelligent" {{L|humanoid}} {{L|creatures}} that live in {{L|fortress}}es carved from {{L|mountain}}s. They are the featured {{L|civilization|race}} of {{L|Dwarf Fortress mode|Fortress Mode}} and are also one of the races playable in {{L|Adventure Mode}}. They are mainly interested in acquiring wealth and rare {{L|metal}}s, especially {{L|adamantine}}. They are {{L|alcohol}} dependent and work slowly if deprived of it for long. Their most hated enemies are the {{L|goblin}}s.

Dwarven {{L|children}} become adults at their twelfth birthday.

In accounts of exploits or {{L|fun}}, the generic name {{L|Urist}} is sometimes used in place of any specific dwarf name. Several nicknames for dwarves also exist; one of the more common is '''dorf''', but there are others that are less polite.
{{Game_Data|[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]
[INTELLIGENT]
[TRANCES]
[BENIGN]
[CANOPENDOORS]
[PREFSTRING:beards]
[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]
[BODY_DETAIL_PLAN:HEAD_HAIR_TISSUE_LAYERS]
[USE_TISSUE_TEMPLATE:EYEBROW:EYEBROW_TEMPLATE]
[TISSUE_LAYER:BY_CATEGORY:HEAD:EYEBROW:ABOVE:BY_CATEGORY:EYE]
[USE_TISSUE_TEMPLATE:EYELASH:EYELASH_TEMPLATE]
[TISSUE_LAYER:BY_CATEGORY:EYELID:EYELASH:FRONT]
[USE_MATERIAL_TEMPLATE:NAIL:NAIL_TEMPLATE]
[USE_TISSUE_TEMPLATE:NAIL:NAIL_TEMPLATE]
[TISSUE_LAYER:BY_CATEGORY:FINGER:NAIL:FRONT]
[TISSUE_LAYER:BY_CATEGORY:TOE:NAIL:FRONT]
[SELECT_TISSUE_LAYER:HEART:BY_CATEGORY:HEART]
[PLUS_TISSUE_LAYER:SKIN:BY_CATEGORY:THROAT]
[TL_MAJOR_ARTERIES]
[BODY_DETAIL_PLAN:FACIAL_HAIR_TISSUES]
[BODY_DETAIL_PLAN:STANDARD_HEAD_POSITIONS]
[BODY_DETAIL_PLAN:HUMANOID_HEAD_POSITIONS]
[BODY_DETAIL_PLAN:HUMANOID_RIBCAGE_POSITIONS]
[BODY_DETAIL_PLAN:HUMANOID_RELSIZES]
[RELSIZE:BY_CATEGORY:LIVER:300]
[USE_MATERIAL_TEMPLATE:SINEW:SINEW_TEMPLATE]
[TENDONS:LOCAL_CREATURE_MAT:SINEW:200]
[LIGAMENTS:LOCAL_CREATURE_MAT:SINEW:200]
[HAS_NERVES]
[USE_MATERIAL_TEMPLATE:BLOOD:BLOOD_TEMPLATE]
[BLOOD:LOCAL_CREATURE_MAT:BLOOD:LIQUID]
[CREATURE_CLASS:GENERAL_POISON]
[GETS_WOUND_INFECTIONS]
[GETS_INFECTIONS_FROM_ROT]
[USE_MATERIAL_TEMPLATE:PUS:PUS_TEMPLATE]
[PUS:LOCAL_CREATURE_MAT:PUS:LIQUID]
[PHYS_ATT_RANGE:STRENGTH:450:950:1150:1250:1350:1550:2250] +
[PHYS_ATT_RANGE:AGILITY:150:600:800:900:1000:1100:1500] -
[PHYS_ATT_RANGE:TOUGHNESS:450:950:1150:1250:1350:1550:2250] +
[MENT_ATT_RANGE:ANALYTICAL_ABILITY:450:950:1150:1250:1350:1550:2250] +
[MENT_ATT_RANGE:FOCUS:700:1200:1400:1500:1600:1800:2500] ++
[MENT_ATT_RANGE:CREATIVITY:450:950:1150:1250:1350:1550:2250] +
[MENT_ATT_RANGE:PATIENCE:450:950:1150:1250:1350:1550:2250] +
[MENT_ATT_RANGE:MEMORY:450:950:1150:1250:1350:1550:2250] +
[MENT_ATT_RANGE:SPATIAL_SENSE:700:1200:1400:1500:1600:1800:2500] ++
[BODY_SIZE:0:0:3000]
[BODY_SIZE:1:168:15000]
[BODY_SIZE:12:0:60000]
[BODY_APPEARANCE_MODIFIER:HEIGHT:75:95:98:100:102:105:125]
[APP_MOD_IMPORTANCE:500]
[BODY_APPEARANCE_MODIFIER:BROADNESS:75:95:98:100:102:105:125]
[APP_MOD_IMPORTANCE:500]
[SET_BP_GROUP:BY_CATEGORY:EYE]
[BP_APPEARANCE_MODIFIER:CLOSE_SET:0:70:90:100:110:130:200]
[APP_MOD_NOUN:eyes:PLURAL]
[BP_APPEARANCE_MODIFIER:DEEP_SET:0:70:90:100:110:130:200]
[APP_MOD_NOUN:eyes:PLURAL]
[BP_APPEARANCE_MODIFIER:ROUND_VS_NARROW:0:70:90:100:110:130:200]
[APP_MOD_NOUN:eyes:PLURAL]
[BP_APPEARANCE_MODIFIER:LARGE_IRIS:25:70:90:100:110:130:200]
[APP_MOD_NOUN:eyes:PLURAL]
[SET_BP_GROUP:BY_CATEGORY:LIP]
[BP_APPEARANCE_MODIFIER:THICKNESS:50:70:90:100:110:130:200]
[APP_MOD_NOUN:lips:PLURAL]
[SET_BP_GROUP:BY_CATEGORY:NOSE]
[BP_APPEARANCE_MODIFIER:BROADNESS:25:70:90:100:110:130:200]
[BP_APPEARANCE_MODIFIER:LENGTH:25:70:90:100:110:130:200]
[BP_APPEARANCE_MODIFIER:UPTURNED:0:70:90:100:110:130:200]
[BP_APPEARANCE_MODIFIER:CONVEX:0:70:90:100:110:130:200]
[APP_MOD_NOUN:nose bridge:SINGULAR]
[SET_BP_GROUP:BY_CATEGORY:EAR]
[BP_APPEARANCE_MODIFIER:SPLAYED_OUT:0:70:90:100:110:130:200]
[APP_MOD_NOUN:ears:PLURAL]
[BP_APPEARANCE_MODIFIER:HANGING_LOBES:0:70:90:100:110:130:200]
[APP_MOD_NOUN:ears:PLURAL]
[BP_APPEARANCE_MODIFIER:BROADNESS:90:95:98:100:102:105:110]
[APP_MOD_IMPORTANCE:700]
[APP_MOD_NOUN:ears:PLURAL]
[BP_APPEARANCE_MODIFIER:HEIGHT:90:95:98:100:102:105:110]
[APP_MOD_IMPORTANCE:700]
[APP_MOD_NOUN:ears:PLURAL]
[SET_BP_GROUP:BY_CATEGORY:TOOTH]
[BP_APPEARANCE_MODIFIER:GAPS:0:70:90:100:110:130:200]
[APP_MOD_NOUN:teeth:PLURAL]
[SET_BP_GROUP:BY_CATEGORY:SKULL]
[BP_APPEARANCE_MODIFIER:HIGH_CHEEKBONES:0:70:90:100:110:130:200]
[BP_APPEARANCE_MODIFIER:BROAD_CHIN:0:70:90:100:110:130:200]
[BP_APPEARANCE_MODIFIER:JUTTING_CHIN:0:70:90:100:110:130:200]
[BP_APPEARANCE_MODIFIER:SQUARE_CHIN:0:70:90:100:110:130:200]
[SET_BP_GROUP:BY_CATEGORY:NECK]
[BP_APPEARANCE_MODIFIER:DEEP_VOICE:0:70:90:100:110:130:200]
[BP_APPEARANCE_MODIFIER:RASPY_VOICE:0:70:90:100:110:130:200]
[SET_BP_GROUP:BY_CATEGORY:HEAD]
[BP_APPEARANCE_MODIFIER:BROADNESS:90:95:98:100:102:105:110]
[APP_MOD_IMPORTANCE:700]
[BP_APPEARANCE_MODIFIER:HEIGHT:90:95:98:100:102:105:110]
[APP_MOD_IMPORTANCE:700]
[MAXAGE:150:170]
[ATTACK:PUNCH:BODYPART:BY_TYPE:GRASP]
[ATTACK_SKILL:GRASP_STRIKE]
[ATTACK_VERB:punch:punches]
[ATTACK_CONTACT_PERC:100]
[ATTACK_FLAG_WITH]
[ATTACK_PRIORITY:MAIN]
[ATTACK:KICK:BODYPART:BY_TYPE:STANCE]
[ATTACK_SKILL:STANCE_STRIKE]
[ATTACK_VERB:kick:kicks]
[ATTACK_CONTACT_PERC:100]
[ATTACK_FLAG_WITH]
[ATTACK_PRIORITY:SECOND]
[ATTACK:SCRATCH:CHILD_TISSUE_LAYER_GROUP:BY_TYPE:GRASP:BY_CATEGORY:FINGER:NAIL]
[ATTACK_SKILL:GRASP_STRIKE]
[ATTACK_VERB:scratch:scratches]
[ATTACK_CONTACT_PERC:100]
[ATTACK_PENETRATION_PERC:100]
[ATTACK_FLAG_EDGE]
[ATTACK_PRIORITY:SECOND]
[ATTACK:BITE:CHILD_BODYPART_GROUP:BY_CATEGORY:HEAD:BY_CATEGORY:TOOTH]
[ATTACK_SKILL:BITE]
[ATTACK_VERB:bite:bites]
[ATTACK_CONTACT_PERC:100]
[ATTACK_PENETRATION_PERC:100]
[ATTACK_FLAG_EDGE]
[ATTACK_PRIORITY:SECOND]
[ATTACK_FLAG_CANLATCH]
[BABY:1]
[GENERAL_BABY_NAME:dwarven baby:dwarven babies]
[BABYNAME:dwarven baby:dwarven babies]
[CHILD:12]
[GENERAL_CHILD_NAME:dwarven child:dwarven children]
[CHILDNAME:dwarven child:dwarven children]
[EQUIPS]
[CAVE_ADAPT]
[DIURNAL]
[PROFESSION_NAME:CRAFTSMAN:craftsdwarf:craftsdwarves]
[PROFESSION_NAME:FISHERMAN:fisherdwarf:fisherdwarves]
[PROFESSION_NAME:HAMMERMAN:hammerdwarf:hammerdwarves]
[PROFESSION_NAME:SPEARMAN:speardwarf:speardwarves]
[PROFESSION_NAME:CROSSBOWMAN:marksdwarf:marksdwarves]
[PROFESSION_NAME:AXEMAN:axedwarf:axedwarves]
[PROFESSION_NAME:SWORDSMAN:swordsdwarf:swordsdwarves]
[PROFESSION_NAME:MACEMAN:macedwarf:macedwarves]
[PROFESSION_NAME:PIKEMAN:pikedwarf:pikedwarves]
[PROFESSION_NAME:BOWMAN:bowdwarf:bowdwarves]
[SPEECH:dwarf.txt]
[HOMEOTHERM:10067]
[ALCOHOL_DEPENDENT]
[SWIMS_LEARNED][SWIM_SPEED:2500]
[PERSONALITY:IMMODERATION:0:55:100]
[PERSONALITY:VULNERABILITY:0:45:100]
[PERSONALITY:STRAIGHTFORWARDNESS:0:55:100]
[MANNERISM_FINGERS:finger:fingers]
[MANNERISM_NOSE:nose]
[MANNERISM_EAR:ear]
[MANNERISM_HEAD:head]
[MANNERISM_EYES:eyes]
[MANNERISM_MOUTH:mouth]
[MANNERISM_HAIR:hair]
[MANNERISM_KNUCKLES:knuckles]
[MANNERISM_LIPS:lips]
[MANNERISM_CHEEK:cheek]
[MANNERISM_NAILS:nails]
[MANNERISM_FEET:feet]
[MANNERISM_ARMS:arms]
[MANNERISM_HANDS:hands]
[MANNERISM_TONGUE:tongue]
[MANNERISM_LEG:leg]
[MANNERISM_LAUGH]
[MANNERISM_SMILE]
[MANNERISM_WALK]
[MANNERISM_SIT]
[MANNERISM_BREATH]
[MANNERISM_POSTURE]
[MANNERISM_STRETCH]
[MANNERISM_EYELIDS]
[CASTE:FEMALE]
[FEMALE]
[MULTIPLE_LITTER_RARE]
[CASTE:MALE]
[MALE]
[BODY_DETAIL_PLAN:FACIAL_HAIR_TISSUE_LAYERS]
[SELECT_CASTE:ALL]
[SET_TL_GROUP:BY_CATEGORY:HEAD:HAIR]
[PLUS_TL_GROUP:BY_CATEGORY:HEAD:CHEEK_WHISKERS]
[PLUS_TL_GROUP:BY_CATEGORY:HEAD:CHIN_WHISKERS]
[PLUS_TL_GROUP:BY_CATEGORY:HEAD:MOUSTACHE]
[PLUS_TL_GROUP:BY_CATEGORY:HEAD:SIDEBURNS]
[PLUS_TL_GROUP:BY_CATEGORY:HEAD:EYEBROW]
[PLUS_TL_GROUP:BY_CATEGORY:HEAD:EYELASH] [TL_COLOR_MODIFIER:AMBER:1:AUBURN:1:BLACK:1:BROWN:1:BUFF:1:BURNT_SIENNA:1:BURNT_UMBER:1:CHARCOAL:1:CHESTNUT:1:CHOCOLATE:1:CINNAMON:1:COPPER:1:DARK_BROWN:1:DARK_CHESTNUT:1:DARK_TAN:1:ECRU:1:FLAX:1:GOLD:1:GOLDEN_YELLOW:1:GOLDENROD:1:LIGHT_BROWN:1:MAHOGANY:1:OCHRE:1:PALE_BROWN:1:PALE_CHESTNUT:1:PUMPKIN:1:RAW_UMBER:1:RUSSET:1:SAFFRON:1:SEPIA:1:TAN:1:TAUPE_DARK:1:TAUPE_GRAY:1:TAUPE_MEDIUM:1:TAUPE_PALE:1:TAUPE_SANDY:1]
[TLCM_NOUN:hair:SINGULAR]
[TL_COLOR_MODIFIER:GRAY:1]
[TLCM_NOUN:hair:SINGULAR]
[TLCM_TIMING:ROOT:80:0:130:0]
[TL_COLOR_MODIFIER:WHITE:1]
[TLCM_NOUN:hair:SINGULAR]
[TLCM_TIMING:ROOT:130:0:150:0]
[SET_TL_GROUP:BY_CATEGORY:HEAD:EYEBROW]
[TISSUE_LAYER_APPEARANCE_MODIFIER:LENGTH:50:80:90:100:110:120:150]
[APP_MOD_NOUN:eyebrows:PLURAL]
[TISSUE_LAYER_APPEARANCE_MODIFIER:DENSE:50:80:90:100:110:120:150]
[APP_MOD_NOUN:eyebrows:PLURAL]
[TISSUE_LAYER_APPEARANCE_MODIFIER:HIGH_POSITION:0:70:90:100:110:130:200]
[APP_MOD_NOUN:eyebrows:PLURAL]
[SET_TL_GROUP:BY_CATEGORY:HEAD:EYELASH]
[TISSUE_LAYER_APPEARANCE_MODIFIER:LENGTH:50:80:90:100:110:120:150]
[APP_MOD_NOUN:eyelashes:PLURAL]
[SET_TL_GROUP:BY_CATEGORY:HEAD:HAIR]
[PLUS_TL_GROUP:BY_CATEGORY:HEAD:CHEEK_WHISKERS]
[PLUS_TL_GROUP:BY_CATEGORY:HEAD:CHIN_WHISKERS]
[PLUS_TL_GROUP:BY_CATEGORY:HEAD:MOUSTACHE]
[PLUS_TL_GROUP:BY_CATEGORY:HEAD:SIDEBURNS]
[TISSUE_LAYER_APPEARANCE_MODIFIER:LENGTH:0:0:0:0:0:0:0]
[APP_MOD_NOUN:hair:SINGULAR]
[APP_MOD_RATE:1:DAILY:0:1000:0:0:NO_END]
[TISSUE_LAYER_APPEARANCE_MODIFIER:CURLY:0:70:90:100:110:130:200]
[APP_MOD_NOUN:hair:SINGULAR]
[TISSUE_LAYER_APPEARANCE_MODIFIER:GREASY:0:70:90:100:110:130:200]
[APP_MOD_NOUN:hair:SINGULAR]
[TISSUE_LAYER_APPEARANCE_MODIFIER:DENSE:50:80:90:100:110:120:150]
[APP_MOD_NOUN:hair:SINGULAR]
[SET_TL_GROUP:BY_CATEGORY:HEAD:HAIR]
[TISSUE_STYLE_UNIT:HAIR:STANDARD_HAIR_SHAPINGS]
[TSU_NOUN:hair:SINGULAR]
[SET_TL_GROUP:BY_CATEGORY:HEAD:CHEEK_WHISKERS]
[PLUS_TL_GROUP:BY_CATEGORY:HEAD:CHIN_WHISKERS]
[TISSUE_STYLE_UNIT:BEARD:STANDARD_BEARD_SHAPINGS]
[TSU_NOUN:beard:SINGULAR]
[SET_TL_GROUP:BY_CATEGORY:HEAD:MOUSTACHE]
[TISSUE_STYLE_UNIT:MOUSTACHE:STANDARD_MOUSTACHE_SHAPINGS]
[TSU_NOUN:moustache:SINGULAR]
[SET_TL_GROUP:BY_CATEGORY:HEAD:SIDEBURNS]
[TISSUE_STYLE_UNIT:SIDEBURNS:STANDARD_SIDEBURNS_SHAPINGS]
[TSU_NOUN:sideburns:PLURAL]
SET_TL_GROUP:BY_CATEGORY:FINGER:NAIL]
PLUS_TL_GROUP:BY_CATEGORY:TOE:NAIL]
TISSUE_LAYER_APPEARANCE_MODIFIER:LENGTH:100:100:100:100:100:100:100]
APP_MOD_RATE:1:DAILY:0:1000:0:0:NO_END]
APP_MOD_NOUN:nails:PLURAL]
[SET_TL_GROUP:BY_CATEGORY:ALL:SKIN] [TL_COLOR_MODIFIER:BROWN:1:BURNT_UMBER:1:CINNAMON:1:COPPER:1:DARK_BROWN:1:DARK_PEACH:1:DARK_TAN:1:ECRU:1:PALE_BROWN:1:PALE_CHESTNUT:1:PALE_PINK:1:PEACH:1:PINK:1:RAW_UMBER:1:SEPIA:1:TAN:1:TAUPE_PALE:1:TAUPE_SANDY:1]
[TLCM_NOUN:skin:SINGULAR]
[TISSUE_LAYER_APPEARANCE_MODIFIER:WRINKLY:0:0:0:0:0:0:0]
[APP_MOD_RATE:1:YEARLY:0:100:60:0:NO_END]
[APP_MOD_NOUN:skin:SINGULAR]
[SET_TL_GROUP:BY_CATEGORY:EYE:EYE] [TL_COLOR_MODIFIER:IRIS_EYE_AMETHYST:1:IRIS_EYE_AQUAMARINE:1:IRIS_EYE_BRASS:1:IRIS_EYE_BRONZE:1:IRIS_EYE_COBALT:1:IRIS_EYE_COPPER:1:IRIS_EYE_EMERALD:1:IRIS_EYE_GOLD:1:IRIS_EYE_HELIOTROPE:1:IRIS_EYE_JADE:1:IRIS_EYE_OCHRE:1:IRIS_EYE_RAW_UMBER:1:IRIS_EYE_RUST:1:IRIS_EYE_SILVER:1:IRIS_EYE_SLATE_GRAY:1:IRIS_EYE_TURQUOISE:1]
[TLCM_NOUN:eyes:PLURAL]}}
[[Category:Creatures]]

v0.31:Centaur

2010-04-11T16:42:48Z

Tfaal: Removed {{verify}} template, because they've got DOES_NOT_EXIST spelled out in big capital letters in their raws.

{{av}}
{{CreatureInfo|name=Centaur|biome=None|symbol=C|color=rgb(128, 128, 0)|butcher=no}}

A '''Centaur''' is a [[fanciful]] creature which is merely the stuff of legends. They do not actually exist, appearing only in [[engravings]] as the fancy of artists, as there is no such thing as [[magic]].

Dwarf Fortress presently does not include a robust or finalized [[magic]] system, so they are in the game's [[:category:modding|raw object data]] only in order to allow them to appear in engravings.

{{Game_Data|[CREATURE:CENTAUR]
[NAME:centaur:centaurs:centaur]
[CREATURE_TILE:'C'][COLOR:6:0:0]
[FANCIFUL]
[DOES_NOT_EXIST]
[PREFSTRING:strength]
[ALL_ACTIVE]
[CASTE:FEMALE]
[CASTE_NAME:centauress:centauresses:centauress]
[FEMALE]
[CASTE:MALE]
[CASTE_NAME:centaur:centaurs:centaur]
[MALE] }}

[[Category:Creatures]]

v0.31:Quickstart guide

2010-04-05T20:56:02Z

Tfaal:

{{av}}
Much of the information in the [[40d:Quickstart_guide|guide for the previous version]] still applies. However, information on the [[military]] and [[healthcare]], as well as almost everything to do with the underground is likely to be deprecated. Be aware that the unstable nature of version 0.31.01 means that it may be difficult for a new player to determine whether they have done some procedure incorrectly or if they have encountered one of the new version's numerous [[bug]]s.

v0.31:Quickstart guide

2010-04-05T20:54:58Z

Tfaal:

{{av}}
Much of the information in the [[40d:Quickstart Guide|guide for the previous version]] still applies. However, information on the [[military]] and [[healthcare]], as well as almost everything to do with the underground is likely to be deprecated. Be aware that the unstable nature of version 0.31.01 means that it may be difficult for a new player to determine whether they have done some procedure incorrectly or if they have encountered one of the new version's numerous [[bug]]s.

v0.31 Talk:Titan

2010-04-05T20:37:25Z

Tfaal:

There's a chance that default humanoid titans as we know them might cease to exist in DF 2010, '''if that happens''', [[Titan]] should be edited to accomodate info on the old titans and the new ones, instead of keeping a page for something that doesn't exist in the game anymore. [[User:Dakk|Dakk]] 21:09, 30 March 2010 (UTC)
:No, actually it shouldn't. What will happen is this:
:*In the 40d namespace, the ''existing'' "titan" article, '''[[40d:titan]]''', will remain as is, untouched - still valid and accurate as it stands for this version.
:*A ''new'' article will be created for "'''[[DF2010:Titan|( newversion# ):titan]]'''", to be forever consistent with all other newversion# articles.*
:*The Search term "titan" will redirect to "'''[[cv:titan|cv:titan]]'''", which it does now, so no edit necessary there. ''("cv" = "current version", so "titan" redirects to 40d now, and will redirect to the next version as soon as we have that one up and running.*)''
:That's how it's going to work with many, ''many'' articles that share names but not details between the present version and the one we might have within a week.
::''(* As a side note/reminder, all users should be conscious that there will be no [[version]] called "DF2010" - it will have a significant reference number like "40d" or "23a" or whatever, but exactly what that number will be we won't know until [[Toady]] tells us, which might not be until the release itself.)''
: --[[User:Albedo|Albedo]] 21:32, 30 March 2010 (UTC)

In my opinion, the Titan article should be the default page for both Titans ( as in, the overland big boys ) as well as a subarticle on the same page for Forgotten Beasts, since Forgotten Beasts are just basically subterranean Titans.
--[[User:Pathos|Pathos]] 15:05, 3 April 2010 (UTC)

==Are multiple articles really nescessary?==

Really, its silly to keep two pages, one for the old version and one for the new version. It'll only confuse new users and take up more space. Why not just merge both articles, with a section in the end called '''''Titans in old versions''''' just like every other game wiki does with features that have been changed drastically? It'd make things alot less clunky and confusing to people who are new to DF, and take up less space. [[User:Dakk|Dakk]] 23:53, 3 April 2010 (UTC)
:The way the admins have set up the version namespaces allows players searching from DF2010 (or whatever it will be called) pages to find DF2010 pages and likewise 40d to 40d and so on. So yeah, it's really confusing right now, but once some time has gone by and all the new stubs have been expanded into full pages and the stable release has gotten everyone playing this version, it'll cease to be an issue. --[[User:Retro|Retro]] 00:03, 4 April 2010 (UTC)

==Actually a spoiler?==

Are titans really that spoilerific? Anyone looking through the legends screen can see them, and people even come to worship them! They're pretty hard to miss. --[[User:Tfaal|Tfaal]] 20:37, 5 April 2010 (UTC)

User:Tfaal/monobook.js

2010-04-05T18:58:10Z

Tfaal: Created page with 'importScript('User:Briess/hideAnnouncements.js');'

importScript('User:Briess/hideAnnouncements.js');

User:Tfaal/The Complete Dorf's Guide to Bodies

2010-04-05T18:56:15Z

Tfaal:

Bodies in Dwarf Fortress, as in real life, are complicated things. But while creating a functioning body from scratch in the real world will take you years of research and a descent into mad science, creating one in Dwarf Fortress only takes a few minutes, and keeps the mad science down to manageable levels. So hook up the lightning rod, throw on your goggles and practice your evil laugh, because we're about to stitch together some giblets.

Body parts are defined by the BP tag in the body_default file, and grouped together in collections with the BODY tag:
[BODY:BASIC_1PARTBODY]
[BP:UB:body:bodies][UPPERBODY][LOWERBODY][CATEGORY:BODY]
[DEFAULT_RELSIZE:2000]
This creates a body part called "body" with a relative size of 2000. Now, if body parts were all just made like that, there would be nothing telling the creature file how to put them together. So for limbs, organs and such, we do it like this:
[BODY:BASIC_3PARTARMS]
[BP:RUA:right upper arm:STP][CONTYPE:UPPERBODY][LIMB][RIGHT][CATEGORY:ARM_UPPER]
[DEFAULT_RELSIZE:200]
. . .
That CONTYPE tag tells the right upper arm to connect with all body parts that have the UPPERBODY tag. There is no limitation on tags here. If I gave the upper body the SQUEDLEYSPOOCH tag, and then gave everything that connected to it CONTYPE:SQUEDLEYSPOOCH, it would work just fine. If I wanted to connect with that part specifically, I would use the CON tag. The syntax for the con tag is this:
[CON:RUA]
That tag tells the body part to connect with the part that has this pattern
[BP:RUA:blah blah blah:blah blah blah]
As you can see, the right upper arm fits this pattern, and so the two parts are connected.

In the creature_whatever file, these collections of body parts are then called via the BODY tag, like so:
[BODY:BODY_WITH_HEAD_FLAG:HEART:GUTS:BRAIN:MOUTH]
Here, things start getting complicated. In the material_template_default file, all of the physical properties of a given material are defined. Ignition point, shear yield, that kinda stuff. Here's the file for skin, as an example:
[MATERIAL_TEMPLATE:SKIN_TEMPLATE]
[STATE_COLOR:ALL_SOLID:GRAY]
[STATE_NAME:ALL_SOLID:skin]
[STATE_ADJ:ALL_SOLID:skin]
Completely independent of this, the tissue_template_default file defines all the biological aspects of a tissue:
[TISSUE_TEMPLATE:SKIN_TEMPLATE]
[TISSUE_NAME:skin:NP]
[SCARS]
[TISSUE_MATERIAL:LOCAL_CREATURE_MAT:SKIN]
[RELATIVE_THICKNESS:1]
[HEALING_RATE:100]
[VASCULAR:1]
[PAIN_RECEPTORS:5]
[CONNECTS]
[TISSUE_SHAPE:LAYER]
In the b_detail_plan_default file, material and tissue templates come together. First the materials are imported, --

[BODY_DETAIL_PLAN:STANDARD_MATERIALS]
[ADD_MATERIAL:SKIN:SKIN_TEMPLATE]
[ADD_MATERIAL:FAT:FAT_TEMPLATE]
[ADD_MATERIAL:MUSCLE:MUSCLE_TEMPLATE]
. . .
-- then the tissues:
[BODY_DETAIL_PLAN:STANDARD_TISSUES]
[ADD_TISSUE:SKIN:SKIN_TEMPLATE]
[ADD_TISSUE:FAT:FAT_TEMPLATE]
. . .
Bear in mind that the b_detail_plan_default file only exists to make the creature_whatever files shorter. These things could just as effectively be done there.

Now we get to the meat of this. Adding the tissues to the body parts. This big ugly line here --
[BP_LAYERS:BY_CATEGORY:BODY:ARG3:50:ARG2:5:ARG1:1]
-- is basically saying "Take all parts that have the CATEGORY:UPPERBODY tag, and give them 50 thickness units of ARG3, 5 thickness units of ARG2, and 1 thickness unit of ARG1." What are those? That's up to the creature_whatever file to decide. Let's have a look at the dwarf entry in creature_standard:
[BODY_DETAIL_PLAN:VERTEBRATE_TISSUE_LAYERS:SKIN:FAT:MUSCLE:BONE:CARTILAGE]
As you can see, the first thing after VERTEBRATE_TISSUE_LAYERS is SKIN, so the ARG1 from b_detail_plan_default gets translated into skin. The same applies for fat, muscle, etc. So that line ends up reading as "Take the upper body, and add 50 thickness units of muscle, 5 thickness units of fat, and 1 thickness unit of skin." And there you have it! The upper body is defined. From here, defining organs is very similar. The only major thing left are body part positions and relations. Positions tell a body part where it is in relation to it's parent body part (the body part closer to the torso), like this:
. . .
[BP_POSITION:BY_CATEGORY:CHEEK:FRONT]
[BP_POSITION:BY_TOKEN:R_EAR:RIGHT]
[BP_POSITION:BY_TOKEN:L_EAR:LEFT]
. . .

Which translates too "Place everything in CATEGORY:CHEEK at the front of it's parent body part, then place the body part with token R_EAR on the right side of it's parent body part, etc." Relations are similar, but instead of giving position in terms of the parent body part, they do so in terms of other, disconnected body parts:
. . .
[BP_RELATION:BY_CATEGORY:CHEEK:AROUND:BY_CATEGORY:TEETH:100]
[BP_RELATION:BY_CATEGORY:CHEEK:AROUND:BY_CATEGORY:MOUTH:100]
[BP_RELATION:BY_CATEGORY:LIP:AROUND:BY_CATEGORY:MOUTH:100]
. . .
Well, that's about all there is to know about bodies. Hope this helped!

User:Tfaal/The Complete Dorf's Guide to Bodies

2010-04-05T18:54:27Z

Tfaal: General style stuff. Still not sure on colon usage and ellipses. A better grammarian than me should probably give this a once over.

Bodies in Dwarf Fortress, as in real life, are complicated things. But while creating a functioning body from scratch in the real world will take you years of research and a descent into mad science, creating one in Dwarf Fortress only takes a few minutes, and keeps the mad science down to manageable levels. So hook up the lightning rod, throw on your goggles and practice your evil laugh, because we're about to stitch together some giblets.

Body parts are defined by the BP tag in the body_default file, and grouped together in collections with the BODY tag:
[BODY:BASIC_1PARTBODY]
[BP:UB:body:bodies][UPPERBODY][LOWERBODY][CATEGORY:BODY]
[DEFAULT_RELSIZE:2000]
This creates a body part called "body" with a relative size of 2000. Now, if body parts were all just made like that, there would be nothing telling the creature file how to put them together. So for limbs, organs and such, we do it like this:
[BODY:BASIC_3PARTARMS]
[BP:RUA:right upper arm:STP][CONTYPE:UPPERBODY][LIMB][RIGHT][CATEGORY:ARM_UPPER]
[DEFAULT_RELSIZE:200]
. . .
That CONTYPE tag tells the right upper arm to connect with all body parts that have the UPPERBODY tag. There is no limitation on tags here. If I gave the upper body the SQUEDLEYSPOOCH tag, and then gave everything that connected to it CONTYPE:SQUEDLEYSPOOCH, it would work just fine. If I wanted to connect with that part specifically, I would use the CON tag. The syntax for the con tag is this:
[CON:RUA]
That tag tells the body part to connect with the part that has this pattern
[BP:RUA:blah blah blah:blah blah blah]
As you can see, the right upper arm fits this pattern, and so the two parts are connected.

In the creature_whatever file, these collections of body parts are then called via the BODY tag, like so:
[BODY:BODY_WITH_HEAD_FLAG:HEART:GUTS:BRAIN:MOUTH]
Here, things start getting complicated. In the material_template_default file, all of the physical properties of a given material are defined. Ignition point, shear yield, that kinda stuff. Here's the file for skin, as an example:
[MATERIAL_TEMPLATE:SKIN_TEMPLATE]
[STATE_COLOR:ALL_SOLID:GRAY]
[STATE_NAME:ALL_SOLID:skin]
[STATE_ADJ:ALL_SOLID:skin]
Completely independent of this, the tissue_template_default file defines all the biological aspects of a tissue:
[TISSUE_TEMPLATE:SKIN_TEMPLATE]
[TISSUE_NAME:skin:NP]
[SCARS]
[TISSUE_MATERIAL:LOCAL_CREATURE_MAT:SKIN]
[RELATIVE_THICKNESS:1]
[HEALING_RATE:100]
[VASCULAR:1]
[PAIN_RECEPTORS:5]
[CONNECTS]
[TISSUE_SHAPE:LAYER]
In the b_detail_plan_default file, material and tissue templates come together. First the materials are imported...

[BODY_DETAIL_PLAN:STANDARD_MATERIALS]
[ADD_MATERIAL:SKIN:SKIN_TEMPLATE]
[ADD_MATERIAL:FAT:FAT_TEMPLATE]
[ADD_MATERIAL:MUSCLE:MUSCLE_TEMPLATE]
. . .
then the tissues:
[BODY_DETAIL_PLAN:STANDARD_TISSUES]
[ADD_TISSUE:SKIN:SKIN_TEMPLATE]
[ADD_TISSUE:FAT:FAT_TEMPLATE]
. . .
Bear in mind that the b_detail_plan_default file only exists to make the creature_whatever files shorter. These things could just as effectively be done there.

Now we get to the meat of this. Adding the tissues to the body parts. This big ugly line here...
[BP_LAYERS:BY_CATEGORY:BODY:ARG3:50:ARG2:5:ARG1:1]
... is basically saying "Take all parts that have the CATEGORY:UPPERBODY tag, and give them 50 thickness units of ARG3, 5 thickness units of ARG2, and 1 thickness unit of ARG1." What are those? That's up to the creature_whatever file to decide. Let's have a look at the dwarf entry in creature_standard:
[BODY_DETAIL_PLAN:VERTEBRATE_TISSUE_LAYERS:SKIN:FAT:MUSCLE:BONE:CARTILAGE]
As you can see, the first thing after VERTEBRATE_TISSUE_LAYERS is SKIN, so the ARG1 from b_detail_plan_default gets translated into skin. The same applies for fat, muscle, etc. So that line ends up reading as "Take the upper body, and add 50 thickness units of muscle, 5 thickness units of fat, and 1 thickness unit of skin." And there you have it! The upper body is defined. From here, defining organs is very similar. The only major thing left are body part positions and relations. Positions tell a body part where it is in relation to it's parent body part (the body part closer to the torso), like this:
. . .
[BP_POSITION:BY_CATEGORY:CHEEK:FRONT]
[BP_POSITION:BY_TOKEN:R_EAR:RIGHT]
[BP_POSITION:BY_TOKEN:L_EAR:LEFT]
. . .

Which translates too "Place everything in CATEGORY:CHEEK at the front of it's parent body part, then place the body part with token R_EAR on the right side of it's parent body part, etc." Relations are similar, but instead of giving position in terms of the parent body part, they do so in terms of other, disconnected body parts:
. . .
[BP_RELATION:BY_CATEGORY:CHEEK:AROUND:BY_CATEGORY:TEETH:100]
[BP_RELATION:BY_CATEGORY:CHEEK:AROUND:BY_CATEGORY:MOUTH:100]
[BP_RELATION:BY_CATEGORY:LIP:AROUND:BY_CATEGORY:MOUTH:100]
. . .
Well, that's about all there is to know about bodies. Hope this helped!

Talk:Main Page/archive2

2010-04-05T16:43:06Z

Tfaal:

{{Archive|
# [[Talk:Main Page/archive1|Archive 1]]
}}

== DF2010 Title needs changing ==

The new version is now df_31_01 and each article beginning with "DF2010" seems tacky. Any others agree it should be changed to df31 or something around like that? [[User:Richards|Richards]] 19:59, 1 April 2010 (UTC)
:The problem is that we version the wiki for each game-save compatibility change. Simply changing it to 31.01 would fix it now, but when 31.02 - 39.07 come out, and then finally 40.01 comes out that breaks save compatibility, we have much more work to do. Until we know the final version number in the series, it's not easy for us to just say "oh, this is it." --[[User:Briess|Briess]] 20:02, 1 April 2010 (UTC)
::And wtf is the precedent? In all the versions of the wiki I've seen, versions are always specified as the actual number. How is it more clear to use DF2010 instead of v0.31.01? --Peewee 09:57, 2 April 2010 (UTC)

:If you aren't planning to make more special version namespaces for a while, let's use the main namespace. Also, you guys really need to talk things out more before implementing giant sweeping changes. The more I see you describe your respective visions for the wiki, the more different they seem from each other. [[User:VengefulDonut|VengefulDonut]] 11:29, 2 April 2010 (UTC)

::Well. A solution would be to make every article title for the current version just say the article name, ex/ instead of "DF2010:Armor", make it "Armor", like last time. If a new version is released that is different, then archive it as whatever version it last applied to, like "40d:Armor, or 31.01:Armor". Is there any problem with this idea? [[User:Richards|Richards]] 14:28, 2 April 2010 (UTC)

Yes, there is. (Namely, the amount of labor you're talking about if pages are not set-up for that.)

Here's "The Plan", which was set up a couple months ago (and which has been discussed elsewhere, but we'll do it one more time)...
:* Old versions are clearly labeled and consistently linked internally. All 40d links bounce around only to 40d articles, so if a player is researching that version, it's all one package. ''(Same w/ 23a, the "2-D" version previous to that, but an ongoing and lower-priority project.)''
:* "New" versions are, likewise, consistent within themselves. Versionless search terms (like "[[stone]]" automatically default to "current version".
:* Future versions get their own version names, "current" becomes one-older, and the pattern continues.
The current PROBLEM is three-fold - the first is the changeover itself, when first time Editors start firing away at articles without the correct names or understanding The Plan. That is understandable, but compounded by the fact that we don't currently ''know'' the "proper" version number to use - is it 0.31.01, or 0.31, or 31.01 - when the first bugfix comes out, what will be changed and what kept? What part of that number constitutes/defines this as a "version"? There is no equiv of 23.a or 40.d - it's a new code, and we weren't given the codebook. (We're waiting on Three-toe/Toady for a response on that.) The 3rd problem is "DF2010" - which is wrong, but while popular and everyone is using it, it won't be very friendly later down the road.

So... we've got something that works now but won't in the future, and needs to be changed to be consistent so we don't bequeath future Admin and users the big bone. A diff between more work now and the sort of complete cluster that has gone on behind the scenes for the last 2 months preparing for this change - which is going SO MUCH SMOOTHER NOW (believe it or not!) because of that (thankless, ahem) preparation.

Once we know the correct version, all current articles will appear as that. Search terms will default to current version. Older articles will be consistent within their own namespace. AND we'll be setup for future version changes without quite so much trauma (which is ''why'' some of the more obscure of these changes are being implemented). Clear as mud?--[[User:Albedo|Albedo]] 19:06, 2 April 2010 (UTC)

:Are you basically trying to say that DF2010 is a convenient placeholder string that can be used to identify and move articles by bot when we get a stable version number from Toady? --[[User:Squirrelloid|Squirrelloid]] 19:20, 2 April 2010 (UTC)

::Dammit, if I could express myself in anything less than 500 words at a time, I would have! (Yes, that's basically what I'm saying.)--[[User:Albedo|Albedo]] 19:31, 2 April 2010 (UTC)

:::I'm not sure who wins the eloquence award here. Anyways, we're still waiting on information from ToadyOne before we rename DF2010 to something else more appropriate. --[[User:Briess|Briess]] 19:37, 2 April 2010 (UTC)

:::: Toady has already said that he plans to aim for possibly as often as a weekly bugfix release while the early issues of this release get ironed out. Trying to keep up with release number changes weekly would be an absolute nightmare. Until things calm down a bit I don't blame anyone here in the least for using DF2010 as a more general version name. [[User:Doctorzuber|Doctorzuber]] 15:54, 5 April 2010 (UTC)

== World Painter Page ==
The wiki has needed a page on the [[World Painter]] for a while, so I've started one. The information in there is decent, but I'm relatively new to wiki editing, so the formatting probably isn't. If someone wouldn't mind cleaning it up a bit for me I'd really appreciate it. --[[User:Timmeh|Timmeh]] 01:15, 3 April 2009 (UTC)

:Well I don't know if someone helped you already, but it looks fine to me. --[[User:frandude|frandude]]
:I changed the name into World Painter so it looked better (no more petty redirects!) [[User:Inawarminister|Inawarminister]] 12:01, 7 December 2009 (UTC)

== French language wiki ==

Can we have interlanguage links with the [http://www.dwarffortress.fr/wiki/ French wiki]? -[[User:Alan Trick|Alan Trick]] 17:48, 14 April 2009 (UTC)

== Add a CptnDuck page? ==

Captain Duck is a DF video tutorial maker, which an impressive collection of 40 videos on youtube (and a few extra videos of sieges and arenas and whatnot), and explains how to do most everything, from magma forges to Dwarven justice. He adds humor to it and he's the reason a lot of people understand the game...I think we should give him a page. – [[template:unsigned|unsigned]] comment by [[User:Blackdoggie998|Blackdoggie998]]

:As it is insanely easy for anyone to sign up for editing priviledges on this site (I managed to, after all), I see no need to make one for him when he could make one for himself. However, if you wish to add user:CptnDuck, or invite him to make one himself, feel free. He can link to all of his tutorials from his user page. They even be searchable through that lovely little box to the(my) left. (Who knows where it is on your skin.) -- [[User:Teres_Draconis|jaz]] ... on this day, at this time.

:P.S. Does it seem odd to you to have it say "unsigned comment by [username]"? Or is that just me? -- [[User:Teres_Draconis|jaz]] ... on this day, just a little after the previous one.
:: Clicking 'unsigned' gave me all the explanation I need, might want to do the same [[User:Kinzarr|Kinzarr]] 23:27, 25 November 2009 (UTC)

:We don't need a userpage for him, but a page with the assembled listing of all his (and others of equal quality) video tutorials wouldn't be a bad idea at all. -[[User:N9103|Edward]] 16:47, 23 June 2009 (UTC)

== Articles on Olivine and other generic stones ==

There is a current discussion as to whether or not [[Olivine]] (and perhaps some few other stones) are duly covered on the current [[stone]] page, or are truly worth having their own article/page. This relates to a larger question of how this wiki is organized, and "What deserves a page" in a general sense. Any interested are encouraged to chime in, if only with a "me too" post pro or con. See [[Talk:Olivine]] for an idea of the issue. I'd like to have the debate move from the specific Olivine page to here since this is a more general issue that affects many potential pages. --[[User:Senso|Senso]] 21:29, 19 May 2009 (UTC)

:I'm not really sure which way to go on this one. A lot of otherwise useless stones would need their own articles if the guidelines were expanded... and yet, there's a good amount of useful information that's not on the main pages, that would further clutter them if it were added; And permitting more individual pages would solve both those problems. I guess this ends up being a vote both ways, with provisions on each. -[[User:N9103|Edward]] 23:54, 19 May 2009 (UTC)

:My vote is, if someone can make it amusing, then sure. If someone is of the bent to enjoy making such a page, then again, sure... otherwise, leave it at the bottom of the pile of "things that someday we might get around to if we feel like it" and don't stress. The relevant data is covered (or will be when someone notices it's not), and everything else is gravy. Beside, what would you rather do, play the game, or figure out how to make a whole page of jokes about how gneiss nice is.... (or did I get that backwards?)... ? --[[User:Teres_Draconis|jaz]] ... on this day, at this time.

::All relevant information is covered, yes. But not necessarily on a relevant page. Before the Olivine page was made you couldn't learn that olivine may contain native platinum from any page related to olivine or stone in general.
::Another example is kaolinite. You can look it up in the table of Other Stone to see it can be found in sedimentary rock. But in order to see that it may itself contain alunite and marcasite you have to go through the entire table (or use the browser search function). Now, in order to see if it may contain anything else, you have to notice the note at the top of the page (just above the table of contents) that points to Metal Ore and Gem, whith another two tables you have to search through. (Kaolinite may contain turquoise). --[[User:Nahno|Nahno]] 21:44, 20 May 2009 (UTC)

:It's not just about "which stones" - it's a larger question of how the wiki is organized and presented. Should each separate and distinct item get its own page, like the current one- or two-line articles on [[vial]]s, [[instrument]]s or [[Restraint|chain]]s, (just as random parallel examples of some [[finished goods]] that have their very own, very short, very dull, and predictably repetitive articles.) Surely the [[Masons guild]] and [[miners guild]] don't deserve or need separate articles. Do we need a separate and largely redundant article for every trap weapon? What about the cookie-cutter articles on ''every'' individual animal? The GCS deserves its own, and many others, but one on each separate type of shark and hunting cat? There is no actual article there, only a template.

:Quivers and bolts are sub-sections of the [[crossbow]] article, and I think that's a ''great'' call. Olivine, talc and kaolinite are merely similar examples, distinct enough to warrant special treatment, but on the borderline of being so small to each only represent a stub. Ultimately, I don't think a functional formal definition would be easily achieved - rather guidelines and a fuzzy target, combining related info into groups with optimal size limitations (both lower end and upper end). Perhaps a template should not be forced on every lesser example, but they could be grouped into a table on their own article, "other stones of note" or "sharks" or "finished goods" or whatever.

:In many ways, our only current guidelines are "what has been done so far" - and that varies widely and wildly. Too often, pages are cobbled onto related ones, or split off just because its a new topic, if a brutally short one. Myself, I'd like to see most related articles of less than 4 lines or so get grouped into larger, more universally informative articles, and anything larger than maybe 5 full sub-sections be considered for splitting up. If an item stands out from the rest, it should stand out somewhere, in an article - but that doesn't mean it has to have its very own, or invite every similar item to do so as well.--[[User:Albedo|Albedo]] 03:30, 21 May 2009 (UTC)

:: Please check out the (no longer) current [[Chalk]] page and tell me what you think. ... which is to say, it doesn't /have/ to be a stub, does it? It can be rich and detailed and sadly unamusing. It would please me to continue to do all stones in this manner, or another manner of your choosing.... Thus negating fussing over "this one was done this way, that one was done that way" arguments. I'll get to them all, in the order they appear on the [[Stones]] page. ... assuming you guys are ok with that. --[[User:Teres Draconis]] 08:28, 21 May 2009 (UTC)
:: P.S. Who's the outpost manager of this place, anyways? I'd like to know to whom I should be pandering. --jaz

::: I think 1) you should take time to read, if not learn the wiki format guidelines, 2) you should sign with your REAL user name, and stop using a pseudonym, and 3) you should not break someone else's post with yours in between their paragraphs. As to the chalk page, I think it's over-enthusiastic and pays no attention to previous article style or formatting precedent - which may be a good thing or a bad thing, depending. --[[User:Albedo|Albedo]] 09:33, 21 May 2009 (UTC)

:::: 1) You're right, I'm sorry.
::::2) We've discussed user names on [[User_Talk:Teres_Draconis#Naming Conventions|my talks page]]. (Also, <nowiki>~~~</nowiki> still puts "jaz"... why bother with the link when it's just a P.S.?)
::::3) I'm sorry. I was (apparently) trained wrong, and that was a /long/ time ago. I was taught (20 years ago) that when responding, to do so in-line, so that people can tell what the response is actually relating to. (Like an actual conversation, except with a time warp. You say something, I respond, someone else adds, we all move on to the next topic.) It supposedly adds clarity. The style and curtesy rules of such things has changed. I can see I'll need to update myself. Thank you for pointing that out. =)
::::4) I was hasty. I had to have meatspace people explain to me why, as wiki-''writers'', you would not want so much detail on a page. Especially when, with every new game release, any given page on the wiki might need an over haul. I was only looking at it from the end-user perspective of "If I'm looking for information, I don't want a page that just tells me to go look at the three pages I've already looked at. I want a page that reduces the noise of the irrelevant, and distills to just that specific (sub-)topic." I /don't/ see the point of six pages that are identacle except for title, and all only three lines long. If it's got it's own page, it should have it's own page. If it just links back to the three pages that linked to it, and they all link to each other already, what's the point? If the only thing Chalk has going for it is that it's flux, why not just make a note on the [[Stone]] page reading, "These three rocks can be used as flux" and link to the flux page from there? Why should chalk have it's own page, if it's not going to be richly detailed and, you know, informative? - [[User:Teres Draconis|jaz]] 18:59, 22 May 2009 (UTC)

::::The templates are there because they are pretty, detailed, and condensed ways to display some key information. Rather than expanding existing information so that it takes up more space, it's more productive to add things that you think are lacking. [[User:VengefulDonut|VengefulDonut]] 12:15, 21 May 2009 (UTC)

::: I changed the other [[Stones]] table to allow for interesting minerals that are in other[[Stones]] to be posted.--[[User:Mrdudeguy|Mrdudeguy]] 22:17, 21 May 2009 (UTC)
:What would actually be helpful is a [[Geology]] primer, indicating how layers and inclusions are placed, where, and what the implications of "You have struck XXX" are. I know, now, that if it's olivine, I have a chance of finding veins of native platinum. One good page explaining what all of the geological processes mean would be a lot more useful then all of the various descriptions of exploratory mining. [[User:Decius|Decius]] 22:35, 21 May 2009 (UTC)
::That sounds like a great idea.--[[User:Mrdudeguy|Mrdudeguy]] 22:46, 21 May 2009 (UTC)

:::I agree! But I have no idea how to write it. Most of what I know about geology I learned from looking at the raws. Everything else is "OMG, is that a ''rock''?! I've heard of those!" - [[User:Teres Draconis|jaz]] 18:59, 22 May 2009 (UTC)

::"More useful" to some, but I agree it would be a great addition. Also, the more I think about it, the more I like what MrDG did with the table in Other Stone - tables could condense any and all small, individual articles into single pages w/ (sortable?) tables where all these various similar objects could be compared/contrasted at a glance. Templates are perfect when there is a lot of various info, but if the different topics (semi-generic stones, animals, finished goods) all differ only in one or two details, and there is just not that many variables to begin with, a Table would be (imo) preferable. ''(And imo that table now covers such stones as Olivine well, to get back to the original example that sparked this discussion.)''

::As an additional example of how current stub-articles could be combined into a simple table, I've made this page - [[Example - some fish]] - which could be a model for such. (A page/table with all the "Sea-creatures" would be more likely approp, but this was faster for now.) It would replace every stub-article on related "generic" items, but any truly noteworthy items would still have their own full articles for expanded information and commentary (here, "carp"). It still has 100% of the prev information, but also allows immediate comparison and contrast, and, if sortable, allows a User to more easily compare relations between similar aspects (like "biome", in this example.)--[[User:Albedo|Albedo]] 00:13, 22 May 2009 (UTC)

::: Is it possible to put the expandable version of the raw ("game object data (show)" seen at the bottom of the [[carp]] page) inside the table, instead of the whole thing? Or does the one preclude the other? - [[User:Teres Draconis|jaz]] 18:59, 22 May 2009 (UTC)

:::Actually, if someone finds it easy to extract that information from the .RAWs, I would find that an improvement on what [[Creatures]] currently has. [[User:Decius|Decius]] 17:52, 22 May 2009 (UTC)

::::If someone here knows PHP they may be able to write a new wiki hook that pulls information from raw entries. That would make many things much easier. [[User:VengefulDonut|VengefulDonut]] 22:22, 22 May 2009 (UTC)

:::Which information do you want extracted? I can probably do it for you, but you may have heard, I'm in the doghouse for not paying attention to style and formating rules. =/ Show me what there is, and one example of what you want, and I can probably do it for you with a minimum of stupid questions. ... ''Probably.'' - [[User:Teres Draconis|jaz]] 18:59, 22 May 2009 (UTC)

::::@ jaz, Dec - Did either of you look at this sample table? [[Example - some fish]] Does that cover what you were envisioning? It's just a rough idea - but it could work the same way that the table on the [[stone]] page currently does, to cover all the generic, almost-identical objects. Same w/ finished goods, weapon traps, probably many other sim categories of like items.--[[User:Albedo|Albedo]] 22:52, 22 May 2009 (UTC)
I've read this sort of. My view is, wikis add value to the game far more for noobs than they do to legends who have been around since when the z-axis was just an idea. With this in mind, I reckon if everything with a name in the game had an article that would be *A Good Thing* (tm). Just my own opinion, feel free to disagree. Ideally, articles for things like stones should contain a template constructed from the raws, with prose/dialogue manually added.
Even things like [[screw pump]] could have a template driven section, advising what the components are / who makes it etc. Maybe <nowiki>{{building|Building Name|Component 1:Component 1 name|Component X| component X name|Constructed by|trade}}</nowiki> or similar.[[User:GarrieIrons|GarrieIrons]] 08:45, 30 May 2009 (UTC)

:I agree, probably, although that sounds like a lot of work. I think the stone templates and articles could do with a bit of a cleanup and more in-game information. I mostly use the articles to see if there's anything notable about a particular stone and then check out the wikipedia page. Some of the wikipedia links are broken or indirect now because disambiguity pages have been added since. Also, the wikipedia links are right at the bottom of very long boxes listing ores and gems and the like - I suggest adding drop down boxes to the templates that contain all that information but which are minimized by default. Or changing the template so that the wikipedia link wraps around the stone name at the top. --[[User:Harmonica|Harmonica]] 01:36, 2 July 2009 (UTC)

Way late to this party, apologies. Tables are no good (to me) if they aren't sortable. The World Ends With You (a Nintendo DS game) Wikia portal/wiki thing has an ''awesome'' method for adding sortable tables. Some gadget called [http://en.wikipedia.org/wiki/Semantic_MediaWiki Semantic MediaWiki] that hooks into the Wiki to automatically pull data out as you request it, then display it in easy-to-read and use sortable tables. The TWEWY Wikia has [http://twewy.wikia.com/wiki/The_World_Ends_With_You:Semantic_MediaWiki a page on it] for their editors, giving a few examples of how powerful it is. Their use of the tool is to easily pull information from a table of 304 items, each containing 30 attributes, to generate lists comparing and compiling various items. Hugely powerful, extremely flexible.

This type of tool would work wonderfully with a PHP RAW parser, or even simple dumps of the RAWs to the Wiki. Think of how easy it would be to update the entire Wiki across the board when new versions come out. New critters? Changes to existing critters? Update the information in one spot and it trickles down through the entire Wiki! That's in addition, of course, to being able to, say, generate tables listing how many bones each creature drops when killed, then sort to see which one drops the most. Pretty sweet stuff.

With some sort of system in place for wading through all the data on the wiki, one wouldn't have to worry about having too much information, right? -- [[User:Blank|Blank]] 04:44, 3 July 2009 (UTC)

Particularly for stone, I think that it would be a good idea to describe each individual stone relative to other, similar stones. Let's use [[sandstone]] as an example. Suppose that I read (either in its own article, or in a table) something along the lines of "Sandstone is a [[sedimentary]] layer. Unlike most sedimentary layers, it may contain [[aquifers]] or veins of [[native copper]]." If I already know what a sedimentary layer is (and how it differs from other types of layers), this information will be much easier to process and much more useful than a full list of everything that appears in sandstone. If I have no idea what a sedimentary layer is, this will tell me that there are several sedimentary layers and that they all have many things in common, which is again more useful than a list of everything that appears in sandstone. --[[User:LaVacaMorada|LaVacaMorada]] 08:56, 2 October 2009 (UTC)
:That's not the way this (any?) wiki is set up. The idea is that a lesser concept (here, "sandstone") need not include redundant info from a larger, parent concept (here, "sedimentary layer"). If you don't know what a sed'y layer is (or an aquifer or a vein or whatever) you click that link. If, then, you don't know what a "layer" is, you click that link. Sounds good at first, but if every lesser article included an explanation, even a quick synopsis, of the info for all relevant articles on broader, umbrella concepts, the articles, and this wiki as a whole, would explode beyond usefulness. --[[User:Albedo|Albedo]] 23:43, 2 October 2009 (UTC)
::Thanks for making my point for me. If you look at the current sandstone article, it lists everything contained in sandstone. Looking at just the ores and non-generic stones, we have: Native copper, Hematite, Limonite, Magnetite, Native platinum, Tetrahedrite, Bituminous coal, Lignite, Bauxite. All of these except for native copper appear in every sedimentary layer. That's not even counting all of the generic stone (especially gypsum with its five other types of generic stone contained in it) and (mostly low-value) gems. 95% of the text in this article is redundant, and could easily be summarized by "This layer is exactly like every other sedimentary layer except for these two differences". --[[User:LaVacaMorada|LaVacaMorada]] 09:06, 6 October 2009 (UTC)
:::Ah - ''that's'' your point. (When you said "describe", I thought you were advocating a narrative commentary on and verbal expansion of the info included in the sidebar.) When I was talking about not having redundant info, I was talking text - which is quite terse in this case, exactly because of the point you make. Those sidebars were designed to encapsulate the key info, an "at a glance" sort of thing, to avoid exactly what you're talking about in narrative form. Are the sidebars redundant? Often, yes. But they are the style this wiki has adopted for ''all'' stone. So you're talking not just about changing sed'y layers, but the style approach to all stone, since they would not then be consistent across the board. (Not how I would have personally designed the layout, but it's there and it works, and well. Any stone, same layout, same info in the same place, bam got it.) And when discussing presentation and usability issues, any article has to be taken both individually and in the context of others "like" it - here, any "stone" article is the same layout, the same info at a glance, which (for now) trumps whatever redundancies exist. Perhaps a quick line such as you're stating would go well, since there is, indeed, very little unique to say about any one sub-type of sedimentary layer, and that is info in and of itself. (Take a look at any [[igneous extrusive]] except obsidian for something similar.)--[[User:Albedo|Albedo]] 16:46, 6 October 2009 (UTC)

A lot of people have been talking a lot of things about reorganizing the information on the stones pages. After browsing around on them for a while, I've found the information to be mostly scattered and difficult to draw conclusions from. For example, I wasn't aware that each geographic stone type had a base list of stones that can appear, while only some of them have a couple of unique stones that may appear along with that list. It wasn't until I began gathering all of that data together for myself, that I found the patterns. I had to work to tie it all together. So, I have a partially completed table of pulldown menus on my user page right now. If anyone's interested they could take a look and tell me what they think? (Yes, I know a lot of it is redundant. I have an idea on how to fix this, but I haven't completely decided yet) --Kydo 13:55, 25 October 2009 (UTC)

Lumping all the generic stones into one page is pretty much a labor saving device. There are a lot of different stones in DF most of which have no real differences other than color. So in one respect, I do see reasoning for saving some effort and dumping them in one place. On the other hand, it would be useful to me to see slightly more detailed information about each of the colored stones, for example, I know alunite looks a certain way before it is mined out, it's general color is bright white, when used to build trap components it is bright white in both the on and off position (many stones go to dark in the off position). In the same vein, when used to build tables and chairs, both will be bright white (many stones go to dark for chairs). If you're looking for a "certain look" and want to know a tiny bit more about the stone colors at present, that information simply isn't here as things are now. [[User:Doctorzuber|Doctorzuber]] 16:21, 5 April 2010 (UTC)

== Not a Roguelike ==

Dwarf Fortress only resembles a Roguelike in the sense that everything kills you. ASCII graphics haven't connoted Rogue-resemblance since Diablo came out with modern 3D graphics and was still considered a Roguelike.
[[User:LogicalDash|LogicalDash]] 22:08, 5 August 2009 (UTC)

I agree with you for Fortress mode, but adventurer mode is rogue like.--[[User:Mjo625|Mjo625]] 22:54, 5 August 2009 (UTC)

:DF is rogue-like like.[[User:GarrieIrons|Gar]][[User Talk:GarrieIrons|rie]] 08:59, 2 September 2009 (UTC)

LogicalDash, Diablo is in 2D, not 3D. --[[User:612DwarfAvenue|612DwarfAvenue]] 05:10, 27 November 2009 (UTC)

What makes a rogue-like? too classic a question to pass up . ahem IMHO there three major elements, A dungeon crawl/ fantasy setting, ASCII and random as hell. That makes dwarf fortress three outta three hits for me. Close enough, i'd say, if it's not a rogue-like what other category could it go in? sure its not a great fit but a unique game has to go somewhere. Diablo is a dungeon crawl like rogue sure, but it lacks the depth and randomness of any of the other recognised roguelikes, ADOM, moria etc. So one outta three? The depth, randomness and spontaneity really make it, ever had a character eaten by a bear on the way to the village in ADOM? classic. --[[User:Pedantictype|Pedantictype]] 05:46, 20 March 2010 (UTC)
:I'm afraid I have to disagree with you, Pedantictype. A Rogue-like is defined by the original: Rogue. Rogue was, first and foremost, a dungeon-crawl with control of a single character, yes? I would postulate that that is one of the elements that is required to be defined as a rogue-like, which qualifies Adventure mode but not Fortress mode. --[[User:Eagle0600|Eagle0600]] 05:04, 5 April 2010 (UTC)

== Link to Add Quotes ==

To get help on how to add quotes to the main page, consult [[Talk:Main Page/Quote|this]] link.

== Incoming New Version ==

Guys. We might as well prepare for the new version that will be coming by the end of the year (maybe). What will need to change? Weapons and armor, the underground stuff... I don't know all of it. But it's extensive. Get ready.--[[User:Zchris13|Zchris13]] 17:02, 7 October 2009 (UTC)
:Well, we don't know all the details, and names of jobs/items can change before actual release. [[User:Kurokikaze|Kurokikaze]] 16:14, 8 October 2009 (UTC)
:I don't see what this has to do with anything, i guess it's nice of you to tell us. But what do you mean "get ready?"
: Gird your loins, gentlemen. Or something.
::It'll be hard to cover every page - if you edit, try to follow up on links, etc. Might also have to check the "oldest pages" listing to see that they've all been updated (except it's broken atm). The worst currently is that we ''still'' have legacy crap from earlier versions in obscure corners and comments that's not relevant to current version. Bonus.--[[User:Albedo|Albedo]] 06:11, 19 October 2009 (UTC)
:This might be useful: http://docs.google.com/Doc?docid=0AT8EQVUjrv96ZGc5cnBwOHZfMjgyY3FzZHFtanA&hl=en
:Are we just changing this wiki? (as opposed to forking with the new version, in case some people keep playing 40d?) [[Special:Contributions/206.45.111.58|206.45.111.58]] 22:39, 9 December 2009 (UTC)
::Forking sounds good to me. But I have no idea how well wikis handle forking. --[[User:Nahno|Nahno]] 14:11, 17 December 2009 (UTC)
:::In any case I think it would be a good idea to updated articles as is, and not wipe them out like in the wiki's switch to 3d which simply wiped out a lot of good information along with outdated text. Forking is a good route to take if people don't want to lose 40d inforamtion. [[User:Richards|Richards]] 19:40, 26 January 2010 (UTC)

== Interwiki ==

Correct link to Russian DF wiki, please.
Right link = www.dfwk.ru instead current www.dfwiki.ru --[[Special:Contributions/91.192.82.106|91.192.82.106]] 11:43, 4 December 2009 (UTC)
:It's done, so should we delete this conservation? (not that great at wiki myself) [[User:Inawarminister|Inawarminister]] 09:46, 7 December 2009 (UTC)

== Random page ==

Why is "Random page" only bringing me to "Count Consort"? :\ --[[Special:Contributions/99.33.67.9|99.33.67.9]] 22:33, 15 January 2010 (UTC)
:It seems "Random page" is only random daily... Is this intentional? --[[Special:Contributions/99.33.67.9|99.33.67.9]] 20:31, 2 February 2010 (UTC)
::There's probably something wrong with your browser cache settings - it works fine for me. --[[User:Quietust|Quietust]] 20:37, 2 February 2010 (UTC)

== Random images ==

Where are the images on the main page coming from? It's easy to find the quotes, but where are the images? [[User:MC Dirty|MC Dirty]] 15:14, 17 January 2010 (UTC)

:I have an image I'd like added... I'll put it on my userpage if anyone wants to take a look at it and see if it's acceptable for uploading. --[[User:Waladil|Waladil]] 06:40, 21 February 2010 (UTC)

== New Category Idea - Well Known Dwarves ==

After reading some stories on many of the most awesome dwarfs to show up in this game. (Namely Captain Ironblood, Morul, Tholtig) That a category, perhaps a sub one to Humor and Stories just for Dwarves that are very very clearly above the normal for the already outrageous(ly awesome) game of Dwarf Fortress. However do to the fact this is less on the game mechanics and such, the idea is first here so other's can figure if it's worth having a category. One thing that comes to mind is there really should be some sort of limit to what makes a Dwarf and Epic/Well Known Dwarf so as to prevent people from putting everyone they liked up there rather then the few '''everyone''' likes. Mostly asking as there is a handful of such dwarfs and that number is only going to (slowly) grow. Each said Dwarf I think deserves some sort of noting on a page for my two cents on the topic.
:I definitely thing that this is a great idea in the true spirit of DF.

== Images ==

So, what does everyone think? Would it be a good idea to have real-world images (or possibly sketches for fantasy, if applicable) of the following:
* Trees
* Fish
* Land animals
* Weapons and armor
* Stones
* Ores
* Land features (desert, savannah, etc.)
* Gems
* Metals
* Plants
We already have two pages with example images for a [[Pike_(weapon)#Pike|weapon]] and a [[Sandstone|stone]] for example. I find this very nice for visualizing my fortress and what's going on, since I'm not very familiar with many of the distinctions DF makes. I mean, I know what a fish looks like but I haven't got a clue what the difference between a pike and a char is, or a birch and alder, or even bronze and pewter to be honest.--[[User:Ar-Pharazon|Ar-Pharazon]] 22:42, 6 February 2010 (UTC)
:The normal issues with this kind of thing is REAL-WORLD publishers being annoying with copyright. I guess if we can find it from the real-world wiki then there is a good chance it is a public domain image.
:There is no way in the world it would hurt an article to have one of these. Although, for fantasy objects, materials, and creatures, there may well be some discussion about if the "Dragon" should be a European, Oriental, or some other dragon (and so on for the rest).
:[[User:GarrieIrons|Gar]][[User Talk:GarrieIrons|rie]] 11:52, 7 February 2010 (UTC)
::Well, I've added pictures to some of the layer stones and vermin, as well as all the ores. If anyone is interested, you can link to files on wikimedia commons as if they were internal files now.--[[User:Ar-Pharazon|Ar-Pharazon]] 04:52, 8 February 2010 (UTC)
:::What if those of us with artistic skills were to produce original content for such pages? For example, I could easily do a few drawings depicting certain fantasy creatures as well as actual creatures. --Kydo 22:56, 24 February 2010 (UTC)
::::I don't see how that could even remotely hurt at all.--[[User:Ar-Pharazon|Ar-Pharazon]] 15:21, 12 March 2010 (UTC)
::Who says that the 'Dragon' as a creature isn't a generalization of any species? To be honest, with the graphics as they are, I think that most of Dwarf Fortress comes down to the way the user imagines it, rather than how it appears on screen. Rather like the old text based adventure games of old.--[[Special:Contributions/85.12.64.150|85.12.64.150]] 10:18, 4 March 2010 (UTC)
:::Whoever you are, that is why i don't use a tileset.[[User:GarrieIrons|Gar]][[User Talk:GarrieIrons|rie]] 06:15, 6 March 2010 (UTC)
:As a rule of thumb, "graphics" are good things - eye candy, if nothing else. Purty. Use common sense and discretion when choosing (or creating) the image - avoid genre-specific images or anything that is copyrighted (like from an identifiable RPG, for instance), and perhaps add "artist's interpretation" under it, or a selection of (smaller) different images for something like a dragon (tho' I, personally, don't see dwarves with oriental dragons - ymmv.) --[[User:Albedo|Albedo]] 08:49, 6 March 2010 (UTC)
::Seeing as how this is a wiki and what not, why not simple add a western dragon, and if anyone objects to the bias they can add an oriental dragon, so we have two pictures and not only both sides are happy but everyone gets more pictures to look at?--[[User:Ar-Pharazon|Ar-Pharazon]] 15:21, 12 March 2010 (UTC)
:(Also, if you're interested enough to post in the Main Page Discussion, you might want to get an account. Meh.)--[[User:Albedo|Albedo]] 08:49, 6 March 2010 (UTC)

== No link to World Generation? ==

Home page needs a link to World Generation. I thought of adding it, but didn't want to upset the delicate symmetry happing in the menus. Thoughts as to where it could go? [[Special:Contributions/118.208.7.232|118.208.7.232]] 04:25, 19 February 2010 (UTC)

== Namespaces ==

As the subject has been mentioned on the forum:
some articles have been moved to a new 40d namespace. This is intended to make way for the "main" namespace to be reserved for the "current version", which ''real soon now'' will be DF2010.
For the full discussion see [[Dwarf Fortress Wiki:Versions]] and the talk page.
[[User:GarrieIrons|Gar]][[User Talk:GarrieIrons|rie]] 10:32, 8 March 2010 (UTC)

Then bloody well move them. These blank 40d pages are making finding information that is supposed to be there very hard to find.

:Agreed..Plus I dont understand the site announcements so i pretty much can't contribute to the wiki right now. Hope you got a stable team to help and are done with it soon. Oh, and a better explanation would be great of course. --[[Special:Contributions/92.202.120.234|92.202.120.234]] 00:10, 4 April 2010 (UTC)

== Tutorials clutter ==

Currently we have in the first box:
*About Dwarf Fortress
*'''Tutorials and guides'''
*'''Quickstart guide (recent)'''
*'''Frequently Asked Questions'''
*'''Your first fortress'''
*'''Video tutorials'''
*'''Important advice'''
*'''Indecisive's Illustrated Tutorial'''
*'''Get help from online chat'''
*Game development
*'''Non-Dwarf's Guide to Rock'''
*'''Starting builds'''

Bolded are the ones I think are redundant. Basically, we have the following categories of stuff:
*Tutorials for newbies: Step by step instructions where you follow what the guide says, without necessarily understanding why right away.
*Guides for newbies: General explanations of game concepts, such as z-level, how to set labors, how to farm, how to work the interface and install a graphical tileset, what the aim of the game is, etc.
*Guides for advanced players: These assume you know how to play the game, and are concerned with optimizing/pushing strategy. Embark build discussions which go beyond explaining the bare minimums you should take (such as "don't embark without a pick!", intended for newbies who may not know what they are doing), megaprojects, combat mechanics, computing, farming strategies, defense strategies, design strategies, macros, world generation parameter discussion and the like.
*FAQ, bugs and troubleshooting: The index of known problems and what to do about them, for when you have a clear question you want to figure out. This includes the FAQ, IRC channels and bugs to watch out for.
That makes 4 categories. Currently, we have 10 categories dealing with the same things. Moreover, the current break down makes no sense, and is obviously not maintained (I think that quickstart guide has been "recent" since early last summer). It's becoming confusing for the clueless first time player who was just linked to Bay12 and the wiki on a forum, and left to fend for itself. In fact, ideally, the tutorials and newbie guides should also be sorted from short to long, with datestamps.

I would rearrange the box myself, but I thought I'd ask what everyone else is thinking first. By the way, are there any tutorials for DF2010, or plans to write any? --[[User:Ar-Pharazon|Ar-Pharazon]] 02:07, 4 April 2010 (UTC)
::By the way, my proposal is to have the box look like this:
::'''Help with Dwarf Fortress'''
::*About Dwarf Fortress
::*How to set up and play Dwarf Fortress (Tutorials)
::*General game information (explanation of basics)
::*Advanced strategies (for experienced players)
::*Troubleshooting: FAQ, where to ask for help, known bugs and issues
::*Game development
::--[[User:Ar-Pharazon|Ar-Pharazon]] 02:14, 4 April 2010 (UTC)

== New modding guide ==
I'm not really sure what the process is for new guides and tutorials. I figured it would be of general community interest, so I'm posting this here; [[User:Tfaal/The Complete Dorf's Guide to Bodies]] --[[User:Tfaal|Tfaal]] 16:43, 5 April 2010 (UTC)

User:Tfaal/Bodies for Dorfs

2010-04-05T16:31:22Z

Tfaal: moved User:Tfaal/Bodies for Dorfs to User:Tfaal/The Complete Dorf's Guide to Bodies: I like this title better.

#REDIRECT [[User:Tfaal/The Complete Dorf's Guide to Bodies]]

User:Tfaal/The Complete Dorf's Guide to Bodies

2010-04-05T16:31:21Z

Tfaal: moved User:Tfaal/Bodies for Dorfs to User:Tfaal/The Complete Dorf's Guide to Bodies: I like this title better.

Bodies in Dwarf Fortress, as in real life, are complicated things. But while creating a functioning body from scratch in the real world will take you years of research and a descent into mad science, creating one in Dwarf Fortress only takes a few minutes, and keeps the mad science down to manageable levels. So hook up the lightning rod, throw on your goggles and practice your evil laugh, because we're about to stitch together some giblets.

Body parts are defined by the BP tag in the body_default file, and grouped together in collections with the BODY tag;
[BODY:BASIC_1PARTBODY]
[BP:UB:body:bodies][UPPERBODY][LOWERBODY][CATEGORY:BODY]
[DEFAULT_RELSIZE:2000]
This creates a body part called "body" with a relative size of 2000. Now, if body parts were all just made like that, there would be nothing telling the creature file how to put them together. So for limbs, organs and such, we do it like this:
[BODY:BASIC_3PARTARMS]
[BP:RUA:right upper arm:STP][CONTYPE:UPPERBODY][LIMB][RIGHT][CATEGORY:ARM_UPPER]
[DEFAULT_RELSIZE:200]
. . .
That CONTYPE tag tells the right upper arm to connect with all body parts that have the UPPERBODY tag. There is no limitation on tags here. If I gave the upper body the SQUEDLEYSPOOCH tag, and then gave everything that connected to it CONTYPE:SQUEDLEYSPOOCH, it would work just fine. If I wanted to connect with that part specifically, I would use the CON tag. The syntax for the con tag is like this:
[BP:RLA:right lower arm:STP][CON:RUA][LIMB][RIGHT][CATEGORY:ARM_LOWER]
[DEFAULT_RELSIZE:200]
The CON:RUA tag tells the body part to connect with the part that has this pattern
[BP:RUA:blah blah blah:blah blah blah]
As you can see, the right upper arm fits this pattern, and so the two parts are connected.

In the creature_whatever file, these collections of body parts are then called via the BODY tag, like so;
[BODY:BODY_WITH_HEAD_FLAG:HEART:GUTS:BRAIN:MOUTH]
Here, things start getting complicated. In the material_template_default file, all of the physical properties of a given material are defined. Ignition point, shear yield, that kinda stuff. Here's the file for skin, as an example;
[MATERIAL_TEMPLATE:SKIN_TEMPLATE]
[STATE_COLOR:ALL_SOLID:GRAY]
[STATE_NAME:ALL_SOLID:skin]
[STATE_ADJ:ALL_SOLID:skin]
Completely independent of this, the tissue_template_default file defines all the biological aspects of a tissue;
[TISSUE_TEMPLATE:SKIN_TEMPLATE]
[TISSUE_NAME:skin:NP]
[SCARS]
[TISSUE_MATERIAL:LOCAL_CREATURE_MAT:SKIN]
[RELATIVE_THICKNESS:1]
[HEALING_RATE:100]
[VASCULAR:1]
[PAIN_RECEPTORS:5]
[CONNECTS]
[TISSUE_SHAPE:LAYER]
In the b_detail_plan_default file, material and tissue templates come together. First the materials are imported;

[BODY_DETAIL_PLAN:STANDARD_MATERIALS]
[ADD_MATERIAL:SKIN:SKIN_TEMPLATE]
[ADD_MATERIAL:FAT:FAT_TEMPLATE]
[ADD_MATERIAL:MUSCLE:MUSCLE_TEMPLATE]
. . .
Then the tissues;
[BODY_DETAIL_PLAN:STANDARD_TISSUES]
[ADD_TISSUE:SKIN:SKIN_TEMPLATE]
[ADD_TISSUE:FAT:FAT_TEMPLATE]
. . .
Bear in mind that the b_detail_plan_default file only exists to make the creature_whatever files shorter. These things could just as effectively be done there.

Now we get to the meat of this. Adding the tissues to the body parts. This big ugly line here:
[BP_LAYERS:BY_CATEGORY:BODY:ARG3:50:ARG2:5:ARG1:1]
Is basically saying "Take all parts that have the CATEGORY:UPPERBODY tag, and give them 50 thickness units of ARG3, 5 thickness units of ARG2, and 1 thickness unit of ARG1." What are those? That's up to the creature_whatever file to decide. Let's have a look at the dwarf entry in creature_standard:
[BODY_DETAIL_PLAN:VERTEBRATE_TISSUE_LAYERS:SKIN:FAT:MUSCLE:BONE:CARTILAGE]
As you can see, the first thing after VERTEBRATE_TISSUE_LAYERS is SKIN, so the ARG1 from b_detail_plan_default gets translated into skin. The same applies for fat, muscle, etc. So that line ends up reading as "Take the upper body, and add 50 thickness units of muscle, 5 thickness units of fat, and 1 thickness unit of skin." And there you have it! The upper body is defined. From here, defining organs is very similar. The only major thing left are body part positions and relations. Positions tell a body part where it is in relation to it's parent body part (the body part closer to the torso), like this;
. . .
[BP_POSITION:BY_CATEGORY:CHEEK:FRONT]
[BP_POSITION:BY_TOKEN:R_EAR:RIGHT]
[BP_POSITION:BY_TOKEN:L_EAR:LEFT]
. . .

Which translates too "Place everything in CATEGORY:CHEEK at the front of it's parent body part, then place the body part with token R_EAR on the right side of it's parent body part, etc." Relations are similar, but instead of giving position in terms of the parent body part, they do so in terms of other, disconnected body parts. Like this:
. . .
[BP_RELATION:BY_CATEGORY:CHEEK:AROUND:BY_CATEGORY:TEETH:100]
[BP_RELATION:BY_CATEGORY:CHEEK:AROUND:BY_CATEGORY:MOUTH:100]
[BP_RELATION:BY_CATEGORY:LIP:AROUND:BY_CATEGORY:MOUTH:100]
. . .
Well, that's about all there is to know about bodies. Hope this helped!

User:Tfaal/The Complete Dorf's Guide to Bodies

2010-04-05T15:50:43Z

Tfaal:

Bodies in Dwarf Fortress, as in real life, are complicated things. But while creating a functioning body from scratch in the real world will take you years of research and a descent into mad science, creating one in Dwarf Fortress only takes a few minutes, and keeps the mad science down to manageable levels. So hook up the lightning rod, throw on your goggles and practice your evil laugh, because we're about to stitch together some giblets.

Body parts are defined by the BP tag in the body_default file, and grouped together in collections with the BODY tag;
[BODY:BASIC_1PARTBODY]
[BP:UB:body:bodies][UPPERBODY][LOWERBODY][CATEGORY:BODY]
[DEFAULT_RELSIZE:2000]
This creates a body part called "body" with a relative size of 2000. Now, if body parts were all just made like that, there would be nothing telling the creature file how to put them together. So for limbs, organs and such, we do it like this:
[BODY:BASIC_3PARTARMS]
[BP:RUA:right upper arm:STP][CONTYPE:UPPERBODY][LIMB][RIGHT][CATEGORY:ARM_UPPER]
[DEFAULT_RELSIZE:200]
. . .
That CONTYPE tag tells the right upper arm to connect with all body parts that have the UPPERBODY tag. There is no limitation on tags here. If I gave the upper body the SQUEDLEYSPOOCH tag, and then gave everything that connected to it CONTYPE:SQUEDLEYSPOOCH, it would work just fine. If I wanted to connect with that part specifically, I would use the CON tag. The syntax for the con tag is like this:
[BP:RLA:right lower arm:STP][CON:RUA][LIMB][RIGHT][CATEGORY:ARM_LOWER]
[DEFAULT_RELSIZE:200]
The CON:RUA tag tells the body part to connect with the part that has this pattern
[BP:RUA:blah blah blah:blah blah blah]
As you can see, the right upper arm fits this pattern, and so the two parts are connected.

In the creature_whatever file, these collections of body parts are then called via the BODY tag, like so;
[BODY:BODY_WITH_HEAD_FLAG:HEART:GUTS:BRAIN:MOUTH]
Here, things start getting complicated. In the material_template_default file, all of the physical properties of a given material are defined. Ignition point, shear yield, that kinda stuff. Here's the file for skin, as an example;
[MATERIAL_TEMPLATE:SKIN_TEMPLATE]
[STATE_COLOR:ALL_SOLID:GRAY]
[STATE_NAME:ALL_SOLID:skin]
[STATE_ADJ:ALL_SOLID:skin]
Completely independent of this, the tissue_template_default file defines all the biological aspects of a tissue;
[TISSUE_TEMPLATE:SKIN_TEMPLATE]
[TISSUE_NAME:skin:NP]
[SCARS]
[TISSUE_MATERIAL:LOCAL_CREATURE_MAT:SKIN]
[RELATIVE_THICKNESS:1]
[HEALING_RATE:100]
[VASCULAR:1]
[PAIN_RECEPTORS:5]
[CONNECTS]
[TISSUE_SHAPE:LAYER]
In the b_detail_plan_default file, material and tissue templates come together. First the materials are imported;

[BODY_DETAIL_PLAN:STANDARD_MATERIALS]
[ADD_MATERIAL:SKIN:SKIN_TEMPLATE]
[ADD_MATERIAL:FAT:FAT_TEMPLATE]
[ADD_MATERIAL:MUSCLE:MUSCLE_TEMPLATE]
. . .
Then the tissues;
[BODY_DETAIL_PLAN:STANDARD_TISSUES]
[ADD_TISSUE:SKIN:SKIN_TEMPLATE]
[ADD_TISSUE:FAT:FAT_TEMPLATE]
. . .
Bear in mind that the b_detail_plan_default file only exists to make the creature_whatever files shorter. These things could just as effectively be done there.

Now we get to the meat of this. Adding the tissues to the body parts. This big ugly line here:
[BP_LAYERS:BY_CATEGORY:BODY:ARG3:50:ARG2:5:ARG1:1]
Is basically saying "Take all parts that have the CATEGORY:UPPERBODY tag, and give them 50 thickness units of ARG3, 5 thickness units of ARG2, and 1 thickness unit of ARG1." What are those? That's up to the creature_whatever file to decide. Let's have a look at the dwarf entry in creature_standard:
[BODY_DETAIL_PLAN:VERTEBRATE_TISSUE_LAYERS:SKIN:FAT:MUSCLE:BONE:CARTILAGE]
As you can see, the first thing after VERTEBRATE_TISSUE_LAYERS is SKIN, so the ARG1 from b_detail_plan_default gets translated into skin. The same applies for fat, muscle, etc. So that line ends up reading as "Take the upper body, and add 50 thickness units of muscle, 5 thickness units of fat, and 1 thickness unit of skin." And there you have it! The upper body is defined. From here, defining organs is very similar. The only major thing left are body part positions and relations. Positions tell a body part where it is in relation to it's parent body part (the body part closer to the torso), like this;
. . .
[BP_POSITION:BY_CATEGORY:CHEEK:FRONT]
[BP_POSITION:BY_TOKEN:R_EAR:RIGHT]
[BP_POSITION:BY_TOKEN:L_EAR:LEFT]
. . .

Which translates too "Place everything in CATEGORY:CHEEK at the front of it's parent body part, then place the body part with token R_EAR on the right side of it's parent body part, etc." Relations are similar, but instead of giving position in terms of the parent body part, they do so in terms of other, disconnected body parts. Like this:
. . .
[BP_RELATION:BY_CATEGORY:CHEEK:AROUND:BY_CATEGORY:TEETH:100]
[BP_RELATION:BY_CATEGORY:CHEEK:AROUND:BY_CATEGORY:MOUTH:100]
[BP_RELATION:BY_CATEGORY:LIP:AROUND:BY_CATEGORY:MOUTH:100]
. . .
Well, that's about all there is to know about bodies. Hope this helped!

User:Tfaal/The Complete Dorf's Guide to Bodies

2010-04-05T15:17:40Z

Tfaal: Created page with 'Body parts are defined by the BP tag in the body_default file, and grouped together in collections with the BODY tag; [BODY:BASIC_1PARTBODY] [BP:UB:body:bodies][UPPERBODY][…'

Body parts are defined by the BP tag in the body_default file, and grouped together in collections with the BODY tag;

[BODY:BASIC_1PARTBODY]
[BP:UB:body:bodies][UPPERBODY][LOWERBODY][CATEGORY:BODY]
[DEFAULT_RELSIZE:2000]
This creates a body part called "body" with a relative size of 2000. Now, if body parts were all just made like that, there would be nothing telling the creature file how to put them together. So for limbs, organs and such, we do it like this:
[BODY:BASIC_3PARTARMS]
[BP:RUA:right upper arm:STP][CONTYPE:UPPERBODY][LIMB][RIGHT][CATEGORY:ARM_UPPER]
[DEFAULT_RELSIZE:200]
. . .
That CONTYPE tag tells the right upper arm to connect with all body parts that have the UPPERBODY tag. There is no limitation on tags here. If I gave the upper body the SQUEDLEYSPOOCH tag, and then gave everything that connected to it CONTYPE:SQUEDLEYSPOOCH, it would work just fine. If I wanted to connect with that part specifically, I would use the CON tag. The syntax for the con tag is like this:
[BP:RLA:right lower arm:STP][CON:RUA][LIMB][RIGHT][CATEGORY:ARM_LOWER]
[DEFAULT_RELSIZE:200]
The CON:RUA tag tells the body part to connect with the part that has this pattern
[BP:RUA:blah blah blah:blah blah blah]
As you can see, the right upper arm fits this pattern, and so the two parts are connected.

In the creature_whatever file, these collections of body parts are then called via the BODY tag, like so;
[BODY:BODY_WITH_HEAD_FLAG:HEART:GUTS:BRAIN:MOUTH]
Here, things start getting complicated. In the material_template_default file, all of the physical properties of a given material are defined. Ignition point, shear yield, that kinda stuff. Here's the file for skin, as an example;
[MATERIAL_TEMPLATE:SKIN_TEMPLATE]
[STATE_COLOR:ALL_SOLID:GRAY]
[STATE_NAME:ALL_SOLID:skin]
[STATE_ADJ:ALL_SOLID:skin]
Completely independent of this, the tissue_template_default file defines all the biological aspects of a tissue;
[TISSUE_TEMPLATE:SKIN_TEMPLATE]
[TISSUE_NAME:skin:NP]
[SCARS]
[TISSUE_MATERIAL:LOCAL_CREATURE_MAT:SKIN]
[RELATIVE_THICKNESS:1]
[HEALING_RATE:100]
[VASCULAR:1]
[PAIN_RECEPTORS:5]
[CONNECTS]
[TISSUE_SHAPE:LAYER]
In the b_detail_plan_default file, material and tissue templates come together. First the materials are imported;

[BODY_DETAIL_PLAN:STANDARD_MATERIALS]
[ADD_MATERIAL:SKIN:SKIN_TEMPLATE]
[ADD_MATERIAL:FAT:FAT_TEMPLATE]
[ADD_MATERIAL:MUSCLE:MUSCLE_TEMPLATE]
. . .
Then the tissues;
[BODY_DETAIL_PLAN:STANDARD_TISSUES]
[ADD_TISSUE:SKIN:SKIN_TEMPLATE]
[ADD_TISSUE:FAT:FAT_TEMPLATE]
. . .
Bear in mind that the b_detail_plan_default file only exists to make the creature_whatever files shorter. These things could just as effectively be done there.

Now we get to the meat of this. Adding the tissues to the body parts. This big ugly line here:
[BP_LAYERS:BY_CATEGORY:BODY:ARG3:50:ARG2:5:ARG1:1]
Is basically saying "Take all parts that have the CATEGORY:UPPERBODY tag, and give them 50 thickness units of ARG3, 5 thickness units of ARG2, and 1 thickness unit of ARG1." What are those? That's up to the creature_whatever file to decide. Let's have a look at the dwarf entry in creature_standard:
[BODY_DETAIL_PLAN:VERTEBRATE_TISSUE_LAYERS:SKIN:FAT:MUSCLE:BONE:CARTILAGE]
As you can see, the first thing after VERTEBRATE_TISSUE_LAYERS is SKIN, so the ARG1 from b_detail_plan_default gets translated into skin. The same applies for fat, muscle, etc. So that line ends up reading as "Take the upper body, and add 50 thickness units of muscle, 5 thickness units of fat, and 1 thickness unit of skin." And there you have it! The upper body is defined. From here, defining organs is very similar. The only major thing left are body part positions and relations. Positions tell a body part where it is in relation to it's parent body part (the body part closer to the torso), like this;
. . .
[BP_POSITION:BY_CATEGORY:CHEEK:FRONT]
[BP_POSITION:BY_TOKEN:R_EAR:RIGHT]
[BP_POSITION:BY_TOKEN:L_EAR:LEFT]
. . .

Which translates too "Place everything in CATEGORY:CHEEK at the front of it's parent body part, then place the body part with token R_EAR on the right side of it's parent body part, etc." Relations are similar, but instead of giving position in terms of the parent body part, they do so in terms of other, disconnected body parts. Like this:
. . .
[BP_RELATION:BY_CATEGORY:CHEEK:AROUND:BY_CATEGORY:TEETH:100]
[BP_RELATION:BY_CATEGORY:CHEEK:AROUND:BY_CATEGORY:MOUTH:100]
[BP_RELATION:BY_CATEGORY:LIP:AROUND:BY_CATEGORY:MOUTH:100]
. . .
Well, that's about all there is to know about bodies. Hope this helped!

Dwarf Fortress Wiki talk:Versions

2010-03-10T03:27:58Z

Tfaal: /* The Tense of 2010 Articles */

== What about <nowiki>{{</nowiki>[[Template:version|version]]<nowiki>}}</nowiki>? ==

Did you have something like this in mind? [[:category:version]] [[template:version]] (: [[User:VengefulDonut|VengefulDonut]] 21:32, 28 February 2010 (UTC)

: I did see that before and I think that's awesome as notes about particular items in an article, but it doesn't quite bring us to the two goals I hoped for [[Dwarf Fortress Wiki:Versions|here]]. It informs users about a statement but because of the difficulty (and undesirability) of labeling every statement in an article I think a single template per article can bring something different to the table. [[User:Mason11987|Mason11987]] ([[User talk:Mason11987|T]]-[[Special:Contributions/Mason11987|C]]) 21:38, 28 February 2010 (UTC)

::[[Template:old]] is the same functionality but with a box. Is this what you need, or did you have something else in mind? [[User:VengefulDonut|VengefulDonut]] 21:43, 28 February 2010 (UTC)

:::Much closer, I think a box for an article (maybe shifted to the top-right) is necessary for this, in order to provide the benefit of information for the user. A difference is I'd like this box to be on every article so that not only are articles labeled as out of date, but also as up to date. Most importantly I'm more about discussing the conceptual idea of this kind of organization, then we can devise an appropriate implementation. [[User:Mason11987|Mason11987]] ([[User talk:Mason11987|T]]-[[Special:Contributions/Mason11987|C]]) 21:51, 28 February 2010 (UTC)

::From what I've seen so far, it looks like what you want is a trivial step away from the things already in place. Is putting the box in the top right corner and putting one on every article the only difference? [[User:VengefulDonut|VengefulDonut]] 21:58, 28 February 2010 (UTC)
:::Oh I'm not saying it's a fundemental change, but it's implementation will allow for the large project of updating after this big update of DF. There are some details I think should be part of this change:

:::*A box on every article stating if the article is up to date or not. If it's not, also stating up to what version it is up to date.
:::*A categorization scheme that follows like so:
:::**If it's up to date, put in two categories: something like "up to date", and something like "version ______"
:::**If it's not up to date, put it in two categories: something like "obsolete", and something like "version _____"

:::Each page should be able to just list the version it's updated as of, the template should determine whether "<nowiki>{{Version|40d}}</nowiki>" should end up in category "up to date" or category "obsolete". This should be done in such a way that when a new version comes out we can make a small change to the template and EVERY article will become "obsolete" and users can over time go through them and confirm that they are still up-to-date by changing the template to refer to the new version. ''I think this is the major aspect I'm proposing that isn't a trivial difference from the current method of organization and upkeep here''. Do you get what I'm suggesting? If I thought it was a trival difference I would have just implemented it and asked what people thought, but this could be a very big deal if we go through with it. [[User:Mason11987|Mason11987]] ([[User talk:Mason11987|T]]-[[Special:Contributions/Mason11987|C]]) 22:11, 28 February 2010 (UTC)

::Take a look at [[template:vcat]]. This is the template currently placed on all of the version category pages. It compares the version the category corresponds to with [[template:current/version]] and displays a message based on whether or not it matches. Is this the type of thing you want? [[User:VengefulDonut|VengefulDonut]] 22:16, 28 February 2010 (UTC)
:::This is certainly a useful feature already in place that would likely go on the categories that will be created, or it might just stay as is but the version template will change slightly. [[User:Mason11987|Mason11987]] ([[User talk:Mason11987|T]]-[[Special:Contributions/Mason11987|C]]) 00:50, 1 March 2010 (UTC)

:Perhaps use "New", "Old", and "Obsolete" markers? DF2010 is "New", 40d is "Old", and pre-40d is "Obsolete"? I like the idea of a small box up in the corner, and a category to group them. --[[User:Aescula|Aescula]] 23:43, 28 February 2010 (UTC)

::I would want to make sure we don't get out of hand; new uses will be likely to ignore anything marked "Old" even if it continues to be accurate (nobody had verified it). Perhaps something like "This page is X releases old; some information may be changed" or something. Most releases don't change more than a few major areas (DF2010 is an exception because of the length of release, but even it won't be changing everything). I do think that something like this is VERY important for "tutorial" sections; a single key change could stymie a new user; and we'd lose them forever. --[[User:Bombcar|Bombcar]] 00:33, 1 March 2010 (UTC)
:::Well of course and that's a detail on the text in the template. There are multiple goals to accomplish and realistically I don't think it would take long on a minor to average version to go through and just check each article to make sure it's up to date. There are a lot but it's not too much, and there a lot of active editors on here who if given a straightforward task of article version checking would be able to accomplish it in the early days of a new version release I'm sure. I also think the New/Old(Current)/Obsolete(Old) is a great addition. That way we can do the transition of New to Current for DF2010 after we've done a lot of the work. [[User:Mason11987|Mason11987]] ([[User talk:Mason11987|T]]-[[Special:Contributions/Mason11987|C]]) 00:50, 1 March 2010 (UTC)
:The problem with "updating" all the old version's pages is that is based on the premise that a page, as a whole, can both be "updated" and then accurately labeled as such. It can't, not either. Pieces will be updated, subsections, or single elements of subsections, but even then only as accurate as that last editor understood the changes. Think about the changes that the Wound/Healing system will undergo, or Materials/Values, or Weapons/Armor, and all the directly associated pages and concepts, and references and paraphrasing in other articles - could be massive and subtle at the same time. When does a label get changed? If each User only edits a bit at a time (and few of us rewrite entire pages!), how do we know we've filtered out'' all'' the legacy information? I ''do'' like the idea of beginning new version labels for each version's article on the same subject - altho' that would almost ''require'' different sites to allow for identical article names. --[[User:Albedo|Albedo]] 12:02, 1 March 2010 (UTC)
::I don't disagree with your opinion on bit-by-bit changes, it makes sense. I think your below idea might be the way to go, with articles of the new version labeled with a suffix (DF2010) linking back to the "old" version, which links forward to the 2010 version. A new site is definitely not needed and would cause a huge amount of problems imo. I think a simple template on every article (like I described) pointing to a 2010 version can be done by a handful of people with a little time. Then the 2010 version can start with just that template (which will automatically point backwards). This will include the separate page like you suggested, but would still accomplish the goals I had hoped to accomplish. [[User:Mason11987|Mason]] ([[User talk:Mason11987|T]]-[[Special:Contributions/Mason11987|C]]) 12:13, 1 March 2010 (UTC)
:::<nods> Those "goals" being:
:::* Allow users to know an article is up to date
:::* If an article isn't up to date, allow a user to know exactly how out of date it currently is.
:::* Allow editors to easily find articles which are out of date and improve them.
:::It seems no article can ever be confirmed as 100% up to date - new observations and insights make this a very dynamic and wiki-appropriate process. But if we can ''start'' every 2010 article (and every version in the future!) with currently accurate info, even if that's only a fraction of what we "knew" for d40, that's as big a step as we can take in the right direction.--[[User:Albedo|Albedo]] 12:25, 1 March 2010 (UTC)

== My vision ==

(For what it's worth). I mentioned a desire to look into the possibility of doing this on my Admin application, in the Q&A process. When I first joined the DF community, we had just(?) undergone a version shift, and the pages here and users on the [[Forums]] here were rife with misinformation and contradictory understandings of the game. Newbies would look in the wiki and find ancient history mixed side-by-side with recent edits, some stuff that went back to the 2-D version, and that would be presented as gospel and no one knew any different. The ''very'' recent revelation that workshops do NOT make [[noise]] in d40 is a perfect example. I'd ''love'' to see this version change-over done differently.

What I had envisioned was a category template, something bold and unmistakable like [[mod]] or [[delete]], that marked a page (or every major subsection?) as "OLD VERSION : d40" (or whatever). (This would also create a category page where all those could be scanned at a glance.) Those pages would '''not''' be edited for DF2010 - to do that would invite a piecemeal disaster that would spiral into the same jumbled quagmire ''(or probably worse!)'' that I first stepped into. As a User wants to address a topic, a new page is started - if that is ''identical'' to the prev info ([[dwarf]], perhaps, etc), then it's mostly just copy/paste - but if not, then it gets edited and updated on the new page. If only part of it can be verified, then only part of that older page makes the transition at that time. Thus (in theory*) only material that has been confirmed as "DF2010 accurate" will make it to the "current" wiki, and the rest is clearly marked as legacy but stays intact as that.

''(* I have no illusions that users will not find a way to screw this up at times. But it has to be better than opening a long legacy article that has already had a dozen editors shake it up - but it's unclear what has and what has not been addressed. [[Armor]], or [[skill]], for instance.)''

The new pages would have a link to the old one(s), so users could see what if any old info is still applicable or unconfirmed, and/or what needs to be translated/updated and added, but the new page will grow the new article from the ground up, rather than pretend a dozen users could patch an accurate final product together from an inaccurate but similar one, one edit at a time.

It's the difference between repairing a totaled car, and using only the good pieces to rebuild a new one.

I'm not experienced enough in the wiki-code to know if or how the two "versions" would be kept distinct if we stayed on this site - many articles will certainly want the same Name, so... yeah. That's what I thought the new site/engine would be used for, not simply copy/pasting current articles and being right where we are now, right where we were with the last significant change, right where we don't want to be.--[[User:Albedo|Albedo]] 10:05, 1 March 2010 (UTC)

:IMO. Personally you would do this by copying every <nowiki>[[article]]</nowiki> (say, [[Miner]]) to a new namespace. With redirects from main namespace to the version namespace.
:So <nowiki>[[Miner]]</nowiki> would redirect to <nowiki>[[VerABC:Miner]]</nowiki>. With a simple Page Copy, editors could copy the whole page, and easily update it to DF2010.[[User:GarrieIrons|Gar]][[User Talk:GarrieIrons|rie]]
::Um, what's the right word?... NO!!! That is ''exactly'' what I would NOT want to see happen! And sorry to shout, but that is so far off the mark it frightens me. That achieves nothing but two legacy sites. What I would prefer is that the new page is blank, and ''only'' information that has gone thru a user's confirmation process is added to that new article. Blind, bulk "copy/pasting" is not that. It's ''much'' easier to read over one section at a time and update that, than to try to weed out legacy information buried in an entire article that has been "mostly edited". For one, how does anyone know what has and has not been checked at least once? Yes, there will be constant updates - but the core information is then at least (in theory) info on 2010, not d40, and any clear d40 legacy material has already been filtered out. ("Healing and wounds" jumps immediately to mind as a collection of articles that would lead to a disastrous "rewrite" - but snipping bits and pieces, and adding that to the updated system - that gives us better accuracy for the end product.)--[[User:Albedo|Albedo]] 10:38, 1 March 2010 (UTC)
Something like this, [[Template:D40x]]:
{{D40x}}

:I like where you're going and I think this could fit nicely with the goals I had in mind when I wrote this. For each article we could have a box in it. Saying that this article was updated as of version 40d, for the new version click "here". Here will link to "''article name'' (DF2010)" or something similar. That article will have a box saying it was updated as of DF2010, and for the old version click "here", where here will link to "''article name''". This can easily be done via templates.
:I understand your concern about updating articles bit-by-bit, and I see a lot of value in your suggestion. I think at SOME point though after the release of DF2010 we'll need to mass move articles so that the 2010 versions become the ''article name'' verions, and the ''article name'' versions become ''article name'' (40d), and the template placed can have a minor modification to continue functioning after a mass move.
:Ultimately I think this will require more administrative work (move-over-redirect for example), and perhaps a larger set of work for editors, but it will more likely have a better end-product then a bit-by-bit change, which is really most important. Organization on something like this is key though, but I like your approach. [[User:Mason11987|Mason]] ([[User talk:Mason11987|T]]-[[Special:Contributions/Mason11987|C]]) 11:59, 1 March 2010 (UTC)
::And I value your experience with what's possible - that could totally work, linking each article to a main (or "best") article in the other version ("best" being relative, depending). And, yes, the "migration" between naming conventions could be a pain and will have to happen as we phase out d40 (another reason I was thinking 2 sites, but if we don't have to go there then that's better still). I completely re-edited some of the larger clusters left by the previous version changes - the whole Armor/Weapon series, and the various Defense Design/Fortress Design/Fortress Defense/Design a Fortress/Defend your Fortress/Siege Engine/Siege/Design a Defense/Design Theory/Design Theory pages - you get the idea. That was ugly and took weeks of planning and then editing, and the info was already mostly there and it was largely "one vision", so I could keep track of my own progress - we can't expect that with this shift. Many of ''groups'' of d40 article will need to be re-conceived 100% ''as well as'' have all new info, rearranged to better fit the 2010 game system and paradigm. "Squads" and "Burrows" will wreck havoc with the current Military and Design concepts, and Wounds/Doctors will most likely call for a new series of articles. It's not going to be a 1:1 translation, and we shouldn't plan on it being so.--[[User:Albedo|Albedo]] 12:18, 1 March 2010 (UTC)
:::I get what you're saying about the changes being big enough that "blind copying" d40 info won't work to make accurate DF2010 articles. But I honestly think the use of a seperate name-space for (legacy) version specific information is a tidier way of "quarantining" it than '''Article (Version)'''. The "quarantining" process was more what I was getting at, than the process of getting "accurate DF2010" articles into main-space. [[User:GarrieIrons|Gar]][[User Talk:GarrieIrons|rie]] 12:27, 1 March 2010 (UTC)
::::I kind of like the namespaced articles idea. However, don't let what I think will / wont work override every other opinion. --[[User:Briess|Briess]] 12:36, 1 March 2010 (UTC)

::: I think the namespace is a good option. My only worry is problems it could cause to things such as search, which the parenthetical notation wouldn't have those problems. On the other hand it isn't as easy to separate a page name and the version it applies to if the version is in parentheses, those I suspect the difference may be minimal especially with parser functions. One thing we don't want is to make navigation more difficult to users. If they type "weapons" they should arrive at the appropriate article automatically. Which either means that information has to be on the article [[Weapons]] (without namespace or parentheses) or the article [[Weapons]] has to redirect to the correct version. I think having [[DF2010:Weapons]] and [[40d:Weapons]] could certainly work, but then when there is a version change all of the articles like [[Weapons]] have to point to the new version. This isn't a big deal to me though, and is a necessary problem to overcome if we're going to have an article for each topic for each version. [[User:Mason11987|Mason]] ([[User talk:Mason11987|T]]-[[Special:Contributions/Mason11987|C]]) 22:42, 1 March 2010 (UTC)
::: I'll update the article page with what I think is the current consensus approach. [[User:Mason11987|Mason]] ([[User talk:Mason11987|T]]-[[Special:Contributions/Mason11987|C]]) 22:42, 1 March 2010 (UTC)

:::::A new namespace would be really good. If we have some large article X that effectively needs to be scrapped, we could move it to Legacy:X and put an appropriate label on it. Then lock it and put a link to it on the new X article. This has the added benefit of disabling all of the [[template:version]] (and maybe [[template:verify]]) tags, which only include pages in a category if they are in the main namespace. So they don't need to be found and removed manually. [[User:VengefulDonut|VengefulDonut]] 12:01, 3 March 2010 (UTC)

== Updated proposal ==

I made some changes, hopefully they are clear. Thoughts? [[User:Mason11987|Mason]] ([[User talk:Mason11987|T]]-[[Special:Contributions/Mason11987|C]]) 22:52, 1 March 2010 (UTC)

: I wonder if what we're doing here would be more suited for a release like DF2010 - a jump from 39d to 40d, say, wouldn't be that much and shouldn't make the whole wiki covered with orange boxes. Perhaps a smaller unverified note unless a manual "this change was major" button is hit somewhere. I like what is there currently, as articles would "rust" just like dwarven skills if not updated. --[[User:Bombcar|Bombcar]] 04:26, 2 March 2010 (UTC)

:: This was inspired by the DF2010 jump but the goal is to make sure the wiki stays up to date through all future releases. Though I agree that larger changes require a different approach then small changes. I'd suggest we worry about small changes when they come afterwords. [[User:Mason11987|Mason]] ([[User talk:Mason11987|T]]-[[Special:Contributions/Mason11987|C]]) 12:34, 2 March 2010 (UTC)

:My suggestion would be to use the "main" namespace (ie: no special prefix) for whatever version is current.[[User:GarrieIrons|Gar]][[User Talk:GarrieIrons|rie]] 06:43, 2 March 2010 (UTC)

:: Well that seems obvious, and way simpler lol. The template could still work just as well that way, since the template will know what version is up to date, if it finds an article that is using it, it will know it's up to date if it's the main namespace article. This will mean that at some point in the near future we'll have to move all of the articles that are relevant to "40d:Article" then edit the redirect to begin the new page which will be about the article for DF2010. Thoughts on this? [[User:Mason11987|Mason]] ([[User talk:Mason11987|T]]-[[Special:Contributions/Mason11987|C]]) 12:34, 2 March 2010 (UTC)
:::It ''seems'' simpler, but is it really, in the long run? (I'm not sure, but I'm just not convinced either way.) The difference is whether we have to update ''every'' "current" page every significant version upgrade. Won't be "every" time, but any time like this one. That, plus however much hassle and confusion having two (and more later!) parallel sets of articles creates. While that won't be often, it will be a LOT of pages to reconcile, recreating (and compounding?) the current situation with every major upgrade. I wish we could somehow create two independent "sites" (with or without a different domain name/etc), but linkable to each other, so that the new one is separate yet still easily self-referential within itself. A new page or internal-link either series is just a new page, [[metal]] or [[stone]], no need for a new template or qualifier to the obvious and appropriate article name. And any older series of articles don't muddy the water for navigation or a Search, they just become "the old site", similarly separate but nearby. If there was a way to mass-mark every page on a site, adding a template that refers users to the new "current version", so much the better. I don't know if anything like this is possible, or practical if it is, but it would be a good thing if it were, and solve both problems.--[[User:Albedo|Albedo]] 06:39, 4 March 2010 (UTC)
:::: I really really don't think that scrapping the wiki and calling it old is useful. We destroy any and all redirecting capability, which is critical for new users. Our goal is to retain information about the old versions while creating information on the new versions as accurately and quickly as possible, and with as little trouble for readers as possible. Creating another wiki is not helpful for this for many reasons (watchlists/usernames not copying over as a couple examples). I don't think old articles in other namespaces will mess up search, as you can explicitly exclude different name spaces in your search. I think this is a fantastic feature, instead of a problem. Imagine being able to search for some topic only in 40d articles? Or only in "up to date" articles? Or both? [[User:Mason11987|Mason]] ([[User talk:Mason11987|T]]-[[Special:Contributions/Mason11987|C]]) 14:37, 4 March 2010 (UTC)
::::Apologies. This is my first time using MediaWiki and certainly I could pick a better place to make my first edit. I feel that I should voice support for the notion of a user wishing to filter his search by -any- version easily and quickly. A drop-down added to the search box that filters the search by 40d-compatible articles, older, DF2010, or everything would be super, as would portal pages for each version linking to the sort of info we currently have for Getting Started, Video Tutorials, Nobles, Fun, and so on. It seems that there is a lot of interest in continuing to play the 40d version for various reasons, and so it should definitely be possible now, after DF2010, and after future releases to select your preferred version when searching and to navigate through a portal for that version. As articles are vetted, edited for accuracy, and properly labeled with which versions they are for, I hope it will be possible to not only continue using this one wiki going forward, but to also go backward and play even older versions of the game, or just to click through the versions to compare the evolution of this feature or that, enabling users to better understand and select a version of the game that best suits what they want to get out of it. The availability of many (all?) past versions of DF indicates to me that Toady et.al. consider them important not just as a legacy, but as slightly different game experiences that Dwarf Fortress fans may still wish to us.--[[User:Carlthuringer|Carlthuringer]] 09:38, 9 March 2010 (UTC)

== DF2010 ==

I just wanted to make sure nobody plans to keep calling the new version DF2010 after it gets released. It will have a real version number at that point. [[User:VengefulDonut|VengefulDonut]] 00:17, 4 March 2010 (UTC)
:Lotsa luck on that one. My guess is it'll be a redirect, as so many "fan contributions" to this culture. Meanwhile, since we have no hard count on the version changes (which equate to the ver number), this will continue to ingrain itself in our consciousness.)--[[User:Albedo|Albedo]] 03:28, 4 March 2010 (UTC)
: *using small text to fake hide my pride* - I coined the name "DF 2010" when I made the wiki article :D [[User:Mason11987|Mason]] ([[User talk:Mason11987|T]]-[[Special:Contributions/Mason11987|C]])
:The 2D version is very commonly referred to as such, so I wouldn't be surprised if it continues to be well known as DF2010. That being said I agree that if we go with the namespaces, we aren't going to use DF2010 unless that phrasing actually existing IN the game. Regardless though our job is to help people find what they're looking for and that should be the #1 concern. If people will search for something using DF2010 or similar we should make that easy as possible. But the name of articles is unimportant as long as the possible names redirect to the actual article, that's my only concern. [[User:Mason11987|Mason]] ([[User talk:Mason11987|T]]-[[Special:Contributions/Mason11987|C]]) 14:31, 4 March 2010 (UTC)

== Consensus? ==

I went through and read everyone's comments on this talk, and tried to summarize everyone's viewpoints. It looks like we have a general consensus for this idea:

*Move version-dependent (almost all) articles to "40d:X"
*Page "X" [this means the "main" namespace] contain DF2010 information only (no Copy/Paste), links to "40d:X"
*'''Current Version''' namespace is intended to be a staging namespace for us editors.
*Make references to "DF2010" able to be changed easily.

I figure we can just do a straw poll to decide if this is a good idea (as a whole). In your comment if you could specify when you think this kind of thing should be done (after we set up templates/categories), that'd be useful [either "ASAP", "some date", or "after DF2010" release].

*'''Support''' - ASAP [[User:Mason11987|Mason]] ([[User talk:Mason11987|T]]-[[Special:Contributions/Mason11987|C]]) 23:46, 7 March 2010 (UTC)
*'''Support''' - ASAP, and I've set up the required namespaces for this project. --[[User:Briess|Briess]] 00:33, 8 March 2010 (UTC)
*'''Support''', except the for the name of the namespace. I think "legacy" has a much better ring to it than "40d". Also, this won't be the last time we want to move outdated info somewhere. [[User:VengefulDonut|VengefulDonut]] 01:35, 8 March 2010 (UTC)
*:I think it would be great to keep all our outdated information for those who want to play legacy versions of the game. --[[User:Briess|Briess]] 01:37, 8 March 2010 (UTC)
:::Strongly support that last sentiment, at least for the now...
:...Also, I'll suggest that less than 36 hrs over a weekend (if at any time) is perhaps NOT adequate time to poll for a "consensus", at least not for something of this magnitude. I had something to say about this, something that might have made a diff, but... it's completely moot now, ''i'n'it?'' Next time, maybe either wait just ''a bit'' longer before taking executive action, or simply don't pretend input matters, pls - it's disheartening, among other things.--[[User:Albedo|Albedo]] 07:27, 8 March 2010 (UTC)
::I had your concerns noted, in particular you noted that you wanted to start fresh for each version, which we are going to do. But I agree that action shouldn't have been taken yet on this.
::This is my fault, I misunderstood what the goal was for this so I hopped into action. Input is extremely important, and because of that, I'm now working on reverting the article moves. --[[User:Briess|Briess]] 15:21, 8 March 2010 (UTC)

:Seconded what Albedo said.[[User:GarrieIrons|Gar]][[User Talk:GarrieIrons|rie]] 09:22, 8 March 2010 (UTC)
*'''Support''' altho' it's a bit late. Vengeful, while I agree about '''legacy:''' vs '''40d:''' - what do we use next version? Mass move all '''legacy:''' to '''40d:''' so we can move '''main:''' to '''legacy:'''?[[User:GarrieIrons|Gar]][[User Talk:GarrieIrons|rie]] 09:22, 8 March 2010 (UTC)

::We don't need a new namespace for every single version. Whenever you have an article that needs to be scrapped, move it to legacy, put the appropriate label on it, and rewrite it. Also, the mass move was a bad idea and not something we should repeat again. [[User:VengefulDonut|VengefulDonut]] 13:08, 8 March 2010 (UTC)

:::But if we have the namespace refer to a particular version then we can easily retain categorization of information based off of version. In that a template can simply use the namespace to categorize articles. If we do what you're suggesting then an article will need to be labeled by it's version. Not a huge problem I suppose, but it is worth noting. [[User:Mason11987|Mason]] ([[User talk:Mason11987|T]]-[[Special:Contributions/Mason11987|C]]) 22:58, 8 March 2010 (UTC)

::::When we move the pages, you're planning to add a template saying the page is an old page pertaining to version blah-blah. This template will include it in category blah-blah. I do not see the problem. [[User:VengefulDonut|VengefulDonut]] 23:04, 8 March 2010 (UTC)

VD's comments about some pages that are ''not'' version specific should be heeded - take a look at articles like [[defense design]] or [[dwarf]] or some of the [[industry]] presentations - those are not going to change significantly, if at all. Otoh, if we want to keep a ''complete'' "40d/legacy" data base, then those need to be duplicated, not changed over. But then, practically speaking, we've doubled our page count. Once more, I'll suggest two different sites, sub-domains, whatever - the legacy being more or less "fossilized", and the current, default one designed to be dynamic and user friendly. Currently, to link to a topic is to create (double?)redirect - "[[siege]]" isn't sufficient, and, for an Admin policy that was worried about making things "easier" for Users to do editing, having to know and remember (and bother) to type "[[40d:siege]]" is counter productive in the long run. imnsho.--[[User:Albedo|Albedo]] 11:27, 8 March 2010 (UTC)

:Briess, now that you've fixed things, has it become possible to undo the move? [[User:VengefulDonut|VengefulDonut]] 13:08, 8 March 2010 (UTC)
::I have to finish fixing the talk pages and then I will be able to undo the move. --[[User:Briess|Briess]] 15:08, 8 March 2010 (UTC)

*'''Support''' - this should work. --[[User:Bombcar|Bombcar]] 02:33, 9 March 2010 (UTC)
:: I've been noticing that this is breaking double redirects; it makes them less useful. See [[Spiked Ball]] for an example. In a perfect world, it wouldn't stop at the second redirect, but continue on. --[[User:Bombcar|Bombcar]] 03:07, 9 March 2010 (UTC)
::: I suspect that it severely harms double redirects that link directly to a subtopic, but I've yet to find one to verify. Something like [[Spiked_Ball#Menacing_spike|Contrived Example]] versus [[Trap_component#Menacing_spike|Single Redirect]]. --[[User:Bombcar|Bombcar]] 03:12, 9 March 2010 (UTC)

*'''Support''' though it's late. Although I'm not catching what "legacy" is supposed to mean. I like the simple, factual idea of calling it 40d, still.--[[User:Aescula|Aescula]] 04:48, 9 March 2010 (UTC)
:Similar to any older (and often non-compatible) version of a product, "legacy" refers to any articles on a ''previous'' version of DF that are not compatible with DF2010. We have none(?) atm, but will soon - what to do with those? If anyone wants to play d40 in the future, any articles on DF2010 might not be accurate (any more), and there may be some articles and terms found in d40 that simply no longer apply. Those are (or will be) all "legacy" articles (if or as long as we choose to keep them around). Also, don't forget that while in the immediate future only d40 articles will be "legacy", eventually DF2010 will follow in the same steps, at the ''next'' version change after this - and we want to try to show some foresight and leave a User- and Admin-friendly policy for then as well.--[[User:Albedo|Albedo]] 08:49, 9 March 2010 (UTC)

==The Tense of 2010 Articles==
I'm not sure if this is the place to put this, but I have seen no authoritative statement on this matter, so I'll post this question here; should DF 2010 articles be in present or future tense? I would go with present, because otherwise we'll just be changing it in a month or two. --[[User:Tfaal|Tfaal]] 03:27, 10 March 2010 (UTC)

Dwarf Fortress Wiki talk:Versions

2010-03-10T00:04:57Z

Tfaal:

Hospitals

2010-03-09T23:28:34Z

Tfaal: Typo fix.

{{DFNewVersion}}
{{NewVersionStub}}
A hospital is a [[zone]] -- or at the least, something quite like a zone -- in the new version of Dwarf Fortress. [[Beds]], [[container]]s, [[traction bench]]s, and any other buildings relevant to medicine that are included in the zone will be set aside for medical use.

Hospitals

2010-03-09T23:28:04Z

Tfaal: Adding basic information.

{{DFNewVersion}}
{{NewVersionStub}}
A hospital is a [[zone]] -- or at the least, something quite like a zone -- in the new version of Dwarf Fortress. [[Beds]], [[container]]s, [[traction benche]]s, and any other buildings relevant to medicine that are included in the zone will be set aside for medical use.

v0.31:Doctor

2010-03-09T23:21:47Z

Tfaal: Adding basic information.

{{DFNewVersion}}
{{NewVersionStub}}
In the new version of Dwarf Fortress, doctors are dwarves assigned to any of the five medical labors; dressing wounds, diagnosis, surgery, setting bones, and suturing. All doctors in the fortress operate under the instruction of the Chief Medical Dwarf, one of the new appointed [[Nobles_(DF2010)|nobles]], and presumably only perform medicine on a dwarf after treatment has been prescribed by a diagnostician. The current system of undesignated beds being used for [[healthcare]] has been scrapped; instead, hospital beds are those explicitly included in a hospital zone.

40d:Magma

2009-09-23T16:22:55Z

Tfaal: "capable of melting objects and constructions" -> "capable of melting objects and buildings"; constructions are held together by dwarfbeard fibers, and can only be destroyed by cave-in.

'''Magma''' is red-hot molten rock present in [[volcano]]es, as well as magma pools and magma pipes. It serves as an energy source, powering [[magma forge]]s, [[magma glass furnace]]s and [[magma smelter]]s, which do not "use it up" in any way. It is extremely dangerous.

Magma never cools, but can [[evaporation|evaporate]] if left at a depth of 1/7 for too long. If mixed with water it can form obsidian (see below).

==Magma sources==
Magma occurs in three different features; Magma pools, Magma Pipes, and [[Volcano|Volcanoes]].

* A '''Magma Pool''' is a reservoir of magma that occupies only a few Z-Levels in the mountain, without reaching the surface. Magma Pools can be very small, and may have few suitable locations for buildings that rely on magma. Magma in these pools is limited, and pools will not refill with magma once emptied.

* A '''Magma Pipe''' starts at the lowest z-level of the map from a magma (or lava) flow and extend in a pipe shape upwards, sometimes reaching the surface but often not. Magma Pipes gradually refill with magma.

* A [[Volcano]] is similar to a magma pipe, but it has the advantage of being a geographical feature that is visible on the [[location]] screen. This means that it is a lot easier to find. However, it IS actually possible for a volcano that shows up on the "local" and region screen in the starting location chooser to be entirely underground - Although you could see it in the starting location chooser, it would not be visible from the surface once your dwarves have arrived at the fort's site.

== Finding magma ==

Volcanoes are visible on the "local" screen in the starting location chooser. It is represented as a red ≈ mark (a double tilde) - essentially it looks like red water. Note that red ≈ marks in the "region" screen mean something different entirely (e.g. red sand).
If you are using a certain [[utility]], you can also see magma pools and magma pipes on the local screen in the embark menu.
After you have embarked for a place that has a volcano, and once your dwarves have arrived at their target destination, you should see a large red pool of lava on your map. If you don't, you should expect your volcano to be somewhere underground. You then have to use [[exploratory mining]] to find it. If you can find a large patch of obsidian on the surface that is devoid of boulders, chances are there is a magma vent below, so that would be a good place to start your mining.

While picking a starting location, the easiest place to look for magma is on or near a [[volcano]] (a red ^ mark in the "region" screen). There are often volcanic islands (easy to find, since they are the sole land in the middle of oceans), but since sea travel is not yet implemented, trade with other races may not be possible on such islands. Instead, find a volcano on land, and (optionally) start looking for a vent in nearby squares. "Nearby squares" can mean anything from literally on top of the volcano, to adjacent, to quite a long distance away indeed. The placement of magma seems to be related to the distance from volcanoes, but is still essentially random.

Magma vents occur exclusively in world map tiles that are primarily igneous extrusive. That is to say, if you select an entire tile on the embarkation screen and press F1 to highlight the most common terrain, the tile will only have magma if the top stone is dark gray, signifying igneous extrusive rock. Magma does not necessarily form in this geological zone/biome, rather anywhere in the tile. Even if magma is not evident on the surface, it's almost certain to be underground somewhere, though the chances of finding it without reveal.exe are still slim.

Much harder than simply finding a magma vent is finding a magma vent that is also near suitable terrain for building. Depending on your requirements - you may be looking for a source of running [[water]], or a [[mountain]] for minerals, or a healthy [[tree]] population, a layer of [[flux]] for [[steel]] production or even all four - suitable building sites can be extremely scarce.

Since volcanoes show up on the region finder, and magma vents do not, you may find it easier to simply check all volcanoes on a map for suitability, and generate a new world if none are suitable, rather than scouring tile after tile for magma vents.

If you're willing to search exhaustively, you might want to consider finding magma vents that are not near volcanoes at all. Very occasionally, magma will be visible in the middle of forests, plains, or other terrain nowhere near a volcano or even mountains. There is no way to spot these on the region map, so you have to review the local maps. This can be done from DF, but since it involves a lot of scrolling and is very tedious, you can try exporting the local map of the world which can be much more quickly searched for the distinctive red ≈ symbol.

You can also occasionally find magma that does not extend all the way to the surface, and therefore is not visible on the local map. These are in fact much more numerous than surface-visible magma vents; however, they are almost impossible to find without cheating via one of the [[utilities]] like "reveal.exe", since unlike proper magma vents these smaller deposits must be almost literally mined into to see (you will get a warning about "warm stone" before you actually breach the deposit). These smaller magma deposits appear in the same places as normal magma vents - near volcanoes, or, failing that, near other known magma.

The newly-added "Site Finder" feature neatly sidesteps all of this legwork, allowing you to search for a site with a magma pool or pipe without having to manually check each tile on the world map. Note that unless you edit the .init file so that magma features are shown on the local map, you won't know exactly ''where'' the lava is prior to embarking- just that it exists. Depending on whether or not you like a little mystery, this can be turned on or off at will.

== Using magma ==

On a map with a magma vent, the magma will be clearly visible from every level ground and below, unless the map is in a Freezing area. In Freezing areas, the top few levels of the vent will have cooled to form an [[obsidian]] "cap". This should still be readily recognizable however, as it will comprise a circular area. The minerals directly adjacent to the magma vent will also be immediately visible, even at the lowest level of the map, which can give some hints about where to prospect for ores.

[[Image:magmacap.png|thumb|188px|Obsidian "magmacap" as seen from ground level]]

The vent has a similar, circular shape on each level. However, it is not identical from one level to the next; some levels will have a larger or somewhat misshapen circle of magma.

The primary use for magma is to power [[magma smelter]]s, [[magma glass furnace]]s and [[magma forge]]s. (There are other uses, including defense, [[obsidian]] production, and possibly even garbage disposal.) To build forges, etc. on magma, at least one of the external eight squares must be above a square of magma.

This can be done most easily by simply building on ground level. The magma is visible from ground level but is actually contained one level below ground level, just like any ground-level water source.

To build underground, you will need to dig at least one tile of a [[channel]] down from the location you wish to build the smelter or forge. Eventually, flowing into this channel (on that lower z-level immediately below the forge or smelter), there must be magma, either from the pipe/pool itself or channeled from the vent. You can simply build a tunnel straight into the magma (and lose the miner who digs it 99% of the time), or use [[channel]]ing to tap into the magma safely from the level above - this latter requires the lower level to be wider than the upper, to jut out so that last tile can be channeled away from above to free the magma into the tunnel system on that level.

Tapping into magma directly is usually safe provided that you are prepared for it (see Pressure note below). Magma is much slower than water, and can be stopped by any [[magma-safe]] [[floodgate]], [[door]] or etc. with a [[bauxite]] mechanism. Take care however if you are using a [[screwpump]] to pump magma into a tunnel/funnel with a cistern below - the pump will make the magma overflow as it would with water.

Volcanoes and magma pipes slowly replenish their supply of magma. A miner with less than Unbelievably Agile will die when breaching a magma tube as he can't move away quick enough.

=== Producing Obsidian ===
Magma can also be used to produce [[Obsidian]], a stone which can be used to make swords at a [[Craftsdwarf's Workshop]] and which has a base value of 3 (compare with 1 for normal [[stone]] and 2 for [[flux]]).

See [[Obsidian farming]].

==Magma flow==

[[Image:Safemagma.png|thumb|188px|Magma safely diverted underground (cross section)]]

Magma is a chunky liquid and as such will not be forced upwards by pressure under normal circumstances.

Thus it can be safely passed through tunnels to be used at a lower point in the fortress.

A frequent mistake, however, is to assume that a channel is sufficient to cause magma to fall. While magma will not rise out of a channel, it can flow over the top once the channel fills up.

Another common mistake has to deal with magma pipes and volcanos in Freezing areas. Many people will channel into the obsidian cap and then into the magma through there. However, once a tile of the obsidian 'cap' is breached, the tile directly above the breach will then be included as part of the magma pipe and the magma will begin rising until it has filled that square. For fortresses that tapped into the magma, this can result in waves of magma slowly filling up the fortress from the bottom level up to the magma pipe's new top level. The magma can continue to rise all of the way to the surface if an entire section of the obsidian cap is channeled. The magma will not harden into obsidian again, though, just from the cold temperatures.

[[Image:Unsafemagma.png|thumb|188px|Danger: This will overflow (cross section)]]

(v0.28.181.40d:) Also note that screw pumps can cause magma to behave oddly. Magma that is emerging pumped from a screwpump will behave as if pressurized, and be forced upwards to the same level as the pump. However, this only occurs while the pump is actively pumping magma into a tile that is already full. It seems likely that this behavior is a result of code in the pump ignoring what type of fluid is being pumped, causing the pumped fluid to be passed to a connected tile as if pressurized. It may not be desired behavior, and thus may change in subsequent versions. It is possible to use this effect to channel magma from distant source. If you happen to have constructed your fortress very far from the magma source, you can use a screw pump to "pressurize" the magma to force to flow much more quickly. Where unpressurized magma might take years to flow across the map, pressurized magma would just take a few days.

[[Image:Pumpedmagma.png|thumb|154px|Pumps will cause magma to rise to the level of the pump (cross section)]]

==Magma compared to water==

Magma is a chunky liquid. As such, it acts like water in certain circumstances, but acts differently in others.

===Similarities===

*Magma fills a tile and has seven possible depths.
*Magma flows outward and downward to expand into clear space.
*Screw pumps work in magma.
*Floodgates and [[pressure plate]]s work in magma.
*Constructed [[wall]]s of all kinds safely contain magma.
*Objects thrown into magma sink to the bottom.
*Magma that is only 1 deep "evaporates" over time.

===Differences===

*Magma is extremely hot, and capable of melting objects and buildings made of most materials (see [[Magma#Magma vs. built objects|Magma vs. built objects]]) and thus destroying them.
*Magma is not normally pressurized, it seeps out of holes slower than water and slow enough for any [[dwarves]] to outrun, unless they are the ones digging into it.
*Magma flows up from a direct vertical line from the bottom of a [[Magma#Magma sources|Volcano or Magma Pipe]] only. Otherwise, its level may rise only by dripping more magma from above, and new magma may only distribute itself by moving down or to the sides, but never up.
*Magma reacts violently with water, releasing steam and, depending on the amount of magma, leaving behind tiles of solid obsidian which can be mined, smoothed or engraved like any natural tile.
*Magma is not a water source. Dwarves can't drink it or supply it to their wounded.
*Magma mist is not generated by falling magma, but only by a [[cave-in]].
*Magma mist, unlike regular mist, will burn whatever it touches.

== Magma vs. built objects ==

Some objects that come in contact with magma will function fine, no matter what their material. Others will melt or cease to work properly unless they're made of [[magma-safe materials]].

* [[Workshop]]s that are powered by magma need not be built of magma-safe materials to function.

* Constructed objects like [[wall]]s, [[floor]]s, [[stairs]] and [[ramps]] can be made of any material, even those that are not "Magma-safe", and can come into contact with magma without issues.

* Like walls, [[door]]s can also be built out of any material and still hold back lava as long as it's in the "closed" position. It may be wise to make sure hallways/rooms close to an engineering project involving magma have plenty of doors, just in case you have a little too much [[fun]] when you forget to build that last [[floodgate]].

* [[Bridge]]s that are built over magma may be constructed of any material. However, bridges that are submerged in magma must be constructed of a magma-safe material.

* Most machines must be made of [[magma-safe materials]] to function for more than a few minutes in magma. This includes [[floodgate]]s. Unsafe materials will function for a while, but then burn away. Screw pumps will not melt, but will burn. Stone [[block]]s and [[copper]] [[pipe]]s/[[enormous corkscrew|corkscrews]] will not melt.

* Stone [[mechanism]]s attached to a construction will melt in magma unless made of bauxite or [[raw adamantine]], even if the construction itself is made of [[steel]]. In addition, if the mechanisms melt off of a floodgate, the floodgate will cease to be "constructed" and become an unplaced item again.{{version|0.27.176.38c}} At this point, the magma will flow over it freely.

== Magma creatures ==
[[Fire imp]]s, [[fire man|firemen]], [[magma man|magma men]], and [[fire snake]]s inhabit Magma. Fire snakes are a type of [[vermin]] that can set your fortress on [[fire]] with little to no warning. Like all other vermin, they may spawn a short distance outside their native environment, meaning they can appear in any region near a magma pipe, even if the region and magma have no physical connection.

== Temperature settings ==

Magma is almost harmless if temperature is disabled in the Dwarf Fortress init file. It can still trap and suffocate or simply starve your dwarves in some situations. It will not melt bridges, etc. constructed of non-[[magma-proof]] materials.

== Magma reactions ==

*Water: If magma happens to contact water it produces some steam and [[obsidian]]. Steam is no longer deadly (as in the old 2D version) so steam traps are ineffective; however, it is now much safer to cast large volumes of [[obsidian]] inside mined or constructed molds. The resulting slabs of [[obsidian]] are functionally identical to native stone.
*[[Brook]]s: If magma comes in contact with a brook, it will not produce steam, but will turn the water tile below the brook to obsidian, and give the brook tile the appearance of a dried-up brook.
*Rocks: [[stone|Rock]]s left over from mining will melt if magma covers them. During the season change, all molten rock is automatically removed (at the same time as blood/vomit).
*Trees: [[Tree]]s will not (yet) burn or be destroyed by magma.
*Speed: Magma moves relatively slowly. While it is nearly impossible to try to seal off water let loose, magma is slow enough for your dwarves to build a floodgate or door, or even wall off the flooding area, if you happen to let magma loose by mistake.
*Pressure: Magma does not transmit [[water pressure|pressure]].
*In a volcano or a magma pipe, magma will occasionally appear in small columns above its surface [http://www.bay12games.com/forum/index.php?topic=26201.msg311730#msg311730] if it is below its original level. It will not be created above floors. It will be created in 7s, and will probably spread around in few seconds. This may be deadly to unlucky dwarves standing around. Therefore, to be sure to avoid casualties, do not build workshops except at the highest level of magma.

[[Category:Physics]]
{{Magma FAQ}}