Dwarf Fortress Wiki - User contributions [en]

Coffin

2022-12-23T08:42:19Z

Prometherus: /* Usage */ Remove d_init info as it seems to be obsolete

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

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

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

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

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

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

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

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

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

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

Technical tricks

2022-12-23T08:41:38Z

Prometherus: /* Settings - d_init.txt */ Remove COFFIN_NO_PETS_DEFAULT; it doesn't seem to have any effect in v50

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

In order to configure ''Dwarf Fortress'' to your liking there are two files you can edit, [[init.txt]] and [[d_init.txt]]. The first file, init.txt, contains mostly the settings pertaining to the window, rendering and sound of ''Dwarf Fortress''. The second file, d_init.txt, contains settings that affect game features such as saving and population controls.

== Locating your configuration files ==
In most cases, the configuration files for ''Dwarf Fortress'' are in the <tt>data/init</tt> folder of the directory you installed it to.

If you installed ''Dwarf Fortress'' on Arch Linux using <tt>pacman</tt>, then running <tt>dwarffortress</tt> will dump the configuration files you should edit into your home directory under <tt>.dwarffortress</tt> - editing the files under <tt>/opt/dwarffortress/data/init</tt> will ''not'' change how the game behaves.

If you installed ''Dwarf Fortress'' on Void Linux using <tt>xbps-install</tt>, then running <tt>dwarffortress</tt> will dump the configuration files you should edit into your home directory under <tt>.local/share/dwarffortress</tt>.

== Editing the configuration files ==
You can edit the configuration files with almost all text editing software, such as Vim or Emacs.
All data in these files is contained in what are called [[token]]s. Each token is defined by the text between an opening square bracket, '[', and the first closing square bracket, ']'. Arguments to the various tokens are separated from a token identifier by a colon, ':'.

== Settings - init.txt ==

=== Sound ===
*[SOUND:YES]
Change the argument from "YES" to "NO" to completely remove sound and music from the game. If this is "NO", it will not be possible to change the volume from the in game options menu.

*[VOLUME:255]
Changes the default volume of sound in ''Dwarf Fortress''. The argument can be any value from 0 to 255, with 255 representing 100% volume.

=== Intro Movie ===
*[INTRO:YES]
Change the argument from "YES" to "NO" to turn off the [[intro movie]].

=== Window ===
*[WINDOWED:PROMPT]
Changes the window mode that ''Dwarf Fortress'' runs in. If this is "PROMPT" the game will ask you if you want to run in windowed or fullscreen mode. If this is "NO" the game will be fullscreen with no prompt, and if this is "YES" the game will be in windowed mode with no prompt.

*[WINDOWEDX:80]
If this is below 256, this specifies the width of the grid used by ''Dwarf Fortress'' with a minimum of 80. As such, the width of the window used will be the product of this value and the width of the font used. If this value is 256 or above, it specifies the width of the window used directly.

*[WINDOWEDY:25]
If this is below 256, this specifies the height of the grid used by ''Dwarf Fortress'' with a minimum of 25. As such, the height of the window used will be the product of this value and the height of the font use. If this value is 256 or above, it specifies the height of the window used directly.

[WINDOWEDX:98][WINDOWEDY:98] will make window big enough to display whole 2x2 [[embark]] [[site]] with 8x8 [[tileset]] or one embark tile with 16x16 tileset.

*[FONT:curses_640x300.png]
The font file that ''Dwarf Fortress'' uses. This value can be any .bmp or .png image in the data/art folder.

*[RESIZABLE:YES]
Can be "YES" or "NO". If this is "YES" you can resize the window while ''Dwarf Fortress'' is running.

*[TOPMOST:NO]
If this is set to "YES", the window is kept above all other windows.

=== Fullscreen ===
These settings are used if the [WINDOWED:PROMPT/YES/NO] token is either "NO", or "PROMPT" and the fullscreen option is chosen.

*[FULLSCREENX:0]
The width of the screen in fullscreen mode. If the value is 0, ''Dwarf Fortress'' chooses the best resolution for you.

*[FULLSCREENY:0]
The height of the screen in fullscreen mode. If the value is 0, ''Dwarf Fortress'' chooses the best resolution for you.

*[FULLFONT:curses_800x600.png]
The font file that ''Dwarf Fortress'' uses. This value can be any .bmp or .png image in the data/art folder.

*[BLACK_SPACE:YES]
If this is "NO", tiles will be stretched to fit to the screen if there is a resolution mismatch. If this is "YES", the extra space around the grid is filled with black space and the tiles are left unstretched.

=== Graphics ===
*[GRAPHICS:NO]
Can be "YES" or "NO". If this is "YES", ''Dwarf Fortress'' will use the raw/graphics folder for certain tile graphics. Currently this is limited to [[Graphics set repository|creature graphics]].

*[GRAPHICS_WINDOWEDX:0]
The window width used when ''Dwarf Fortress'' is in windowed mode.

*[GRAPHICS_WINDOWEDY:0]
The window height used when ''Dwarf Fortress'' is in windowed mode.

*[GRAPHICS_FONT:curses_square_16x16.png]
The [[Main:Tileset repository|font]] used by ''Dwarf Fortress'' when in windowed mode and [GRAPHICS:YES/NO] is "YES".

*[GRAPHICS_FULLSCREENX:0]
The width of the screen used by ''Dwarf Fortress'' if in fullscreen mode.

*[GRAPHICS_FULLSCREENY:0]
The height of the screen used by ''Dwarf Fortress'' if in fullscreen mode.

*[GRAPHICS_FULLFONT:curses_square_16x16.png]
The font used by ''Dwarf Fortress'' when in fullscreen mode and [GRAPHICS:YES/NO] is "YES".

*[GRAPHICS_BLACK_SPACE:YES]
If this is "NO", the tiles are stretched to fit the window in the case of a resolution mismatch. If this is "YES", the extra space is filled with black space and the tiles are left unstretched.

=== Video Card Options ===

