Dwarf Fortress Wiki - User contributions [en]

System requirements

2023-01-04T03:45:07Z

HawkOwl: update OS section

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

:''If you're looking for information on improving the performance of Dwarf Fortress on your computer, see [[Maximizing framerate|Maximizing Framerate]]. For installation instructions, see [[Installation]].''

''Dwarf Fortress'' is a very complex game, but in ways that differ from most other complex games. This leads to the game having a somewhat unusual set of requirements.

Note that while the [http://bay12games.com/dwarves/ front page] displays only the current Windows x86-64 build, there also exist previous versions [http://bay12games.com/dwarves/older_versions.html under the "All Versions" link].

==Premium version official requirements==
From the [https://store.steampowered.com/app/975370/Dwarf_Fortress/ Steam page]

* Requires a 64-bit processor and operating system
* OS: minimum Windows XP SP3 or later
* Processor: minimum Dual Core CPU - 2.4GHz+, recommended Dual Core CPU - 4GHz+
* Memory: 4 GB RAM
* Graphics: 1GB of VRAM: Intel HD 3000 GPU / AMD HD 5450 / Nvidia 9400 GT
* Storage: 500 MB available space

== OS ==

* '''64-bit Windows''' can run the Premium and Classic releases natively. 32-bit and ARM versions of Windows will not be able to run DF. If you are unsure if you are using 64-bit Windows, check using the instructions [https://support.microsoft.com/en-us/windows/32-bit-and-64-bit-windows-frequently-asked-questions-c6ca9541-8dce-4d48-0415-94a3faa2e13d here].
** Windows XP/7/8/8.1 are unsupported by Microsoft and may have issues -- be warned!
* '''Linux on x86-64''' (including '''SteamOS''') can run the Premium version of Dwarf Fortress on Steam through the Proton compatibility layer. As of v50.04, it is [https://www.protondb.com/app/975370 rated Platinum on ProtonDB].
* '''Linux on x86-64''' and '''MacOS on Intel''' may be able to run Dwarf Fortress via Wine, previous versions are [https://appdb.winehq.org/objectManager.php?sClass=application&iId=5608 rated Platinum on Wine's AppDB].
* '''MacOS on Apple Silicon''' ([https://support.apple.com/en-au/HT211814 listed here]) ''may'' be able to run Dwarf Fortress via Wine in Rosetta 2's x86-64 emulation. Add your experiences below under Reports if you try!
* '''Linux x86-64/ARM64''' and '''MacOS on Intel/Apple Silicon''' native builds, as of v50.04, are not yet published.

==GPU==

''Dwarf Fortress'' is not particularly graphically intensive, even when using high-res [[tilesets]] and [[graphics set]]s. ''Dwarf Fortress'' also doesn't use technologies like [[wikipedia:OpenCL|OpenCL]] to make use of graphics cards anyway, so a top-of-the-line graphics card will generally not improve performance.

==CPU==

''Dwarf Fortress'' mostly operates on a single thread, so if you want to optimize for DF, you should probably optimize for single-core performance. This is especially true if you want to do more laggy things, such as [[mist]] generators. However, laggy circumstances are generally the exception, not the rule, and in those other circumstances, you generally don't need a ''particularly'' powerful CPU.

=== Cache size ===

As ''Dwarf Fortress''' bottlenecks are mostly due to [https://en.wikipedia.org/wiki/CPU_cache#Cache_miss cache misses], it has been [http://www.bay12forums.com/smf/index.php?topic=151121.msg6270374#msg6270374 speculated on the DF forums] that "a CPU with a positively giant L3/L4 cache (and I mean > 256 mb or GTFO)" would improve DF performance, as would using faster RAM with smaller [https://en.wikipedia.org/wiki/CAS_latency transfer times]—see the next section.

== RAM ==

During [[Fortress mode|regular]] [[Adventurer mode|gameplay]], ''Dwarf Fortress'' usually doesn't consume too much memory - 512MB is probably a bit tight, but 1GB is absolutely sufficient, though if you're short on RAM, you may want to quit other running processes. What's particularly important during regular gameplay is RAM ''latency''—since the game uses the RAM ''every single frame'', it's important that your RAM be fast, lest you experience FPS death.

However, [[world generation]] is known to eat up a lot more RAM than normal gameplay, especially if you generate worlds that are particularly large or have long histories - multiple gigabytes may be consumed. To be safe, you should shut down any background processes when generating a world, and if you're particularly tight on RAM, consider reducing the size or history of the worlds you generate—the game is rich enough with content that you'll still have plenty of things to do, and you can always tweak the other, less RAM-hungry [[advanced world generation]] parameters. (RAM latency is less of a problem here, since you'll only need to do this once every so often.)

== Experimental reports ==
=== Report format ===
Please read [[System_requirements/Report_Template|the report template]] page before contributing any reports.

=== Reports ===

''None provided for v50. Please see previous versions of this page for reports of running previous versions of DF.''

{{Translation| dwarven = idith inem | elvish = eritha enotho | goblin = obsår eted | human = histek tikes}}

{{Category|Game}}
[[ru:System requirements]]

Maximizing framerate

2022-12-30T00:05:45Z

HawkOwl: pet-passable doors are not in v50

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

[[File:Frames_Per_Second_Meter.png|300px|thumb|bottom|A picture of ''Dwarf Fortress'' with frames per second displayed.]]

[[Frames per second|Framerate]] is used in ''Dwarf Fortress'' to measure the speed at which the game is running. It is measured in "frames per second", or FPS for short. To check your FPS in-game, simply change [FPS:NO] to [FPS:YES] in [[init.txt]], and your FPS will be displayed on the top row of the screen. The first number is the current frame rate, while the number in parentheses is the current graphical frame refresh rate.

==Increasing your framerate==
In general, the more stuff the game has to keep track of, the slower the game will run. So, reducing the amount of stuff that's active keeps your game running fast. The lists below separate ways to improve FPS into two categories: things that don't change the game in any fundamental way, and things that do.

===Without Game Alterations===
Fortress design is specific ways of building and planning, game setting changes are changes mostly in the [[init.txt]] and [[D_init.txt]] files that don't actually change how the game plays out.

====World Generation====
* Larger worlds require more background processing to update. The larger the civilizations, the more events occur in the world and the more complex they are. Generating too-large civilized populations can result in a permanent, unavoidable FPS drop. However, with how rich the game is with content, even a small world will be fairly interesting, while leading to a much higher framerate, though you may want to adjust some of the [[advanced world generation]] settings.
* Longer histories require more memory and storage space for [[historical figure]]s and events.
* Reducing the number of civilizations, sites, beasts, and setting world population cap can limit the resources spent updating the rest of the world.
* [[Caverns]] can be an FPS hog due to [[pathfinding]] and how complex they can be. Creatures will repeatedly try to path into your fort from a cavern. Sometimes even [[Trading#Caravans|trading caravans]] will try to path out of your fort underground.
** Adjusting the [[Advanced_world_generation#Cavern_Layer_Number|cavern layer number]] in [[advanced world generation]] parameters can reduce the number of [[cavern]] layers (default 3). However, this will restrict access to subterranean plants and creatures, and reduce the number of spawned [[forgotten beast]]s.
** Similarly, one could adjust [[Advanced_world_generation#Layer_Openness_Min.2FMax|Layer Openness]] and [[Advanced_world_generation#Layer_Passage_Density_Min.2FMax|Layer Passage Density]] in [[advanced world generation]] to make the caverns have fewer tiles to path through. In general, the pathfinding algorithm will make a beeline to the right X and Y coordinates and then start floodfilling dumbly through the entire Z from there until it can find a way up, at which point the whole process repeats, so having fewer cavern tiles is better and open areas are to be avoided.{{cite forum|104643/3096896}}
** Generating a world using a "REGION" template (instead of an "ISLAND" template which is used by "Create New World!") can significantly reduce the height of caverns and also place them closer together, resulting in fewer Z-levels. This generally also requires embarking in an area that isn't very close to an ocean or a mountain peak.
* [[Snow]] and [[ice]] melting can cause lag spikes.{{verify}} You can generate a world without poles with a somewhat heightened temperature, or just embark somewhere which doesn't freeze over.

====Fortress Design====
* Larger embark sites dramatically increase the amount of terrain which DF needs to keep track of and path through.
** Reducing the size of your embark site from the default 4×4 squares to 3×3 or even 2×2 will have an enormous impact on FPS.
** Keep in mind that a 2×2 embark is only 25% of the size of a 4×4 embark. However, in 3D it is still a large enough area for many fortresses in normal play.

* Fewer items inside a fort means fewer items to be [[stockpile]]d, checked for [[wear]], and so on and so forth.
** The obvious solution is not to generate so many items in the first place. Don't build such large [[Farming|farm plot]]s and don't go overboard with multiple [[Workshop|workshops]] constantly queued or set on perpetual repeat.
** Checking for clothing [[wear]] and unhappy [[thoughts]] could still have some impact on FPS. (Research is needed.) Armor counts for missing clothing thoughts, so dwarves can wear armor instead of clothes or going naked. If nothing else, dumping excess/worn out clothing may help FPS on an old fortress.
** Use a [[Dwarven atom smasher]] to remove items, or donate them to [[Trading|passing caravans]] to be taken away.
** [[Exploit#Quantum_stockpiles|Quantum stockpiles]] can [http://www.bay12forums.com/smf/index.php?topic=92241.msg3276117#msg3276117 reportedly] improve game speed.
** The quantity of items in any particular stack doesn't affect framerate so much as the number of stacks in general, due to the resultant impact on [[hauling]], [[stockpiles]], [[pathfinding]] and other CPU-intensive tasks. The research done on the [http://www.bay12forums.com/smf/index.php?topic=92241.0 Undump Engine] and [http://www.bay12forums.com/smf/index.php?topic=109319.0 Micha's experimental fort] demonstrate very FPS efficient solutions, while avoiding traditional stockpiles and the use of [[barrel]]s and [[bin]]s.
** That said, [http://www.bay12forums.com/smf/index.php?topic=104643.msg3094753#msg3094753 total quantity of items does matter]. Quantity matters far more with objects that have quality or decorations than boulders, as they take up more memory. Even in quantum stockpiles, temperature checks, wear increments, and other issues lag the game, although it takes far larger item quantities (10,000+) to be seriously notable.
* Flowing [[water]] slows the game down.
** Don't build [[mist]] generators, [[Screw pump|pump stacks]], or other major water-moving projects. If you do build them, build a [[Lever|way to switch them off]].
** Don't embark on a [[river]] or [[ocean]]. Rivers aren't too bad in their natural state, because the game only needs to calculate at where the water enters and where the water leaves, more-or-less skipping the water in between. Then you start [[Dam|damming]] them and pumping water out, and it gets worse.
** [[Aquifer]]s don't impose load until you start digging around in them.
** [[Water wheel#Perpetual motion|Dwarven water reactors]] also slow down the game, often significantly.
** Wall off areas with changing water levels[https://dwarffortress.mantishub.io/view.php?id=5986#c22870]. This prevents the game from needing to update pathfinding information whenever the water level changes and is safer anyway.
* Changes to the map's connections can cause brief lag spikes as the game's connections map needs updating.
** This is most notable with doors, drawbridges, or other objects linked to a [[repeater]]. An atom-smasher linked to a repeater, even disconnected from the rest of the fortress, can cause lag spikes every time it is raised or lowered. If you use an atom-smasher to eliminate garbage, make it operate only very infrequently through mechanics, or operate it manually by [[lever]].
* Proper use of [[traffic]] designations will help.
** Setting corridors to "high" traffic, and dead-end workshop rooms next to them to "low" traffic, means the pathfinder algorithm will search more quickly along the corridor, and waste less time searching in the rooms.
* Reducing the area which the pathfinder algorithm has to search lets the game run faster.
** The obvious solution is to not dig out quite so much of the ground.
** Some careful fort planning and design can cut down on pathfinding with shorter trips.
** Spreading your fortress out horizontally tends to mean travelling three or four tiles further down the hallway per every second workshop you build. Making workshops stack vertically upon multiple stairwells or ramps up or down from the stockpiles lets you cram workshops around the stairs or ramps just one further tile per set of four workshops.
** Giant stockpile areas are huge areas that cost pathfinding. Quantum stockpiling can prevent the need to excavate more space. That said, each item you produce [http://www.bay12forums.com/smf/index.php?topic=104643.msg3094753#msg3094753 takes up more memory and is considered in routine cycles like temperature]. Avoid producing more goods than you can actually use just because you "want to keep dwarves busy". If you are starting to run out of space to hold your goods, rather than dig out more space to stash it all, just stop producing goods.
** If fortress functions are spread far apart, consider multiple dining halls. A legendary dining hall isn't THAT hard to produce, and there are few reasons a magma forge operator has to cross 100 zs to the surface to get a drink before going back down.
** Crowded hallways force "dodging" which results in more pathfinds. Find ways to spread traffic out to avoid collisions. Don't rely upon a 1-tile hallway for access to areas dwarves travel to frequently, and possibly set up multiple paths that are "shortcuts" for dwarves rather than always having to travel through the same hallways to the same central staircase every single time.
** Dwarves have been found to prefer pathing across ramps to stairs or even horizontal travel if there is a change in z-level. Laying out your fortress with ramps rather than stairs can give an edge.
** Closing off unused areas with raised [[bridge]]s and locked [[door]]s can help.
** Open "quarry pits" are pathfinding traps. Seal them off from your fort with walls when you are done with them.
** Caverns are probably the worst offender for pathfinding in irrelevant areas. So keep any part you aren't occupying closed off.
** Don't designate large areas to be smoothed at once.{{bugl|5986}}
** Trapped dwarves, particularly trapped [[mood]]y dwarves cause significant lag at times. There is a bug where a trapped dwarf with a [[strange mood]] will slow the game down tremendously. {{bug|8698}} Free them of bondage or life to get on with your own.
** [[Location]]s without sufficient floor space invite frequent pathing. Make sure your locations are large enough for your population.
* Each animal needs to pathfind, too.
** Tame animals can be put into [[cage]]s, keeping them from having anywhere to go. Or you can butcher them.
* Multi-tile trees are a potential source of lag.
** Choosing an embark location that only grows trees on one or two squares can improve performance.
* [[DF2012:Contaminant|Contaminants]] can accumulate on the ground and on dwarves and creatures. Especially for old forts, this can impact FPS. There is a bug ({{bug|296}}) which makes contaminants continuously multiply and another ({{bug|3270}}) which prevents blood from ever disappearing.
** If the contaminants are outside, isolate the area and let [[DF2012:Weather|rain]] slowly wash it away. Pets can be kept out with a [[Activity_zone#Pen.2FPasture|pen/pasture]] or a [[Activity_zone#Pit.2FPond|pit]]. Similarly, setting the [[traffic]] designation to restricted and/or assigning [[Activity_zone|Activity Zones]] strategically may keep dwarves away.
** Add in some in-fortress means of cleaning dwarves and pets. Just soap and a well will allow dwarves to clean themselves. Make sure you have the [[cleaning]] labor enabled, too. Details of these and other suggestions can be found on the [[cleaning]] page.
* Encountering [[HFS]] will dramatically reduce FPS AFTER you seal the breach ({{bug|1340}}). Either avoid doing so or use the work around posted in the bug report.
* Heavy construction, especially megaprojects, will cause increasingly severe input lag as the fortress grows. Forbid materials (especially stones, blocks, and bars) as much as possible to reduce the time the game needs to calculate the list of available materials to build constructions with.
* Training your military can cause lag, mostly due to sparring. Try to avoid training more than one or two squads at a time.
* When a team comes back from a raid/mission, a huge lag can appear suddenly (down to 5 fps). You can disband the squad and situation should come back to normal.
* The same can happen when sending a squad out for a mission. If squad members are somehow locked inside, they will continuously try to find a path to the mission and the game can grind to a near halt.
* Use as few engravings as possible.
* Minimize the number of living plants. This will not endear you to the Elves.
* Avoid looking at complicated areas. Displaying a map tile takes a varying amount of work depending on what it is:
** Unrevealed tiles take almost no time at all - it just needs to look up what "random glyph" to display there
** Layer stone tiles need to take the biome number and layer number and look up the layer material, then look up the inorganic raw object to get the symbol/color
** Lava stone tiles need to take the biome number and look up some region information to determine what lava-stone to use, then continue as above
** Feature stone tiles (i.e. adamantine) need to look up the map feature located within the tile to figure out what it's made of, then continue as above
** Vein stone tiles need to do a linear lookup within a list specific to the 16x16x1 map block to see which vein they match and determine the material, then continue as above
** Grass tiles need to do a linear lookup within that same list to figure out what type of grass is present, then look up the plant raw object to get the symbol/color (and also account for animations)
** Shrubs and saplings need to search a separate list (not sure if it's the global list or a column-specific one) to find the plant in question and determine its symbol/color
** Trees need to do a linear search through a column-specific list (one list per 48x48 tile embark region block) to determine what growths are present in the tile and look up within the plant itself to get the symbol/color
** Constructed tiles need to do a binary search by X/Y/Z coordinates in a separate list to determine what material it uses, then look up that material for the symbol/color
** On top of all of that, it does a ''linear'' search in yet another list to determine whether or not an engraving is present (and, if there is, what tile to display)
** Other tile contents (units, buildings, items, vermin, etc.) get displayed
** After all of that is done, it then does yet another linear search (though the same list as with vein stones and grass) to see if the tile has a spatter on it (e.g. mud, blood, vomit, or leaves) and adjust the symbol/color accordingly

====Game Settings====
* G_FPS is a setting in the [[init.txt]] file. It controls how often Dwarf Fortress redraws the screen. It also controls how often the game checks for keyboard or mouse input.
** Reducing G_FPS can speed up the rest of the game. The default choice of 50 works well, but many people reduce it down to 20 with no ill effect.
** Reducing G_FPS too far can make the game unresponsive and glitchy. Some people can cope with 5; most cannot.
* PRINT_MODE is another init setting. It controls the method Dwarf Fortress uses to draw the screen.
** More advanced methods allow DF to make more use of OpenGL features and therefore your graphics card. STANDARD and VBO are good starting points.
** More advanced methods may still have bugs. 2D is more likely to be reliable.
* Using creature graphics may reduce FPS. (Using a custom ASCII tileset should have no effect)
*PRIORITY represents how much importance the game is given when it makes a request of the CPU. From [[init.txt]]:
**"Change this to make the dwarfort.exe process have a different priority. From highest to lowest, the options are REALTIME, HIGH, ABOVE_NORMAL, NORMAL, BELOW_NORMAL and IDLE."
**While it's best to run DF with no other programs in the background if FPS is an issue, giving the priority a bump or two can help speed things up regardless. You [https://devblogs.microsoft.com/oldnewthing/20100610-00/?p=13753 should not set this to REALTIME].
*TEXTURE_PARAM controls how the graphics are displayed, specifically how the color value of each pixel is smoothed. It is LINEAR by default. Turning this to NEAREST gives the CPU slightly less to do, though the improvement in performance is so far unquantified.
**From [[init.txt]]: "Change this to NEAREST if you want the texture values to use the nearest pixel without averaging. Change this to LINEAR if you want the texture values to be averaged over the adjacent pixels."

===With Game Alterations===
All changes in this area have some effect on the game itself, use at your own discretion.

====Game Settings====
* [[Temperature]] calculations place a significant load on the processor.
** Disabling them, using the settings in [[d_init.txt]], will speed things up.
** Without temperature calculations, [[obsidian farming]] becomes unusable; as the tiles never cool down, dwarves refuse to step on the obsidian floor, preventing access for hauling dwarves.{{bug|6033}} You can re-enable temperature occasionally to allow tile temperatures to normalize. Alternatively, you can work around this issue by altering obsidian in the raws to give it [MAT_FIXED_TEMP:10000] (as [[nether-cap]] does normally), preventing it from being hot.
** Disabling temperature calculations will cause [[fire]] to become glitchy, including creatures who can create it ([[fire imp]]s, [[dragon]]s, [[forgotten beast]]s, etc). Dwarves set on fire with temperature disabled will burn perpetually until exposed to water, though they won't receive any damage. Tiles exposed to fire with temperature calculations disabled will become entirely impassable, which may lead to significant parts of your map being blocked away. If confronted by fire or fire-based creatures, it may be worth turning temperature back on until they're dealt with.
** Multiple users have reported an FPS increase of 100% or better when disabling temperature calculations [http://www.bay12forums.com/smf/index.php?topic=86761.msg2352509#msg2352509].
* Disabling [[weather]] is likely to speed things up as well, but then rain won't refill [[murky pool]]s, clean contaminants, kill dwarves, etc.
* Each dwarf has a lot of processing involved with them.
** Limit the number of dwarves by setting a [[immigration|population cap]].
* [[Invader]]s also need to pathfind. While you can simply kill them to get rid of the problem, their mere presence may slow the game down to the point it is unfeasible.
** The number of invaders can be controlled with d_init.txt. Lower the invader cap to get smaller [[siege]]s with a more reasonable amount of enemies. If that is not enough, invaders can be disabled outright, though that will lock you out of [[fun]] content.
* The game also has to track what is happening in the caverns.
** You can disable cavern layers in [[advanced world generation]]. Without caverns, you will have far fewer critters and threats pathfinding through winding passages. Unfortunately, you also lose underground [[plant]]s and [[tree]]s. Alternatively, you can reduce the number of cavern layers to just one.
** If you don't mind losing large amounts of [[fun]], you can also disable generation of the [[magma sea]] and [[HFS|bottom layer]].

====Mods and Utilities====
* Accumulations of [[contaminant]]s can decrease FPS, and they are somewhat buggy. (See {{bug|296}} and {{bug|3270}}.)
** Sometimes contaminants are widespread or difficult to reach, such that relying on the usual [[cleaning]] methods would be impractical or impossible, or the player may lack the patience to deal with it that way. Some opt to use the "clean" and "spotclean" commands in the [[Utility:DFHack|DFhack]] utility to clear contaminants.

* Constantly-growing piles of cast-off clothes and checking for clothing [[wear]] and unhappy [[thoughts]] can impact FPS.
** One could [[Modding_guide|modify]] clothing to prevent [[wear]]. This can be done by adding an [[DF2012:Armor_token|ARMORLEVEL:1]] token. Aside from a possible FPS gain, this has other benefits as well. This fix is part of the [[DF2012:List_of_mods#Modest_Mod|Modest Mod]] as an optional "Eternal Fashion module". It might also be found in other mods which are based around Modest Mod. (Search the [http://dffd.wimbli.com/ DFFD] for "Modest".) Also, [[DF2012:List_of_mods#Masterwork_Dwarf_Fortress_.28MDF.29|Masterwork Dwarf Fortress]] allows the creation of metal clothing.

* Some mods have been created specifically to improve performance. They often reduce and standardize materials (like leather and bone) and may reduce the types of clothing available to control item count (especially for invaders).
** [http://www.bay12forums.com/smf/index.php?topic=117954.0 Accelerated Dwarf Fortress] for v0.34.11
** [http://www.bay12forums.com/smf/index.php?topic=141715.0 Modest Accelerated Mash] for v0.40.x
** [http://www.bay12forums.com/smf/index.php?topic=148265.0 Modest Mod] for v0.42.x has the Accelerated module

==DFHack commands==
A list of [[Utility:DFHack|DFHack]] commands that can help with your framerate by fixing bugs and reducing items.

*{{DFtext|autodump|white}} Useful for mass dumping or destroying items. Use {{DFtext|help autodump|white}} for options.
*{{DFtext|cleanowned|white}} Confiscates and dumps garbage owned by dwarves. Use {{DFtext|help cleanowned|white}} for options. Can cause unhappy thoughts if no replacement clothing is available.
*{{DFtext|clean|white}} and {{DFtext|spotclean|white}} Removes contaminants from tiles/units/items or one tile. {{bug|296}}{{bug|1750}}{{bug|3270}} Use {{DFtext|help clean|white}} for options.
*{{DFtext|flows|white}} Counts map blocks with flowing liquids, which slow the game down.

*{{DFtext|tweak fast-heat|white}} Further improves temperature update performance.

*{{DFtext|timestream}} alters the game simulation speed so that it *feels* fast even at low FPS. Either the calendar, or the units themselves, or both, can be changed - so {{DFtext|timestream -fps 100 -units}} while your actual FPS sits at a measly 20 will make the calendar tick and the units move five times faster. This is very useful to extend the playability of older forts where early micromanagement isn't as important and most of day-to-day functioning runs itself.

*{{DFtext|fastdwarf|white}} Causes dwarves and other creatures to move and work faster or causes them to teleport. Run {{DFtext|fastdwarf help|white}} for more information.

==Mac OS X Specific==
Spotlight indexes files on your mac. Since DF constantly changes files, spotlight will keep indexing them using 60-70% of your CPU. Exclude DF in system preferences: spotlight's privacy settings (by dragging the save folder into the list or pressing the {{K|+}} button) and you can get a factor of two in FPS. This can easily provide benefits of over 30 FPS, even on multicore computers that do not need to worry about CPU. This is due to the fact that DF is not multi-threaded in any significant way.

Note that excluding the save folder from Spotlight means you can't use Spotlight or Finder to search through the raw files. If you need to for some reason, you can use "find" from the command line for this.

==GNU/Linux Specific==
Placing the whole df_linux directory in tmpfs using [https://github.com/graysky2/anything-sync-daemon Anything Sync Daemon] might improve FPS depending on your system.

If you run any indexing, exclude DF directory.

Installing mimalloc or jemalloc and preloading it in your ./df script to run ''Dwarf Fortress'' may result in improved framerates:

<nowiki>#!/bin/sh
DF_DIR=$(dirname "$0")
cd "${DF_DIR}"
LD_PRELOAD="/path/to/libmimalloc.so.2.0" ./libs/Dwarf_Fortress "$@"</nowiki>

The path the malloc is installed to may vary, check ''/usr/lib/'', ''/usr/lib64/'', ''/usr/local/lib/'', ''/usr/local/lib64/'', and ''/usr/lib/x86_64-linux-gnu/''. The .so file's name may also vary.

==Mac OS X or GNU/Linux Specific==
===Setting process niceness===
One thing that Unix-like systems feature is being able to control the priority of a process in relation to other processes running at the same time. This is its "niceness" value, with -20 being most favorable to the process. Some graphical task managers can set this value, but otherwise, you can use the "renice" command as so:

<nowiki>sudo renice -n -20 -p $(pgrep Dwarf_Fortress)</nowiki>

This command should work in most distributions of GNU/Linux. For macOS (whose Dwarf Fortress binary uses Windows' naming convention for some reason), use:

<nowiki>sudo renice -n -20 -p $(pgrep dwarfort.exe)</nowiki>

==See also==
* [[System requirements]] - hardware changes affecting framerate

{{Category|Guides}}
[[ru:Maximizing framerate]]

Room

2022-12-23T10:10:41Z

HawkOwl: description of removed feature instead of flat redirect

{{av}}
{{removed feature}}

A '''room''' was an area defined from an object that specified the purpose of the room (for example, a [[bedroom]] would be defined from a [[bed]]).

As of v50.01, you instead specify [[activity zone|activity zones]] that may or may not have objects inside them. For the behavior in previous versions, see [[DF2014:Room]].

Dwarf Fortress Wiki talk:Versions

2022-12-23T10:03:35Z

HawkOwl: /* Removed features & concepts */

{{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)
::: I much prefer your tabber solution, but if that fails we can also use the gallery slideshow mode. If so, beware it has no way to control image size so the images have to be maliciously uploaded using the exact same size. example:
<gallery mode="slideshow">
File:SteelSample.png
File:TinSample.png
File:ZincSample.png
File:GoldSample.png
</gallery> --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 10:19, 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)

: Not sure. I wish the classic release soon --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 16:45, 22 December 2022 (UTC)
:: Are you Toady's herald? Looks like it was just released! [[User:Brightgalrs|Brightgalrs]] ([[User talk:Brightgalrs|talk]]) 18:18, 22 December 2022 (UTC)
:: And our questions are answered, the old hotkeys seem to have been thrown out. Part of me is disappointed (useless muscle memory) but also relieved (unified UI for both versions is good in general and for the wiki). [[User:Brightgalrs|Brightgalrs]] ([[User talk:Brightgalrs|talk]]) 18:25, 22 December 2022 (UTC)
::: According to info, in a sort of 'demo version' at that. I'll wait a little while longer, for myself.[[User:Silverwing235|Silverwing235]] ([[User talk:Silverwing235|talk]]) 18:22, 22 December 2022 (UTC)
::::It's unlikely that keybindings in it will change significantly. My vote is that we should include information for both premium and classic, everywhere. Hopefully the keybindings are not different between versions. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 18:26, 22 December 2022 (UTC)
:::Shouldn't it be based on the 50 or what verion the article is written for? [[User:Dominick|Dominick]] [[User_talk:dominick|(TALK)]] 18:42, 22 December 2022 (UTC)

=== Removed features & concepts ===

Since they're removed concepts, I've set [[Room]] to be a redirect for [[DF2014:Room]] and created [[Template:Activity zones]] for the nav bar bedrooms, etc, and made the necessary changes to [[Bedroom]] for it. Is this the correct approach, before I go on much further? (also a note, if it is, then [[Template:v50_rooms]] probably needs to be deleted) I also imagine that considering the number of changes in the interface, that things like [[Adventure mode]] and related pages might best be truncated to "not in 50.03" and when it does make it across, being more deliberately brought over in pieces? [[User:HawkOwl|HawkOwl]] ([[User talk:HawkOwl|talk]]) 06:23, 23 December 2022 (UTC)

:Usually it is marked with [[Template:Removed_feature]]. For example: [[Dipscript]] or [[Party]]. --[[User:Jan|Jan]] ([[User talk:Jan|talk]]) 07:45, 23 December 2022 (UTC)

:: Ah, that's fair. Should that be mentioned in [[Dwarf_Fortress_Wiki:Versions#Redirects]]? [[User:HawkOwl|HawkOwl]] ([[User talk:HawkOwl|talk]]) 10:03, 23 December 2022 (UTC)

User:HawkOwl

2022-12-23T07:28:14Z

HawkOwl:

computer hammerer irl

<div style="width: 300px; height: 36px; background:#1c1c1c; display: flex; color: white; box-sizing: border-box;">
<div style="height: 36px; width:36px; border-top: 1px solid #393939; border-left: 1px solid #393939; box-sizing: border-box;">
<div style="height: 33px; width: 33px; border: 1px solid #2d2d2d;">
<div style="height: 32px; width: 32px; border-right: 1px solid #393939; border-bottom: 1px solid #393939;">
<div style="height: 30px; width: 30px; background-color: black; border: 1px solid black;">
<div style="height: 28px; width: 28px; border: 1px solid #1c1c1c; border-radius: 1.5px; background-color: #49384a">
</div>
</div>
</div>
</div>
</div>
<div style="padding-left: 20px; padding-top: 10px; line-height: 12px; font-size: 12px; font-family: Monospace;">
<div style=" color: #ffe112">Ilthosbut</div>
<div style="color: white">"Wordsdrill"</div>
</div>

</div>

User:HawkOwl

2022-12-23T06:28:21Z

HawkOwl: Created page with "computer hammerer irl"

computer hammerer irl

Dwarf Fortress Wiki talk:Versions

2022-12-23T06:23:37Z

HawkOwl: removed features & concepts

Bedroom

2022-12-23T06:16:35Z

HawkOwl:

{{migrated article}}
{{av}}
{{Quality|Unrated}}
[[File:bedroom_preview.png|thumb|320px|right|A bedroom a player was lazy in creating.]]A '''bedroom''' is an [[Activity zone|activity zone]] that probably should contain a [[bed]]. Bedrooms are automatically claimed by [[dwarves]] (or spouses of dwarves); or they may be manually assigned to a dwarf. Once a bedroom has an owner, it becomes the private quarters for that dwarf, where he/she will [[sleep]], store any belongings that are not carried, and hang out in if there is no [[activity zone|meeting area]].

==Setup and ownership==
Bedrooms can be created designating the relevant {{k|z}}one. For it to be of use to your dwarves, you will have to first craft a [[bed]] in a [[carpenter's workshop]], then {{k|b}}-{{k|f}}-{{k|b}}uild it in the zone. Dwarves will not sleep in beds which have been produced in a workshop until they are placed via the build menu.

To remove a bedroom, select enter {{k|z}}one mode and select it, then click "Remove this zone permanently".

{{migrated section}}
A dwarf with no bedroom will automatically claim an unowned bedroom upon sleeping in it. The player can also manually assign bedrooms or change the ownership from one dwarf to another. Married couples have joint ownership of a single bedroom and sleep in the same bed; [[children|babies]] will also share a bedroom with their mother until they grow into children. Assigning a dwarf a new bedroom will NOT un-assign them from their old bedroom(s); if you want them to only have one bedroom, you'll need to track down their old bedroom and un-assign it.

===Other furniture===
Other pieces of [[furniture]] placed in the zone (such as [[cabinet]]s and [[container|coffer]]s) are usable by the dwarf that owns the bedroom. Owning furniture (especially high-quality furniture) gives dwarves happy [[thought]]s, and cabinets and coffers give them a place to store their possessions.



==Design tips==
[[Image:Dwarven_Housing.png|thumb|right|A true dwarf does not care for pretty designs or "privacy". For a dwarf, a bedroom is a hole where he dumps his body for rest and his [[Finished goods|Useless crap]] for storage, to never touch again.]]
{{main|Bedroom design}}
The living quarters of a fortress can take up a very large area, and since there will be constant [[traffic]] of dwarves going to and from their bedrooms, it is important to put some thought into the placement of the bedrooms. Simply making a long hall with rooms branching off from it is a simple method, but dwarves living at the end of the hall will have to travel a long time, and there will be a lot of dwarves bumping into each other at the entrance of the hall. Making multilevel living complexes can dramatically reduce the amount of time it takes for dwarves to travel to their bedrooms.

There is no need to build massive palaces for the average dwarf. They will get happy [[thoughts]] just from having a bedroom to claim as their own, though bigger and shinier ones will make them happier. Three tiles gives enough room for a [[bed]], a [[cabinet]], and a [[chest]], everything a dwarf needs. These pieces of furniture do ''not'' block movement.

{{Translation| dwarven = zust-mosus | elvish = sira-imira | goblin = zozax-xustxu | human = ina-coni}}

{{Activity zones}}
{{Category|Activity zones|Bedroom}}

Zone

2022-12-23T06:07:32Z

HawkOwl: add activity zone nav box

{{migrated article}}
{{Quality|Unrated}}
{{av}}
[[Image:Zones menu v50.03.png|right]]
'''Activity zones''' are areas where your citizens will work, socialize, rest, or perform specific duties, such as [[fishing]], dumping objects, or collecting [[water]].
Activity zones are optional for the performance of certain tasks (fishing, collecting water) but obligatory for certain others (dumping), and are used primarily to keep dwarves out of [[fun|danger]].

Activity zones can be placed in any [[revealed tile]], including in [[open space]], over a [[river]], or on top of a [[building]] or [[stockpile]]. They are placed in one of three ways: rectangular, draw, or (for some zones) multi. From within the Zones [[menu]] ({{k|z}}), selecting the zone type will open the zone creation screen. From here, you can select whether to create a zone in a rectangle (at which point you click the two corners for the zone), draw (where clicking adds single squares to the zone). You can enable erasing at any time and use rectangle and draw to remove squares from the zone. The number shown indicates how many selected floor tiles can be used for that type of zone.

For select zones types you can change from Paint to Multi mode in which you can draw multiple rectangle over multiple rooms, and each room valid for that zone type will be a separate zone. The number shown is the number of zones created in the last rectangle drawn, and the undo button will only undo the last rectangle created.

Some activity zones can be further specified into [[locations]] after creation. To do this first create the relevant zone, then click the Add Location button (+) to further specify it into a location. Multiple zones can be added to a single location, allowing them to span multiple rooms.

In some cases (pen/pasture, pit/pond) additional orders can then be set from the same menu. The location of a zone is only visible while in the Zones menu, and any object lying on the ground will hide the presence of a zone tile. The maximum size of an activity zone is 31×31.

== Meeting area ==
Meeting area zones are zones in which idle dwarves and animals will congregate, similar to [[meeting hall]]s. Additionally, [[immigration|immigrants]] will collect at a meeting area until their "migrant" status wears off. Note that the [[wagon (embark)|wagon]] you [[embark|arrive with]] constitutes a meeting area until you designate the first meeting area of your own. If you start in hostile surroundings, it is important to do so, so as to get your dwarves and animals out of danger quickly. It is a good idea to have at least one meeting area of one form or another: It allows you to make off-duty dwarves and animals gather in an area where they are not vulnerable within the fortress. A meeting area filled with dwarves increases the [[social skill]]s of idlers. It makes idle dwarves a little less idle. Because almost every dwarf visits a meeting area at least occasionally, it's an ideal place to site valuable objects and buildings. A meeting area exposed to sunlight will additionally prevent dwarves from becoming [[cave adaptation|cave-adapted]]. Note that having dwarves socialize will often result in them forming [[relationship]]s.

It is not advisable to have animals mill around in crowded meeting areas for a prolonged time, as they will pick fights with dwarves and other animals. While this may be negligible in the case of a hen, it also applies to your [[Dog#War dogs|war dogs]] (although this can be partly beneficial, since all your dwarves will get combat experience from being bitten occasionally, especially the children, who mill around constantly). Designating a meeting area is done via the zone menu; type {{k|i}}, set up a zone, and mark it both "active" and "meeting".

== Office ==
{{main|Office}}

== Bedroom ==
{{main|Bedroom}}

== Dormitory ==
{{main|Dormitory}}

== Dining hall ==
{{main|Dining hall}}

== Barracks ==
{{main|Barracks}}

== Pen/Pasture ==
{{main|Pasture}}

A pen or a pasture is used to contain tame animals. Once one is created, animals must be assigned to it individually by pressing {{k|N}} from the zone information screen. Dwarves will drag the assigned animals to the pen or pasture automatically. Domestic animals tend to aggregate at [[meeting area]]s instead, as will herbivorous ones, which will lead to probably starvation unless your meeting area is overgrown with [[grass]] or fungi for some reason. Any tame creature with the "grazer" token in the raws should be assigned to a pasture. This includes mules, cows, goats, horses, yaks, unicorns etc. Animals will not typically wander out of their assigned pasture even if it is not walled in, however animals will abandon their posts and will have to be dragged back to them if they are threatened by enemies, and an exposed pasture may lead to premature slaughter at the hands of invaders. Since pets can be assigned to pen/pastures and a zone can be created under a [[dwarven atom smasher]], this is one of the easiest ways to prevent [[catsplosion]]s.

== Archery range ==
{{main|Archery range}}

== Pit/Pond ==
:''See also: [[Mass pitting]]''
:{{k|p}}

{{TipBox2|titlebg=#c00|textbg=#ffd|[[File:warning_icon.png|25px]] Warning!|There have been multiple reports of hostile creatures escaping confinement while pitting. In previous versions, only "thief" type creatures, flyers, or large creatures like titans would escape using this system. The 0.40 behavior is still being investigated. Use of forbidden tightly closed hatches above every hole appears to prevent escape. See [[Mass pitting]] for more. If there are walls under the hole's edges rather than open space, they will allow [[Climber|grabbing and climbing]], so you may want to dig out an overhang, or at least [[Smoothing|smooth]] these walls.
}}

A Pit/Pond requires a [[ramp]] or hole with adjacent flooring on which a dwarf can stand. Designate the zone from the top of the ramp or hole, such that the zone designation is floating in the open space above the floor of the pit/pond. By default, the zone will be a pit. To change it to a pond, press {{k|P}} then {{k|f}}. It can be changed back to a pit the same way. Creatures can be assigned to a pit/pond through the {{k|P}} menu. If the creature is [[cage]]d, a dwarf will release it from the cage (rather than bringing the cage to the pit). The dwarf will lead the beast to the pit and throw it in. If the pit is a ramp rather than a hole, the creature will then wander back out, as it will if the pit has some other exit path (which would include straight back up the hole for flying creatures). Note that some (or possibly all?) hostile creatures may escape on being released from their cage, possibly attacking the dwarf who opened the cage. See [[Mass pitting]] for more information on pit design involving hostile creatures. Additionally, dwarves refuse to pit dwarves, hostile or not.

The only real difference between a pit and a pond is that dwarves will attempt to fill a pond with [[water]], carried by [[bucket]] from a water source. They will stand on the floor adjacent to the top of the ramp or hole, and toss the water onto the ramp or into the hole. This works even if there is a forbidden [[floor hatch]] covering the hole. Each bucketful increases the depth of the water in the tile below by 1/7. Once the water is dumped from the bucket, the dwarf will either drop the bucket and perform a different task, or choose to fill a pond zone tile again using the bucket (s)he currently holds. Dwarves will stop scheduling the Fill Pond job when the water depth reaches 6/7. Specifying a pond zone is one technique used for [[irrigation]], in order to make [[mud]] for [[farming]] on areas without soil. Currently, no matter how large the designated pond area, only one dwarf at a time will try to fill the pond. In order to fill a large area quickly, it is necessary to designate multiple smaller pond zones (or several zones overlapping the same area).

To make obsidian or cleanse stagnant water with fresh water, the pond zone must be designated an extra tile above the magma/stagnant pool, so that the water falls for a full tile before contacting the surface.

If you have more than one pond designated as a water source, your dwarves may endlessly try to fill each pond with the other pond's water, making a loop of useless duty; this may be undesirable, although otherwise-idle dwarves performing this task won't be making any friends. Only dwarves with the [[Hauling#Water_hauling|Water hauling]] labor enabled will fill ponds.

Artificial ponds are considered to be the same as Murky Pools - you'll only catch pond fish from them (i.e. turtles). If you want to catch river fish, you must fish from the river's original tiles (or perform some DFHack trickery to mark your new tiles as being part of the river).

== Garbage Dump ==
{{main|Garbage dump}}
Garbage dump zones are areas in which dwarves will throw items marked for dumping - either with by using {{k|k}}-{{k|d}} (one item at a time), or {{k|d}}-{{k|b}}-{{k|d}} (bulk dumping; note that this designates ''all'' items on the tiles for dumping, even built [[furniture]] and items inside [[container]]s). Garbage dumps are ''not'' the same as [[Refuse#Refuse|refuse]] stockpiles, which can be designated to accept specific type(s) of refuse, such as animal [[corpse]]s or [[bones]], and then are automatically filled by haulers whenever the items appear on the map. Despite the name, garbage dump zones are useful for many things beyond [[garbage disposal]]; they can create [[quantum stockpile]]s, transport materials to a job site, send items to the [[trade depot]] when no caravan is present, [[trap design#Falling_debris_trap|drop rocks]] on enemies below, and numerous other uses.

The garbage dump may be inappropriately named, as it's more of a matter compression zone. The specifics are beyond human understanding; however, dwarves are in fact capable of compressing an infinite amount of matter into only one tile, as long as it is specified as a garbage dump. If for some reason [[Main:Urist|Urist]] is yet again incapable of locating his favorite pair of cave troll leather socks, he should think to look among the black hole of matter that is the nearest garbage dump, as they could be snugly lodged between a few billion rocks.

Be aware that if a garbage zone is designated beside a cliff or hole (any open space, either natural or dwarf-made), garbage will be thrown into the open space. If a dump is designated over a [[ramp]] to the next level down, some dwarves may walk down the ramp to dump their items, while others may just toss their items down from above and onto those dwarves, injuring or killing them.

== Water source ==
Dwarves will use these zones to draw water, to satisfy booze-less [[thirst]], to tend to another thirsty dwarf (with the Give Water job), or to fill a [[#Pit/Pond|Pond zone]]. Only tiles ''adjacent'' to water qualify as usable water sources - thus, if you want to place a single-tile zone, place the zone onto a ground tile next to the water, not over the water itself. This zone should ''not'' be used with [[well]]s - this is redundant, as they are already considered their own water source.

If this zone does not exist, any water source can be used. If at least one water source zone exists, then dwarves will only get water from these zones.

Remember that natural bodies of water usually contain aquatic wildlife, some of which may attack your dwarves, or at least spook civilians, and interrupt their tasks. Often it may be best to simply designate a safe body of water as a water source so dwarves aren't allowed to drink/fish anywhere else.

Normally, creatures cannot attack any dwarves through a [[well]] so long as the well is not on the same z-level as the top of the lake/river, thus building one will allow your dwarves safe access to water inhabited by vicious animals (as long as those can't climb).

When dangerous fish are found in the river, one solution is to dig an artificial [[channel]] and place a [[grate]] between it and the river proper, as fish cannot swim through grates, but grates still allow water through. However, beware [[Grate#Bugs|the bug with flow and ''wall'' grates]] - taking water via U-shaped tunnel capped with ''floor'' grates may be safer. If you use a completely isolated smooth reservoir filled with [[pump]]-filtered water, it may still need protection, since the dwarf operating a pump stands right next to its water source tile.
Placing floor grates over the river or channel may also protect dwarves by preventing them from falling in.

[[Carp]] and other non-[[vermin]] fish suffocate if they are not in water, so in some situations it might be possible to pump the water out of a lake or pond. Conversely, an open water body (river or sea) not only cannot be subjected to temporary drainage, but even if there isn't anything dangerous right now, it may arrive later.

== Animal Training ==
{{main|Animal Training}}

== Dungeon ==
{{main|Jail}}

== Tomb ==
{{main|Tomb}}

== Fishing ==
Dwarves will preferably use these zones when [[fishing]], using them up until their supply is exhausted before moving on to the next water source. As with water sources, only tiles ''adjacent'' to water qualify as usable tiles. Far-flung fisherdwarves fishing in a distant [[river]] or [[pool]] are a serious defensive liability in case of an attack, so designating a safer fishing zone and, optionally, restricting non-zone fishing in the [[standing orders]] menu will help keep your fisherdwarves safe. Dwarves can fish through a [[grate]] or even a [[well]], provided there is water in the tile 1 z-level below the activity zone.

The [[Captured live fish|capture live fish]] job can ''only'' be carried out at a designated fishing zone.

== Gather Fruit ==
This will automate plant-gathering jobs in this area, necessary if you want your dwarves to collect fruit from the floor or trees. If there are fruit-bearing trees in the designated area, a dwarf will fetch a [[stepladder]] to climb into the tree. The ladder-using dwarf will drop harvested fruit to the ground for others to collect and haul. The details can be set in a sub-menu.

== Sand collection ==
{{main|Glass industry#Collecting sand}}
A '''sand collection''' zone allows dwarves with the [[item hauling]] labor active to fill an unused [[bag]] with [[sand]] for use in the [[glass industry]]. The 'collect sand' task is created at a [[glass furnace]].

== Clay collection ==
{{main|Ceramic industry#Clay collection}}
:{{k|c}}
A '''clay collection''' zone allows dwarves with the [[item hauling]] labor active to create [[clay]] for use in the [[ceramic industry]]. The 'collect clay' task is created at a [[kiln]].

An animal training zone allows [[Animal trainer|animal training]]. Animals cannot be trained unless they are in a training zone or [[pasture]] or on a [[restraint]].
To be tamed, they must be in a [[cage]]. For making an animal training zone, it is advisable to create a small room with a [[Door|tightly shut door]]. The training zone should be combined with a pasture to keep in wild animals. This will make sure your animals don't escape when they are not being trained.

{{Activity zones}}
{{Category|Fortress mode}}
{{Category|Activity zones}}
[[ru:Activity zone]]

Template:V50 zones

2022-12-23T06:02:23Z

HawkOwl: initial version of an activity zones nav box

{{Navbox
| name = V50 activity zones
| title = [[Activity zone]]s
| state = {{{state|}}}
| basestyle = background-color: #cebedf;

| group1 = Civilian
| list1 = [[Meeting area]] • [[Bedroom]] • [[Dormitory]] • [[Dining hall]] • [[Activity_zone#Pit.2FPond|Pit/Pond]] • [[Garbage dump]] • [[Activity_zone#Water_source|Water source]]

| group2 = Industry
| list2 = [[Pasture|Pen/Pasture]] • [[Activity_zone#Fishing|Fishing]] • [[Activity_zone#Gather_Fruit|Gather fruit]] • [[Activity_zone#Sand_collection|Sand collection]] • [[Activity_zone#Clay_collection|Clay collection]]

| group3 = Government
| list3 = [[Office]] • [[Jail|Dungeon]]

| group4 = Military
| list4 = [[Barracks]] • [[Archery range]] • [[Activity_zone#Animal_Training|Animal training]]
}}<noinclude>[[Category:Navigation templates]]</noinclude>

Template:Zones

2022-12-23T05:45:44Z

HawkOwl: Create activity zones template to replace rooms template

{{version switch|activity zones}}{{interwiki|{{FULLPAGENAME}}}}

Category:Activity Zones

2022-12-23T05:43:23Z

HawkOwl: HawkOwl moved page Category:Activity Zones to Category:Activity zones: rule n on page names

#REDIRECT [[:Category:Activity zones]]

Category:Zones

2022-12-23T05:43:23Z

HawkOwl: HawkOwl moved page Category:Activity Zones to Category:Activity zones: rule n on page names

[[Activity zone|Activity zones]] are areas where your citizens will work, socialize, rest, or perform specific duties.

[[category:Fortress mode]]

Bedroom

2022-12-23T05:42:43Z

HawkOwl: rule n, on capitalised names

{{migrated article}}
{{av}}
{{Quality|Unrated}}
[[File:bedroom_preview.png|thumb|320px|right|A bedroom a player was lazy in creating.]]A '''bedroom''' is an [[Activity zone]] that probably should contain a [[bed]]. Bedrooms are automatically claimed by [[dwarves]] (or spouses of dwarves); or they may be manually assigned to a dwarf. Once a bedroom has an owner, it becomes the private quarters for that dwarf, where he/she will [[sleep]], store any belongings that are not carried, and hang out in if there is no [[activity zone|meeting area]].

==Setup and ownership==
Bedrooms can be created designating the relevant {{k|z}}one. For it to be of use to your dwarves, you will have to first craft a [[bed]] in a [[carpenter's workshop]], then {{k|b}}-{{k|f}}-{{k|b}}uild it in the zone. Dwarves will not sleep in beds which have been produced in a workshop until they are placed via the build menu.

To remove a bedroom, select enter {{k|z}}one mode and select it, then click "Remove this zone permanently".

{{migrated section}}

A dwarf with no bedroom will automatically claim an unowned bedroom upon sleeping in it. The player can also manually assign bedrooms or change the ownership from one dwarf to another. Married couples have joint ownership of a single bedroom and sleep in the same bed; [[children|babies]] will also share a bedroom with their mother until they grow into children. Assigning a dwarf a new bedroom will NOT un-assign them from their old bedroom(s); if you want them to only have one bedroom, you'll need to track down their old bedroom and un-assign it.

===Other furniture===
Other pieces of [[furniture]] placed in the zone (such as [[cabinet]]s and [[container|coffer]]s) are usable by the dwarf that owns the bedroom. Owning furniture (especially high-quality furniture) gives dwarves happy [[thought]]s, and cabinets and coffers give them a place to store their possessions.



==Design tips==
[[Image:Dwarven_Housing.png|thumb|right|A true dwarf does not care for pretty designs or "privacy". For a dwarf, a bedroom is a hole where he dumps his body for rest and his [[Finished goods|Useless crap]] for storage, to never touch again.]]
{{main|Bedroom design}}
The living quarters of a fortress can take up a very large area, and since there will be constant [[traffic]] of dwarves going to and from their bedrooms, it is important to put some thought into the placement of the bedrooms. Simply making a long hall with rooms branching off from it is a simple method, but dwarves living at the end of the hall will have to travel a long time, and there will be a lot of dwarves bumping into each other at the entrance of the hall. Making multilevel living complexes can dramatically reduce the amount of time it takes for dwarves to travel to their bedrooms.

There is no need to build massive palaces for the average dwarf. They will get happy [[thoughts]] just from having a bedroom to claim as their own, though bigger and shinier ones will make them happier. Three tiles gives enough room for a [[bed]], a [[cabinet]], and a [[chest]], everything a dwarf needs. These pieces of furniture do ''not'' block movement.

{{Translation| dwarven = zust-mosus | elvish = sira-imira | goblin = zozax-xustxu | human = ina-coni}}

{{Activity zones}}
{{Category|Activity zones|Bedroom}}

Category:Zones

2022-12-23T05:41:20Z

HawkOwl: Activity Zones -> Activity zone

[[Activity zone|Activity zones]] are areas where your citizens will work, socialize, rest, or perform specific duties.

[[category:Fortress mode]]

Category:Zones

2022-12-23T05:40:03Z

HawkOwl: Activity Zone category

[[Activity Zones]] are areas where your citizens will work, socialize, rest, or perform specific duties.

[[category:Fortress mode]]

Bedroom

2022-12-23T05:37:47Z

HawkOwl: Updates for 50.03, mainly room -> activity zone

{{migrated article}}
{{av}}
{{Quality|Unrated}}
[[File:bedroom_preview.png|thumb|320px|right|A bedroom a player was lazy in creating.]]A '''bedroom''' is an [[Activity zone]] that probably should contain a [[bed]]. Bedrooms are automatically claimed by [[dwarves]] (or spouses of dwarves); or they may be manually assigned to a dwarf. Once a bedroom has an owner, it becomes the private quarters for that dwarf, where he/she will [[sleep]], store any belongings that are not carried, and hang out in if there is no [[activity zone|meeting area]].

==Setup and ownership==
Bedrooms can be created designating the relevant {{k|z}}one. For it to be of use to your dwarves, you will have to first craft a [[bed]] in a [[carpenter's workshop]], then {{k|b}}-{{k|f}}-{{k|b}}uild it in the zone. Dwarves will not sleep in beds which have been produced in a workshop until they are placed via the build menu.

To remove a bedroom, select enter {{k|z}}one mode and select it, then click "Remove this zone permanently".

{{migrated section}}

A dwarf with no bedroom will automatically claim an unowned bedroom upon sleeping in it. The player can also manually assign bedrooms or change the ownership from one dwarf to another. Married couples have joint ownership of a single bedroom and sleep in the same bed; [[children|babies]] will also share a bedroom with their mother until they grow into children. Assigning a dwarf a new bedroom will NOT un-assign them from their old bedroom(s); if you want them to only have one bedroom, you'll need to track down their old bedroom and un-assign it.

===Other furniture===
Other pieces of [[furniture]] placed in the zone (such as [[cabinet]]s and [[container|coffer]]s) are usable by the dwarf that owns the bedroom. Owning furniture (especially high-quality furniture) gives dwarves happy [[thought]]s, and cabinets and coffers give them a place to store their possessions.



==Design tips==
[[Image:Dwarven_Housing.png|thumb|right|A true dwarf does not care for pretty designs or "privacy". For a dwarf, a bedroom is a hole where he dumps his body for rest and his [[Finished goods|Useless crap]] for storage, to never touch again.]]
{{main|Bedroom design}}
The living quarters of a fortress can take up a very large area, and since there will be constant [[traffic]] of dwarves going to and from their bedrooms, it is important to put some thought into the placement of the bedrooms. Simply making a long hall with rooms branching off from it is a simple method, but dwarves living at the end of the hall will have to travel a long time, and there will be a lot of dwarves bumping into each other at the entrance of the hall. Making multilevel living complexes can dramatically reduce the amount of time it takes for dwarves to travel to their bedrooms.

There is no need to build massive palaces for the average dwarf. They will get happy [[thoughts]] just from having a bedroom to claim as their own, though bigger and shinier ones will make them happier. Three tiles gives enough room for a [[bed]], a [[cabinet]], and a [[chest]], everything a dwarf needs. These pieces of furniture do ''not'' block movement.

{{Translation| dwarven = zust-mosus | elvish = sira-imira | goblin = zozax-xustxu | human = ina-coni}}

{{Activity Zones}}
{{Category|Activity Zones|Bedroom}}

Room

2022-12-23T05:18:25Z

HawkOwl: Rooms no longer exist in v50, there are now only activity zones -- setting a redirect as per https://dwarffortresswiki.org/index.php/Dwarf_Fortress_Wiki:Versions#Redirects

#REDIRECT [[DF2014:Room]]

Bedroom design

2022-12-23T05:12:18Z

HawkOwl: designating dormitory from bed -> activity zone

{{migrated article}}
{{av}}
{{Quality|Unrated}}
There are many ways to design the layout of [[bedroom]]s. Simplicity, ease of designating, efficiency, and aesthetics are all important factors in designing dwarven housing. The ability to modify the design to enlarge, improve, or add rooms can be important as well. Proximity of the rooms to [[noise]] should also be considered.

As to size, all a dwarf needs to sleep is a 1-tile bed, anywhere. However, to be [[Thought|happy]], a dwarf wants their own room with a bed, and a chest and a cabinet to put stuff in. Dwarves consider it a bonus if the room is enclosed by 4 walls (or 3 and a door) for privacy. If you want to add some other item(s) that a dwarf [[preference|prefers]] to add to their happiness, that would require that much more space - usually no more than a tile or two. However, some [[noble]]s can get very [[Room#Quality|particular]], and their rooms need to be bigger to meet all their requirements.

The simplest approach resolving dwarven sleeping requirements is to have all your dwarves sleep in a large communal [[dormitory]]. The smallest ''bedroom design'' possible is a corridor with notched spaces for beds.

Players frequently want designs which maximize positive thought and minimize the path distance between a dwarf's food, drink, job and home. For these purposes, nothing holds a candle to the ease, simplicity, and efficiency of [[#The_multiply-overlapping_single_bedroom|overlapping bedrooms]] in a single large, carved-out area. In the current version, the main benefits of individualized rooms are for roleplaying purposes. Historically, room design was further complicated when the [[dwarven economy]] kicked in, and a wide range of "[[Room#Specific room quality grades|room qualities]]" were needed, and poor dwarves were kicked out of over-priced quarters (the dwarven economy is currently disabled). To this end, a number of solutions, some surprisingly elegant, have been produced.

Many of the designs shown here were taken from [http://www.bay12forums.com/smf/index.php?topic=16901.0 this forum post].

=Minimalism=

Sometimes, simpler is better... not always, but sometimes...

=== 1x1 bed only, no walls ===

By far the most minimal design is to take a bed, place it anywhere you want, then set it as a 1x1 room. This bed 'room' can be assigned to a dwarf early on, and will at least serve the bare minimum purpose of avoiding unhappy thoughts from the lack of a room. It will not, of course, leave the dwarves with any space to store any possessions at all. However, it requires the absolute minimum work to set up; all you need is existing empty space, preferably with no noise nearby, and a bed to place in it.

Alternatively if you are building compact merely to save space or improve framerate, a 1x1 bedroom on a smoothed, engraved floor can have quite a high room value.

Note that since beds do not block movement and simply having people moving nearby (or even directly ''over'' them) does not produce noise or disrupt sleeping dwarves in any way, you can place these 1x1 rooms in a solid block with no space between them; this makes it easy to smooth and engrave the floor for all of them at once. With a competent engraver and quality beds, this is often enough to raise the room value to the point where even this minimalist setup will produce happy thoughts; compared to a high-quality bed, the amount that un-engraved walls would add to a room's value is minimal anyway.

=== Communal dormitory ===

The simplest form of dwarven housing. Stick a bunch of beds in a room, zone them in a [[dormitory]], and voilà, instant flophouse. On maps with no [[tree]]s, this is pretty much your only option for sleeping quarters before breaching a cavern or importing large amounts of wood. (Dwarves will sleep on the floor of the dormitory if no beds are available, which at least keeps them from sleeping in the wilderness.)

This setup only causes a single negative thought ("slept without a proper room recently"), although you miss out the benefit of the happy thoughts generated by personally-owned furniture. However, as long as you compensate by offering your dwarves high-quality [[food]] and [[alcohol]], an expansive [[dining room]], and other luxuries, your dwarves will remain happy enough to be productive throughout the life of a fortress. (You may still wish to give [[noble]]s their own rooms, however; they tend to [[mandate|get]] [[demand|upset]] when their [[Noble#Room Requirements Summary|requirements]] are not met)

More than one dormitory can be built in a fortress; if they do not own their own bedroom, dwarves will gravitate to a nearby empty bed when it is time for them to sleep.

Communal dormitories are more appealing now due to the presence of [[vampire]]s among fortress populations, as it increases the likelihood of the offending bloodsucker being caught.

Note that compared to the solid block of 1x1 bedrooms above, the only advantage to a communal dormitory is the ease with which it can be set up - even owning a 1x1 room generates happy thoughts (as opposed to the minor negative one from a dormitory) and take the exact same space. Therefore, if unhappy thoughts are a concern, you should designate the beds as rooms instead.

=== Plain square design ===
[[Image:square_bedroom.png|right]]
If it is 2×2, 3×3 or more, square designs are probably the first choice of many players. Easy to plan, easy to put in place, this kind of design is one of the best when the player values their playing time instead of the overall layout of their fortress. While square designs are easy to reproduce en masse, most are not optimized either for beauty or space efficiency, two aspects that other designs excel at.

=== Line design ===
[[Image:line_bedroom.png|right|thumb| '''Line design''', laid out (left) and finished (right)]]
Line designs have the advantage of being very space efficient and very adaptative. From 1×1 to 1×4 and longer, it can fit almost anywhere, can be upgraded later on as long as you have the space behind your first original line and do not need excessive corridor space for the bedroom access. Simply dig a few lines out of an access tunnel already in use in your fortress and voilà, you have new living quarters. This kind of minimalistic design was particularly useful when the economy kicked in, as it could be adapted in a flash to meet the needs of low-wage citizens.

===Decentralized living===
In larger fortresses, one of the bigger problems is traffic. Dwarves have a tendency to all get hungry, thirsty, and tired in waves, and a crowd of 50 of them storming your centralized food stockpiles, one big dining room, and dormitory tunnels can cause a lot of lost time while the hordes shuffle by each other. A good solution to this is decentralized architecture, incorporating most of the essentials of every day life into numerous smaller areas. This isn't to suggest that you shouldn't have a legendary dining hall set as a meeting area, capable of holding half your fortress at once. You definitely should! But decentralizing from that dining hall relieves a lot of congestion in the halls surrounding the main dining hall, and makes it easier for dwarves just to pass through.

[[image:Living.GIF|right]]
In this image, the access stairwell (blue fields in the center), spread out in all directions to a public dormitory and dining room for poorer dwarves on the left/right and to 3x3 private rooms on the top/bottom. The design allows for two small stockpiles of food (gray fields) to minimize the walk to a dining hall.

There are also built-in areas for impressive things like [[Main:statues|statues]] and [[Main:cages|cages]] (for zoos) to keep dwarves admiring your handiwork. The 3x3 rooms are easy to get up to decent or higher to keep your most useful dwarves happy as clams. They're also convenient for impromptu noble housing, since you can just knock out a wall between two rooms and convert one into a dining room for a whiny noble. You could even expand the corner rooms a bit more on both the X and Y axes to make four 3x3 rooms to give the noble a dining room, tomb, and office all in one area. This is especially useful for the mayor, who gets replaced every so often. When a new Mayor is elected, one can reassign all the trappings to the new mayor in one go. If you want an even more decentralized and calm traffic pattern, put tables and chairs in all the private rooms; dwarves will prefer to eat in their quarters. The walls between the doors leading to the dormitory and Dining Room allow for 2 entrances and 2 exits to each predictably higher-traffic room while leaving a pillar of rock for an engraving. The main corridor also allows you to branch off into 4 restraints per floor in a private 1x2 prison. Since it's flanked by an animal cage and a statue (or alternatively, 2 statues. This may be better because Statues block movement and it's effectively the same as surrounding the prisoner with walls). Additionally, in an area you want smoothed and engraved to begin with, it gives prisoners a leg upon their happiness immediately and -- once again -- prevents traffic jams from convicts being brought food and water in larger prisons.

Another option for maximizing traffic throughput is to put a 1x3 line of upward stairwells on one end of the blue field, and a 1x3 line of downward stairwells on the other. This simulates a 3-wide vertical corridor without the safety risks of up/down stairwells.

You may also, at your discretion, knock out the statues and cages near the stairwell to make the entire plan a little more compact (though you lose the easy prisons in this case). This plan can stretch on the x axis as much as you like, but note that the 1 wide corridors leading to individual rooms can get crowded if more than 10 dwarves are living along each one. Even with the given layout, though, one floor supports 26 private rooms and as many as 14 public beds. This works out quite nicely since one floor is enough to handle most immigrant waves, while existing floors' public beds can handle a decent amount of overflow. The public dormitory rooms can also be converted into prisons very easily (just put chains next to every bed) if you decide not to go with the main design.

=== High density single floor housing ===

[[Image:Housing_by_Marble_Dice.png|thumb|244px|This is the 61x61 housing plan]]

This fractal-inspired design combines space efficiency with wider access hallways to alleviate traffic jams. Stairs are placed in the middle, and the design can expand indefinitely. To decrease the size, remove the outermost perimeter hallway, and all connected bedrooms. To increase the size, use the picture as a guide and follow the same radial pattern.

{| class="wikitable" style="padding:"
|-
! style="text-align:left;" | Size
! style="text-align:left;" | Capacity
! style="text-align:left;" | Max walk distance from center
|-
| style="padding-right:26px;" | 29x29 tiles
| style="padding-right:26px;" | 48 dwarves
| style="padding-right:26px;" | 23 steps
|-
| style="padding-right:26px;" | 45x45 tiles
| style="padding-right:26px;" | 120 dwarves
| style="padding-right:26px;" | 39 steps
|-
| style="padding-right:26px;" | 61x61 tiles
| style="padding-right:26px;" | 224 dwarves
| style="padding-right:26px;" | 55 steps
|-
| style="padding-right:26px;" | 77x77 tiles
| style="padding-right:26px;" | 360 dwarves
| style="padding-right:26px;" | 71 steps
|}

 

=== The multiply-overlapping single bedroom ===

A variation on the dormitory can produce large numbers of cheap, high quality bedrooms, very easily. Start with a large room, perhaps 20 x 20 tiles, and put many beds in it. From each of those beds, create a bedroom that covers the entire room. Each of the rooms overlaps the other rooms, and therefore suffers a quality modifier, but the room is large enough that its size can dominate the quality calculation. The quality hit for overlapping rooms is only applied once; your room either overlaps or it does not. With any reasonable amount of beds, it is easier and cheaper to furnish the one room with high quality items (at a penalty) than it is to carve out and furnish dozens of rooms separately. In addition, side by side beds in an open room is by far the most efficient use of space and walking distance. A room this size with a couple hundred beds in it, and some combination of smoothing, engraving, or multiple pieces of cheap furniture, can be of any quality level that is desired, from modest to royal.

=== Staggered Doorless Rooms ===

Dwarves suffer no penalties for having other Dwarves travel through their bedrooms even when they are sleeping. They also don't require doors. Therefore, you can take advantage of diagonal pathing in room design for high-density, non-overlapping, multi-tile rooms.

The following diagram shows a 3x1 layout surrounding a 3x3 stairwell. The design can be repeated outwards as far as necessary.

<pre>
---.B.---.B.---
.B.---.B.---.B.
---.B.---.B.---
.B.---XXX---.B.
---.B.XXX.B.---
.B.---XXX---.B.
---.B.---.B.---
.B.---.B.---.B.
---.B.---.B.---
</pre>

Dwarves will navigate from the stairwell diagonally through rooms, while bedroom sizes can be applied at 3x3 (without the area leaking to adjoining rooms) allowing for some level of furnishing.

=High density, single floor, quick housing=

[[Image:Dwarf-bedroom-simple.jpg|thumb|250px|This is a 35x35 housing plan]]

This design is nice in that it is very quick to lay since using shift to move the cursor moves in steps of 11 tiles. It is also very easy to increase or decrease their value by adding or removing [[furniture]]. Each 1-tile wide walkway is shared by 10 dwarves reducing congestion and each room can fit a bed, a chest and a cabinet leaving 1 free space for any miscellaneous items such as a statue for legendary dwarves, the free space is in the back of the room for the reason that it allows you to place blocking items that cannot be moved over there without sealing your dwarves in/out.

=High density, multi-level=

Optimizing space, minimizing walking distance, these are good things... for some...

===Magical Multi-way Doors===

The main point of this design is that it squeezes six bedrooms in a space of 9x8 squares (including walls) by using two-way doors. It's meant to be built across several Z-levels, making it take up a minimal amount of practical space. It can be easily mirrored, although that requires a wider corridor (or the use of four bedrooms instead of six on the other side).

{{diagram|spaces=yes|\
Level -1 ¦ Level 0 ¦ Level 1
+-----+ ¦ +-----+ ¦ +-----+
¦..¦..¦ ¦ ¦..¦..¦ ¦ ¦..¦..¦
+-+.¦.+-+ ¦ +-+.¦.+-+ ¦ +-+.¦.+-+
¦.+D-D+.¦ ¦ ¦.+D-D+.¦ ¦ ¦.+D-D+.¦
¦..¦X¦..¦ ¦ ¦..¦X¦..¦ ¦ ¦..¦X¦..¦
¦---D---¦ ¦ ---+.+--- ¦ ¦---D---¦
¦...¦...¦ ¦ ......... ¦ ¦...¦...¦
+-------+ ¦ ¦ +-------+}}

'''Alternate layout:'''

This is a simpler (though slightly less compact) design using three-way doors.

{{diagram|spaces=yes|\
+---+---+
¦...¦...¦
+---+---D---+
¦...¦XXX¦...¦
+---D---+---+
¦...¦...¦
+---+---+}}

One apartment "unit" gives you 6 rooms using only 2 doors and it fits within a 13x7 space (including walls). Access to the apartments in the unit is through the 1-3 up/down stairwells in the center. This design can be expanded by repeating the same pattern one level down and/or by tiling together multiple units together on the same level.

Both designs mean that you have to build less doors per bedroom, which helps save time and materials.

===Sandwich===

A design to move bedrooms vertically spread across many unused Z levels easily. The rooms can be preferentially scaled up or down depending on needs. If space is reserved serves well for expansion of each bedroom as suitable.

The sandwich basically consists of a three tile wide hallway or wider. Up/Down Stairways are evenly distributed in increments which lead to one or more bedrooms as needed. [[Floor hatch]]es can be used between the individual bedrooms like vertical doors, but, unlike doors, owned floor hatches can generate happy [[thought]]s.

[http://www.bay12forums.com/smf/index.php?topic=118751.0 Recent science] has established that having any "holes" in a room's walls reduces the apparent [[room value]]; this design is therefore particularly well-suited to producing high-value rooms.

{{diagram|spaces=yes|\
Level -1 ¦ Level 0 ¦ Level 1
+-----------+ ¦ ¦ +-----------+
¦B.¦B.¦B.¦B.¦ ¦ ¦ ¦B.¦B.¦B.¦B.¦
¦..¦..¦..¦..¦ ¦ ------------- ¦ ¦..¦..¦..¦..¦
¦X.¦X.¦X.¦X.¦ ¦ .X..X..X..X.. ¦ ¦X.¦X.¦X.¦X.¦
¦--+--+--+--¦ ¦ ............. ¦ ¦--+--+--+--¦
¦X.¦X.¦X.¦X.¦ ¦ .X..X..X..X.. ¦ ¦X.¦X.¦X.¦X.¦
¦..¦..¦..¦..¦ ¦ ------------- ¦ ¦..¦..¦..¦..¦
¦B.¦B.¦B.¦B.¦ ¦ ¦ ¦B.¦B.¦B.¦B.¦
+-----------+ ¦ ¦ +-----------+}}

The bedroom design can be copied several times further up and down starting from Level 1 or -1 to exploit available space in neighbouring Z levels. The design is excellent as the space surrounding the hallway can be used for directly tying to the dining/meeting hall.

===6-room clusters===

[[File:ClusterBedrooms.png|thumb|350 pix|'''6-room clusters''' ''(click to enlarge)'']]
This one is quite dense. There are six bedroom clusters. They can be built close to each other.

There are 7 6-room clusters here. If 5 Z-Levels of this are built, that's 5*7*6=210, which is plenty for most any fortress.

=== Living Pods (Residential Flats) ===

This design is compact and allows for a large number of rooms. Each room has 3 tiles plus a door. To add to the complex build an apartment level one level above or below the lobby - the stairs allow direct access. The design can be stretched to make the rooms 3x2 or 3x3, or to allow more rooms per floor, depending on your preference. Though not as visually impressive as the fractal patterns it is very efficient in that it can allow for large numbers of dwarves to easily access the main hallway. The pods are very quick to deploy as the interior (mined out) width of the pods exactly equals one {{k|Shift}}+move of the cursor. Highlight a full square with a horizontal shift+move then a vertical. Then ''un''mark the 3 internal walls in both horizontal and vertical directions (each also 1 shift+move distance long), and finally mark in the four staircases. Sixteen bedrooms with extremely efficient pathing laid out in as many seconds.
{{diagram|spaces=yes|\
Upper/lower
Apartment Level: Lobby Level:
+-----------+ +-----------+..
¦..¦..¦..¦..¦ ¦..¦..¦..¦..¦.. O
¦.+-+.¦.+-+.¦ ¦.+-+.¦.+-+.¦.. u
¦-¦X¦-+-¦X¦-¦ ¦-¦X+---+X+-+.. t
¦.+-+.¦.+-+.¦ ¦.++..O........ e
¦..¦..¦..¦..¦ ¦..¦........... r
¦--+--+--+--¦ ¦--¦O...O+--+..
¦..¦..¦..¦..¦ ¦..¦.....¦..¦.. H
¦.+-+.¦.+-+.¦ ¦.++..O..++.¦.. a
¦-¦X¦-+-¦X¦-¦ ¦-¦X+---+X¦-¦.. l
¦.+-+.¦.+-+.¦ ¦.+-+.¦.+-+.¦.. l
¦..¦..¦..¦..¦ ¦..¦..¦..¦..¦..
+-----------+ +-----------+..}}

==== Pod variant ====

This is an example of varying the above to suit personal taste. Three significant changes have been made:

:1) 2 pairs of vertical access stairs feed upward, instead of one horizontal hallway.

:2) The entire design has been expanded (to 15x15, vs 13x13 above), but rooms have not been expanded to fill all available space - not yet. That will be done if/as need arises, and many of the 3-tile rooms can become 5- or 7-tile1, or two joined together to become 12-tile suites2.

:3) Allow for a central waterfall with drain system*.

<pre>
Upper Apartment Lobby Lower Apartment
Level(s*): Level: Level(s*):
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
¦..¦..¦ ¦..¦..¦ ¦..¦..¦ ¦..¦..¦ ¦..¦..¦ ¦..¦..¦
¦.+-+.¦ ¦.+-+.¦ ¦.+-+.¦ ¦.+-+.¦ ¦.+-+.¦ ¦.+-+.¦
¦-¦X¦-¦ ¦-¦X¦-¦ ¦-¦X¦-----¦X¦-¦ ¦-¦X¦-----¦X¦-¦
¦.+¦+.¦ ¦.+-+.¦ ¦.+¦+.OOO.+-+.¦ ¦.+¦+..¦..+-+.¦
¦..¦..¦ ¦..¦..¦ ¦..¦.......¦..¦ ¦..¦.+---+.¦..¦
+--+-------+--+ +--¦..###..¦--+ +--¦.¦~~~¦.¦--+
¦XX#~#XX¦ ¦<<#~#<<¦ ¦-¦~¦~¦-¦
+--+-------+--+ +--¦..###..¦--+ +--¦.¦~~~¦.¦--+
¦..¦..¦ ¦..¦..¦ ¦..¦.......¦..¦ ¦..¦.+---+.¦..¦
¦.+-+.¦ ¦.+-+.¦ ¦.+-+.OOO.+-+.¦ ¦.+-+..¦..+-+.¦
¦-¦X¦-¦ ¦-¦X¦-¦ ¦-¦X¦-----¦X¦-¦ ¦-¦X¦-----¦X¦-¦
¦.+-+.¦ ¦.+-+.¦ ¦.+-+.¦ ¦.+-+.¦ ¦.+-+.¦ ¦.+-+.¦
¦..¦..¦ ¦..¦..¦ ¦..¦..¦ ¦..¦..¦ ¦..¦..¦ ¦..¦..¦
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+}}
Legend:
X = up/down stair
< = up stair
~ = flowing water, in waterfall and drain
# = [[grate]] or floor [[bars]] over drain
¦ = solid block at base of waterfall
O = [[statue]]s (though a [[zoo]] or booze stockpiles could work as well)</pre>
Notes:
: 1) There is a central, vertical line of unused tiles, allowing adjacent rooms to be expanded to 5 tiles large.
: 2) Expanding out one more tile beyond the outer boundaries can create size 5-11 rooms, or size 19 if two are connected.
: 3) A size 15 room is ample for any noble, with the possible exception of a [[king|king/queen]].

:<nowiki>*</nowiki> The floor plan for the waterfall/drain system may vary from floor to floor, and by personal taste. Eventually it can be routed off and out one side, and the full interior area of all levels below that reserved for apartments.

''(Note - It's easy to [[flood]] an area with a waterfall such as this - be sure you are familiar with the technique before risking an entire dormitory (or the lower parts, at least) on it.)''

=== Greek Cross design===
[[image:VaniverGreek48.png|right|thumb| 48 room design]]
Minimizing walking distances requires good use of vertical space. This plan is simple, scalable, and only takes up a few floors - 6 if you have 32 per floor, 4 if you have 48. The maximum walking distance should be less than 20 (walking up/down stairs counts as one distance.).[[image:VaniverGreek32.png|center|thumb| 32 room design]]
A Quickfort blueprint for the 32 tile Greek Cross design is available [http://www.mediafire.com/download/yfeoeo0qj38vw24/Greek_Cross_Design_Blueprint.zip here]

=== Shaft design ===

[[Image:Shaft_bedroom_design.gif|thumb|Shaft bedroom design with a few possible variations.]]

The Shaft design allows various options for entry direction and central "shaft" use. The central shaft may be altered to create dining rooms and offices for minor nobles, "deluxe" bedrooms, hospital beds, or simply more bedrooms. The design can easily accommodate several different room sizes while maintaining efficiency. However, the design utilizes Z-levels for efficiency, and you must build several levels of Shaft designs to accommodate a fully grown fortress.

The Shaft design can fit 20 2x2 rooms, or 30 1x1 rooms.

=== Tileable shaft design ===

The tileable shaft design is a further expansion of the general shaft design above, coming in somewhere between the simple geometric designs and the vastly more complex fractal designs. These are designs that can be symmetrically tiled, that means concatenated in all six directions and are thus suited both for manual design as well as macro-automation. They allow the user to extend the same pattern over very large areas and to easily extend the available space per room up to a given size by tearing down just a few walls. Additionally, they can be suited for bedrooms as well as work and storage.[[Image:tileable_shaft_big.png|thumb|Tileable shaft design with a few possible variations.]]

The downsides are that they're not especially optimized for walking distance or large hallways, and the necessity of the main access shaft on the z-level (stairs) having to be in the central-most tile (marked red in the examples) to allow z-level stacking.

=== Modified Windmill Villas ===

This is the most efficient method I have seen, and it keeps the central staircase as well.

(Calculations use 8 levels)
*Dwarfs per level = 28
*Levels needed for 200 = 7.1
*Max distance (including Z) = 15
*Average distance = 10.2
*Average distance per level = 5.4

[[Image:Modified_Windmill_Villas.png|Modified windmill villas]]

=== Squarified Tri-way Doors ===

Four "tri-way doors" patterns adjacent to each other, squarified with 4 normal rooms and 2 noble rooms.

This results in 30 bedrooms in a 21x15 rectangular space (counting all walls, including external ones). Can be repeated multiple z-levels, accessed from a lobby hallway.

{{diagram|spaces=yes|\
+-------+---+---+---+
¦.....DX¦...¦...¦...¦
+---+---+---D-+-+-+D¦
¦...¦...¦...¦X¦...¦X¦
+---D-+-+-+-+-D---+D¦
¦...¦X¦...¦...¦...¦.¦
+-+-+-D---+---+---+.¦
¦.¦...¦...¦...¦...¦.¦
¦.+---+---+---D-+-+-+
¦.¦...¦...¦...¦X¦...¦
¦D+---D-+-+-+-+-D---+
¦X¦...¦X¦...¦...¦...¦
¦D+-+-+-D---+---+---+
¦...¦...¦...¦XD.....¦
+---+---+---+-------+}}

=== Large Squarified Tri-way Doors ===

By playing with the basic building block of the above design, and a 25x25 space, you can get this elegant square and symmetrical design:

{{diagram|spaces=yes|\
╔═╦═╦═══╦═╦═╦═╦═╦═══╦═╦═╗
║ +X+ ║ ║ ║ ║ ║ +X+ ║
║ ╠═╬═╦═╣ ║ ║ ║ ╠═╦═╬═╣ ║
║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║
╠═╣ ║ ║ ╠═+═╬═+═╣ ║ ║ ╠═╣
║ ║ ║ ║ ║X║ ║ ║X║ ║ ║ ║ ║
║ ╠═+═╬═+═╣ ║ ╠═+═╬═+═╣ ║
║ ║X║ ║ ║ ║ ║ ║ ║ ║ ║X║ ║
╠═+═╣ ║ ║ ╠═╩═╣ ║ ║ ╠═+═╣
║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║
║ ║ ╠═╩═╬═╣ ╔═╩═╬═╩═╣ ║ ║
║ ║ ║ ║X+ ║ ║ ║ ║ ║
╠═╬═╬═══+═╩═╬═╦═+═══╬═╬═╣
║ ║ ║ ║ ║ +X║ ║ ║ ║
║ ║ ╠═╦═╬═╦═╝ ╠═╬═╦═╣ ║ ║
║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║
╠═+═╣ ║ ║ ╠═╦═╣ ║ ║ ╠═+═╣
║ ║X║ ║ ║ ║ ║ ║ ║ ║ ║X║ ║
║ ╠═+═╬═+═╣ ║ ╠═+═╬═+═╣ ║
║ ║ ║ ║ ║X║ ║ ║X║ ║ ║ ║ ║
╠═╣ ║ ║ ╠═+═╬═+═╣ ║ ║ ╠═╣
║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║
║ ╠═╬═╩═╣ ║ ║ ║ ╠═╩═╬═╣ ║
║ +X+ ║ ║ ║ ║ ║ +X+ ║
╚═╩═╩═══╩═╩═╩═╩═╩═══╩═╩═╝}}

This is the most space-efficient design when aiming for bedrooms with exactly three tiles of space which are accessible without crossing another bedroom. It uses only 9 tiles per bedroom overall, an amazing feat, since the mathematical minimum for the problem given is 8 tiles per bedroom! Such bedroom allocations are not in any way required, however: normal citizens are perfectly happy with an [[#The_multiply-overlapping_single_bedroom|overlapping bedroom]] in a large hall packed to capacity with beds.

=Repeating patterns & fractals=

Art for art's sake... and if it's functional, so much the better...

=== Blossom ===
[[Image:blossom.png|300px]]

Not truly fractal, but inspired by other fractals with a more aesthetic appeal. A slightly stripped down quickfort version of this is available [http://www.mediafire.com/view/?wx3g4373422u02r here].

=== Tessellated Apartments ===

[[File:Tessellatedrooms.jpg]]

Access can be from above and/or below by the stairs, or a hallway can be run into the dining room level by removing the bedroom at one of the cardinal points. This design can be repeated as far as desired in the X, Y, and Z directions.

===Noble Hive Pods===

A geometric pattern for Noble housing trying for interesting aesthetics and high mobility. The basic tiling pattern is shown on the left; one possible way to join them, involving surrounding corridors and a central staircase and a jillion doors, on the right.

[[File:Noblehive.png]]

=== Fractal designs ===

Betting on design beauty and on geometrical symmetry first, fractal designs can also be, at the same time, very space and walk efficient. They however require a lot of time and space both to plan and execute and are most likely out of reach of all but the most serious players. On the other hand, most of the designs displayed below would be avoided by the most serious players, due to their lack of serious Z-level access and incongruity with almost any general access plan. Most players however agree that they are the most incredible of all the designs around, if not for the sheer challenge of successfully executing something as complex, as for the extra touch it gives to the fortress as a whole once it is done.

[[image:Raynard_square_delight1.png]] [[image:Raynard1.png]]

[[image:Raynard_whirlpool_housing.png]]

[[image:Hactar1_3_branch_tree.png]] [[image:Hactar1_Mandelbrot_Tree.png]]

[[Image:SavokisLeaf08a032.png]]

[[image:Andrelius_Windmill_Villas.png]]

[[image:4bh0r53n_h-fractal.jpg]]

More fractal bedroom designs based upon the H-Tree (pictured above) can be found at [[User:Tenebrous|this user page]].

===Fractal modified for 3d===
This was created by palin88 from [http://www.bay12forums.com/smf/index.php?topic=17784.msg17413 Bay12Games forum] in order to make a three-dimensional version of Raynard's Fractal Design.

[[File:Palin88_Bedroom_Design.png]]

===Hallway with office===

+---------+╤¦ ¦b+---------+
¦B¦B¦B¦B¦B¦╥¦ ¦r¦B¦B¦B¦B¦B¦
¦k¦k¦k¦k¦k¦H¦ ¦H¦k¦k¦k¦k¦k¦
¦c¦c¦c¦c¦c¦ ¦c¦c¦c¦c¦c¦
¦D¦D¦D¦D¦D¦ ¦D¦D¦D¦D¦D¦
X
¦D¦D¦D¦D¦D¦ ¦D¦D¦D¦D¦D¦
¦c¦c¦c¦c¦c¦ ¦c¦c¦c¦c¦c¦
¦k¦k¦k¦k¦k¦H¦ ¦H¦k¦k¦k¦k¦k¦
¦B¦B¦B¦B¦B¦╥¦ ¦╥¦B¦B¦B¦B¦B¦
+---------+╤¦ ¦╤+---------+

Legend: 
B: Bed 
D: Door 
X: Staircase 
╥: Chair 
╤: Table 
c: Chest or Bag 
k: Cabinet 

An interesting design made to consume less space but still look pretty. It can be repeated infinitely, or at least as far as your embark square goes. One may also decide to use the stairwells as noble offices or rooms, or put the staircase somewhere else and put a well where the staircase would be.

{{Buildings}}
{{Category|Design}}