*[PRINT_MODE:2D]
This value changes how ''Dwarf Fortress'' draws to the screen. As such, changing this value can significantly change the performance of ''Dwarf Fortress'' on your computer. Possible values for this are "2D", "2DSW", "2DASYNC", "STANDARD", "TEXT", "ACCUM_BUFFER", "FRAME_BUFFER", "VBO" and "PARTIAL". A technical description of what these do can be found [http://www.bay12forums.com/smf/index.php?topic=63667.msg1478550#msg1478550 in this post].
"PARTIAL" print mode takes an additional argument similar to how the PARTIAL_PRINT value worked in previous versions, with the number representing the number of frames a changed tile is rendered before it is skipped.
"TEXT" is only available on OS X and Linux, and uses the 8 ANSI colors with emboldening. OS X users should enable "Use bright colors for bold text" in the Profile tab of their Terminal preferences.

*[SINGLE_BUFFER:NO]
If this is "NO" ''Dwarf Fortress'' will use double buffering, which may reduce flickering of the screen at the expense of a possible (small) drop in frame rate. If this is "YES", double buffering is turned off.

*[ARB_SYNC:NO]
On video cards that support the OpenGL ARB_sync extension, turning this on can greatly improve performance in GPU overload conditions. However, this can cause ''Dwarf Fortress'' to crash on some video cards.

*[VSYNC:NO]
If this is set to "YES", when ''Dwarf Fortress'' redraws the screen it will wait for the monitor to finish its vertical retrace. This can negatively impact your FPS if G_FPS is set high, as the game is forced to suspend calculating game frames to wait for the monitor to finish. The main reason to change this to "YES" is if tearing of the game image occurs regularly for you.

*[TEXTURE_PARAM:LINEAR]
Can be either "LINEAR" or "NEAREST". If it is "NEAREST", the texture values use the nearest pixel value without averaging. If it is "LINEAR", the texture values use the average of the adjacent pixels. In terms of what the two options do to the graphics, the "LINEAR" option will appear to blur adjacent pixels and can result in a fuzzy appearance. The "NEAREST" option will produce a sharp, pixelated look but may result in images looking clipped at some different screen resolutions.

=== FPS ===
*[FPS:NO]
If this is "YES" a FPS counter is displayed on the top left corner.

*[FPS_CAP:100]
The game frames per second the game limits itself to. This changes the number of turns calculated per second, not the graphical frames displayed. If this value is 0 the FPS is uncapped.

*[G_FPS_CAP:50]
The graphical frames per second the game attempts to draw. This changes the number of times ''Dwarf Fortress'' draws itself to the screen per second. Lower numbers will cause ''Dwarf Fortress'' to run faster but skip displaying more game frames between each redraw.
To find the number of game frames that are calculated per redraw done by ''Dwarf Fortress'', divide the value for FPS_CAP by the value of G_FPS_CAP. In the default case, this is 100/50=2, so for every second frame calculated ''Dwarf Fortress'' will redraw the screen.

=== Priority ===
*[PRIORITY:NORMAL]
Change this to affect the process priority of ''Dwarf Fortress''. Higher priorities mean that ''Dwarf Fortress'' will run faster and other programs will run slower. Possible values are "REALTIME", "HIGH", "ABOVE_NORMAL", "NORMAL", "BELOW_NORMAL" and "IDLE".

=== Game Options ===
*[ZOOM_SPEED:10]
How fast the game zooms. A value of 10 corresponds to increasing grid size by 10 units each time you zoom.

[RECENTER_INTERFACE_SHUTDOWN_MS:0]
This controls the number of milliseconds that must pass before input works again after the view recenters on an event in dwarf mode.

[COMPRESSED_SAVES:YES]
Change this to "NO" if you want to leave save uncompressed. If "YES", saves are compressed in the .zip format to save space. If you experience save corruption, you can try turning this off. However, turning this off may cause saves to be over ten times their compressed size, which can lead to your save folder growing several gigabytes large if you have seasonal backups enabled. Make sure you have plenty of disk space or delete old backups regularly if you want to turn this off.

=== Mouse ===
*[MOUSE:YES]
Determines if the game accepts mouse input.

*[MOUSE_PICTURE:NO]
If the game should display a picture in place of the system mouse icon. The picture lags if ''Dwarf Fortress'' is lagging.

=== Keyboard ===
*[KEY_HOLD_MS:250]
The number of milliseconds before holding a key causes it to be repeated.

*[KEY_REPEAT_MS:150]
The number of milliseconds between consecutive repetitions of a held key.

*[KEY_REPEAT_ACCEL_LIMIT:8]
*[KEY_REPEAT_ACCEL_START:10]
If you set KEY_REPEAT_ACCEL_LIMIT above one, then after KEY_REPEAT_ACCEL_START repetitions the repetition delay will smoothly decrease until repetition is this number of times faster than at the start.

*[MACRO_MS:150]
The number of milliseconds between macro instructions.

== Settings - d_init.txt ==

=== Save Behavior ===
*[AUTOSAVE:NONE]
When ''Dwarf Fortress'' should automatically save your game. If this is "NONE", ''Dwarf Fortress'' never saves your game for you. Possible values are "NONE", "SEASONAL", "SEMIANNUAL" and "YEARLY".

*[AUTOBACKUP:NO]
If this is "YES", ''Dwarf Fortress'' will back up your save file each time it autosaves your game.

*[AUTOSAVE_PAUSE:NO]
If ''Dwarf Fortress'' should pause the game each time it autosaves for you.

*[INITIAL_SAVE:NO]
If this is "YES", ''Dwarf Fortress'' will save the game immediately after you embark.

=== More Game Options ===
*[IDLERS:TOP]
Where to display the number of idling dwarves. The value can be either "TOP", "BOTTOM", or "OFF".

*[PAUSE_ON_LOAD:YES]
If "YES", ''Dwarf Fortress'' starts Fortress mode paused.

*[TEMPERATURE:YES]
Turns [[temperature]] ''calculations'' on or off. If temperature calculations are off, only a few direct temperature changes will take place. For example, [[magma]] will set tiles and creatures to high temperatures, but those tiles will never cool and those creatures will not catch fire. Effects that rely on temperature calculations, such as water freezing, melting, or evaporating, or creatures and items taking temperature-related damage, will not occur.

*[WEATHER:YES]
Turns [[weather]] on or off. If weather is off it will never rain or snow.

*[ECONOMY:YES]
Turns on or off the fortress mode dwarven economy. This has no effect, since the economy does not function in v0.40.

*[INVADERS:YES]
Turns on or off fortress mode [[siege]]s. Turning this off for your first couple of games may make the game easier to start with.

*[CAVEINS:YES]
If this is "YES" it is possible for [[cave-in]]s to occur.

*[ARTIFACTS:YES]
Turns on or off [[strange mood]]s and the resulting [[artifact]]s.

*[ZERO_RENT:NO]
If this is "YES", when the dwarven economy kicks in all rooms will cost nothing, allowing even the poorest of haulers to have a room fit for a king. This has no effect, since the economy does not function in the current version.

*[TESTING_ARENA:YES]
Turns on or off the testing arena.

*[WALKING_SPREADS_SPATTER_DWF:NO]
Turns on or off the spread of blood spatter and other contaminants between creatures and ground tiles in [[Fortress mode]]. As contaminants are [[Blood|buggy]] and can have a major negative impact on [[FPS]] in [[Fortress mode]], it is recommended to leave this set at "NO" for now.

*[WALKING_SPREADS_SPATTER_ADV:YES]
Turns on or off the spread of blood spatter and other contaminants between creatures and ground tiles in [[Adventurer mode]].

*[PATH_COST:1:2:5:25]
The pathfinding costs associated with different [[traffic]] values.

*[STORE_DIST_ITEM_DECREASE:20]
*[STORE_DIST_SEED_COMBINE:1000]
*[STORE_DIST_BUCKET_COMBINE:1000]
*[STORE_DIST_BARREL_COMBINE:1000]
*[STORE_DIST_BIN_COMBINE:1000]

*[SHOW_IMP_QUALITY:YES]
If "YES" ''Dwarf Fortress'' will display the [[quality]] of an item's improvements in the name. If you get annoyed by seeing items like *<*sword*>* you can
get rid of the outside ** by setting this to NO.

*[SHOW_ALL_HISTORY_IN_DWARF_MODE:YES]
If "YES", inspecting engravings and artifacts in Fortress Mode will have an extended history displayed.

*[LOG_MAP_REJECTS:NO]
If this is "YES", ''Dwarf Fortress'' will log the reason why maps were rejected during world gen in the log.txt file.

*[GRAZE_COEFFICIENT:100]

=== Adventure Mode ===
*[MORE:YES]
*[DISPLAY_LENGTH:23]
*[ADVENTURER_TRAPS:NO]
If you set this to "YES" your adventurer will trigger the traps of your old fortresses.
*[ADVENTURER_ALWAYS_CENTER:YES]
*[ADVENTURER_Z_VIEWS:UNHIDDEN:9]

=== Nicknames ===
*[NICKNAME_DWARF:REPLACE_FIRST]
*[NICKNAME_ADVENTURE:REPLACE_FIRST]
*[NICKNAME_LEGENDS:REPLACE_FIRST]

=== Embark Options ===
*[EMBARK_WARNING_ALWAYS:NO]
If this value is YES, then it will always pop up a warning screen when you embark (Like you get when you have [[DF2012:Water#Salt Water|Salt Water]] or an [[DF2012:Aquifer|Aquifer]] on-site)
*[SHOW_EMBARK_TUNNEL:FINDER]
*[EMBARK_RECTANGLE:4:4]
The size of the default embark site.

=== Wounds ===
*[WOUND_COLOR_NONE:7:0:1]
The color of body parts when there are no recorded active wounds on the part.
Default = white

*[WOUND_COLOR_MINOR:6:0:0]
The color of body parts when there is any damage that doesn't have functional/structural consequences (might be heavy bleeding though).
Default = brown

*[WOUND_COLOR_INHIBITED:6:0:1]
The color of body parts when there is any muscular, structural or functional damage without total loss.
Default = yellow

*[WOUND_COLOR_FUNCTION_LOSS:3:0:1]
The color of body parts when an important function of the part is completely lost, but the part is structurally sound (or at least partially intact).
Default = bright cyan

*[WOUND_COLOR_BROKEN:4:0:1]
The color of body parts when the part has lost all structural integrity or muscular ability.
Default = bright red

*[WOUND_COLOR_MISSING:0:0:1]
The color of body parts when the part is completely gone.
Default = dark gray

=== Tiles ===

*[SKY:178:3:0:0]
The tile and color of areas that are far below the currently displayed z level.
The format is SKY:<character>:<foreground color>:<background color>:<brightness>. <character> can be either an ASCII number or a character in single quotes, like '#'.

*[CHASM:250:0:0:1]
The tile and color of areas that are far below the currently displayed z level while indoors.
The format is the same as for SKY above.

*[PILLAR_TILE:'O']
The tile displayed for pillars. Pillars are created at the ends of strings of wall tiles. Some [[tilesets]] may have been designed to use tile 9, 10, or 255 for this, even some that are primarily ASCII, and may or may not include a custom d_init.txt file to do so.

*Multiple [TRACK_*] and [TREE_*] lines
The tiles displayed for most of the various possible [[track]] or [[tree]] parts. Not all the track tiles can be customized, such as the [[roller]]s or the track stop. By default, the track tiles are followed by an I to have them displayed with inverted colors so that they don't look the same as walls. Some tilesets may have been designed to use tile 9, 10, or 255 for tree trunk pillars, instead of the default 'O'. Note that the TREE_TRUNK_* and TREE_CAP_WALL_* corner tokens use a different naming convention than the other tokens; For example, by default TREE_TRUNK_NW uses tile 201 which is ╔, while TREE_BRANCH_NW uses 217 which is ┘, and TRACK_NW uses 188 (with inverted colors) which is ╝.

*[VARIED_GROUND_TILES:YES]
If this is "YES" the ground will be varied randomly using the tiles ,.`'.
If this is "NO", only the period will be used for ground tiles.

*[ENGRAVINGS_START_OBSCURED:NO]
If this is "YES", all [[engravings]] are displayed initially looking the same, like highlighted smooth walls/floors. Otherwise, they'll be displayed as a tile of one of the things they depict. Either way, a given engraving's behavior can be changed through designation.

*[SHOW_FLOW_AMOUNTS:NO]
If "YES" ''Dwarf Fortress'' displays water as numbers from 1-7 indicating [[depth]].

=== Resolution to Grid Ratios ===
Taken from [http://www.bay12forums.com/smf/index.php?topic=22302.msg241991#msg241991]

{| class="wikitable" border="1"
|-
! colspan="2" | Geometry
! colspan="3" | Character Size
|-
! Resolution
! Aspect
! 8x8
! 12x12
! 16x16
|-
| 800x600
| 4:3
| 100 x 75
| 66 x 50
| 50 x 37
|-
| 1024x768
| 4:3
| 128 x 96
| 85 x 64
| 64 x 48
|-
| 1152x864
| 4:3
| 144 x 108
| 96 x 72
| 72 x 54
|-
| 1280x960
| 4:3
| 160 x 120
| 106 x 80
| 80 x 60
|-
| 1600x1200
| 4:3
| 200 x 150
| 133 x 100
| 100 x 75
|-
| 1280x1024
| 5:4
| 160 x 128
| 106 x 85
| 80 x 64
|-
| 1440x900
| 16:10
| 180 x 75
| 135 x 56.25
| 90 x 37.5
|-
| 1680x1050
| 16:10
| 210 x 131
| 140 x 87
| 105 x 65
|-
| 1920x1080
| 16:9
| 240 x 135
| 160 x 90
| 120 x 67
|-
| 1920x1200
| 16:10
| 240 x 150
| 160 x 100
| 120 x 75
|}

{{Category|Game}}
[[ru:Technical tricks]]

Coffin

2022-12-23T08:32:41Z

Prometherus: /* Usage */ fixed wrong menu key

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

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

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

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

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

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

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

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

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

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

Coffin

2022-12-23T08:32:05Z

Prometherus: /* Usage */ Updated for v50

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

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

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

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

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

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

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

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

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

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

Dwarf Fortress Wiki talk:Versions

2022-12-22T10:16:18Z

Prometherus: /* v50 specific issues */ Added question regarding menu navigation.

{{archive|
# [[DF Talk:Versions/Archive 1|Page 1]]}}

== Version 0.31.19 starts a new DF generation? ==

My reading of Toady's comments on the release of 0.31.19 is that it came out basically because he felt it would take too long to get DF all the way to 0.32. With the ore changes, the sitefinder changes, the addition of grazing and several different industries, there's a lot of changes between 31.18 and 31.19. So I'm thinking it might be a good idea to call it the first release of DF2011 - and what we refer to as "DF2010" would then become 0.31.18.

Thoughts? --[[User:DeMatt|DeMatt]] 07:06, 28 February 2011 (UTC)

==Revisiting Redirects==

I wasn't around when the redirect policy was created, and I'm having trouble understanding the rationale. The example claims that linking [[Main:Cheese]] to [[cv:Cheese maker]] is problematic...but mainspace only ever redirects to the current version. If the best target in the current version is cheese maker, why not link to it directly? (It's not, at least for Cheese, since [[DF2012:Cheese]] exists now.) The explanation seems to be claiming that 40d articles that link to Cheese will follow the Mainspace link--but that hasn't been the case for a long while now. Articles in 40d automatically link against other articles in 40d, so that version remains internally consistent no matter where mainspace links to in the current version. For a current example, what do we gain by linking [[Main:Mead]] to [[cv:Mead]] and linking [[DF2012:Mead]] to [[DF2012:Alcohol]]?

If this really is just an outdated procedure, I recommend we drop the mummery and allow mainspace to link to cv:(best target). Double redirects ''may'' work (sometimes, but [[Main:Mead]] demonstrates a common problem where automatic redirection fails), but if they are unnecessary I think they should be avoided, partly because of problems like [[Main:Mead]] and partly because of the effort required to protect double redirects from users who believe they are problematic.--[[User:Loci|Loci]] ([[User talk:Loci|talk]]) 20:16, 8 January 2014 (UTC)

:I was just thinking that. I'm currently attempting to write a basic extension to eliminate the need for mainspace redirects entirely, although Mediawiki's class structure may make this more difficult than I had hoped (the only method I've found for resolving redirects takes the ''article text'' instead of a title, e.g. "#REDIRECT ..."). I do agree that the current situation with redirects isn't ideal, so I'm hoping this will work better (once I get it to work). --[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 20:42, 8 January 2014 (UTC)

Okay, that wasn't quite as clear as I meant it to be. In general, I think this is a tricky situation. Mediawiki wasn't designed to have five content namespaces, and certainly not chains of redirects between them. The problem that was pointed out in the [[DF:REDIR|policy]] is the fact that with:
Main:Foo -> cv:Bar
pages in the cv: namespace can't use [[<nowiki/>foo]], since the namespace links modification causes it to be treated as [[<nowiki/>cv:foo]] instead, which doesn't exist. The current suggested solution is this:
Main:Foo -> cv:Foo -> cv:Bar
This fixes the problem of [[<nowiki/>foo]] not working on cv pages, but creates issues with double redirects not always working. Another solution, which is more intuitive to new editors, is:
Main:Foo -> cv:Bar
cv:Foo -> cv:Bar
Both require creating two redirects. The first method has the advantage of ''ensuring'' that the cv redirect exists (otherwise, main:foo would be a redlink), while the second has the advantage of working more reliably in a couple cases.

What I'm trying to do is make main:Foo "jump" to cv:Foo when cv:foo exists, ''even if main:foo doesn't exist'' (basically it would treat all mainspace pages as redirects to cv pages, but only if the cv page exists and not the mainspace page). I had main:Bar jumping to cv:Bar fine, but if cv:Foo redirected to cv:Bar, accessing main:Foo would mysteriously stop at cv:Foo even if I increased the redirect limit. What I'm trying to do now is follow the redirects internally, without relying on Mediawiki to do it automatically - unfortunately, that has proved to be harder than I had hoped (and I sent my web server into an infinite loop while trying). I will try to work on this some more when I get a chance, although I'm not sure when that'll be yet :(. For now, feel free to fix broken double mainspace redirects as necessary, as long as redirects in the DF2012 namespace stay pointing to the right page (and new mainspace redirects get added in the DF2012 namespace too). --[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 04:21, 9 January 2014 (UTC)

:You're treating cv like a namespace--it's not. It is simply shorthand for "fill in the current version here". [http://dwarffortresswiki.org/index.php?title=User_talk:Briess&diff=182404&oldid=181281 As I discovered a long time ago on a server not far away], linking from Main:Foo to cv:Foo tends to break redirection chains. If, instead of linking to cv:Foo, you link to DF2012:Foo, it might just work. It would, of course, be better if your patch could evaluate cv itself, but even if you have to hardcode the current version it's a single point of maintenance that requires update very infrequently. (For that matter, we could probably dispense with the cv hack entirely and just have a bot update mainspace links from DF2012 to DF201X when we switch to a new version.)--[[User:Loci|Loci]] ([[User talk:Loci|talk]]) 20:05, 9 January 2014 (UTC)
::I know cv isn't a namespace - I was just trying to avoid future confusion when the DF2012 namespace changes. It's interesting that changing "cv" to "DF2012" fixes some broken redirects, although I've found that simply making an edit to a broken redirect can usually fix it as well. I've actually had the most problems with double redirects when the second one (in the DF2012 namespace) doesn't use the DF2012 prefix (e.g. main:Foo containing <nowiki>[[cv:Foo]] and DF2012:Foo containing [[Bar]]</nowiki>). I'd rather keep the cv alias even if it isn't necessary for mainspace redirects when I get the patch to work, since it makes it easier to refer to the current version of the page (for example, several MDF articles contain links to a vanilla page for things that don't change in the mod).
::Also, using aliases like "cv" is supported by Mediawiki; in fact, several WMF wikis use them (for example, "[[wikipedia:WP:Redirects|WP:Redirects]]" on Wikipedia). It's quite likely that Mediawiki isn't processing double redirects using aliases correctly, though, since that's uncommon on most wikis. --[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 21:35, 9 January 2014 (UTC)

In light of the lack of support for the current redirect policy, I propose we replace the current redirect section with:

:Mainspace article pages should use the cv: alias when redirecting to a versioned page, which will automatically update the link when a new version is released. For example, page "Main:Foo" should redirect to page "cv:Bar" (where "Bar" is the page that best describes the topic Foo in the current version).

:Pages in mainspace should only redirect to an older versioned page if that content no longer exists in the current version of the game (e.g. [[Cave river]], [[Chunk]]). In these cases the cv: alias cannot be used.

:Pages inside a versioned namespace should not use the cv: alias. Instead, they should redirect to the best page within that versioned namespace (e.g. [[DF2012:Dodging]], [[v0.31:Drink]]).

:Due to limitations of the wiki software, double redirects should be avoided if possible. When fixing double redirects in mainspace, please make sure to use the cv: alias as appropriate.

If no one objects, I will make this change in a few days.--[[User:Loci|Loci]] ([[User talk:Loci|talk]]) 20:21, 15 January 2014 (UTC)

:Okay with me. It may be worth mentioning that double redirects only really need to be changed when they don't work (since changing a lot of redirects that work isn't necessary), but I think it's clearer and more relevant than the current policy. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 00:26, 16 January 2014 (UTC)

Done.--[[User:Loci|Loci]] ([[User talk:Loci|talk]]) 20:55, 22 January 2014 (UTC)

I was finally able to get my extension to work after being motivated by one too many malfunctioning redirects. It now causes nonexistent pages in the main namespace to behave exactly like redirects to their DF2012 counterparts (when linked to, accessed directly, and transcluded). Double redirects also work (up to 100, in fact, although that was a temporary safety measure that I'll probably change). This means we'll be able to safely get rid of all mainspace redirects (redirects that redirect to something other than "cv" will still function if not deleted). —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 01:20, 14 March 2014 (UTC)
:What about articles which don't exist in the current version but do exist in older versions? Will those still need mainspace redirects, or will your extension be able to automatically redirect them to v0.31/40d/23a? --[[User:Quietust|Quietust]] ([[User talk:Quietust|talk]]) 01:29, 14 March 2014 (UTC)
::It ignores all mainspace pages that actually have content, including redirects, so pages like [[masons guild]] won't be affected (unless deleted). —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 01:47, 14 March 2014 (UTC)

Done and deployed. [[Cat]] is still treated as a redirect, even though I just deleted it (try clicking on the "redirected from" link). Pages that exist are ignored, so [[Masons guild]] and [[History of Dwarf Fortress]] still function normally (as a redirect to a 23a page and a non-redirect, respectively). —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 18:57, 14 April 2014 (UTC)

I'm sending around a bot right now to delete all redirects of the format "foo -> cv:foo" (a surprising number don't fit this format, so I'm leaving them alone for now). —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 20:43, 14 April 2014 (UTC)

:I'm confused. Do we use double redirects or not? Is there a single place we define our linking policy (including redirects), and is it updated?
:I had trouble linking to [[Consolidated_development]] in [[v0.34:Dragon]]. It kept pointing to v0.34:Consolidated_development, which does not exist. I ended up linking to Main:Consolidated_development to make it work. --[[User:Nahno|Nahno]] ([[User talk:Nahno|talk]]) 10:18, 1 July 2014 (UTC)

::That's a separate problem altogether - links in the versioned namespaces (v0.34, v0.31, 40d, 23a) automatically link to pages within their namespace. I may be able to set up a fallback to mainspace once I'm able to deploy again, but for now the "main:" alias is the intended solution. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 11:36, 1 July 2014 (UTC)

== Google often directs people to the 0.31 page ==

I've noticed a couple of times that finding a wiki page from an external search will often drop me onto a page from an older version. Is it possible to mitigate this somehow for new players? I could imagine something like redirecting old:Bar -> cv:Bar unless the user has come from old:Foo; no idea if that would actually work though. [[User:PeridexisErrant|PeridexisErrant]] ([[User talk:PeridexisErrant|talk]]) 11:48, 4 May 2014 (UTC)

:As a temporary solution, I could write a script that displays a banner of some kind if the user came from an external site. I'll ask Briess if he can do anything on the server level to increase the weighting of the current version's pages. (Obviously there are situations where people are looking for old pages, like [[23a:dungeon master]], so we don't want to disable indexing entirely on old pages.) —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 17:03, 4 May 2014 (UTC)

== DF2014? ==

As Toady [http://www.bay12games.com/dwarves/ draws closer to a new release], it might be worthwhile to discuss the addition of a new version to the wiki. The upcoming release covers two years of changes and introduces a number of new plants, foods, drinks, multi-tile trees, climbing, jumping, etc., so it is likely to have significant changes from the current DF2012. To avoid having people start new pages (and lose all the effort spent refining the prior version's page), I think it would be best to have a bot automatically copy over the DF2012 pages as a starting point for DF2014. I would suggest that these copied pages include a noticebox template mentioning that the content may be outdated, so that we can easily track which pages have been reviewed. I think either the {{tl|version check}} or {{tl|old}} template would work. --[[User:Loci|Loci]] ([[User talk:Loci|talk]]) 19:43, 5 May 2014 (UTC)

:This is what [[User:QuietBot]] did after the 0.34 release, so it's certainly possible to use the same script to migrate to DF2014. I would like a way of tagging migrated pages, since inaccuracies in some pages went unnoticed for months after they were migrated. Since {{tl|old}} is already in use, {{tl|version check}} may be a better solution (it can be reworded slightly, or we can make a separate template for DF2014 migration). —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 19:23, 1 June 2014 (UTC)
:Made [[Template:DF2014 migrated]] as an example. Any thoughts? —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 19:32, 1 June 2014 (UTC)

== Redirects inconsistency ==

Following a redirect is supposed to be exactly the same as going straight to the page it redirects to, but this actually isn't the case:
* Go to [[Seeds]] and you get [[v0.34:Seed]] (outdated)
* Go to http://dwarffortresswiki.org/index.php?title=Seeds&redirect=no and click on the link and you get to [[DF2014:Seed]] (current)
So if you search for "seed", the top result is the DF2014 version. But search for "seeds" and you get the redirect, which sends you to the outdated page instead. [[User:Hairy Dude|Hairy Dude]] ([[User talk:Hairy Dude|talk]]) 23:22, 22 February 2015 (UTC)

While I'm talking about redirects, it seems redirects to sections don't work: see [[DF2014:How do I manage my seeds and crops]]. I know MediaWiki is capable of this trick because Wikipedia does it. [[User:Hairy Dude|Hairy Dude]] ([[User talk:Hairy Dude|talk]]) 23:32, 22 February 2015 (UTC)

:I have absolutely no idea why [[seeds]] redirects to a v0.34 page - it could be a Mediawiki bug. The section links issue is due to a known issue in the redirect extension we use, which has yet to be fixed. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 00:01, 23 February 2015 (UTC)
:It looks like deleting both [[Seeds]] and [[DF2014:Seeds]] fixed things (by allowing AutoRedirect to handle the redirects instead). Feel free to tag any others with {{tl|bad redirect}}. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 00:03, 23 February 2015 (UTC)
::It gets stranger. [[Vial]] redirects explicitly to [[cv:Flask]] which displays (when you look at it with &redirect=no) as [[DF2014:Flask]], but still goes to the v0.34 version. It seems redirects interpret the cv: pseudo-namespace (or whatever it's called) in an outdated way. [[User:Hairy Dude|Hairy Dude]] ([[User talk:Hairy Dude|talk]]) 18:08, 23 February 2015 (UTC)
::I've added a note to this page about this issue. If it gets resolved, the note should be removed. [[User:Hairy Dude|Hairy Dude]] ([[User talk:Hairy Dude|talk]]) 21:04, 23 February 2015 (UTC)

==Reorganizing versions==

The internet deals with moved content... poorly. Google is still linking to v0.34 pages more than a year after the switch to "DF2014", and even the wiki software still has cached links pointing to the old version pages.

I propose reorganizing versions on the wiki to avoid moving content whenever possible. Instead of having a temporary "current version" namespace that changes occasionally, all the current information gets promoted to the Main namespace. When the next version split occurs, the Main articles as of a certain revision number can be copied to the newly-created permanent "old version" namespace, while all the current information remains in Main. This not only fixes the link rot issue, but it has a few other benefits as well: fewer administrative tasks, no lockdown (a historical version of the Main pages can be copied at any point, even if the Main articles are already modified for the new version), almost all the article history is maintained in the Main article (instead of being spread unevenly across multiple versions), no "temporary" namespaces are needed, fewer problematic long redirect chains, and hopefully less user confusion (since Main gets priority in search results, etc.).

As an example, today we would not have a DF2014 namespace (which is good because "temporary" namespaces historically disappear anyway). If you ran a search for [[seed]] you'd end up at Main:seed, which would have all the current information on seeds. The version box at the top of the page would still link to the older versions of the seed article. When a new version is released, an admin would choose a revision number and copy the Main:seed article as it exists at that revision number to v0.40:seed. That's it. One historical copy that needs little to no new editing, and zero redirections/moves.--[[User:Loci|Loci]] ([[User talk:Loci|talk]]) 19:02, 27 July 2015 (UTC)

:Makes sense to me. It would involve a lot of work, though (e.g. fixing templates and categories to account for the current version being in mainspace), although that should be doable thanks to {{tl|category}}, {{tl|version switch}}, etc.. A bot could be set up to copy revisions from before a release date as well, which would be more difficult (and maybe slower) than a direct copy, but not severely. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 17:24, 30 July 2015 (UTC)

:Actually, there are a few issues with that, namely that there wouldn't be an easy way to distinguish between versioned and non-versioned mainspace pages. There are ways to resolve Google search priority (we can exclude pages from older versions from search engine results if there are newer versions of those pages available, for example). —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 19:47, 6 August 2015 (UTC)

::There aren't very many non-versioned mainspace pages, and determining if a page is versioned is as simple as looking for the version template and/or categories added by the version template (e.g. copy [http://dwarffortresswiki.org/index.php/Category:Current this category] instead of Main:*). The problem with "suggesting" newer pages to Google is that they obviously aren't crawling our wiki regularly (if they were, the fact that the mainspace redirects point to new pages would automatically be picked up). Even if your Google hints worked they wouldn't do anything for all the other broken links out on the 'net.--[[User:Loci|Loci]] ([[User talk:Loci|talk]]) 20:35, 6 August 2015 (UTC)

::: Google actually crawls the wiki constantly - we probably get crawl hits from google for a continuous block of 2-3 hours per day, each and every day. Why they are slow to update is beyond me though. I can't remember why we didn't do this initially, but there was a technical limitation involved if I remember correctly. --[[User:Briess|Briess]] ([[User talk:Briess|talk]]) 22:05, 6 August 2015 (UTC)

::: There are <meta> tags that can be used to hide pages from search results (for search engines that recognize them, that is). Searching for {{tl|av}} or [[:Category:Current]] might work, although we'd have to make sure all of the DF2014 pages include that (some pages don't, particularly some disambiguation pages, although all of them should). —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 22:53, 6 August 2015 (UTC)

:Is there a particular reason main and current are separate to begin with?—[[User:CLA|CLA]] ([[User talk:CLA|talk]]) 00:17, 7 August 2015 (UTC)

::It's mostly intended to distinguish between versioned and non-versioned pages and make version-related templates simpler to work with, since every versioned page has a namespace. I wasn't active here in 2010 when this system was created, so Briess and Emi would know more.
::Another issue I just thought of with Loci's suggestion is categories - currently, categories like [[:Category:Animals]] are used to organize the versioned sub-categories. Sure, we can change {{tl|Category}} to categorize mainspace pages in [[:Category:v0.40:Animals]] or [[:Category:DF2014:Animals]], but that would be less straightforward because there wouldn't be a namespace with that name (until pages are migrated when a newer major version is released). —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 13:05, 7 August 2015 (UTC)

:Moving current pages to the main namespace sounds like a great idea. -[[User:Jecowa|Jecowa]] ([[User talk:Jecowa|talk]]) 20:47, 4 January 2018 (UTC)

Another thought: dealing with migrating redirects could be difficult with this proposal - specifically, determining which redirects should be migrated to a versioned namespace. Redirects can't contain {{tl|av}}, at least not before ``#REDIRECT``. I ''think'' it would be possible to copy pages in two stages, though - all non-redirects first, then all redirects whose targets were also copied. Thoughts? Anything I'm missing? —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 23:41, 27 June 2019 (UTC)

Some subpages (particularly /raw and /Edit notice) also deliberately lack {{tl|av}}, although those shouldn't be too hard to handle. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 00:35, 9 July 2019 (UTC)

:Redirect pages (and all other edge cases I've looked at) can be included in categories (like [[:Category:Current]]) to determine whether or not they should be copied into an archival version. But if the redirects are "properly qualified" then they can all be copied over blindly. Mainspace redirects pointing to versioned information should use a blank namespace (which will be automatically constrained to the archival namespace); mainspace redirects pointing to unversioned information should use an explicit "Main" (which will automatically link back to the unversioned page). Then, when [[[[Toady]]]] gets copied to [[[[v0.4x:Toady]]]] it will point back to [[[[Main:Toady One]]]]. Meanwhile, [[[[Beer]]]], copied to [[[[v0.4x:Beer]]]], will properly point to [[[[v0.4x:Alcohol]]]].--[[User:Loci|Loci]] ([[User talk:Loci|talk]]) 20:00, 14 July 2019 (UTC)

::I think qualifying redirects is the best solution here - categorizing redirects manually is another possible source of errors, since categories (or a lack thereof) would only be visible on the redirect page itself, and [[:Category:Current]] is a hidden category. Copying over mainspace redirects into versioned namespaces would also resolve some issues that have come up due to those not reliably existing currently. I should be able to set up a bot script to add "main:" to current mainspace redirects (and it shouldn't break anything, since those redirects go to other mainspace pages anyway). —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 21:57, 14 July 2019 (UTC)

(Note: I wrote all of this without noticing the previous discussion above.) I was wondering, when the wiki creates a new namespace for a major release again, if it is possible to ''not'' create a namespace for the next current version (e.g. "DF202x") and instead have the mainspace articles (which are currently redirects) become the new cv and move the content there. Therefore, [[cv:Cat]] would just be "[[Cat]]" (or [[Main:Cat]]).

Certain namespace-related templates like [[Template:Ns/0]] would need to be changed, though nothing significant as far as I know. For most cases, any "DF2014" would be replaced with "Main" or even blank. There's also multiple extensions handling the current namespace system and they may need to be modified too, though I'm not sure if or how much. I'm guessing based on the discussions above that it will change stuff up.

My reason is the current namespace is increasingly becoming more anachronistic. "DF2014" could be misinterpreted as "this page is about the 2014 version of the game" or "this page was last updated in 2014", which I've seen a few people in forums mention. Granted that [[Template:Av]] is on the top of very article, I still think the namespace is inconsistent with the recentness of the article. But how is this related to what I'm asking for? Let's say we continue the current system: if we happen to do a new namespace change this year and create DF2020, the next major release (after graphics/UI) will be mythgen, which is estimated to take several years to develop (the Big Wait), and so the anachronism will start over again. The proposed way will prevent this from occurring for the next major release and every release thereafter.

I think the confusion with having a namespace that becomes old-fashioned overtime supersedes the confusion with not marking current versioned articles with a namespace. Most users just search "Cat" on the search bar and naturally expect to get information about the latest release of DF. So if users go a page that's just titled "Cat", they won't expect outdated info about cats from a previous release. That's how the current system works anyways. We'll be skipping the two-step process that we have now. It'll make several wiki tasks much simpler as well. Editors can create new articles for current versions without remembering to add a namespace. It'll fix any existing issues with (double) redirects; instead of [[Main:Kitten]] redirecting to [[cv:Kitten]], which goes to [[DF2014:Kitten]], which then redirects to [[DF2014:Cat]], [[Main:Kitten]] would just redirect to [[Main:Cat]]. And the cv: alias will no longer be necessary since "cv:" = "Main:" and will be forever.

There's no need to differentiate the current version and previous versions with a namespace for the current version is what I'm saying. Articles of previous versions will retain their respective namespaces. Users will still type "40d:Cat" to go to the 40d version of the article, but if they want the current version, they'll just type "Cat" (like now). The mainspace containing the "live" version of an article is natural and would create no uncertainty when browsing the wiki. And it would simplify the wiki somewhat and future-proof this anachronism problem. As a bonus, this change will also prevent web search engines from showing previous version pages when typing "DF cat" or something. (This isn't happening right now as DF2014 has been the current namespace for ~6 years, but it'll happen again when everything moves to a new namespace.)

This is the gist of it, and I may have ignored most of the problems with this proposal. I have personally wished for the whole version namespacing be made less complicated and have been seeking for a solution, and I feel like this is the best way to go about in the future. – [[User:Doorkeeper|Doorkeeper]] 21:27, 14 August 2020 (UTC)

:<s>Whoops, looks like Loci already proposed this exact thing long ago. I definitely missed that discussion and should have checked first. My apologies. I'll move my text to that section and remove this one. – [[User:Doorkeeper|Doorkeeper]] 21:36, 14 August 2020 (UTC)</s> Done. – [[User:Doorkeeper|Doorkeeper]] 21:40, 14 August 2020 (UTC)

:The main issue I have with that is that putting pages about the current version in a namespace also differentiates between those pages and pages not about ''any'' version (for example, [[Toady One]] does not need a 40d or v0.34 page). Yes, we can use {{tl|av}} to mark versioned pages, but people often forget to add that to new pages. The current system also allows determining whether a page is versioned or not from its title, which makes migrations a lot faster. Relying on {{tl|av}} would require either reading the content of every page (which would slow scripts down significantly) or cross-checking with the list of all pages including the template (feasible, but a bit more complicated, and still susceptible to missing templates). I suppose that manually fixing and migrating pages missing {{tl|av}} later wouldn't be too much work, though.
:I am definitely in favor of changing "DF2014" (or a new namespace) to "Current", though. I was in favor of "DF2014" in 2014, but I don't think it makes sense anymore, and "Current" seemed to be a popular alternative in both the DF2012 and DF2014 discussions on the matter. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 04:02, 16 August 2020 (UTC)

== Weird redirect behaviour ==

[[Pump stack]] redirects to [[cv:Screw pump#Pump stack]]. If you look at the redirect itself it says it redirects to DF2014 namespace, which is correct. But if you actually follow the redirect, it goes to v0.34 namespace. [[User:Hairy Dude|Hairy Dude]] ([[User talk:Hairy Dude|talk]]) 16:10, 20 August 2018 (UTC)
:Yeah, that's part of the issue described in the above section (the wiki caching part, not on Google's end.) —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 15:00, 21 August 2018 (UTC)

== v50 organization ==

Some wiki admins have had a talk on Discord and decided that the most sustainable path forward is to put content for all future versions of DF in the main namespace. We will be working on a bot to do this in the next few days. Feel free to chime in with suggestions here. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 22:56, 14 December 2022 (UTC)

:Is it maybe possible to do backwards-namespacing? Like we have a "Main" namespace, which people are free to update, and whenever there's a new version of DF the "Main" namespace is copied into a namespace for the then old version, much like how you'd branch a stable branch from a development branch when working with a git-project? [[User:Therahedwig|Therahedwig]] ([[User talk:Therahedwig|talk]]) 23:13, 14 December 2022 (UTC)

::Yeah, we could do that if we decide to. We were talking about doing that for v50, actually, and might still do something similar to preserve edit history if it doesn't end up being too hard to automate. Our hope is that we will not introduce new namespaces for v50 -> v5x, unless there is a serious breaking change (and hopefully there isn't one). But if we change our mind, one advantage of the type of migration you mentioned is that it can be done retroactively - we can copy historical revisions that were current at the time of the release, and would only lose some typo fixes made after the release that apply to earlier versions as well. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 02:11, 15 December 2022 (UTC)

ETA is < 24 hours. Doing some final checks on a migration script. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 07:08, 19 December 2022 (UTC)

: We should really have a task list as there are many things that change and need updating. Including but not limited to:
:* Most templates that used the previous namespace convention broke, including nav templates.
:* Many game files changed locations and their pages need to be updated.
:* Raws need to be updated.
:* Various features added, changed, removed.
:* UI has been changed -- though I am more inclined to wait for classic release to avoid extra work --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 06:56, 20 December 2022 (UTC)

"''Raws need to be updated.''" Including applying text wraparound where necessary, I suppose - more than a few of them have proven to be that special kind of...''difficult'' to navigate otherwise, shall we say? [[User:Silverwing235|Silverwing235]] ([[User talk:Silverwing235|talk]]) 12:52, 20 December 2022 (UTC)

:There is already a task list in the [[#v50 migration|section below]] that includes templates and raws, with an explanation. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 16:25, 20 December 2022 (UTC)

== v50 migration ==

The initial migration script is done. New content is in the '''main''' namespace, e.g. [[Cat]]. Old content is still at [[DF2014:Cat]]. History was migrated to the ''new'' (main namespace) articles.

I know several things are broken still. Please reply if you find any others:
<div style="border-left: 2px solid red">
* <s>Versioned templates haven't been migrated yet (e.g. {{tl|vermin}} on [[Ant]])</s>
** Fixed. Most were migrated by a bot.
* Raws are missing on all pages that use them.
** This also affects sidebars, such as on [[Cat]] and [[Microcline]].
** This will be addressed with an upgrade to the DFRawFunctions extension. This will take some time because the layout of the raws has changed significantly, so we cannot do a straightforward migration here.
* Some pages where the DF2014 page was a redirect to a main namespace page that contained content were migrated incorrectly.
** In this case, the main namespace page is usually a redirect to itself. This can be fixed by undoing LethosorBot's edit to the main namespace page, then copying the content to the DF2014 page.
** Update: most seem to have been fixed manually - thanks! —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 19:41, 21 December 2022 (UTC)
* <s>Some main-namespace talk pages redirect to DF2014 talk pages. Some of these redirects work, and some (usually older ones) do not.</s>
** Fixed with a bot. Some redirects from talk pages to other deleted talk pages are now broken, e.g. [[Talk:Above_ground]] (exists) -> [[Talk:Tile attributes]] (redlink). I am leaving them like that because they redirect to where the talk page should be created, but I'm also fine with people deleting them if they really want to. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 19:41, 21 December 2022 (UTC)
* {{tl|quality}} for new articles is disabled (see below)
* Some links from DF2014 to Main weren't working: e.g. the version selector [[DF2014:Mason's workshop]] was linking to [[DF2014:Main:Mason's workshop]] instead of [[Main:Mason's workshop]]. I'm not sure exactly why, but I fixed it with a change to the NamespaceLinks extension. Let me know if you spot similar broken links. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 23:19, 21 December 2022 (UTC)
</div>

—[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 04:54, 20 December 2022 (UTC)
:The quality levels of the 50.03 pages seem to be missing. I'm not sure if that's covered under that first point. [[User:Trainzack|Trainzack]] ([[User talk:Trainzack|talk]]) 06:47, 20 December 2022 (UTC)
::If the the [[Dwarf Fortress Wiki:Quality]] feature can be made to work with namespace scheme change, I suggest to automatically assign the lowest quality rating to all pages, alternately add the {{tl|old}} to all pages. Otherwise there will be a lot of pages that will fall through the cracks. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 09:12, 20 December 2022 (UTC)
:::I disabled {{tl|quality}} in the main namespace because it would require some rework to make the rating script and the template work properly there. Feel free to take a stab at the template. I will see what can be done on the extension side. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 21:14, 20 December 2022 (UTC)

It appears some pages are redirecting recursively and never resolving correctly, like the [[https://dwarffortresswiki.org/index.php?title=Character_table&redirect=no|character table]] and [[tileset repository]] 07:35, 20 December 2022 (UTC)
: Indeed, these can be caught here: [[Special:DoubleRedirects]] --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 07:51, 20 December 2022 (UTC)

It might be useful to change the notice title to "release information '''for editors'''" --[[Special:Contributions/142.59.195.176|142.59.195.176]] 10:26, 20 December 2022 (UTC)
:Can do. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 16:27, 20 December 2022 (UTC)

Main talkpages seem to redirect to DF2014 talk. Not sure if it is intentional but I like it, though we should pay attention when creating new discussion relating to v50 ending up there.--[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 14:18, 20 December 2022 (UTC)
:That's unintentional. I specifically wrote the migration script to not move talk pages, but that has the side-effect of leaving any previously-created "Talk -> DF2014 talk" redirects intact. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 16:27, 20 December 2022 (UTC)

Yo Lethosor, are we adding graphic sprites for the pages in some way? Or are we waiting for you to add some sort of new template or something? I'm sure you don't need me to tell you that the current templates don't allow that. Not sure if I'm allowed to change/create any templates either, as I don't want to break things for hundreds of pages. Edit: And IF the icons are allowed, should they be left alone, or 2×-3× sized like how the Minecraft wiki does it? --[[User:Zippy|Zippy]] ([[User talk:Zippy|talk]]) 14:29, 20 December 2022 (UTC)
:Depends on which templates you mean. There are copyright concerns with uploading a premium sprite sheet, for instance. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 16:27, 20 December 2022 (UTC)
::I'm not talking about uploading an entire sprite sheet. I'm just talking about individual icons for each respective page. One image for cows, one for horses, one for werebeasts, etc. --[[User:Zippy|Zippy]] ([[User talk:Zippy|talk]]) 16:50, 20 December 2022 (UTC)
:::If we do that for every creature in the sprite sheet, that's not much different (in terms of copyright) from uploading the entire sprite sheet. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 17:09, 20 December 2022 (UTC)
::::Is there someone we can talk to about that? We finally get this new game with graphics, and then we can't use the very graphics of the game? No matter what the rules are, I'd say that would be the stupidest thing ever. I know I'm infamous here when it comes to copyright and images and stuff, but about 80% of game wikis out there are completely unofficial, and use game file images like no one's business. I can't imagine anyone's door being knocked on if we used the game's sprites, but I won't add any here until we have a go-ahead. --[[User:Zippy|Zippy]] ([[User talk:Zippy|talk]]) 17:14, 20 December 2022 (UTC)

:::::...I've made noise in Mayday's direction on this matter, at least (prob an incorrect maneuver, ''but'').[[User:Silverwing235|Silverwing235]] ([[User talk:Silverwing235|talk]]) 17:55, 20 December 2022 (UTC)
:::::: I hope some sort of arrangement can be made so we can use the new sprites with permission/limits, just as we are using the raw files. Otherwise we are all (devs and editors alike) shooting ourselves in the foot here.--[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 21:07, 20 December 2022 (UTC)

:::::::I just thought of something. We're supposedly not allowed to upload entire sprite sheets, right? What if - for the time being - we just use a few of them for the purpose of testing out new infoboxes? --[[User:Zippy|Zippy]] ([[User talk:Zippy|talk]]) 21:46, 20 December 2022 (UTC)
::::::::I don't know. If someone could ask Kitfox and post the response here, that would be great. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 21:47, 20 December 2022 (UTC)

:::::::::I've reached out to Alexandra, but she hasn't answered yet. Until then I found these old approvals from the previous community manager, Feeona: ([http://www.bay12forums.com/smf/index.php?topic=173474.msg8243633#msg8243633 link1], [http://www.bay12forums.com/smf/index.php?topic=176640.msg8243642#msg8243642 link2]). Waiting for a newer response until we begin mass uploads is probably the politer option, but like Zippy said, it is also standard for wikis to use game sprites with less approval. I second their idea of trying it out with a few images to test the infoboxes. On the extreme off-chance (and I do think it is) Kitfox protests we can always remove these few. --[[User:Voliol|Voliol]] ([[User talk:Voliol|talk]]) 22:19, 20 December 2022 (UTC)
:::::::::And here is a third, more official statement: ([http://www.bay12forums.com/smf/index.php?topic=173474.msg8249718#msg8249718 link3]). Perhaps that address of info@kitfoxgames.com is the better channel to ask for a confirmation, rather than Discord DMs, but I will be going to bed, so it is best if someone else does that. --[[User:Voliol|Voliol]] ([[User talk:Voliol|talk]]) 22:29, 20 December 2022 (UTC)
::::::::::Thanks for tracking this down! Ok, sprites should be fine, but let's avoid uploading the entire premium tileset as a single image, for instance (as the forum thread says, "use common sense"). —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 00:21, 21 December 2022 (UTC)
::::::::::: Looks good, permission is always preferable over fairuse, I think it is a win win for all involved. I agree that we shouldn't upload entire sprite sheets (e.g. there is no reason to upload the windmill from every direction or whole construction phase for workshops) and that there are a lot of details that needs to be ironed out through testing. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 05:07, 21 December 2022 (UTC)

Shifting temporarily to a new issue, is the documentation of [[Template:ArticleVersion]] outdated? It would seem so to me, since the current version no longer has its own namespace, with the templates needing updating being different ones. --[[User:Voliol|Voliol]] ([[User talk:Voliol|talk]]) 18:30, 20 December 2022 (UTC)
:I think it is still accurate enough. We left open the possibility of making another namespace in the future, albeit with a different migration strategy - see [[#v50 organization|above]]. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 21:52, 20 December 2022 (UTC)
::We have a green light on uploading all and any sprites. Their response to me can be seen [https://i.imgur.com/BhmHjzC.png here]. I'm sure someone else confirmed it before me. --[[User:Zippy|Zippy]] ([[User talk:Zippy|talk]]) 19:00, 21 December 2022 (UTC)
Some Changes to infoboxes might be needed. Too bad [[User:Doorkeeper]] isn't around. He did a great work with navbox project--[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 20:52, 21 December 2022 (UTC)

I just realized that raw files aren't stored as regular wiki pages but loaded via the DFRawFunctions extension (hence the need to update). Good news it's going to be handled in bulk, consistently and relatively easy to updated. Even better it's Lethosor problem ;) Also I just realized that all the "raw files" (txt files in the new vanilla folder) are released into the public domain. Both are probably not news to the vets but I'll leave it here for those who less up to date like myself. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 07:35, 22 December 2022 (UTC)

== v50 specific issues ==
=== Graphics===
Follow up on the use of game sprites and the need to trying it out with a few images to test the infoboxes. First sprite [[:File:Beds v50.png]] was uploaded and used on [[Bed]] entry. Any thoughts? --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 18:06, 21 December 2022 (UTC)
:Seems like it should be rearranged to be horizontal. Also, has there been a serious discussion about copyright? Full screenshots are 100% fine, but you start going into a grey area when you upload pieces of a spritesheet. I'm of the opinion that it's all fine as long as it's inconvenient to reconstruct the full sheet from the individual images. Maybe a further restriction could be you shouldn't upload any of the art unless it's used in an infobox (maybe an exception for pieces of the UI). And one more restriction could be you shouldn't show everything, like in your bed example, maybe just the wooden bed is good enough, leave out the stone and metal, especially since those can only be made from strange moods. [[User:Brightgalrs|Brightgalrs]] ([[User talk:Brightgalrs|talk]]) 18:43, 21 December 2022 (UTC)
::Actually, your bed image is kinda bad for showing off what a bed looks like because it doesn't show the pillow/blankets. That might point to cropped screenshots being the best path, although less convenient for the uploader, as you don't get details left out. [[User:Brightgalrs|Brightgalrs]] ([[User talk:Brightgalrs|talk]]) 18:46, 21 December 2022 (UTC)
::I created a new license template [[Template:Copyright game]], based it on the way the RimWorld wiki does things. Call it a prototype, but it's probably how your bed image should be labelled. Indeed, I added it to it already. [[User:Brightgalrs|Brightgalrs]] ([[User talk:Brightgalrs|talk]])

::: I agree that the horizontal arrangement would suit better here and that we should strive to represent how things look in-game. Otherwise, I am not too concerned about people being able to reconstruct anything (lets just say that ''anyone'' interested in that can get the real thing from the game files), also it seem we have permission to use the sprits on top of fairuse. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 19:55, 21 December 2022 (UTC)

::: Modifying the existing template to allow the inclusion of the new sprites is easy (Something like [https://ibb.co/zFXCrjd this]?) The big question is the matter of consistency is there any exceptions that will break the format (size wise with variant bloat for example), the sprite naming format, etc --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 20:44, 21 December 2022 (UTC)
::: If we are going to show a variant for each material type, then maybe these should be added as separate images so we can add a tooltip for each image. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 20:49, 21 December 2022 (UTC)

:I've got another prototype going here and here: [[User:Brightgalrs/vector.css]] and [[User:Brightgalrs/Sandbox]]. (You'll need to add the css stuff to your own /vector.css). Basically it's a way to recolor images using css classes. No idea if there's a better way. Also, the real implementation would require a change to [[MediaWiki:Common.css]]. [[User:Brightgalrs|Brightgalrs]] ([[User talk:Brightgalrs|talk]]) 22:41, 21 December 2022 (UTC)
:Should mention, there ''is'' a different way, just upload each image 16 times, one for each coloring. But maybe that's not very elegant. [[User:Brightgalrs|Brightgalrs]] ([[User talk:Brightgalrs|talk]]) 22:45, 21 December 2022 (UTC)

: It should be noted that soon the classic edition will be released, hence one should plan to have both the Premium and classic alongside in that little space --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 03:14, 22 December 2022 (UTC)
::I'm looking into a tab extension to potentially support this in infoboxes. Perhaps [https://www.mediawiki.org/wiki/Extension:Tabs Extension:Tabs]? I tried [https://www.mediawiki.org/wiki/Extension:TabberNeue Extension:TabberNeue], but it displays a placeholder if JavaScript is disabled, which isn't great. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 04:22, 22 December 2022 (UTC)
::: The Neue Tabber seem to works pretty much like the old one (which fandom [https://coding-help.fandom.com/wiki/Tabber#Adding_images_into_tabbers still use]) defaulting to showing the first tab only. Quick look suggest that neue work the same, plus the notice that 'Tabber requires Javascript to function' warning? if so, and if it is a bother, then you should be able to edit out the tabberneue-noscript string in code. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 06:29, 22 December 2022 (UTC)

=== Hotkeys/Menu navigation ===
Most key bindings and menus have changed. Should the article reflect a) only the old version, b) only the GUI version or c) both? For example, [[Bridge|bridges]] used to be built via {{k|b}} -> {{k|g}}, but now it's in Place strucutures {{k|b}} -> Constructions {{k|n}} -> Bridge {{k|b}}. What should be written in the article? Currently, it's {{k|b}} -> {{k|g}}. I ''think'' it should be only b), but I am not sure if there will be differences regarding hotkeys or menus between the premium version and the free version and then, c) would be the most appropriate option. --[[User:Prometherus|Prometherus]] ([[User talk:Prometherus|talk]]) 10:16, 22 December 2022 (UTC)

Technical tricks

2022-12-22T09:45:45Z

Prometherus: /* Save Behavior */ Add semiannual autosave option.

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

In order to configure ''Dwarf Fortress'' to your liking there are two files you can edit, [[init.txt]] and [[d_init.txt]]. The first file, init.txt, contains mostly the settings pertaining to the window, rendering and sound of ''Dwarf Fortress''. The second file, d_init.txt, contains settings that affect game features such as saving and population controls.

== Locating your configuration files ==
In most cases, the configuration files for ''Dwarf Fortress'' are in the <tt>data/init</tt> folder of the directory you installed it to.

If you installed ''Dwarf Fortress'' on Arch Linux using <tt>pacman</tt>, then running <tt>dwarffortress</tt> will dump the configuration files you should edit into your home directory under <tt>.dwarffortress</tt> - editing the files under <tt>/opt/dwarffortress/data/init</tt> will ''not'' change how the game behaves.

If you installed ''Dwarf Fortress'' on Void Linux using <tt>xbps-install</tt>, then running <tt>dwarffortress</tt> will dump the configuration files you should edit into your home directory under <tt>.local/share/dwarffortress</tt>.

== Editing the configuration files ==
You can edit the configuration files with almost all text editing software, such as Vim or Emacs.
All data in these files is contained in what are called [[token]]s. Each token is defined by the text between an opening square bracket, '[', and the first closing square bracket, ']'. Arguments to the various tokens are separated from a token identifier by a colon, ':'.

== Settings - init.txt ==

=== Sound ===
*[SOUND:YES]
Change the argument from "YES" to "NO" to completely remove sound and music from the game. If this is "NO", it will not be possible to change the volume from the in game options menu.

*[VOLUME:255]
Changes the default volume of sound in ''Dwarf Fortress''. The argument can be any value from 0 to 255, with 255 representing 100% volume.

=== Intro Movie ===
*[INTRO:YES]
Change the argument from "YES" to "NO" to turn off the [[intro movie]].

=== Window ===
*[WINDOWED:PROMPT]
Changes the window mode that ''Dwarf Fortress'' runs in. If this is "PROMPT" the game will ask you if you want to run in windowed or fullscreen mode. If this is "NO" the game will be fullscreen with no prompt, and if this is "YES" the game will be in windowed mode with no prompt.

*[WINDOWEDX:80]
If this is below 256, this specifies the width of the grid used by ''Dwarf Fortress'' with a minimum of 80. As such, the width of the window used will be the product of this value and the width of the font used. If this value is 256 or above, it specifies the width of the window used directly.

*[WINDOWEDY:25]
If this is below 256, this specifies the height of the grid used by ''Dwarf Fortress'' with a minimum of 25. As such, the height of the window used will be the product of this value and the height of the font use. If this value is 256 or above, it specifies the height of the window used directly.

[WINDOWEDX:98][WINDOWEDY:98] will make window big enough to display whole 2x2 [[embark]] [[site]] with 8x8 [[tileset]] or one embark tile with 16x16 tileset.

*[FONT:curses_640x300.png]
The font file that ''Dwarf Fortress'' uses. This value can be any .bmp or .png image in the data/art folder.

*[RESIZABLE:YES]
Can be "YES" or "NO". If this is "YES" you can resize the window while ''Dwarf Fortress'' is running.

*[TOPMOST:NO]
If this is set to "YES", the window is kept above all other windows.

=== Fullscreen ===
These settings are used if the [WINDOWED:PROMPT/YES/NO] token is either "NO", or "PROMPT" and the fullscreen option is chosen.

*[FULLSCREENX:0]
The width of the screen in fullscreen mode. If the value is 0, ''Dwarf Fortress'' chooses the best resolution for you.

*[FULLSCREENY:0]
The height of the screen in fullscreen mode. If the value is 0, ''Dwarf Fortress'' chooses the best resolution for you.

*[FULLFONT:curses_800x600.png]
The font file that ''Dwarf Fortress'' uses. This value can be any .bmp or .png image in the data/art folder.

*[BLACK_SPACE:YES]
If this is "NO", tiles will be stretched to fit to the screen if there is a resolution mismatch. If this is "YES", the extra space around the grid is filled with black space and the tiles are left unstretched.

=== Graphics ===
*[GRAPHICS:NO]
Can be "YES" or "NO". If this is "YES", ''Dwarf Fortress'' will use the raw/graphics folder for certain tile graphics. Currently this is limited to [[Graphics set repository|creature graphics]].

*[GRAPHICS_WINDOWEDX:0]
The window width used when ''Dwarf Fortress'' is in windowed mode.

*[GRAPHICS_WINDOWEDY:0]
The window height used when ''Dwarf Fortress'' is in windowed mode.

*[GRAPHICS_FONT:curses_square_16x16.png]
The [[Main:Tileset repository|font]] used by ''Dwarf Fortress'' when in windowed mode and [GRAPHICS:YES/NO] is "YES".

*[GRAPHICS_FULLSCREENX:0]
The width of the screen used by ''Dwarf Fortress'' if in fullscreen mode.

*[GRAPHICS_FULLSCREENY:0]
The height of the screen used by ''Dwarf Fortress'' if in fullscreen mode.

*[GRAPHICS_FULLFONT:curses_square_16x16.png]
The font used by ''Dwarf Fortress'' when in fullscreen mode and [GRAPHICS:YES/NO] is "YES".

*[GRAPHICS_BLACK_SPACE:YES]
If this is "NO", the tiles are stretched to fit the window in the case of a resolution mismatch. If this is "YES", the extra space is filled with black space and the tiles are left unstretched.

=== Video Card Options ===

*[PRINT_MODE:2D]
This value changes how ''Dwarf Fortress'' draws to the screen. As such, changing this value can significantly change the performance of ''Dwarf Fortress'' on your computer. Possible values for this are "2D", "2DSW", "2DASYNC", "STANDARD", "TEXT", "ACCUM_BUFFER", "FRAME_BUFFER", "VBO" and "PARTIAL". A technical description of what these do can be found [http://www.bay12forums.com/smf/index.php?topic=63667.msg1478550#msg1478550 in this post].
"PARTIAL" print mode takes an additional argument similar to how the PARTIAL_PRINT value worked in previous versions, with the number representing the number of frames a changed tile is rendered before it is skipped.
"TEXT" is only available on OS X and Linux, and uses the 8 ANSI colors with emboldening. OS X users should enable "Use bright colors for bold text" in the Profile tab of their Terminal preferences.

*[SINGLE_BUFFER:NO]
If this is "NO" ''Dwarf Fortress'' will use double buffering, which may reduce flickering of the screen at the expense of a possible (small) drop in frame rate. If this is "YES", double buffering is turned off.

*[ARB_SYNC:NO]
On video cards that support the OpenGL ARB_sync extension, turning this on can greatly improve performance in GPU overload conditions. However, this can cause ''Dwarf Fortress'' to crash on some video cards.

*[VSYNC:NO]
If this is set to "YES", when ''Dwarf Fortress'' redraws the screen it will wait for the monitor to finish its vertical retrace. This can negatively impact your FPS if G_FPS is set high, as the game is forced to suspend calculating game frames to wait for the monitor to finish. The main reason to change this to "YES" is if tearing of the game image occurs regularly for you.

*[TEXTURE_PARAM:LINEAR]
Can be either "LINEAR" or "NEAREST". If it is "NEAREST", the texture values use the nearest pixel value without averaging. If it is "LINEAR", the texture values use the average of the adjacent pixels. In terms of what the two options do to the graphics, the "LINEAR" option will appear to blur adjacent pixels and can result in a fuzzy appearance. The "NEAREST" option will produce a sharp, pixelated look but may result in images looking clipped at some different screen resolutions.

=== FPS ===
*[FPS:NO]
If this is "YES" a FPS counter is displayed on the top left corner.

*[FPS_CAP:100]
The game frames per second the game limits itself to. This changes the number of turns calculated per second, not the graphical frames displayed. If this value is 0 the FPS is uncapped.

*[G_FPS_CAP:50]
The graphical frames per second the game attempts to draw. This changes the number of times ''Dwarf Fortress'' draws itself to the screen per second. Lower numbers will cause ''Dwarf Fortress'' to run faster but skip displaying more game frames between each redraw.
To find the number of game frames that are calculated per redraw done by ''Dwarf Fortress'', divide the value for FPS_CAP by the value of G_FPS_CAP. In the default case, this is 100/50=2, so for every second frame calculated ''Dwarf Fortress'' will redraw the screen.

=== Priority ===
*[PRIORITY:NORMAL]
Change this to affect the process priority of ''Dwarf Fortress''. Higher priorities mean that ''Dwarf Fortress'' will run faster and other programs will run slower. Possible values are "REALTIME", "HIGH", "ABOVE_NORMAL", "NORMAL", "BELOW_NORMAL" and "IDLE".

=== Game Options ===
*[ZOOM_SPEED:10]
How fast the game zooms. A value of 10 corresponds to increasing grid size by 10 units each time you zoom.

[RECENTER_INTERFACE_SHUTDOWN_MS:0]
This controls the number of milliseconds that must pass before input works again after the view recenters on an event in dwarf mode.

[COMPRESSED_SAVES:YES]
Change this to "NO" if you want to leave save uncompressed. If "YES", saves are compressed in the .zip format to save space. If you experience save corruption, you can try turning this off. However, turning this off may cause saves to be over ten times their compressed size, which can lead to your save folder growing several gigabytes large if you have seasonal backups enabled. Make sure you have plenty of disk space or delete old backups regularly if you want to turn this off.

=== Mouse ===
*[MOUSE:YES]
Determines if the game accepts mouse input.

*[MOUSE_PICTURE:NO]
If the game should display a picture in place of the system mouse icon. The picture lags if ''Dwarf Fortress'' is lagging.

=== Keyboard ===
*[KEY_HOLD_MS:250]
The number of milliseconds before holding a key causes it to be repeated.

*[KEY_REPEAT_MS:150]
The number of milliseconds between consecutive repetitions of a held key.

*[KEY_REPEAT_ACCEL_LIMIT:8]
*[KEY_REPEAT_ACCEL_START:10]
If you set KEY_REPEAT_ACCEL_LIMIT above one, then after KEY_REPEAT_ACCEL_START repetitions the repetition delay will smoothly decrease until repetition is this number of times faster than at the start.

*[MACRO_MS:150]
The number of milliseconds between macro instructions.

== Settings - d_init.txt ==

=== Save Behavior ===
*[AUTOSAVE:NONE]
When ''Dwarf Fortress'' should automatically save your game. If this is "NONE", ''Dwarf Fortress'' never saves your game for you. Possible values are "NONE", "SEASONAL", "SEMIANNUAL" and "YEARLY".

*[AUTOBACKUP:NO]
If this is "YES", ''Dwarf Fortress'' will back up your save file each time it autosaves your game.

*[AUTOSAVE_PAUSE:NO]
If ''Dwarf Fortress'' should pause the game each time it autosaves for you.

*[INITIAL_SAVE:NO]
If this is "YES", ''Dwarf Fortress'' will save the game immediately after you embark.

=== More Game Options ===
*[IDLERS:TOP]
Where to display the number of idling dwarves. The value can be either "TOP", "BOTTOM", or "OFF".

*[PAUSE_ON_LOAD:YES]
If "YES", ''Dwarf Fortress'' starts Fortress mode paused.

*[TEMPERATURE:YES]
Turns [[temperature]] ''calculations'' on or off. If temperature calculations are off, only a few direct temperature changes will take place. For example, [[magma]] will set tiles and creatures to high temperatures, but those tiles will never cool and those creatures will not catch fire. Effects that rely on temperature calculations, such as water freezing, melting, or evaporating, or creatures and items taking temperature-related damage, will not occur.

*[WEATHER:YES]
Turns [[weather]] on or off. If weather is off it will never rain or snow.

*[ECONOMY:YES]
Turns on or off the fortress mode dwarven economy. This has no effect, since the economy does not function in v0.40.

*[INVADERS:YES]
Turns on or off fortress mode [[siege]]s. Turning this off for your first couple of games may make the game easier to start with.

*[CAVEINS:YES]
If this is "YES" it is possible for [[cave-in]]s to occur.

*[ARTIFACTS:YES]
Turns on or off [[strange mood]]s and the resulting [[artifact]]s.

*[ZERO_RENT:NO]
If this is "YES", when the dwarven economy kicks in all rooms will cost nothing, allowing even the poorest of haulers to have a room fit for a king. This has no effect, since the economy does not function in the current version.

*[TESTING_ARENA:YES]
Turns on or off the testing arena.

*[WALKING_SPREADS_SPATTER_DWF:NO]
Turns on or off the spread of blood spatter and other contaminants between creatures and ground tiles in [[Fortress mode]]. As contaminants are [[Blood|buggy]] and can have a major negative impact on [[FPS]] in [[Fortress mode]], it is recommended to leave this set at "NO" for now.

*[WALKING_SPREADS_SPATTER_ADV:YES]
Turns on or off the spread of blood spatter and other contaminants between creatures and ground tiles in [[Adventurer mode]].

*[PATH_COST:1:2:5:25]
The pathfinding costs associated with different [[traffic]] values.

*[COFFIN_NO_PETS_DEFAULT:NO]
When building a [[coffin|burial receptacle]], the option to allow pets to be buried in it will default to NO if this is set to "YES".

*[STORE_DIST_ITEM_DECREASE:20]
*[STORE_DIST_SEED_COMBINE:1000]
*[STORE_DIST_BUCKET_COMBINE:1000]
*[STORE_DIST_BARREL_COMBINE:1000]
*[STORE_DIST_BIN_COMBINE:1000]

*[SHOW_IMP_QUALITY:YES]
If "YES" ''Dwarf Fortress'' will display the [[quality]] of an item's improvements in the name. If you get annoyed by seeing items like *<*sword*>* you can
get rid of the outside ** by setting this to NO.

*[SHOW_ALL_HISTORY_IN_DWARF_MODE:YES]
If "YES", inspecting engravings and artifacts in Fortress Mode will have an extended history displayed.

*[LOG_MAP_REJECTS:NO]
If this is "YES", ''Dwarf Fortress'' will log the reason why maps were rejected during world gen in the log.txt file.

*[GRAZE_COEFFICIENT:100]

=== Adventure Mode ===
*[MORE:YES]
*[DISPLAY_LENGTH:23]
*[ADVENTURER_TRAPS:NO]
If you set this to "YES" your adventurer will trigger the traps of your old fortresses.
*[ADVENTURER_ALWAYS_CENTER:YES]
*[ADVENTURER_Z_VIEWS:UNHIDDEN:9]

=== Nicknames ===
*[NICKNAME_DWARF:REPLACE_FIRST]
*[NICKNAME_ADVENTURE:REPLACE_FIRST]
*[NICKNAME_LEGENDS:REPLACE_FIRST]

=== Embark Options ===
*[EMBARK_WARNING_ALWAYS:NO]
If this value is YES, then it will always pop up a warning screen when you embark (Like you get when you have [[DF2012:Water#Salt Water|Salt Water]] or an [[DF2012:Aquifer|Aquifer]] on-site)
*[SHOW_EMBARK_TUNNEL:FINDER]
*[EMBARK_RECTANGLE:4:4]
The size of the default embark site.

=== Wounds ===
*[WOUND_COLOR_NONE:7:0:1]
The color of body parts when there are no recorded active wounds on the part.
Default = white

*[WOUND_COLOR_MINOR:6:0:0]
The color of body parts when there is any damage that doesn't have functional/structural consequences (might be heavy bleeding though).
Default = brown

*[WOUND_COLOR_INHIBITED:6:0:1]
The color of body parts when there is any muscular, structural or functional damage without total loss.
Default = yellow

*[WOUND_COLOR_FUNCTION_LOSS:3:0:1]
The color of body parts when an important function of the part is completely lost, but the part is structurally sound (or at least partially intact).
Default = bright cyan

*[WOUND_COLOR_BROKEN:4:0:1]
The color of body parts when the part has lost all structural integrity or muscular ability.
Default = bright red

*[WOUND_COLOR_MISSING:0:0:1]
The color of body parts when the part is completely gone.
Default = dark gray

=== Tiles ===

*[SKY:178:3:0:0]
The tile and color of areas that are far below the currently displayed z level.
The format is SKY:<character>:<foreground color>:<background color>:<brightness>. <character> can be either an ASCII number or a character in single quotes, like '#'.

*[CHASM:250:0:0:1]
The tile and color of areas that are far below the currently displayed z level while indoors.
The format is the same as for SKY above.

*[PILLAR_TILE:'O']
The tile displayed for pillars. Pillars are created at the ends of strings of wall tiles. Some [[tilesets]] may have been designed to use tile 9, 10, or 255 for this, even some that are primarily ASCII, and may or may not include a custom d_init.txt file to do so.

*Multiple [TRACK_*] and [TREE_*] lines
The tiles displayed for most of the various possible [[track]] or [[tree]] parts. Not all the track tiles can be customized, such as the [[roller]]s or the track stop. By default, the track tiles are followed by an I to have them displayed with inverted colors so that they don't look the same as walls. Some tilesets may have been designed to use tile 9, 10, or 255 for tree trunk pillars, instead of the default 'O'. Note that the TREE_TRUNK_* and TREE_CAP_WALL_* corner tokens use a different naming convention than the other tokens; For example, by default TREE_TRUNK_NW uses tile 201 which is ╔, while TREE_BRANCH_NW uses 217 which is ┘, and TRACK_NW uses 188 (with inverted colors) which is ╝.

*[VARIED_GROUND_TILES:YES]
If this is "YES" the ground will be varied randomly using the tiles ,.`'.
If this is "NO", only the period will be used for ground tiles.

*[ENGRAVINGS_START_OBSCURED:NO]
If this is "YES", all [[engravings]] are displayed initially looking the same, like highlighted smooth walls/floors. Otherwise, they'll be displayed as a tile of one of the things they depict. Either way, a given engraving's behavior can be changed through designation.

*[SHOW_FLOW_AMOUNTS:NO]
If "YES" ''Dwarf Fortress'' displays water as numbers from 1-7 indicating [[depth]].

=== Resolution to Grid Ratios ===
Taken from [http://www.bay12forums.com/smf/index.php?topic=22302.msg241991#msg241991]

{| class="wikitable" border="1"
|-
! colspan="2" | Geometry
! colspan="3" | Character Size
|-
! Resolution
! Aspect
! 8x8
! 12x12
! 16x16
|-
| 800x600
| 4:3
| 100 x 75
| 66 x 50
| 50 x 37
|-
| 1024x768
| 4:3
| 128 x 96
| 85 x 64
| 64 x 48
|-
| 1152x864
| 4:3
| 144 x 108
| 96 x 72
| 72 x 54
|-
| 1280x960
| 4:3
| 160 x 120
| 106 x 80
| 80 x 60
|-
| 1600x1200
| 4:3
| 200 x 150
| 133 x 100
| 100 x 75
|-
| 1280x1024
| 5:4
| 160 x 128
| 106 x 85
| 80 x 64
|-
| 1440x900
| 16:10
| 180 x 75
| 135 x 56.25
| 90 x 37.5
|-
| 1680x1050
| 16:10
| 210 x 131
| 140 x 87
| 105 x 65
|-
| 1920x1080
| 16:9
| 240 x 135
| 160 x 90
| 120 x 67
|-
| 1920x1200
| 16:10
| 240 x 150
| 160 x 100
| 120 x 75
|}

{{Category|Game}}
[[ru:Technical tricks]]

D init.txt

2022-12-22T09:44:36Z

Prometherus: Use correct filename.

{{migrated article}}
{{Quality|Unrated}}
{{av}}
{{buggy}}
:''Many of these settings are covered in detail [[Technical_tricks#Settings_-_d_init.txt|here]].''
{{file|DF/prefs/d_init.txt}}
The '''d_init.txt''' file can be used to make many adjustments to the game's behavior, such as enabling autosave or changing the population limit, as well as some [[technical tricks]] to improve framerate by deactivating features like weather and temperature.

This file is located at <code>[[Game folder|<Dwarf Fortress>]]/prefs/d_init.txt</code>. Changes made to this file take effect the next time the game is loaded, and apply to all worlds. The file can be edited manually or manipulated by an external launcher such as the [[Utility:Lazy Newb Pack|Lazy Newb Pack]].

The contents of the default '''d_init.txt''' file can be found below:

==Default settings==
{{gamedata|title=d_init.txt|whitespace=pre-wrap}}

== Bugs ==
* The text in the file says you need a population of 80 for a [[monarch]], but you actually need 140.

{{files}}
[[ru:d_init.txt]]