Dwarf Fortress Wiki - User contributions [en]

DF2014 Talk:Tree

2019-08-28T03:56:54Z

Thundercraft: Started new discussion: "Elven tree quota & subterranean mushroom trees"

So, before anyone works on the tree page here, what should we do? Do we need gifs of new trees since I could make some but I dont feel like writing an article. -- I suggest setting up the tree part as a cross section, showing what the roots are and such. Also, we could change the current tree icon(spades or clubs) to the 1/4 signs since its the leaf colours that matter – [[template:unsigned|unsigned]] comment by [[User:209.197.142.167|209.197.142.167]] 02:56, 9 July 2014 (UTC)
:I suggest making a new version of the table template that shows all tiles for each species, though I'm not sure what would be the best way to organize it.--[[User:Amena Ralikema|Amena Ralikema]] ([[User talk:Amena Ralikema|talk]]) 13:12, 12 July 2014 (UTC)

What the current way of organising it, with the root trunk, leavs is fairly good. I approve of it. also praise Amena Ralikema! The tree page is looking quite better- oddstranger

== Burning trees ==
Burning trees collapse, and forest fires cause immense pause+recenter spam of trees collapsing.
Perhaps something to mention(and warn for forest fires, aside from the obvious dangers). [[Special:Contributions/83.83.21.167|83.83.21.167]] 15:18, 9 July 2014 (UTC)

== Fruit ==
How do you get the fruits the new trees drop? – [[template:unsigned|unsigned]] comment by [[User:66.177.96.41|66.177.96.41]] 14:52, 10 July 2014 (UTC)

In adventurer mode i believe you can eat directly from the tree with e or use g to pick up the fruit form the tree. I dont think it's in fortress mode since he mentioned hes still working on harvesting.-stranger – [[template:unsigned|unsigned]] comment by [[User:72.38.18.124|72.38.18.124]] 13:09, 11 July 2014 (UTC)

== Cutting Trees in Fortress Mode ==

I'd like to put this bit of page for discussing and confirming... well, what's in the title.

Some things I've noticed so far:

* when cutting a tree at a trunk tile '''above''' the ground level ( = the lowest z-level the tree occupies), it's possible to produce some sort of a cave-in; presumably, the woodcutter chops the trunk that s/he's standing on.
** Can anyone replicate this behavior?
** Has anyone received any quasi-cave-ins by cutting trees at ground level? --[[User:StrikaAmaru|StrikaAmaru]] 15:25, 12 July 2014‎ (UTC)
:What do you mean by "cave in"? A message about something collapsing? I remember seeing something like that on the bug tracker. --[[User:Amena Ralikema|Amena Ralikema]] ([[User talk:Amena Ralikema|talk]]) 15:31, 12 July 2014 (UTC)
:: Yes, exactly like a cave-in; my woodcutter was happily chopping a branch, then I get the message, the game re-centers, and the dorf is on the ground, stunned but uninjured. Actually, when considering that cutting a branch cuts down the whole tree, a cave-in is exactly what happened: she was sitting on the tree, then the tree stopped existing. Cue one dropping dwarf. I'm inclined to think this is normal behavior, but still something that we need to take into account. BTW: the bug about cave-ins is probably about the completely unrelated, and definitely buggy, random "Something has collapsed on the surface!" messages that keep popping up with no rhyme or reason. --[[User:StrikaAmaru|StrikaAmaru]] 17:15, 13 July 2014‎ (UTC)
::* Yes, I've experienced something like that in the current version. Maybe not the exact same thing, but I think it's worth mentioning. Repro steps, 1. dig out the root under a tree. 2. chop down the tree. 3. watch one of the logs fall in a hole where the stump once was. It's already recorded on the bug tracker with a few related tree shenanigans, I took a look. It's id is {{bugl|8469}}: if you want to look it up [[User:ReturningUser|ReturningUser]] ([[User talk:ReturningUser|talk]]) 18:57, 10 February 2015 (UTC)
* Trees grow every year; a freshly-matured tree only extends 2 z-levels, and produces comparatively little wood (7 in my case). Still has fruit, even though it was a sapling when flowering season passed.--[[User:StrikaAmaru|StrikaAmaru]] 15:25, 12 July 2014‎ (UTC)
:As for the fruiting, I don't think pollination is implemented yet. :) Fruit just grows at a set time.--[[User:Amena Ralikema|Amena Ralikema]] ([[User talk:Amena Ralikema|talk]]) 15:31, 12 July 2014 (UTC)
::More interested in verifying tree growth across multiple years; the fruit thing was a minor quirk, seeing how fruits are useless now :( --[[User:StrikaAmaru|StrikaAmaru]] 17:20, 13 July 2014‎ (UTC)

== I need help reading the raws ==

I have a problem reading the raws: the new table format requires tiles for the different growths, but the characters I've extracted from the raws don't match what's displayed in the game, especially for flowers/growths. I think there may be different tiles for growths if they are on or off the tree. Any idea how to interpret the tags?--[[User:Amena Ralikema|Amena Ralikema]] ([[User talk:Amena Ralikema|talk]]) 08:21, 17 July 2014 (UTC)

== Explosive leaves and fruit ==

I've lost several dwarves in a freak Oak leaf shedding accident; some sort of bug makes tree-leaves and fruit about the same weight as a constructed wall-- with the same amount of impact force that it could cause from falling such a height.

An oak dispersed its leaves normally after autumn rolled around, but little did my passing stone hauler know what he was about to become.

The force of the falling oak-leaves shattered the dwarf's skull and sent his fingers, arms, a leg, and teeth flying in several directions. Each possessed the force of some carnal meteor that burrowed through the mess of wood and bone of the surrounding environment-- a tooth had even gone so far as to destroy a hovering, unwary Kea many z-levels above the intial impact. The dwarf's left arm struck and killed my only carpenter, going so far as to pulp both his head and upper-body-- his already dead corpse being sent off my drawbridge's unsealed walls and into the abyss. The other arm flew several feet away and into the canopy of another Oak tree as though an omen of things to come. The poor stone-pusher's fingers, somehow detached from the arms they once occupied by the velocity of the impact, simply fell to the ground beneath the squashed dwarf. None could find his missing left-leg; some believed it ended up somewhere inside the unfortunate dwarf's remaining body, others believe it transcended space and time with the sheer amount of speed it acquired from the initial earth-shattering oak leaf-fall.

It's not limited to fruit-baring trees you see. – [[template:unsigned|unsigned]] comment by [[User:184.166.69.80|184.166.69.80]]

== Forrests on world map ==
The old tree tiles are still used for world map forests containing that particular tree, so that information needs to be displayed somewhere. I don't know how to modify the table to do that. [[User:King Mir|King Mir]] ([[User talk:King Mir|talk]]) 20:01, 24 August 2014 (UTC)
:Already listed on [[map legend]]. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 20:13, 24 August 2014 (UTC)
::It's not really correct, or complete. Map forrests use the tile of the tree they contain, plus 3 special tiles. See here: http://www.bay12forums.com/smf/index.php?topic=137096.msg5481446#msg5481446. Ergo you need to list each tree's tile somewhere. I suppose that information could be put on that page instead of here. [[User:King Mir|King Mir]] ([[User talk:King Mir|talk]]) 20:32, 24 August 2014 (UTC)

== Destructive tree growth ==

Tree growth can deconstruct buildings. I had a small "indoor/light" area that I had bridged over for indoorish farming of above-ground crops, and refuse. A few tiles weren't buildings/stockpiles, and one ended up growing a sapling. Subsequently, I witnessed a spectacular explosion when the tree burst through the ceiling, deconstructing it and sending blocks and logs flying. I didn't get any alert or auto-pause of the sort you get when trees spontaneously collapse on the surface. Probably a fact worth noting in the page. This might also be related to why there are spontaneous collapses of trees—trees growing across portions of each other, and causing tree deconstruction? --[[User:Jaygengelbach|Jaygengelbach]] ([[User talk:Jaygengelbach|talk]]) 05:10, 4 September 2014 (UTC)

:Trees bursting through ceilings are a bug that was supposedly fixed. If it's still happening, it's not intended. Trees deconstructing things might not be. [[User:King Mir|King Mir]] ([[User talk:King Mir|talk]]) 05:25, 4 September 2014 (UTC)

== Time needed to harvest trees ==

Hi guys,
how long does it take for a sapling to grow into a full-grown tree that can be chopped down? I cannot find this information in the thread and think it would be interesting to add it!--[[User:Afghani84|Afghani84]] ([[User talk:Afghani84|talk]]) 15:01, 4 January 2015 (UTC)

== Trees supporting land ==

I'm not 100% certain how or if this is working, but I appear to have a section of surface being supported by trees. I have embarked on a heavily forested map and dug out a section of the map 1 z level down, then channeled out the surface area around it cleanly separating it from the supporting surface tiles. When I pulled the lever to yank out the support, it continued to dangle, apparently suspended by nothing. There are some trees still on the surface area, and I think their branches may be what is supporting my floating land. Is this a known issue or expected behavior? [[Special:Contributions/50.202.1.113|50.202.1.113]] 17:38, 10 July 2017 (UTC)

Update: I went ahead and cleared the trees still on the "floating" surface and when I yanked out the support this time everything collapsed as expected. Seems the branches were what was supporting the tiles. [[Special:Contributions/50.202.1.113|50.202.1.113]] 14:28, 11 July 2017 (UTC)

== Stuck Dwarfs ==
In the current release, I had a dwarf stuck in a tree (I think he chased a pet into it). It paused and re-centered on him, and he was over a vary small murky pool. Not knowing what else to do, I sent a woodcutter to cut it down. he fell in the pool, but was still conscious and unharmed from the fall, so he was able to pull himself out. It might be useful to note this possibility --[[Special:Contributions/50.103.112.214|50.103.112.214]] 08:28, 24 July 2017 (UTC).
:Added as a bug.--[[User:Loci|Loci]] ([[User talk:Loci|talk]]) 18:10, 28 July 2017 (UTC)

== Cut Trees Removing Ground Tiles ==
This bug seems pretty major to me, it seems like not much is made of it on the main page. A FB that has fire could potentially burn down a tree over a tunnel or room in your fort, thus opening it to fun. I noticed a FB had pathed into a closed-off portion of my fort(luckily it was a part made specifically for trapping cavern stuff). It also managed to path diagonally down a level through a natural floor and a smoothed wall(the tree that was cut was directly over a smoothed wall, with an open space next to it, and surrounded by natural floors. Definitely has the potential to be a fortress-ender.--[[User:Struck Down|Struck Down]] ([[User talk:Struck Down|talk]]) 07:34, 26 September 2017 (UTC)

:I included this info in the [[Tree#Chopping down trees|Chopping down trees]] section. You can edit/add more to it if you'd like. I can't visualize your second part very well, but if you're referring to creatures doing an impossible diagonal pathing between z-levels, I think that is related to {{bug|8383}}. – [[User:Doorkeeper|Doorkeeper]] 08:31, 26 September 2017 (UTC)

::The bug is related to the problem, but it doesn't go far enough. It seems that they can path through any floorless tile diagonally down to an open space. It makes sense that the reporter mentioned down stairs as they puncture the "floor" part of a tile. Constructed walls automatically put this floor layer in the level above them but for a smoothed wall, the floor is absent, leaving an empty space. I suspect that constructing a wall under a tree and doing this would leave a floor of the material the wall was made of instead of open space(will test when I can). For an illustration of the pathing:
:::X - Open space 
:::O - Wall 
:::F - Floor 

:::Z TOP: 
:::FFFF 
:::FXFF 
:::FFFF 

:::Z BOTTOM: 
:::OOFF 
:::OOFF 
:::OOFF 

::FB is able to path to the 3rd column from the left on Z bottom from the X on Z top. Under normal circumstances, the walls would form a floor, preventing passage. It seems once the floor is removed, the game treats it as any other diagonal movement(however impossible it would be to visualize a FB squeezing through a crack the size of a cat).--[[User:Struck Down|Struck Down]] ([[User talk:Struck Down|talk]]) 09:13, 26 September 2017 (UTC)

:::I see now. Constructing a wall under a tree and cutting it down will indeed leave a '+' floor tile above. So basically:

<diagram fg="0:1" bg="7:1">
Disallows Diagonal Movement
┌─ ─┐
│ │
Open space <──┤ ├──> Open Space
(where trunk was) │ │
│ │
└─ ─┘
Floor <──── ▓▓▓▓▓▓▓▓▓▓[#4:1][@0:1]↓[#@]▓▓▓▓▓▓▓▓▓▓▓ ────> Floor
┌─ ▒▒▒▒▒▒▒▒▒▒▒[#4:1]↓[#] ─┐
│ ▒▒▒▒▒▒▒▒▒▒▒ │
Natural Wall <──┤ ▒▒▒▒▒▒▒▒▒▒▒ ├──> Open Space
(or Constructed) │ ▒▒▒▒▒▒▒▒▒▒▒ │
│ ▒▒▒▒▒▒▒▒▒▒▒ │
└─ ▒▒▒▒▒▒▒▒▒▒▒ ─┘
Floor <──── ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ ────> Floor

Allows Diagonal Movement
┌─ ─┐
│ │
Open space <──┤ ├──> Open Space
(where trunk was) │ │
│ │
└─ ─┘
Open space <──── [#2:1]↓[#]▓▓▓▓▓▓▓▓▓▓▓ ────> Floor
┌─ ▒▒▒▒▒▒▒▒▒▒▒[#2:1]↓[#] ─┐
│ ▒▒▒▒▒▒▒▒▒▒▒ │
Smoothed Wall <──┤ ▒▒▒▒▒▒▒▒▒▒▒ ├──> Open Space
│ ▒▒▒▒▒▒▒▒▒▒▒ │
│ ▒▒▒▒▒▒▒▒▒▒▒ │
└─ ▒▒▒▒▒▒▒▒▒▒▒ ─┘
Floor <──── ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ ────> Floor
</diagram>

:::And any locomotion that allows omnidirectional movement, e.g. swimming, flying, and climbing, will allow creatures to move diagonally between the open space (floor) and open space (wall). I will add this to the page as well, but won't go too far in depth about it. This info is more associated with articles such as [[Smoothing]], [[Path]], [[Tile]], etc., and the in-depth explanations should go to there instead. Thanks for bringing this up. I am also going to post some of my additional findings in the bug report page, so check that out. – [[User:Doorkeeper|Doorkeeper]] 14:07, 26 September 2017 (UTC)

::::Excellent work! Your diagram is much nicer, and illustrates it exactly. I figured out this quirk many years ago after having a FB path through my main stairway which seemed sealed to me at the time. I suspect something like this is happening in many of the alleged "teleporting FB" bugs. The difference between smooth walls, and constructed walls was new for me though. At least, I assume this is an issue with smooth walls, because this issue doesn't show up on the surface level, even on revealed tiles. Soil and presumably rough rock would not produce empty space in the above situation. --[[User:Struck Down|Struck Down]] ([[User talk:Struck Down|talk]]) 21:31, 26 September 2017 (UTC)

:::::I never got around to post the findings to the bug report, but {{bug|8383}} has been fixed, so the impossible Z-axis movement part may be fixed. I'm not positive that the floorless smoothed wall was fixed too though, that's most likely a bug on its own. I have yet to confirm the results though, which I will be doing. – [[User:Doorkeeper|Doorkeeper]] 01:25, 30 March 2018 (UTC)

:::::Actually the floorless wall bug may have been fixed too; see {{bug|7127}}. Still need to verify – [[User:Doorkeeper|Doorkeeper]] 02:17, 30 March 2018 (UTC)

== Elven tree quota & subterranean mushroom trees ==

Subterranean mushroom trees still count towards Elven tree quotas, don't they? I'm confused because current wiki pages do not mention this, despite how some older wiki pages suggest as much. For that matter, why doesn't the [[Tree]] page at least mention elven tree quotas in passing?

For example, on [[23a:Elf]] it says, "Although [[Tower-cap|tower-caps]] are giant mushrooms, they are considered trees by the elves and thus are not acceptable." And the [[23a:Tree]] page has a whole section for [[23a:Tree#Elven%5FDiplomats|Elven Diplomats]] which at least mentions elven tree quotas.

Currently, the only mentions of elves on the Tree page is the [[DF2014:Tree#Fruit|Fruit]] sub-section, which says that elves bring fruit to trade, and the [[DF2014:Tree#Growing%5Ftrees|Growing trees]] sub-section, which bemoans that elves fail to understand how new saplings randomly regrow. The latter is a '''loosely implied reference''' to elven tree quotas without explaining it or even using the word "quota". Indeed, it '''seems out of place''' as an in-joke that belongs in a "D for Dwarf" humor sub-section.

Because tree harvesting and the attempted trade of wood products is so important to elf diplomacy, I find the lack of even a mention on this page to be a rather significant oversight. And I '''strongly''' recommend how subterranean mushrooms are counted as "trees" as far as elves are concerned should also be mentioned on the tree page. After all, the wiki is relied upon by new players as a source of information and the lack of this mention would likely lead some to assume otherwise. One might argue that such info only belongs on the [[Elf]] page. '''At the least''', this should be mentioned on the [[Elf]] page, if not both.

If nobody replies to this talk in 2 weeks time, I'll take that as nobody having an objection and as permission to add this info. [[User:Thundercraft|Thundercraft]] ([[User talk:Thundercraft|talk]]) 03:56, 28 August 2019 (UTC)

DF2014 Talk:Double-slit method

2016-05-22T08:43:08Z

Thundercraft: /* Lots of Missing Images! */ Issue only when logged-in or viewing "Printable version"

"The general method still works fine, however, constructing walls on a tile a pump is sucking from does not seem to work, any more (stuck at "nearly done", always "building site submerged").
Thus, on the final level you'll have to build that wall after relocating the pump. Don't forget to build it, though, or there just might be too much water to evaporate once you're finished.
Someone please do screenshots etc and so on and stuff."

I went through the double-slit method last night step by step as listed and experienced no problems with it. I don't know how constructing walls on a tile a pump is sucking from doesn't work - the constructing wall shouldn't be submerged if the pump is sucking water from it.

:Nagidal, author of the article writes: From this description I can't understand at which point exactly you could not proceed. Somebody already reports no problems with it, so maybe you try again following the tutorial more closely. I am currently busy with an ongoing non-aquifer fortress in 40.04, I will try to verify the double-slit method as soon as I'm done with it. I might as well rework it taking Panando's shortcut shown in the linked youtube video. --[[User:Nagidal|Nagidal]] ([[User talk:Nagidal|talk]]) 17:21, 27 July 2014 (UTC)

I've just tested this on a single-level aquifier, can confirm that there doesn't seem to be an issue. I'm going to remove the top bit, until someone else experiences problems. [[User:Hagger|Hagger]] ([[User talk:Hagger|talk]]) 16:36, 18 September 2014 (UTC)

OP here, just for the record, I just tried again in .23 with a two-level aquifer and it indeed does work. I'm also bloody sure that it *did't* work in an earlier version, but whatever. [[Special:Contributions/80.171.41.191|80.171.41.191]] 15:34, 8 January 2015 (UTC)

== Lots of Missing Images! ==

Back with v0.34, this was considered a ☼Masterwork☼ page. However, '''sadly''', about '''a third''' of the images in this tutorial are gone! I've looked through the page history. But '''all versions''' are missing the same images - going back to Nagidal's original page for v0.34. With so many images missing, it's difficult to near impossible to follow this tutorial. Is there any chance that someone can recover the missing images? (I sent Nagidal a PM about this via the forums. But he hasn't been on in the last 6 weeks.) Did the files get corrupted or misplaced somehow? Also, until this is fixed, should page quality be reduced to xTatteredx or +Fine+ ? --[[User:Thundercraft|Thundercraft]] ([[User talk:Thundercraft|talk]]) 10:44, 18 May 2016 (UTC)

:I don't see any missing images. It was likely a brief wiki software issue (the server that hosts the images acts up occasionally), which isn't a good reason to reduce a page's quality. —[[User:Lethosor|Lethosor]] ([[User talk:Lethosor|talk]]) 22:02, 19 May 2016 (UTC)

::If you '''still''' don't see any missing images, perhaps clearing your browser's cache would change that? Regardless, this is clearly not a minor or temporary issue as it persists for me and I'm not the only one reporting it. I did get a reply from Nagidal and he told me he'd try to re-upload the missing images. But, if this is a wiki software issue, perhaps it's due to how image-intensive this page is? I'm not aware of broken images on any other pages. Nor am I aware of another wiki page with this many images. And this is a tutorial. Perhaps breaking this tutorial into two or three parts (pages) would fix this? --[[User:Thundercraft|Thundercraft]] ([[User talk:Thundercraft|talk]]) 00:27, 22 May 2016 (UTC)

Getting the same issue as Thundercraft - I can see multiple missing images as well. Hopefully just an isolated issue, like Lethosor said. Specifically missing for me are the follow images (as per time of writing)
<pre>
Aq18.png
Aq20.png
Aq23.png
Aq24.png
Aq25.png
Aq26.png
Aq27.png
Aq29.png
Aq30.png
Aq31.png
Aq34.png
Aq41.png
Aq44.png
Aq56.png
Aq57.png
Aq58.png
Aq59.png
Aq61.png
Aq63.png
</pre>

(apologies for the formatting - really no good way to organize that list.)
--[[User:CalmBit|CalmBit]] ([[User talk:CalmBit|talk]]) 05:32, 21 May 2016 (UTC)

:I'm missing the same images as on your list. Except, I'm also missing Aq17.png. (Is it possible that you merely overlooked that one?) I question whether this could be merely a server issue. If it was, then why would visitors see the '''same''' images missing, instead of random ones? --[[User:Thundercraft|Thundercraft]] ([[User talk:Thundercraft|talk]]) 00:27, 22 May 2016 (UTC)

I have the same issue, but it occurs only when I am logged into my account. When I log out, all the images appear correctly. – [[User:Doorkeeper|Doorkeeper]] 02:45, 22 May 2016 (UTC)

:This is very weird. You're right: All the images '''will''' display correctly when I am logged out, while the images will '''not''' display when logged in. They also will '''not''' display when viewing the "Printable version" (accessible from the Toolbox on the left). So, I guess it is some sort of software issue. --[[User:Thundercraft|Thundercraft]] ([[User talk:Thundercraft|talk]]) 08:43, 22 May 2016 (UTC)

DF2014 Talk:Double-slit method

2016-05-22T00:27:14Z

Thundercraft: /* Lots of Missing Images! */ This problem persists and we're missing the same images

DF2014 Talk:Double-slit method

2016-05-18T10:44:43Z

Thundercraft: Lots of missing images makes tutorial difficult to follow. Reduce quality of page until fixed?

Dwarf Fortress Wiki talk:Spambot attacks

2013-12-11T10:14:27Z

Thundercraft: MoogleDan's suggest is valid. Why not at least consider this? At the least, it forces spammers to change tactics.

===One Possible Solution===

The spambots are really getting out of hand. Do we know if they're targeting us specifically? If not, it might help to put something like a nonce on the signup page: just a text box where it forces you to type "magma" to sign up or something else unique to this site to thwart bots. The spammers won't adapt their software to spam us unless it's worth the effort, and if they're just hunting down random wikis to spam, it's probably not worth their effort and they'll go away. [[User:Uristocrat|Uristocrat]] 04:09, 31 January 2011 (UTC)
: I've already added several things to help deter spambots, which has stemmed a large percentage (we're actually only seeing about .5% of the attacks make it to an actual account registration and post). I'll see about incorporating that as well here in the near future. --[[User:Briess|Briess]] 05:02, 31 January 2011 (UTC)
:: Good to know. I saw another thread about a different spam attack on this wiki when I was looking around and I sent a contact at Google's anti-spam division some ideas about how to combat wiki-spam like what happened here, given that it apparently made it into Google's index at one point. No clue if they'll do anything, but they did make an algorithm change recently, so you never know. And anything that kills their incentive for spamming us is good. I've heard good things about making your site unique (even via dead-simple tests, so long as too many people aren't using the exact same thing), so hopefully that helps get rid of that last 0.5%. I see that we're already using rel=nofollow and such, so best of luck combating the spambot menace. [[User:Uristocrat|Uristocrat]] 05:26, 31 January 2011 (UTC)
: I mentioned several possible solutions here: [[Dwarf_Fortress_Wiki_talk:Spamreport]], but nobody seemed to notice. Even though ''actual'' SPAM has been practically eliminated, all this SPAM and (Deletion log) / (Block log) ''really'' clutters up the Recent changes list. In addition, have you considered restricting new members (those that seem to pass the spambot tests) so that they must make at least a few content edits before they (automatically) get permission to start a new page? --[[User:Thundercraft|Thundercraft]] 07:14, 9 February 2011 (UTC)
::You're right about the clutter. I read your suggestions and while the general ideas are good, one problem is that we want our solutions to be as unique as possible. So it's not just a matter of using a new captcha or something, it's a matter of using a technique *not* used (or solvable) by the same means as those on every other site. The idea is that, if everyone is using the same few anti-spam plugins/captchas/whatever, they'll take the time to make a program (or trick people into) bypassing them. But the more unique we can make our signup pages and such, the less likely they'll be able to do anything on this one site (because we're not big enough for them to bother with). Right now, I've traced the spam to see that they mostly target MediaWikis. I think we'd get a lot of mileage out of changing even trivial things, like the id fields on the forms (input id="wpSave" name="wpSave" type="submit"). Even a rename of a few fields on, say, the sign up page might confuse them enough to make signups fail more often. Parsing HTML is a pain in the rear and if we have nice, *unique* stuff, we'll make it not worth their time to change their code just to spam one small wiki, when they have zillions of others that they can attack. [[User:Uristocrat|Uristocrat]] 08:32, 9 February 2011 (UTC)
:::We have considered the whole new page thing, I told Briess to do it, I'm not sure if he actually set it up or not. Also, like he said above, only about 0.5% of the registration attempts have been successful. There've been around 17000 attempts, and around 100 have made it through. We're not going to do much better than that unfortunately. Hopefully they give up attacking us once they realize its not doing them any good. [[user:Emi|Emi]] [[user_talk:Emi|[T]]] 08:46, 9 February 2011 (UTC)
::::Well, one problem is that they'll probably never realize it's not doing them any good, unless perhaps the whole system of theirs is undermined. My real point, though, was to focus on simple, unique ways of making the site different, rather than adding complex solutions like a new captcha module that a lot of sites might use. The more people that do that, the more work we create for the spambot's owner. [[User:Uristocrat|Uristocrat]] 19:16, 9 February 2011 (UTC)
:::::Just make a trickier question. Like "The most famous dwarf name in Dwarf Fortress", or best metal for swords etc. I've seen websites use these slightly trickier questions, and they seem to be very effective. Not everyone is interested in registering on the wiki anyway so I don't think we'll have that many people asking "What's the answer to the question? =(((". OH and btw, are you guys able to edit the HTML of this website at all, considering it's not your web host? --[[User:Qvazzler|- qvazzler]] 09:59, 22 July 2012 (UTC)
:::: However, AdaSPOILERS is some minor spoilers, so how about What is the solution? A: Magma --[[User:Spy227X|Spy227X]] 15:43, 9 March 2013 (UTC)

===Anything we can do?===

I'm watching some spambots attack right now and you guys don't appear to be online to banish them at the moment. I've blanked out the spam I could find and replaced it with the deletion template. I also marked the two user pages for the confirmed spammers with the same template. I don't really know if that helps or not, but is there anything we normal users can do to help kick these spammers out? [[User:Uristocrat|Uristocrat]] 07:12, 7 February 2011 (UTC)
:What you are doing is extremely helpful (marking them, marking pages for deletion, etc.) Remember that we're only seeing less than .5% of the spam attacks attempted against the wiki, we're working on solutions to kick out the last few successful attacks (we are under rather heavy attack at the moment.) --[[User:Briess|Briess]] 12:39, 7 February 2011 (UTC)
::I assume you want us to use the AIV page that I now see in announcements as a place to report this stuff? Also, I traced the spam from here to a bunch of other MediaWiki/Drupal sites. They're building an entire web of spam links across random pages as a sort of blackhat SEO trick. Most of the links in their spam pages point to compromised Wikis and such; you can follow them via that. I can't trace this by hand any more. There are too many dead wikis out there and only maybe one in ten or twenty appears to be fighting back. A quick check of "recent changes" on most of them shows that all recent edits are spam. As near as I can tell, the attacks started around 27 JAN 2011, but I only looked at a few sites, so maybe I didn't go far enough back. If you can, check the logs to see if there are any suspicious search queries; that might tell us how they found us. Anyhow, I'll keep tagging them if I find them. [[User:Uristocrat|Uristocrat]] 20:42, 7 February 2011 (UTC)
:::Yeah listing accounts to be blocked/deleted on AIV is the idea. Still mark pages with <nowiki>{{del|spam}}</nowiki> though. [[user:Emi|Emi]] [[user_talk:Emi|[T]]] 00:13, 8 February 2011 (UTC)
::::I'm seeing lots of users joining (probably spambots), but I'm not seeing more spam pages. That's good. Except for the fact that they're still trying to break in, I guess you have it under control now? [[User:Uristocrat|Uristocrat]] 10:52, 8 February 2011 (UTC)

== IP bans ==

Can you ban IP addresses, instead of waiting for the accounts to be made? Or are they too random, or shared with actual users? --[[User:DeMatt|DeMatt]] 03:28, 9 February 2011 (UTC)
:When we block the accounts, we've been also disabling account creation on the IPs associated with the account. They've just got a ton of IPs. [[user:Emi|Emi]] [[user_talk:Emi|[T]]] 03:41, 9 February 2011 (UTC)

== A fellow victim ==

I hope you do not regard this as spam but I run a wiki at www dot livingcontrol dot com slash wiki and we have just seen an increase in spambot attacks. I hope you do not mind if I join in here to help find ways to defeat them. [[Special:Contributions/2.102.214.196|2.102.214.196]] 09:38, 6 December 2011 (UTC)

Hey, I'm an admin from the Dungeon Crawl: Stone Soup wiki. Last year we were getting hammered with nearly a hundred spam accounts and posts a day, and eventually we just turned off account registration to the public entirely. Now, to get an account, they simply send the admins an email and we make the account for 'em. It's much less work than constantly deleting spam and blocking accounts, and we haven't seen a single instance of the stuff since. You could even remove the obnoxious CAPTCHA images entirely. Just a suggestion... --[[User:MoogleDan|MoogleDan]] 16:40, 23 July 2012 (UTC)

Good, but it kind of makes signing up inconvenient. Let's say 100 people want an account. Can the admins go through all that in a day? --[[User:Spy227X|Spy227X]] 15:45, 9 March 2013 (UTC)

I seriously doubt that MagmaWiki gets 100 '''legitimate''' new accounts registered in a month. There are not very many actual wiki contributors. Right now, looking at the [[Recent changes]] page, I see '''hundreds''' of new accounts registered '''per day'''! That's a new account every few minutes. I'm sure about 99.9% are either Spambots or people wanting to spread Spam. It's '''already''' a hassle and nuisance, I'm sure. And it sucks up bandwidth. I've participated on forums where registration involves sending an email to an administrator or moderator with the requirement that the request ''include a short message'' with the reason '''why''' they want to join. From what I've heard, this stops Spam and Spambots cold. Don't worry: You will '''not''' get hundreds of hand-written email requests to register because that's too much of a hassle for spammers. Apparently, they just leave in favor of finding easier targets. MoogleDan's suggest is valid. It is a proven technique. So why not try something like this? You can always revert back to the old system if it's unsatisfactory. If nothing else, changing things will force the spammers to change their tactics. And if it takes a week or two for a moderator to get around to approving a registration, so what? Explain this to people with a warning that approval may take some time and they'll understand. If not, I suspect they probably would not have contributed anything. --[[User:Thundercraft|Thundercraft]] ([[User talk:Thundercraft|talk]]) 10:14, 11 December 2013 (UTC)

v0.34 Talk:Megaprojects

2013-12-11T09:48:07Z

Thundercraft: Impossible suggestions are utterly impossible to achieve: I suggest deleting them to clean up page

== Impossible Suggestions ==

I propose that the Megaprojects page needs a bit of cleaning up. Specifically, at least a few of these suggestions are '''physically impossible''' to achieve.

Examples:

[[DF2012:Megaprojects#Make_a_Water-Powered_Robot|Make a Water-Powered Robot]] (#55) is an absolutely impossible pipe dream. Granted, there are a few mods that feature "golems" and similar. However, no mod or game hack (not even DFHack) can make it possible to build a quote, "pump-based perpetual motion machine and can move" via wheels. Nor can a '''mobile''' "robot" or golem suck up magma and shoot it out. DF is not coded for anything like this. It does not even have wheels, aside from the [[water wheel]]. So this suggestion is at least as impossible as the "land mobile aircraft carrier" fictional concept it evokes!

Similarly, the [[DF2012:Megaprojects#UtopiaSort|UtopiaSort]] (#56) suggestion is either entirely impossible or - at the very least - impossible without coding very complicated scripts for DFHack. Even if it can be done with DFHack, it would rely almost entirely on said complicated scripts to do all the sorting for the player. And while that might be an impressive achievement in DFHack coding and hacking, it would '''not''' be an impressive '''player''' achievement. (Instead of building a sophisticated [[DF2012:Computing|dwarfputer]] to do this, all the player would have to do is activate said scripts.) As such, I do not believe it fits on this page.

Right now, I'm thinking of deleting these two entries.
Thoughts? --[[User:Thundercraft|Thundercraft]] ([[User talk:Thundercraft|talk]]) 09:48, 11 December 2013 (UTC)

v0.34:Maximizing framerate

2013-02-07T05:16:54Z

Thundercraft: Edit of caverns on FPS; mostly differentiates parameters & recommends open expanses instead of mazes

{{quality|Fine|02:47, 21 May 2012 (UTC)}}
{{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 Dwarf Fortress, 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 active keeps your game running fast. The below lists 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 and init_d files that don't actually change how the game plays out.

====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 4x4 squares to 3x3 or even 2x2 will have an enormous impact on FPS. Keep in mind that a 2x2 embark is only 25% of the size of a 4x4.
** World size probably doesn't matter except for the size of the save files, but reducing the number of cavern layers (default of 3) will help. You need at least 1 cavern layer to get underground [[crop|plants]], and 2 caverns to get all the underground [[tree]]s.
* 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.
** Bugs related to [[clothing]] used to make it a real FPS drain. Recent bug fixes, such as {{bug|3942}}, have improved the situation drastically. But checking for clothing [[wear]] and unhappy [[thoughts]] could still have some impact on FPS. (Research is needed.) As of [[Release information/0.34.11|0.34.11]], 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.
** Evidence has emerged that the ''quantity'' of items may not be the actual culprit, but rather the [[hauling]], [[stockpiles]], [[pathfinding]] and other CPU-intensive tasks they involve. Specifically, 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]. These seem to demonstrate very FPS efficient solutions, while avoiding traditional stockpiles and the use of [[barrels]] and [[bins]].
* 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 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.
* 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.
** Changing the normal traffic weight to 1 in d_init.txt will optimize the pathfinder at the cost of High traffic zones not making a difference ([http://www.bay12forums.com/smf/index.php?topic=97763.msg2841109#msg2841109 source])
* 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.
** Closing off unused areas with raised [[bridge]]s and locked [[door]]s can help.
** Caverns are probably the worst offender for pathfinding in irrelevant areas. So keep them closed off.
* [[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. The [[User:Uristocrat/Dwarven_Bathtub|Dwarven Bathtub]] is one example. And make sure you have the [[cleaning]] labor enabled. 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.

====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.
*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 off gives the CPU one less thing 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====
* Consider running an older version of DF. While lacking features, 40d or a [[version]] of v0.31 ''may'' run faster than 2012. *Disputed* (See [http://www.bay12forums.com/smf/index.php?topic=122441.0 this topic] for a debate over FPS on 2012 vs v0.31, game settings, and other FPS issues.)
* [[Temperature]] and [[Weather]] are two more features which users may or may not notice.
** Disabling them, using the settings in d_init.txt, ''might'' speed things up.
** But then rain won't refill [[murky pool]]s, [[magma]] won't melt [[goblin]]s, etc.
** Disabling temperature also results in obsidian farms being unusable; as they never cool down, dwarves refuse to step on the obsidian floor, preventing the access of hauling dwarves.{{bug|6033}}
** One user [http://www.bay12forums.com/smf/index.php?topic=86761.msg2352509#msg2352509 reported] an FPS boost from 35 to 90 upon disabling temperature. (User note: Confirmed, went from 15 FPS to 70 FPS)
* Each dwarf needs to keep track of where he's going.
** Limit the number of dwarves by setting the population cap.
* 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.
* Invaders also need to pathfind.
** Turn off invasions using the option in [[D_init.txt]]. Or you can kill them all.
* [[Caverns]] can be a FPS hog due to [[pathfinding]] and how complex they can be. Creatures may try to path into your fort from a cavern. Sometimes even [[DF2012:Trading#Caravans|trading caravans]] will try to path to your fort underground.
** Adjusting the [[DF2012:Advanced_world_generation#Cavern_Layer_Number|Cavern_Layer_Number]] in [[advanced world generation]] parameters can reduce or disable the number [[cavern]] layers during [[world generation]]. However, this may restrict access to subterranean plants and creatures, [[DF2012:Megabeast|megabeasts]], and [[Demonic_fortress|fun features]].
** 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 turn caverns into wide, open expanses instead of complex mazes that have to be pathed through.

====Mods and Utilities====
* Accumulations of [[contaminant]]s can decrease FPS and they are still 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 make lack the patience to deal with it that way. So some opt to [[Cheating|cheat]] by using the "clean" and "spotclean" commands in the [[Utility:DFHack|DFhack]] utility.
* Recent bug fixes for [[clothing]] (such as {{bug|3942}}) have largely resolved related FPS issues. But checking for clothing [[wear]] and unhappy [[thoughts]] may still have some impact on FPS. (Research is needed.)
** One could [[Modding_guide|modify]] clothing to prevent [[wear]]. (This would require a [[DF2012:World_generation|world regen]].) 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.

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

{{Category|Guides}}

v0.34:Maximizing framerate

2013-02-07T04:48:14Z

Thundercraft: Added Cavern Parameters & advanced world generation as it pertains to pathfinding & FPS; also, minor edits

{{quality|Fine|02:47, 21 May 2012 (UTC)}}
{{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 Dwarf Fortress, 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 active keeps your game running fast. The below lists 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 and init_d files that don't actually change how the game plays out.

====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 4x4 squares to 3x3 or even 2x2 will have an enormous impact on FPS. Keep in mind that a 2x2 embark is only 25% of the size of a 4x4.
** World size probably doesn't matter except for the size of the save files, but reducing the number of cavern layers (default of 3) will help. You need at least 1 cavern layer to get underground [[crop|plants]], and 2 caverns to get all the underground [[tree]]s.
* 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.
** Bugs related to [[clothing]] used to make it a real FPS drain. Recent bug fixes, such as {{bug|3942}}, have improved the situation drastically. But checking for clothing [[wear]] and unhappy [[thoughts]] could still have some impact on FPS. (Research is needed.) As of [[Release information/0.34.11|0.34.11]], 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.
** Evidence has emerged that the ''quantity'' of items may not be the actual culprit, but rather the [[hauling]], [[stockpiles]], [[pathfinding]] and other CPU-intensive tasks they involve. Specifically, 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]. These seem to demonstrate very FPS efficient solutions, while avoiding traditional stockpiles and the use of [[barrels]] and [[bins]].
* 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 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.
* 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.
** Changing the normal traffic weight to 1 in d_init.txt will optimize the pathfinder at the cost of High traffic zones not making a difference ([http://www.bay12forums.com/smf/index.php?topic=97763.msg2841109#msg2841109 source])
* 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.
** Closing off unused areas with raised [[bridge]]s and locked [[door]]s can help.
** Caverns are probably the worst offender for pathfinding in irrelevant areas. So keep them closed off.
* [[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. The [[User:Uristocrat/Dwarven_Bathtub|Dwarven Bathtub]] is one example. And make sure you have the [[cleaning]] labor enabled. 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.

====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.
*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 off gives the CPU one less thing 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====
* Consider running an older version of DF. While lacking features, 40d or a [[version]] of v0.31 ''may'' run faster than 2012. *Disputed* (See [http://www.bay12forums.com/smf/index.php?topic=122441.0 this topic] for a debate over FPS on 2012 vs v0.31, game settings, and other FPS issues.)
* [[Temperature]] and [[Weather]] are two more features which users may or may not notice.
** Disabling them, using the settings in d_init.txt, ''might'' speed things up.
** But then rain won't refill [[murky pool]]s, [[magma]] won't melt [[goblin]]s, etc.
** Disabling temperature also results in obsidian farms being unusable; as they never cool down, dwarves refuse to step on the obsidian floor, preventing the access of hauling dwarves.{{bug|6033}}
** One user [http://www.bay12forums.com/smf/index.php?topic=86761.msg2352509#msg2352509 reported] an FPS boost from 35 to 90 upon disabling temperature. (User note: Confirmed, went from 15 FPS to 70 FPS)
* Each dwarf needs to keep track of where he's going.
** Limit the number of dwarves by setting the population cap.
* 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.
* Invaders also need to pathfind.
** Turn off invasions using the option in [[D_init.txt]]. Or you can kill them all.
* [[Caverns]] can be a FPS hog due to [[pathfinding]] and how complex they can be. Creatures may try to path into your fort from a cavern. Sometimes even [[DF2012:Trading#Caravans|trading caravans]] will try to path to your fort underground.
** One could use [[DF2012:Advanced_world_generation#Cavern_Parameters|advanced world generation]] parameters to reduce or disable [[cavern]] layers during [[world generation]]. However, doing so may restrict access to subterranean plants and creatures, [[DF2012:Megabeast|megabeasts]], and other [[Demonic_fortress|fun features]].

====Mods and Utilities====
* Accumulations of [[contaminant]]s can decrease FPS and they are still 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 make lack the patience to deal with it that way. So some opt to [[Cheating|cheat]] by using the "clean" and "spotclean" commands in the [[Utility:DFHack|DFhack]] utility.
* Recent bug fixes for [[clothing]] (such as {{bug|3942}}) have largely resolved related FPS issues. But checking for clothing [[wear]] and unhappy [[thoughts]] may still have some impact on FPS. (Research is needed.)
** One could [[Modding_guide|modify]] clothing to prevent [[wear]]. (This would require a [[DF2012:World_generation|world regen]].) 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.

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

{{Category|Guides}}

v0.34:Maximizing framerate

2013-02-07T04:09:58Z

Thundercraft: fixed link to 0.34.11

{{quality|Fine|02:47, 21 May 2012 (UTC)}}
{{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 Dwarf Fortress, 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 active keeps your game running fast. The below lists 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 and init_d files that don't actually change how the game plays out.

====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 4x4 squares to 3x3 or even 2x2 will have an enormous impact on FPS. Keep in mind that a 2x2 embark is only 25% of the size of a 4x4.
** World size probably doesn't matter except for the size of the save files, but reducing the number of cavern layers (default of 3) will help. You need at least 1 cavern layer to get underground [[crop|plants]], and 2 caverns to get all the underground [[tree]]s.
* 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.
** Bugs related to [[clothing]] used to make it a real FPS drain. Recent bug fixes, such as {{bug|3942}}, have improved the situation drastically. But checking for clothing [[wear]] and unhappy [[thoughts]] could still have some impact on FPS. (Research is needed.) As of [[Release information/0.34.11|0.34.11]], 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.
** Evidence has emerged that the ''quantity'' of items may not be the actual culprit, but rather the [[hauling]], [[stockpiles]], [[pathfinding]] and other CPU-intensive tasks they involve. Specifically, 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]. These seem to demonstrate very FPS efficient solutions, while avoiding traditional stockpiles and the use of [[barrels]] and [[bins]].
* 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 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.
* 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.
** Changing the normal traffic weight to 1 in d_init.txt will optimize the pathfinder at the cost of High traffic zones not making a difference ([http://www.bay12forums.com/smf/index.php?topic=97763.msg2841109#msg2841109 source])
* 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.
** Closing off unused areas with raised [[bridge]]s and locked [[door]]s can help.
** Caverns are probably the worst offender for pathfinding in irrelevant areas. So keep them closed off.
* [[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. The [[User:Uristocrat/Dwarven_Bathtub|Dwarven Bathtub]] is one example. And make sure you have the [[cleaning]] labor enabled. 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.

====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.
*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 off gives the CPU one less thing 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====
*Consider running an older version of DF. 40d should run better than 2010 or 2012, and 23a, while severely lacking, should be significantly faster. *Disputed*
* [[Temperature]] and [[Weather]] are two more features which users may or may not notice.
** Disabling them, using the settings in d_init.txt, can speed things up.
** But then rain won't refill [[murky pool]]s, [[magma]] won't melt [[goblin]]s, etc.
** Disabling temperature also results in obsidian farms being unusable; as they never cool down, dwarves refuse to step on the obsidian floor, preventing the access of hauling dwarves.{{bug|6033}}
** One user [http://www.bay12forums.com/smf/index.php?topic=86761.msg2352509#msg2352509 reported] an FPS boost from 35 to 90 upon disabling temperature. (User note: Confirmed, went from 15 FPS to 70 FPS)
* Each dwarf needs to keep track of where he's going.
** Limit the number of dwarves by setting the population cap.
* 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.
* Invaders also need to pathfind.
** Turn off invasions using the option in [[D_init.txt]]. Or you can kill them all.

====Mods and Utilities====
* Accumulations of [[contaminant]]s can decrease FPS and they are still 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 make lack the patience to deal with it that way. So some opt to [[Cheating|cheat]] by using the "clean" and "spotclean" commands in the [[Utility:DFHack|DFhack]] utility.
* Recent bug fixes for [[clothing]] (such as {{bug|3942}}) have largely resolved related FPS issues. But checking for clothing [[wear]] and unhappy [[thoughts]] may still have some impact on FPS. (Research is needed.)
** One could [[Modding_guide|modify]] clothing to prevent [[wear]]. (This would require a [[DF2012:World_generation|world regen]].) 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.

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

{{Category|Guides}}

v0.34:Maximizing framerate

2013-02-07T04:06:55Z

Thundercraft: Mentioned clothing & wear under 'fewer items' as a possible FPS culprit & some suggestions; also, minor edits

{{quality|Fine|02:47, 21 May 2012 (UTC)}}
{{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 Dwarf Fortress, 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 active keeps your game running fast. The below lists 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 and init_d files that don't actually change how the game plays out.

====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 4x4 squares to 3x3 or even 2x2 will have an enormous impact on FPS. Keep in mind that a 2x2 embark is only 25% of the size of a 4x4.
** World size probably doesn't matter except for the size of the save files, but reducing the number of cavern layers (default of 3) will help. You need at least 1 cavern layer to get underground [[crop|plants]], and 2 caverns to get all the underground [[tree]]s.
* 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.
** Bugs related to [[clothing]] used to make it a real FPS drain. Recent bug fixes, such as {{bug|3942}}, have improved the situation drastically. But checking for clothing [[wear]] and unhappy [[thoughts]] could still have some impact on FPS. (Research is needed.) As of [[0.34.11#Other_bug_fixes.2Ftweaks|0.34.11]], 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.
** Evidence has emerged that the ''quantity'' of items may not be the actual culprit, but rather the [[hauling]], [[stockpiles]], [[pathfinding]] and other CPU-intensive tasks they involve. Specifically, 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]. These seem to demonstrate very FPS efficient solutions, while avoiding traditional stockpiles and the use of [[barrels]] and [[bins]].
* 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 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.
* 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.
** Changing the normal traffic weight to 1 in d_init.txt will optimize the pathfinder at the cost of High traffic zones not making a difference ([http://www.bay12forums.com/smf/index.php?topic=97763.msg2841109#msg2841109 source])
* 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.
** Closing off unused areas with raised [[bridge]]s and locked [[door]]s can help.
** Caverns are probably the worst offender for pathfinding in irrelevant areas. So keep them closed off.
* [[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. The [[User:Uristocrat/Dwarven_Bathtub|Dwarven Bathtub]] is one example. And make sure you have the [[cleaning]] labor enabled. 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.

====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.
*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 off gives the CPU one less thing 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====
*Consider running an older version of DF. 40d should run better than 2010 or 2012, and 23a, while severely lacking, should be significantly faster. *Disputed*
* [[Temperature]] and [[Weather]] are two more features which users may or may not notice.
** Disabling them, using the settings in d_init.txt, can speed things up.
** But then rain won't refill [[murky pool]]s, [[magma]] won't melt [[goblin]]s, etc.
** Disabling temperature also results in obsidian farms being unusable; as they never cool down, dwarves refuse to step on the obsidian floor, preventing the access of hauling dwarves.{{bug|6033}}
** One user [http://www.bay12forums.com/smf/index.php?topic=86761.msg2352509#msg2352509 reported] an FPS boost from 35 to 90 upon disabling temperature. (User note: Confirmed, went from 15 FPS to 70 FPS)
* Each dwarf needs to keep track of where he's going.
** Limit the number of dwarves by setting the population cap.
* 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.
* Invaders also need to pathfind.
** Turn off invasions using the option in [[D_init.txt]]. Or you can kill them all.

====Mods and Utilities====
* Accumulations of [[contaminant]]s can decrease FPS and they are still 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 make lack the patience to deal with it that way. So some opt to [[Cheating|cheat]] by using the "clean" and "spotclean" commands in the [[Utility:DFHack|DFhack]] utility.
* Recent bug fixes for [[clothing]] (such as {{bug|3942}}) have largely resolved related FPS issues. But checking for clothing [[wear]] and unhappy [[thoughts]] may still have some impact on FPS. (Research is needed.)
** One could [[Modding_guide|modify]] clothing to prevent [[wear]]. (This would require a [[DF2012:World_generation|world regen]].) 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.

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

{{Category|Guides}}

v0.34:Maximizing framerate

2013-02-07T03:48:50Z

Thundercraft: Update on clothing bug status & relevance; removed suggestion on disabling clothing (see Discussion)

{{quality|Fine|02:47, 21 May 2012 (UTC)}}
{{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 Dwarf Fortress, 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 active keeps your game running fast. The below lists 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 and init_d files that don't actually change how the game plays out.

====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 4x4 squares to 3x3 or even 2x2 will have an enormous impact on FPS. Keep in mind that a 2x2 embark is only 25% of the size of a 4x4.
** World size probably doesn't matter except for the size of the save files, but reducing the number of cavern layers (default of 3) will help. You need at least 1 cavern layer to get underground [[crop|plants]], and 2 caverns to get all the underground [[tree]]s.
* 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 [[workshops]] constantly queued or set on perpetual repeat.
** 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.
** Evidence has emerged that the ''quantity'' of items may not be the actual culprit, but rather the [[hauling]], [[stockpiles]], [[pathfinding]] and other CPU-intensive tasks they involve. Specifically, 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]. These seem to demonstrate very FPS efficient solutions, while avoiding traditional stockpiles and the use of barrels and bins.
* 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 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.
* 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.
** Changing the normal traffic weight to 1 in d_init.txt will optimize the pathfinder at the cost of High traffic zones not making a difference ([http://www.bay12forums.com/smf/index.php?topic=97763.msg2841109#msg2841109 source])
* 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.
** Closing off unused areas with raised [[bridge]]s and locked [[door]]s can help.
** Caverns are probably the worst offender for pathfinding in irrelevant areas. So keep them closed off with bridges and locked doors.
* [[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. The "[[Dwarven_Bathtub|Dwarven Bathtub]]" is one example. And make sure you have the [[cleaning]] labor enabled. 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.

====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.
*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 off gives the CPU one less thing 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====
*Consider running an older version of DF. 40d should run better than 2010 or 2012, and 23a, while severely lacking, should be significantly faster. *Disputed*
* [[Temperature]] and [[Weather]] are two more features which users may or may not notice.
** Disabling them, using the settings in d_init.txt, can speed things up.
** But then rain won't refill [[murky pool]]s, [[magma]] won't melt [[goblin]]s, etc.
** Disabling temperature also results in obsidian farms being unusable; as they never cool down, dwarves refuse to step on the obsidian floor, preventing the access of hauling dwarves.{{bug|6033}}
** One user [http://www.bay12forums.com/smf/index.php?topic=86761.msg2352509#msg2352509 reported] an FPS boost from 35 to 90 upon disabling temperature. (User note: Confirmed, went from 15 FPS to 70 FPS)
* Each dwarf needs to keep track of where he's going.
** Limit the number of dwarves by setting the population cap.
* 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.
* Invaders also need to pathfind.
** Turn off invasions using the option in [[D_init.txt]]. Or you can kill them all.

====Mods and Utilities====
* Accumulations of [[contaminant]]s can decrease FPS and they are still 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 make lack the patience to deal with it that way. So some opt to [[Cheating|cheat]] by using the "clean" and "spotclean" commands in the [[Utility:DFHack|DFhack]] utility.
* Recent bug fixes for [[clothing]] (such as {{bug|3942}}) have largely resolved related FPS issues. But checking for clothing [[wear]] and unhappy [[thoughts]] may still have some impact on FPS. (Research is needed.)
** One could [[Modding_guide|modify]] clothing to prevent [[wear]]. (This would require a [[DF2012:World_generation|world regen]].) 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.

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

{{Category|Guides}}

v0.34 Talk:Maximizing framerate

2013-02-07T03:40:21Z

Thundercraft: The 'disable your dwarven civ from wearing clothing' suggestion is no longer relevant; details on why

== Contaminants ==
I removed the following tips for now. My reasoning being that contaminant spreading is currently off by default. When this is turned back on by default (after the bugs are fixed I'd assume), please add these back in. For now they can do little more than confuse players. [[User:Calite|Calite]] 23:31, 22 May 2012 (UTC)

----
* Contaminants, including [[blood]] spatters, accumulate on the ground and on dwarves and creatures. When they walk over contaminants, these sometimes get smeared and spread. There is a bug ({{bug|296}}) which makes contaminants continuously multiply and another bug ({{bug|3270}}) which prevents blood spatters from ever disappearing.
** There is a setting in D_init.txt (as of {{version|0.31.16}}) that prevents them spreading from dwarf (or animal) to ground. For [[v0.31:Fortress_mode|Fortress Mode]], this is [[v0.31:Technical_tricks#More_Game_Options|WALKING_SPREADS_SPATTER_DWF]] and is already turned off by default.
** If the contaminants are outside, isolate the area and let [[v0.31:Weather|rain]] slowly wash it away. Pets can be kept out with a [[Activity_zone#Pen.2FPasture|pen/pasture]] or a [[v0.31: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. The "Dwarven Bathtub" is one example. And make sure you have the [[cleaning]] labor enabled. Details of these and other suggestions can be found on the [[cleaning]] page.
** Finding the above cleaning measures too tedious or lacking, some players opt to [[v0.31:Cheating|cheat]] by using the [[v0.31:Utilities#dfcleanmap|dfcleanmap]] tool from the [[v0.31:Utilities#DFHack|DFhack]] library.
----

: I strongly disagree with your assessment that this information has no value now and does "little more than confuse players." The [[DF2012:Technical_tricks#More_Game_Options|WALKING_SPREADS_SPATTER_DWF]] option may be off by default. But this does not change the fact that large amounts of contaminants on a map has a noticeable impact on FPS. Cleaning contaminants or removing them with DFHack '''proves''' this. For that matter, the bugs I mentioned which multiplies contaminants uncontrollably and does not allow blood to evaporate away (like it's supposed to) remain unresolved, meaning this info is as valid for v0.34 as it was for v0.31. Improving FPS is the whole point of this topic. As such, players should still be able to learn about the effect contaminants can have on FPS '''and''' find suggestions on how to deal with it.

: Relocating or editing content is fine. But I expected a discussion in Talk '''before''' removing large sections like this if the removal could be controversial. Considerable time and research was put into it and the removal ''discourages'' me from further participation. I am updating this info to be more relevant and reinserting. --[[User:Thundercraft|Thundercraft]] 13:10, 6 February 2013 (UTC)

== Disabling Clothing as a Mod ==

I will remove ''part'' of the following as it is not relevant to recent versions. My reasoning: 1) All clothing bugs are fixed now. Many of these, including {{bug|3942}}, were resolved a while ago. 2) Unlike previous versions, dwarves '''will''' get unhappy [[thoughts]] for going naked. 3) No details or suggestions are offered on how to mod a game to disable clothing. 4) There are much better solutions and I've added them.

However, the suggestion of dumping excess/worn clothing may still be useful. As this fits in [[Maximizing_framerate#Fortress_Design|Fortress Design]] and not [[Maximizing_framerate#Fortress_Design|Mods and Utilities]], I will move it. --[[User:Thundercraft|Thundercraft]] 03:40, 7 February 2013 (UTC)
----
* Disabling your dwarven civ from wearing [[clothing]] as a mod (would require a [[DF2012:World_generation|world regen]]) may help maintain higher FPS later in the game{{bug|3942}}, if you don't mind naked dwarves running around. Alternatively, dumping excess/worn out clothing might help restore FPS on an existing fortress.

v0.34:Maximizing framerate

2013-02-06T16:41:44Z

Thundercraft: Clarified and expanded tips on reduced area for pathfinding

{{quality|Fine|02:47, 21 May 2012 (UTC)}}
{{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 Dwarf Fortress, 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 active keeps your game running fast. The below lists 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 and init_d files that don't actually change how the game plays out.

====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 4x4 squares to 3x3 or even 2x2 will have an enormous impact on FPS. Keep in mind that a 2x2 embark is only 25% of the size of a 4x4.
** World size probably doesn't matter except for the size of the save files, but reducing the number of cavern layers (default of 3) will help. You need at least 1 cavern layer to get underground [[crop|plants]], and 2 caverns to get all the underground [[tree]]s.
* 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 [[workshops]] constantly queued or set on perpetual repeat.
** 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.
** Evidence has emerged that the ''quantity'' of items may not be the actual culprit, but rather the [[hauling]], [[stockpiles]], [[pathfinding]] and other CPU-intensive tasks they involve. Specifically, 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]. These seem to demonstrate very FPS efficient solutions, while avoiding traditional stockpiles and the use of barrels and bins.
* 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 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.
* 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.
** Changing the normal traffic weight to 1 in d_init.txt will optimize the pathfinder at the cost of High traffic zones not making a difference ([http://www.bay12forums.com/smf/index.php?topic=97763.msg2841109#msg2841109 source])
* 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.
** Closing off unused areas with raised [[bridge]]s and locked [[door]]s can help.
** Caverns are probably the worst offender for pathfinding in irrelevant areas. So keep them closed off with bridges and locked doors.
* [[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. The "[[Dwarven_Bathtub|Dwarven Bathtub]]" is one example. And make sure you have the [[cleaning]] labor enabled. 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.

====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.
*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 off gives the CPU one less thing 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====
*Consider running an older version of DF. 40d should run better than 2010 or 2012, and 23a, while severely lacking, should be significantly faster. *Disputed*
* [[Temperature]] and [[Weather]] are two more features which users may or may not notice.
** Disabling them, using the settings in d_init.txt, can speed things up.
** But then rain won't refill [[murky pool]]s, [[magma]] won't melt [[goblin]]s, etc.
** Disabling temperature also results in obsidian farms being unusable; as they never cool down, dwarves refuse to step on the obsidian floor, preventing the access of hauling dwarves.{{bug|6033}}
** One user [http://www.bay12forums.com/smf/index.php?topic=86761.msg2352509#msg2352509 reported] an FPS boost from 35 to 90 upon disabling temperature. (User note: Confirmed, went from 15 FPS to 70 FPS)
* Each dwarf needs to keep track of where he's going.
** Limit the number of dwarves by setting the population cap.
* 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.
* Invaders also need to pathfind.
** Turn off invasions using the option in [[D_init.txt]]. Or you can kill them all.

====Mods and Utilities====
* Accumulations of [[contaminant]]s can decrease FPS and they are still 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 make lack the patience to deal with it that way. So some opt to [[Cheating|cheat]] by using the "clean" and "spotclean" commands in the [[Utility:DFHack|DFhack]] utility.
* Disabling your dwarven civ from wearing clothing as a mod (would require a [[World generation|world regen]]) may help maintain higher FPS later in the game{{bug|3942}}, if you don't mind naked dwarves running around. Alternatively, finding a way to dump excess/worn out clothing might help restore FPS on an existing fortress. Requires research.
** Alternatively, one could modify clothing to prevent decay. This can be done by adding an [[Armor token|ARMORLEVEL:1 token]]. Aside from maintaining FPS, this has other benefits as well. This is one of many fixes found in the [[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" for more.) Also, [[List of mods#Masterwork Dwarf Fortress (MDF)|Masterwork Dwarf Fortress]] allows the creation of metal clothing.

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

{{Category|Guides}}

v0.34:Maximizing framerate

2013-02-06T16:22:00Z

Thundercraft: Evidence that the FPS of items is due to hauling, stockpiles, & pathfinding & what can be done about it

{{quality|Fine|02:47, 21 May 2012 (UTC)}}
{{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 Dwarf Fortress, 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 active keeps your game running fast. The below lists 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 and init_d files that don't actually change how the game plays out.

====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 4x4 squares to 3x3 or even 2x2 will have an enormous impact on FPS. Keep in mind that a 2x2 embark is only 25% of the size of a 4x4.
** World size probably doesn't matter except for the size of the save files, but reducing the number of cavern layers (default of 3) will help. You need at least 1 cavern layer to get underground [[crop|plants]], and 2 caverns to get all the underground [[tree]]s.
* 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 [[workshops]] constantly queued or set on perpetual repeat.
** 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.
** Evidence has emerged that the ''quantity'' of items may not be the actual culprit, but rather the [[hauling]], [[stockpiles]], [[pathfinding]] and other CPU-intensive tasks they involve. Specifically, 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]. These seem to demonstrate very FPS efficient solutions, while avoiding traditional stockpiles and the use of barrels and bins.
* 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 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.
* 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.
** Changing the normal traffic weight to 1 in d_init.txt will optimize the pathfinder at the cost of High traffic zones not making a difference ([http://www.bay12forums.com/smf/index.php?topic=97763.msg2841109#msg2841109 source])
* Closing off unused areas with raised [[bridge]]s and locked [[door]]s can help.
** Reducing the area which the pathfinder algorithm has to search lets it run faster.
** In general the pathfinder algorithm is good about not searching irrelevant areas. Caverns are probably the worst offender.
* [[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. The "[[Dwarven_Bathtub|Dwarven Bathtub]]" is one example. And make sure you have the [[cleaning]] labor enabled. 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.

====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.
*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 off gives the CPU one less thing 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====
*Consider running an older version of DF. 40d should run better than 2010 or 2012, and 23a, while severely lacking, should be significantly faster. *Disputed*
* [[Temperature]] and [[Weather]] are two more features which users may or may not notice.
** Disabling them, using the settings in d_init.txt, can speed things up.
** But then rain won't refill [[murky pool]]s, [[magma]] won't melt [[goblin]]s, etc.
** Disabling temperature also results in obsidian farms being unusable; as they never cool down, dwarves refuse to step on the obsidian floor, preventing the access of hauling dwarves.{{bug|6033}}
** One user [http://www.bay12forums.com/smf/index.php?topic=86761.msg2352509#msg2352509 reported] an FPS boost from 35 to 90 upon disabling temperature. (User note: Confirmed, went from 15 FPS to 70 FPS)
* Each dwarf needs to keep track of where he's going.
** Limit the number of dwarves by setting the population cap.
* 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.
* Invaders also need to pathfind.
** Turn off invasions using the option in [[D_init.txt]]. Or you can kill them all.

====Mods and Utilities====
* Accumulations of [[contaminant]]s can decrease FPS and they are still 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 make lack the patience to deal with it that way. So some opt to [[Cheating|cheat]] by using the "clean" and "spotclean" commands in the [[Utility:DFHack|DFhack]] utility.
* Disabling your dwarven civ from wearing clothing as a mod (would require a [[World generation|world regen]]) may help maintain higher FPS later in the game{{bug|3942}}, if you don't mind naked dwarves running around. Alternatively, finding a way to dump excess/worn out clothing might help restore FPS on an existing fortress. Requires research.
** Alternatively, one could modify clothing to prevent decay. This can be done by adding an [[Armor token|ARMORLEVEL:1 token]]. Aside from maintaining FPS, this has other benefits as well. This is one of many fixes found in the [[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" for more.) Also, [[List of mods#Masterwork Dwarf Fortress (MDF)|Masterwork Dwarf Fortress]] allows the creation of metal clothing.

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

{{Category|Guides}}

v0.34:Maximizing framerate

2013-02-06T16:02:07Z

Thundercraft: Added Contaminants: Why they affect FPS and simple measures to deal with it

{{quality|Fine|02:47, 21 May 2012 (UTC)}}
{{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 Dwarf Fortress, 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 active keeps your game running fast. The below lists 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 and init_d files that don't actually change how the game plays out.

====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 4x4 squares to 3x3 or even 2x2 will have an enormous impact on FPS. Keep in mind that a 2x2 embark is only 25% of the size of a 4x4.
** World size probably doesn't matter except for the size of the save files, but reducing the number of cavern layers (default of 3) will help. You need at least 1 cavern layer to get underground [[crop|plants]], and 2 caverns to get all the underground [[tree]]s.
* Fewer items inside a fort means fewer items to be [[stockpile]]d, checked for [[wear]], and so on and so forth.
** 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.
** Don't dig out so much of the ground, don't build such large [[Farming|farm plot]]s, just don't generate so many items in the first place.
* 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 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.
* 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.
** Changing the normal traffic weight to 1 in d_init.txt will optimize the pathfinder at the cost of High traffic zones not making a difference ([http://www.bay12forums.com/smf/index.php?topic=97763.msg2841109#msg2841109 source])
* Closing off unused areas with raised [[bridge]]s and locked [[door]]s can help.
** Reducing the area which the pathfinder algorithm has to search lets it run faster.
** In general the pathfinder algorithm is good about not searching irrelevant areas. Caverns are probably the worst offender.
* [[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. The "[[Dwarven_Bathtub|Dwarven Bathtub]]" is one example. And make sure you have the [[cleaning]] labor enabled. 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.

====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.
*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 off gives the CPU one less thing 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====
*Consider running an older version of DF. 40d should run better than 2010 or 2012, and 23a, while severely lacking, should be significantly faster. *Disputed*
* [[Temperature]] and [[Weather]] are two more features which users may or may not notice.
** Disabling them, using the settings in d_init.txt, can speed things up.
** But then rain won't refill [[murky pool]]s, [[magma]] won't melt [[goblin]]s, etc.
** Disabling temperature also results in obsidian farms being unusable; as they never cool down, dwarves refuse to step on the obsidian floor, preventing the access of hauling dwarves.{{bug|6033}}
** One user [http://www.bay12forums.com/smf/index.php?topic=86761.msg2352509#msg2352509 reported] an FPS boost from 35 to 90 upon disabling temperature. (User note: Confirmed, went from 15 FPS to 70 FPS)
* Each dwarf needs to keep track of where he's going.
** Limit the number of dwarves by setting the population cap.
* 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.
* Invaders also need to pathfind.
** Turn off invasions using the option in [[D_init.txt]]. Or you can kill them all.

====Mods and Utilities====
* Accumulations of [[contaminant]]s can decrease FPS and they are still 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 make lack the patience to deal with it that way. So some opt to [[Cheating|cheat]] by using the "clean" and "spotclean" commands in the [[Utility:DFHack|DFhack]] utility.
* Disabling your dwarven civ from wearing clothing as a mod (would require a [[World generation|world regen]]) may help maintain higher FPS later in the game{{bug|3942}}, if you don't mind naked dwarves running around. Alternatively, finding a way to dump excess/worn out clothing might help restore FPS on an existing fortress. Requires research.
** Alternatively, one could modify clothing to prevent decay. This can be done by adding an [[Armor token|ARMORLEVEL:1 token]]. Aside from maintaining FPS, this has other benefits as well. This is one of many fixes found in the [[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" for more.) Also, [[List of mods#Masterwork Dwarf Fortress (MDF)|Masterwork Dwarf Fortress]] allows the creation of metal clothing.

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

{{Category|Guides}}

v0.34:Maximizing framerate

2013-02-06T15:33:43Z

Thundercraft: DFHack can remove contaminants & an ARMORLEVEL:1 token can prevent clothing decay

{{quality|Fine|02:47, 21 May 2012 (UTC)}}
{{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 Dwarf Fortress, 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 active keeps your game running fast. The below lists 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 and init_d files that don't actually change how the game plays out.

====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 4x4 squares to 3x3 or even 2x2 will have an enormous impact on FPS. Keep in mind that a 2x2 embark is only 25% of the size of a 4x4.
** World size probably doesn't matter except for the size of the save files, but reducing the number of cavern layers (default of 3) will help. You need at least 1 cavern layer to get underground [[crop|plants]], and 2 caverns to get all the underground [[tree]]s.
* Fewer items inside a fort means fewer items to be [[stockpile]]d, checked for [[wear]], and so on and so forth.
** 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.
** Don't dig out so much of the ground, don't build such large [[Farming|farm plot]]s, just don't generate so many items in the first place.
* 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 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.
* 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.
** Changing the normal traffic weight to 1 in d_init.txt will optimize the pathfinder at the cost of High traffic zones not making a difference ([http://www.bay12forums.com/smf/index.php?topic=97763.msg2841109#msg2841109 source])
* Closing off unused areas with raised [[bridge]]s and locked [[door]]s can help.
** Reducing the area which the pathfinder algorithm has to search lets it run faster.
** In general the pathfinder algorithm is good about not searching irrelevant areas. Caverns are probably the worst offender.
* 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.

====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.
*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 off gives the CPU one less thing 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====
*Consider running an older version of DF. 40d should run better than 2010 or 2012, and 23a, while severely lacking, should be significantly faster. *Disputed*
* [[Temperature]] and [[Weather]] are two more features which users may or may not notice.
** Disabling them, using the settings in d_init.txt, can speed things up.
** But then rain won't refill [[murky pool]]s, [[magma]] won't melt [[goblin]]s, etc.
** Disabling temperature also results in obsidian farms being unusable; as they never cool down, dwarves refuse to step on the obsidian floor, preventing the access of hauling dwarves.{{bug|6033}}
** One user [http://www.bay12forums.com/smf/index.php?topic=86761.msg2352509#msg2352509 reported] an FPS boost from 35 to 90 upon disabling temperature. (User note: Confirmed, went from 15 FPS to 70 FPS)
* Each dwarf needs to keep track of where he's going.
** Limit the number of dwarves by setting the population cap.
* 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.
* Invaders also need to pathfind.
** Turn off invasions using the option in [[D_init.txt]]. Or you can kill them all.

====Mods and Utilities====
* Accumulations of [[DF2012:Contaminant|contaminants]] can decrease FPS and they are still buggy in [[DF2012:Release_information|DF2012]]. (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 make lack the patience to deal with it that way. So some opt to [[DF2012:Cheating|cheat]] by using the "clean" and "spotclean" commands in the [[Utility:DFHack|DFhack]] utility.
* Disabling your dwarven civ from wearing clothing as a mod (would require a [[DF2012:World_generation|world regen]]) may help maintain higher FPS later in the game{{bug|3942}}, if you don't mind naked dwarves running around. Alternatively, finding a way to dump excess/worn out clothing might help restore FPS on an existing fortress. Requires research.
** Alternatively, one could modify clothing to prevent decay. This can be done by adding an [[DF2012:Armor_token|ARMORLEVEL:1 token]]. Aside from maintaining FPS, this has other benefits as well. This is one of many fixes found in 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" for more.) Also, [[DF2012:List_of_mods#Masterwork_Dwarf_Fortress_.28MDF.29|Masterwork Dwarf Fortress]] allows the creation of metal clothing.

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

{{Category|Guides}}

v0.34:List of mods

2013-02-06T14:22:07Z

Thundercraft: Added Modest Mod

{{av}}
{{mod}}

==[http://www.bay12forums.com/smf/index.php?topic=28829.0 Community Mod List]==

==[http://www.bay12forums.com/smf/index.php?topic=105871.0 Modest Mod]==
'''''Current version: 2.1 ''''' for '''''DF Version 0.34.11''''' 

'''Description:'''

Author: Igfig 
Type: Modpack 
Summary: The Modest Mod is a collection of vital bugfixes and tweaks that everyone should be able to use comfortably and without reservation. This mod doesn't add anything new. It doesn't do anything controversial. It's just like vanilla DF, but a little better. French vanilla.

See forum thread for the list of changes. 

Support is provided for Phoebus, Ironhand and ASCII tilesets. (Be sure to install Modest Mod '''after''' the graphics pack.) 

[http://dffd.wimbli.com/file.php?id=6028 Download (ASCII-compatible)] 
[http://dffd.wimbli.com/file.php?id=6843 Download (Phoebus-compatible)] 
[http://dffd.wimbli.com/file.php?id=6844 Download (Ironhand-compatible)] 
[http://www.bay12forums.com/smf/index.php?topic=105871.0 Forum thread]

==[http://www.bay12forums.com/smf/index.php?topic=84186.0 Legends of Forlorn Realms (LFR)]==
'''''Current version: 0.19b ''''' for '''''DF Version 0.34.11''''' 
'''''Legacy version: 0.15a ''''' for '''''DF Version 0.31.25+'''''

'''Description:'''

Author: [http://www.bay12forums.com/smf/index.php?action=profile;u=32622 narhiril] 
Type: Major 
Summary: A major modification that aims to set itself apart from the other major expansion mods out there. LFR includes dozens of new creatures (EVERY ONE with custom graphics), new metals and minerals, an obscene number of new weapons and armor types, and some very unique civilizations, each with their own distinctive flavor and style. LFR contains extensive lore files, an incredibly detailed manual to help you navigate the new features, and two multi-tiered, interlocking technology trees to advance your civilization in the ways of innovation and spirituality. Rife with new features to discover and a huge amount of hidden content, LFR is rewarding for both casual players and those looking for more of a challenge. 

LFR offers support for both Ironhand and ASCII tilesets, and is fully compatible with Fortress Defense II, for those desiring even more chaos. 

[http://dffd.wimbli.com/file.php?id=4242 Download] 
[http://dffd.wimbli.com/file.php?id=5529 Legacy download] 
[http://www.bay12forums.com/smf/index.php?topic=84186.0 Forum thread]

==[http://www.bay12forums.com/smf/index.php?topic=98196.645 Masterwork Dwarf Fortress (MDF)]==
'''''Current version: 2a ''''' for '''''DF Version 0.34.11''''' 

'''Description:'''

Author: Meph 
Type: Modpack 
Summary: A massive modpack containing the best of the greatest mods, as well as fully configurable settings, with +100 options, as well as a wealth of new content, including: +45 buildings, +850 creatures, +160 plants, +120 trees, +25 instruments, +85 toys, +85 food types, +75 weapons and armor, +75 engravings, +250 pref-strings, +30 civs, and more! 

Masterwork provides texture pack support for Phoebus, Ironhand and ASCII tilesets, and has a fully integrated Fortress Defense II, as well as configurable creature settings. 

[http://dffd.wimbli.com/file.php?id=5315 Download] 
[http://www.bay12forums.com/smf/index.php?topic=98196.0 Forum thread]

==[http://dffd.wimbli.com/file.php?id=4101 Corrosion]==

'''Description:'''

Author: IT 000 
Type: Total Conversion 
Summary: A Total Conversion featuring hundreds of changes. Face hordes of Infected in a barren, and decimated world in an attempt to create a flourishing fort. 
Forum Post:[http://www.bay12forums.com/smf/index.php?topic=81068.0 Corrosion]

==[http://www.bay12forums.com/smf/index.php?topic=97516.0: vilous Mod]==
'''''Current version: [http://www.bay12forums.com/smf/index.php?topic=97516.0]''''' for '''''DF Version 0.31.25'''''

'''Description:'''

Author: Skie, Chronojiuj, Vellarain, Darklord92 
Type: Major 
Summary:The land of the beast men is on the march! Vilous comes alive in your dwarf fortress worlds! With four new races based on the Vilous novella by Trancy Mick. Set many years after the collapse of the Silvorain empire, the northern Sergals have become a slightly more docile race soon with this lasting peace the other races of Vilous took there time to expand and evolve from simple races into full civilizations. The southern Sergals no longer enslaved and oppressed by the Northerns escaped back to there deserts and began to rebuilt on a farming and trading culture based around religion. The Nevreans a technological race of avians far more advanced than most of the other creatures that inhabit Vilous, with firearms and stronger armor to make up for there physical downfalls ( armor soon to come ). The Talyxians a cat like race born for the trees agile and fast, and unlike the Elves there happy with cutting down and using the forest, much to there Elf neighbors dismay. Lastly the Agudners, an ancient race lost to a cataclysm, the last survivors cling to survival spreading out in what small numbers are left, not much is know about them or there technology.

adds: 
-sergal race 
-Nevrean race 
-Talyxian race 
-agundner race 
-13 new weapons, including guns 
-14 new armors cloths and hats 
-1 new plant 
-3 new workshops 
-1 new megabeast 

all of which come in packs that can be included or left out for different configurations of the mod.

v0.34 Talk:Maximizing framerate

2013-02-06T13:10:01Z

Thundercraft: Explanation why the section on Contaminants and the effect they can have on FPS is still relevant

=Contaminants=
I removed the following tips for now. My reasoning being that contaminant spreading is currently off by default. When this is turned back on by default (after the bugs are fixed I'd assume), please add these back in. For now they can do little more than confuse players. [[User:Calite|Calite]] 23:31, 22 May 2012 (UTC)

----
* Contaminants, including [[blood]] spatters, accumulate on the ground and on dwarves and creatures. When they walk over contaminants, these sometimes get smeared and spread. There is a bug ({{bug|296}}) which makes contaminants continuously multiply and another bug ({{bug|3270}}) which prevents blood spatters from ever disappearing.
** There is a setting in D_init.txt (as of {{version|0.31.16}}) that prevents them spreading from dwarf (or animal) to ground. For [[v0.31:Fortress_mode|Fortress Mode]], this is [[v0.31:Technical_tricks#More_Game_Options|WALKING_SPREADS_SPATTER_DWF]] and is already turned off by default.
** If the contaminants are outside, isolate the area and let [[v0.31:Weather|rain]] slowly wash it away. Pets can be kept out with a [[Activity_zone#Pen.2FPasture|pen/pasture]] or a [[v0.31: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. The "Dwarven Bathtub" is one example. And make sure you have the [[cleaning]] labor enabled. Details of these and other suggestions can be found on the [[cleaning]] page.
** Finding the above cleaning measures too tedious or lacking, some players opt to [[v0.31:Cheating|cheat]] by using the [[v0.31:Utilities#dfcleanmap|dfcleanmap]] tool from the [[v0.31:Utilities#DFHack|DFhack]] library.
----

: I strongly disagree with your assessment that this information has no value now and does "little more than confuse players." The [[DF2012:Technical_tricks#More_Game_Options|WALKING_SPREADS_SPATTER_DWF]] option may be off by default. But this does not change the fact that large amounts of contaminants on a map has a noticeable impact on FPS. Cleaning contaminants or removing them with DFHack '''proves''' this. For that matter, the bugs I mentioned which multiplies contaminants uncontrollably and does not allow blood to evaporate away (like it's supposed to) remain unresolved, meaning this info is as valid for v0.34 as it was for v0.31. Improving FPS is the whole point of this topic. As such, players should still be able to learn about the effect contaminants can have on FPS '''and''' find suggestions on how to deal with it.

: Relocating or editing content is fine. But I would expect a discussion in Talk '''before''' removing large sections like this, especially if the removal could be controversial. Considerable time and research was put into it and this removal ''discourages'' me from further wiki participation. I am updating this info to be more relevant and reinserting. --[[User:Thundercraft|Thundercraft]] 13:10, 6 February 2013 (UTC)

v0.31:Magma kiln

2011-07-19T01:03:17Z

Thundercraft: Updating the Materials Used list with more clay types, Ash, & Cassiterite

{{quality|Exceptional|20:58, 11 August 2010 (UTC)}}
{{Furnace|name=Magma kiln|key=n|job={{L|Furnace operator}}
|construction=
* {{L|Fire-safe}} material
|construction_job=
* {{L|Architecture}}
* {{L|Masonry}} or {{L|Metalsmithing}}
|use=
* {{L|Potash}}
* {{L|Gypsum}}
* {{L|Alabaster}}
* {{L|Selenite}}
* {{L|Satinspar}}
* {{L|Kaolinite}}
* {{L|Clay}}
* {{L|Silty clay}}
* {{L|Sandy clay}}
* {{L|Clay loam}}
* {{L|Fire clay}}
* {{L|Ash}}
* {{L|Cassiterite}}
|production=
* {{L|Earthenware}} {{L|Block|Brick}}
* {{L|Stoneware}} {{L|Block|Brick}}
* {{L|Porcelain}} {{L|Block|Brick}}
* {{L|Jug}}
* {{L|Large_pot|Large Pot}}
* {{L|Statue}}
* {{L|Trade_good#Crafts|Crafts}}
* {{L|Glaze}}d clay/stone items
* {{L|Ash|Pearlash}}
* {{L|Plaster powder}}
}}
{{av}}

A '''magma kiln''' behaves the same as a {{L|kiln}}, differing only by the fact that it uses the heat from {{L|magma}} instead of requiring {{L|fuel}}. Like all magma furnaces, it must be built out of magma-safe materials, and one of the edge tiles must be directly above a tile of magma at least 4 deep. It is recommended to place the kiln such that the impassable tile at the top is directly over the magma channel so that dwarves cannot accidentally fall into the magma.

As with other magma workshops, magma kilns will not be available for construction until you have discovered magma in your region.

{{Workshops}}

v0.31:Kiln

2011-07-19T01:02:03Z

Thundercraft: Updating the Materials Used list

{{Quality|Exceptional}}{{Furnace|name=Kiln|key=k|job={{L|Furnace operator}}
|construction=
* {{L|Fire-safe}} material
|construction_job=
* {{L|Architecture}}
* {{L|Masonry}} or {{L|Metalsmithing}}
|use=
* {{L|Coke}} or {{L|Charcoal}} ({{L|Fuel}})
* {{L|Potash}}
* {{L|Gypsum}}
* {{L|Alabaster}}
* {{L|Selenite}}
* {{L|Satinspar}}
* {{L|Kaolinite}}
* {{L|Clay}}
* {{L|Silty clay}}
* {{L|Sandy clay}}
* {{L|Clay loam}}
* {{L|Fire clay}}
* {{L|Ash}}
* {{L|Cassiterite}}
|production=
* {{L|Earthenware}} {{L|Block|Brick}}
* {{L|Stoneware}} {{L|Block|Brick}}
* {{L|Porcelain}} {{L|Block|Brick}}
* {{L|Jug}}
* {{L|Large_pot|Large pot}}
* {{L|Statue}}
* {{L|Trade_good#Crafts|Crafts}}
* {{L|Glaze}}d clay/stone items
* {{L|Ash|Pearlash}}
* {{L|Plaster powder}}
}}{{av}}

A '''kiln''' is a specific type of {{L|furnace}}, and the cornerstone of the {{L|ceramic industry}}. At a kiln, the order to collect clay from {{L|activity zone#Clay_Collection|clay collection zones}} is given. All of the clay/porcelain items (such as bricks, jugs, large pots, statues, and crafts) are made here. {{L|ash|Pearlash}} (for clear and crystal glass) from {{L|potash}} and {{L|plaster powder}} from {{L|gypsum}}, {{L|alabaster}}, {{L|selenite}} or {{L|satinspar}} are also made here. {{L|Fuel}} is required and the {{L|Furnace operator}} skill is used for pearlash and plaster production. All ceramic products require fuel and the clay (under crafting) job enabled. For plaster powder production, an empty {{L|bag}} is required.

{{L|Glaze|Glazing}} of {{L|earthenware}} also happens here, requiring either {{L|ash}} or {{L|cassiterite}}.

Building a kiln requires a dwarf with the {{L|Building designer|architecture}} {{L|labor}} enabled, after which construction will be completed by a {{L|mason}} or {{L|metalsmith}}, depending on the material used.

{{Workshops}}

v0.31:Magma kiln

2011-07-19T00:54:32Z

Thundercraft: Updating the Materials Used, which only mentioned Potash, & the Goods Created list, which only mentioned Pearlash

{{quality|Exceptional|20:58, 11 August 2010 (UTC)}}
{{Furnace|name=Magma kiln|key=n|job={{L|Furnace operator}}
|construction=
* {{L|Fire-safe}} material
|construction_job=
* {{L|Architecture}}
* {{L|Masonry}} or {{L|Metalsmithing}}
|use=
* {{L|Potash}}
* {{L|Gypsum}}
* {{L|Alabaster}}
* {{L|Selenite}}
* {{L|Satinspar}}
* {{L|Kaolinite}}
* {{L|Clay}}
|production=
* {{L|Earthenware}} {{L|Block|Brick}}
* {{L|Stoneware}} {{L|Block|Brick}}
* {{L|Porcelain}} {{L|Block|Brick}}
* {{L|Jug}}
* {{L|Large_pot|Large Pot}}
* {{L|Statue}}
* {{L|Trade_good#Crafts|Crafts}}
* {{L|Glaze}}d clay/stone items
* {{L|Ash|Pearlash}}
* {{L|Plaster powder}}
}}
{{av}}

A '''magma kiln''' behaves the same as a {{L|kiln}}, differing only by the fact that it uses the heat from {{L|magma}} instead of requiring {{L|fuel}}. Like all magma furnaces, it must be built out of magma-safe materials, and one of the edge tiles must be directly above a tile of magma at least 4 deep. It is recommended to place the kiln such that the impassable tile at the top is directly over the magma channel so that dwarves cannot accidentally fall into the magma.

As with other magma workshops, magma kilns will not be available for construction until you have discovered magma in your region.

{{Workshops}}

v0.31:Kiln

2011-07-19T00:49:44Z

Thundercraft: Updated the Goods Created list, which only mentioned Pearlash & Plaster powder

{{Quality|Exceptional}}{{Furnace|name=Kiln|key=k|job={{L|Furnace operator}}
|construction=
* {{L|Fire-safe}} material
|construction_job=
* {{L|Architecture}}
* {{L|Masonry}} or {{L|Metalsmithing}}
|use=
* {{L|Coke}} or {{L|Charcoal}} ({{L|Fuel}})
* {{L|Potash}}
* {{L|Gypsum}}
* {{L|Alabaster}}
* {{L|Selenite}}
* {{L|Satinspar}}
* {{L|Kaolinite}}
* {{L|Clay}}
|production=
* {{L|Earthenware}} {{L|Block|Brick}}
* {{L|Stoneware}} {{L|Block|Brick}}
* {{L|Porcelain}} {{L|Block|Brick}}
* {{L|Jug}}
* {{L|Large_pot|Large Pot}}
* {{L|Statue}}
* {{L|Trade_good#Crafts|Crafts}}
* {{L|Glaze}}d clay/stone items
* {{L|Ash|Pearlash}}
* {{L|Plaster powder}}
}}{{av}}

A '''kiln''' is a specific type of {{L|furnace}}, and the cornerstone of the {{L|ceramic industry}}. At a kiln, the order to collect clay from {{L|activity zone#Clay_Collection|clay collection zones}} is given. All of the clay/porcelain items (such as bricks, jugs, large pots, statues, and crafts) are made here. {{L|ash|Pearlash}} (for clear and crystal glass) from {{L|potash}} and {{L|plaster powder}} from {{L|gypsum}}, {{L|alabaster}}, {{L|selenite}} or {{L|satinspar}} are also made here. {{L|Fuel}} is required and the {{L|Furnace operator}} skill is used for pearlash and plaster production. All ceramic products require fuel and the clay (under crafting) job enabled. For plaster powder production, an empty {{L|bag}} is required.

{{L|Glaze|Glazing}} of {{L|earthenware}} also happens here, requiring either {{L|ash}} or {{L|cassiterite}}.

Building a kiln requires a dwarf with the {{L|Building designer|architecture}} {{L|labor}} enabled, after which construction will be completed by a {{L|mason}} or {{L|metalsmith}}, depending on the material used.

{{Workshops}}

v0.31:Ceramic industry

2011-07-19T00:39:31Z

Thundercraft: Updating links for jugs, large pots, & crafts

{{quality|Fine|18:07, 16 March 2011 (UTC)}}{{av}}

The '''Ceramic industry''' is a source of items such as {{L|jug}}s, {{L|Large_pot|large pots}}, {{L|block|bricks}} (clay {{L|block}}s), {{L|statue}}s, {{L|Trade_good#Crafts|crafts}}, and {{L|hive|beehives}}. Three types of {{L|ceramic}}s can be produced - {{L|earthenware}}, {{L|stoneware}}, and {{L|porcelain}}.

==Varieties of Ceramics==

*Producing earthenware requires a lump of {{L|clay}}, {{L|silty clay}}, {{L|sandy clay}}, or {{L|clay loam}}. Earthenware items are {{L|value|worth}} 3 times as much as objects made from most {{L|stone}}, making it equivalent to {{L|obsidian}}. In order to store liquids in earthenware containers, they must first be {{L|glaze}}d.
*Producing stoneware requires a lump of {{L|fire clay}}. Stoneware items are worth 4 times as much as items made from most stones, and they can safely store liquids without having to be glazed.
*Producing porcelain requires a chunk of {{L|kaolinite}}. Porcelain items are worth ten times as much as objects made from most stones, making it equivalent in value to metals like {{L|silver}}.

==Producing Ceramics==

To make items from clay, the clay must first be gathered using a task available at any {{L|kiln}}, "Collect Clay". You must designate a {{L|activity zone|Clay Collection zone}} from the ({{k|i}})-menu that includes an accessible area of clay in order for this task to succeed.

Once you have a lump of clay, you can order earthenware or stoneware goods to be created at the kiln; porcelain goods can be made once you mine out some kaolinite. A standard {{L|kiln}} will consume one unit of {{L|fuel}} per job; a {{L|magma kiln}} uses no fuel. Note that the kiln does '''not''' allow you to select which type of ceramic to produce - your potter will take the closest available material, whether it be ordinary clay, fire clay, or kaolinite.

==Collecting clay==

The "Collect Clay" order at the kiln requires the "{{L|hauling#Item hauling|item hauling}}" labor, not pottery or furnace operating. The Collect Clay order does, however, still occupy the kiln, preventing potters from working in it until it has been completed. Collecting clay is also a time consuming task, and potters quickly become faster at making items then at gathering materials to the point that jobs are cancelled as clay becomes scarce.

Unlike the {{L|glass industry}}, collecting clay does not require any sort of container, so all you need to do is have several kilns set to "Collect Clay" on repeat (preferably with 10 instances of the task so the {{L|manager}} will not use them for work orders) - any available dwarves will simply walk to the clay collection zone, work for a while, then haul the lump of clay to a stone {{L|stockpile}} (or leave it lying on the floor if there's no room).

{{Category|Industry}}

v0.31:Jug

2011-07-18T04:54:19Z

Thundercraft:

{{quality|Fine|03:21, 18 April 2011 (UTC)}}{{av}}

'''Jugs''' are a type of {{L|container}}, made from {{L|ceramic}} at a {{L|kiln}}, from {{L|glass}} at a {{L|glass furnace}}, from stone by a {{L|stone crafter}} at a {{L|craftsdwarf's workshop}}, or [[DF2010_Talk:Jug#Wooden_Jugs.3F.3F|from wood]] at a {{L|craftsdwarf's workshop}}. They are used in {{l|Beekeeping industry|beekeeping}} to store royal jelly or at a {{L|screw press}} to store honey or rock nut oil. Jugs made from earthenware need to be {{L|glaze}}d before they can be used to hold liquids like honey. Jugs are stored in the {{L|tool|Tools}} section of the Finished Goods stockpile, and managed from the '''tools''' section of the Stocks screen.

Jugs are stored in bins. Jugs with royal jelly / honey can be stored in two stockpiles:
* Finished goods / tools (stored as JUGS)
* food / extract animal / honey, royal jelly (Stored based on content)

'''Note''': Jugs with royal jelly, that stored as finished goods are '''NOT''' used for processing royal jelly, like screw press.

{{Category|Items}}

v0.31:Large pot

2011-07-18T04:51:02Z

Thundercraft: Mention that pots can be made from wood at a Craftdwarf's Workshop and can store liquids

{{Quality|Fine|18:07, 16 March 2011 (UTC)}}{{av}}

{{buggy}}

'''Pots''' are basically stone versions of {{L|barrel}}s. They can be made from {{L|ceramic}} at a {{L|kiln}}, from {{L|glass}} at a {{L|glass furnace}}, from stone by a {{L|stone crafter}} at a {{L|craftsdwarf's workshop}}, or [[DF2010_Talk:Large_pot|from wood]] at a {{L|craftsdwarf's workshop}}. Pots made from stone, {{L|stoneware}}, {{L|glass}}, {{L|wood}}, or {{L|glaze}}d {{L|earthenware}} are water-tight and can be used to store liquids, and even for {{L|brewing}}. Unglazed earthenware can only be used for storing dry items. Pots are stored in the Tools section of the Finished Goods stockpile. Pots are visible on the haul-for-trade screen under Tools section.
Workshops that require a barrel for construction cannot use a pot instead.

== Bugs ==
* Pots will not be used for processing {{L|sweet pod|sweet pods}} into {{L|dwarven syrup}}. {{Bug|4356}}
* Empty pots go into furniture {{L|stockpiles}} regardless of stockpile setting. {{Bug|4135}}
* Dwarves will sometimes leave pots in furniture stockpile even when using them to store food. {{Bug|3389}}

{{Category|Items}}

v0.31:Jug

2011-07-18T04:26:21Z

Thundercraft: Mention that jugs can be made of wood at a Craftdwarf's Workshop

{{quality|Fine|03:21, 18 April 2011 (UTC)}}{{av}}

'''Jugs''' are a type of {{L|container}}, made from {{L|ceramic}} at a {{L|kiln}}, from {{L|glass}} at a {{L|glass furnace}}, from stone by a {{L|stone crafter}}, or [[DF2010_Talk:Jug#Wooden_Jugs.3F.3F|from wood]] at a {{L|craftsdwarf's workshop}}. They are used in {{l|Beekeeping industry|beekeeping}} to store royal jelly or at a {{L|screw press}} to store honey or rock nut oil. Jugs made from earthenware need to be {{L|glaze}}d before they can be used to hold liquids like honey. Jugs are stored in the {{L|tool|Tools}} section of the Finished Goods stockpile, and managed from the '''tools''' section of the Stocks screen.

Jugs are stored in bins. Jugs with royal jelly / honey can be stored in two stockpiles:
* Finished goods / tools (stored as JUGS)
* food / extract animal / honey, royal jelly (Stored based on content)

'''Note''': Jugs with royal jelly, that stored as finished goods are '''NOT''' used for processing royal jelly, like screw press.

{{Category|Items}}

v0.31:Finished goods

2011-07-18T00:31:19Z

Thundercraft: /* Materials */ Clarifying that glass & gems have a small chance to be cut into crafts

{{quality|Exceptional|19:03, 16 April 2011 (UTC)}}{{av}}
'''Finished goods''' are items that go to a finished goods {{L|stockpile}} when made. Many of these items are frequently referred to as trade goods as they are lightweight and only useful for {{L|trading}}. They include '''crafts''', '''goblets''', '''instruments''', '''toys''', '''large gems''', and '''totems''', some of which have several sub-types.

There is no way to issue a job order for a specific subtype of a good with multiple subtypes. If you have a mandate to make piccolos, the best you can do is to order instruments and hope for the best.

Some types of trade goods can be produced in multiples. It is possible to get up to three crafts from a single resource. The chance of multiples is increased with more {{L|experience}} in the craftsdwarf skill. Mugs will ''always'' be made in threes, so they are more productive in terms of value than other trade goods (unless an import agreement offers a high price for another type of trade good).

==Types of trade goods==

===Crafts===
Crafts include {{l|figurine|'''figurines'''}}, {{L|jewelry|'''rings''', '''earrings''', '''amulets''', '''bracelets''', '''crowns'''}}, and '''scepters'''. They are the only type of trade good that appears on its own page in the Trade Depot menu.

===Goblets===
Goblets have no subtypes, but have different names depending on the material from which they are made: {{L|metal}} goblets are simply '''goblets''', {{L|stone}} goblets are called '''mugs''', and {{L|wood}}en goblets are called '''cups'''. Stone mugs can be found under the 'All' section of the Move Trade Goods interface.

Note that dwarves never drink {{L|booze}} out of mugs, preferring instead to drink straight from the {{L|barrel}}.

===Instruments===
Instruments include '''drums''', '''flutes''', '''harps''', '''trumpets''', and '''piccolos'''.

===Toys===
Toys include '''mini-forges''', '''toy hammers''', '''toy axes''', '''toy boats''', and '''puzzleboxes'''.

===Totems===
Totems are made from skulls by a {{L|bone carver}} at a {{L|craftsdwarf's workshop}}. Totems cannot be built as permanent structures, but careful management of custom {{L|stockpile}}s will allow the player to place totems at artistically pleasing locations around the fortress.

Although totems have the same base {{L|value}} as all other crafts, totems made from the skulls of more valuable animals like {{L|unicorn}}s will fetch a hefty price.

===Large gems===
Large gems have no subtypes. It is not possible to issue a job order for large gems; instead, cutting any {{L|gem}} or raw {{L|glass}} has a chance to produce a large gem instead of ordinary cut gems. Gems and glass also have a chance to be cut into crafts this way. In fact, glass crafts cannot be made directly at a {{L|glass furnace}}, and must be acquired through the processing of raw glass by a gem cutter.

==Materials==
Most materials can be used to make trade goods. On occasion, a {{L|dwarf}} in a {{L|strange mood}} will make a trade good out of a material not normally suited for it (e. g., a cloth instrument).

{| border = 1 cellspacing="0" cellpadding="5"
| align="center" style="background:#f0f0f0;"|'''Material'''
| align="center" style="background:#f0f0f0;"|'''Labor'''
| align="center" style="background:#f0f0f0;"|'''Workshop'''
| align="center" style="background:#f0f0f0;"|'''Crafts'''
| align="center" style="background:#f0f0f0;"|'''Goblets'''
| align="center" style="background:#f0f0f0;"|'''Instruments'''
| align="center" style="background:#f0f0f0;"|'''Toys'''
| align="center" style="background:#f0f0f0;"|'''Large Gems'''
|-
| {{L|Stone}}||{{L|Stonecrafting}}||{{L|Craftsdwarf's workshop}}||Y||Y||Y||Y||N
|-
| {{L|Wood}}||{{L|Woodcrafting}}||{{L|Craftsdwarf's workshop}}||Y||Y||Y||Y||N
|-
| {{L|Leather}}||{{L|Leatherworking}}||{{L|Craftsdwarf's workshop}}||Y||N||N||N||N
|-
| {{L|Cloth}}||{{L|Clothesmaking}}||{{L|Craftsdwarf's workshop}}||Y||N||N||N||N
|-
| {{L|Bone}}1||{{L|Bone carving}}||{{L|Craftsdwarf's workshop}}||Y||N||N||N||N
|-
| {{L|Shell}}||{{L|Bone carving}}||{{L|Craftsdwarf's workshop}}||Y||N||N||N||N
|-
| {{L|Horn}}||{{L|Bone carving}}||{{L|Craftsdwarf's workshop}}||Y||N||N||N||N
|-
| {{L|Ivory}}||{{L|Bone carving}}||{{L|Craftsdwarf's workshop}}||Y||N||N||N||N
|-
| {{L|Pearl}}||{{L|Bone carving}}||{{L|Craftsdwarf's workshop}}||Y||N||N||N||N
|-
| {{L|Ceramic}}||{{L|Pottery}}||{{L|Kiln}} or {{L|Magma kiln}}||Y||N||N||N||N
|-
| {{L|Wax}}||{{L|Wax working}}||{{L|Craftsdwarf's workshop}}||Y||N||N||N||N
|-
| {{L|Metal}}||{{L|Metalcrafting}}||{{L|Metalsmith's forge}} or {{L|Magma forge}}||Y||Y||Y||Y||N
|-
| {{L|Glass}}||{{L|Glassmaking}}||{{L|Glass furnace}} or {{L|Magma glass furnace}}||Y2||Y||Y||Y||Y3
|-
| {{L|Gems}}||{{L|Gem cutting}}||{{L|Jeweler's workshop}}||Y2||N||N||N||Y3
|}
1 Skull totems, like bone crafts, are also made by a bone carver at a craftsdwarf's workshop.

2 Glass and gems have a small, random chance to be cut into crafts. See the finished goods {{L|Finished_goods#Glass_Crafts.3F|discussion page}} for details.

3 See {{L|Trade good#Large gems|Large gems}} above. Large glass gems are cut at a jeweler's workshop, not a glass furnace.

{{Category:Items}}

v0.31 Talk:Screw pump

2011-06-25T21:38:55Z

Thundercraft: /* Pump Speed */ Thoughts on draining water 1/7 deep

Note: Pumps will transfer power vertically as they did in 40d. It is confirmed they function in all respects as they did in the previous version. For information on vertical power transfer see Pump Stack in the article.
:Moved this to here from the article. [[User:Oddtwang of Dork|Oddtwang of Dork]] 22:00, 28 April 2010 (UTC)

About the service area in the picture. You can use a door at the impassible part of the screw pump instead of using two doors. The dwarves can dig and move diagonally. --[[User:Altaree|Altaree]] 15:38, 13 April 2010 (UTC)

<blockquote>
it can be ... operated by ... using gear assemblies connected to water wheels and/or windmills.
</blockquote>
A gear assembly is not necessary. It is possible to build a water wheel, connected to a horizontal axle, connected to a screw pump. The screw pump will function as intended.

== Pump Speed ==

How much water do screw pumps move? Is it 1/7 of water per game frame? If you wanted to build a 1x1 waterfall that operated constantly without sourcing any new water, how many pump stacks would you need?

:A lot. I don't know. Less than one, so to speak ;) In any case, channel the water through a diagonal after the pump --[[Special:Contributions/92.202.29.45|92.202.29.45]] 17:16, 22 April 2010 (UTC)

:I believe they move 7/7 per step. Make sure your drainage is good :) [[Special:Contributions/66.30.8.88|66.30.8.88]] 21:27, 26 April 2010 (UTC)

In a different tack. In the notes section it is mentioned that pumps do not pump 1/7 amounts of liquids, but at least my pumps do in an unmodded version. If no one corrects me I'm going to change that in a few days. --[[User:Egodeus|Egodeus]] 14:50, 20 May 2011 (UTC)
:Could you record a movie of this and upload it to DFMA? I just tried this with water, and a screw pump would '''not''' move it from the source tile unless it was at least 2/7 deep. --[[User:Quietust|Quietust]] 16:12, 20 May 2011 (UTC)
::I'll try to do that once I get the chance. I'm going out of town for the weekend so probably not going to happen before next tuesday. --[[User:Egodeus|Egodeus]] 05:52, 23 June 2011 (UTC)
:I've done a lot of pumping, and it always drains water to 0/7 in the tile being pumped out when it can, assuming it's powered. Non-empty tiles are mostly when surrounded by water and flowing in anyway from pressure. [[User:AutomataKittay|AutomataKittay]] 09:06, 23 June 2011 (UTC)
::Perhaps there is confusion in this discussion due to terminology? I'm thinking, perhaps, pumps will not '''start''' pumping unless the source is at least 2/7 deep, but it will still '''drain''' the source to 0/7 if it had enough to start pumping? Just a thought... I haven't tested this. Also, I vaguely seem to recall a technical discussion on how water flows in DF that claimed the water level in a tile can, sometimes, fluctuate too fast to be updated on the screen. Perhaps the water was fluctuating like this between 1/7 and 2/7? --[[User:Thundercraft|Thundercraft]] 21:38, 25 June 2011 (UTC)

== Magma-Safe Pump ==

How is it possible to make a magma-safe pump (or rather, one which does not degrade into its component parts), since pipe sections and corkscrews can (apparently) only be made of wood? [[User:Rodya mirov|Rodya mirov]]
* Nevermind, pipe sections and corkscrews can be made of metal, just not rock. Leaving this here in case anyone else has a similar concern. [[User:Rodya mirov|Rodya mirov]]

The entry implies that you can pump magma with a pump containing some wooden parts. This is very misleading because while you can fill an area on the other side of it with some magma, the pump pretty much instantly catches on fire, and within a couple minutes will fall apart.--[[User:Krenn|Krenn]] 06:40, 9 May 2010 (UTC)

== Desalinating water ==

Can someone add an idiot-proof explanation for how pumps desalinate water? I can't get it to work.

Here's my setup:

(saltwater lake)
%
╔═0%0
║+++║
║+++║
║▲++║
╚═══╝
▲

Pump pumping north to south from the lake, ramps put in for access while constructing, floor built under first tile of the pump. When I order the pump to be started, the reservoir gets filled. I stopped the pumping before the reservoir overfilled, then designated the level above as a zone. Water source does not highlight, and designating it doesn't work.

Initially I did the above but had not built a floor tile under the exit end of the pump, which did not work. I removed the pump, put in the floor, waited for all the water to evaporate and tried again - no dice. Does that mean mud will contaminate the water and make it salty?
:See [[Salt_water]] - you have to pump the salt water into a completely constructed cistern. The water inside the cistern will be desalinated.

========desalination not as simple as portrayed 9/22/2010
I built a basalt cistern. Basalt floor, basalt walls, basalt door into basalt floored pumping room. cistern fills, holds water, not drinkable.

cistern is constructed from rock hauled up the mountain.

does the cistern need to be made of blocks or bars?

I must be an idiot though because after 3 days trying with the wiki and youtube open I still can't get a single level of pump stack to work either.

== Pumping FPS ==

I have built about 110 pumps in a stack to get magma to the surface. After I have turned them on, the FPS dropped to <1 (with typical FPS about ~60) until all stack containments filled up to the 7/7. [[User:WFrag|WFrag]] 06:24, 25 June 2010 (UTC)

: http://www.bay12forums.com/smf/index.php?topic=72296.0 [[User:WFrag|WFrag]] 11:27, 25 January 2011 (UTC)

== They only stack one way if you dig correctly ==
Worth noting that due to the way the power is transmitted from one pump to the next, if you have any problems of this nature it's because the inlet hole and power transmition holes are not dug correctly -- one level is '1010' and the next level is '0101', repeated as many times as is necessary. If you dig the holes correctly, then the pumps will only allow you to build them one way -- the way that will work. This confused me for a good while! [[User:FleshForge|FleshForge]] 01:10, 29 August 2010 (UTC)

FYI These are extraordinarily dangerous - if you didn't channel your aquifer access, dorfs slip and drown when using pumps.

== Necessity of pump stacks ==

Here's the thing that I've never understood: If I dig a set of Up/Down stairs straight down, and then position a pump stack to pump water into the stairs, water will get pushed into the stairwell. This water has nowhere to go but up, and eventually rises up the stairwell. So why do we need pump stacks in the first place? Why not just pump into a vertical aqueduct? --[[User:Romeofalling|Romeofalling]] 02:57, 1 October 2010 (UTC)
:Er, pumps don't work that way - they can't lift a liquid higher than the Z-level of the pump output tile. Thus, if you have water on Z=120 and you need to move it up to Z=140, you '''need''' twenty screw pumps. --[[User:Quietust|Quietust]] 04:49, 1 October 2010 (UTC)

== power output ==

How much power does the pump transfer? And given no other power source, what's the limit of pumps that a single dwarf could hand-power? [[User:Uzu Bash|Uzu Bash]] 00:31, 20 October 2010 (UTC)
:Power transfer? As much as is supplied, minus the 10 points for running the pump. Dwarf-power? Just the one he's operating. --[[User:DeMatt|DeMatt]] 00:33, 20 October 2010 (UTC)

v0.31 Talk:Workshop

2011-06-20T09:15:04Z

Thundercraft: Concepts and Organization: Tier System is useful, but needs some work

==Concepts and Organization==
There is a lot of information on this page, mostly in list form. I'd like to condense the lists into more generalized concepts, useful forms, or transfer some of the information to the specific workshop pages themselves. Any suggestions are welcome! I'm currently working on updating the individual workshop pages, but I have a feeling there is a better way to list the workshops within each tier (alphabetically, the order listed in-game, perhaps in some sub-category?). Even the products could use similar attention. -- [User:DwarfNuke|DN]] 17:49 1 March 2011 (GMT)

Yes, there is a lot of info. And it ''really'' needs to be corrected, updated and reformatted. But I'm opposed to condensing it down to generalizations. That would greatly diminish its usefulness. Despite its shortcomings, I find the Tier System handy to see at a glance how far removed end products are from the materials used. Using this to make comparisons allows me to judge the time and labor cost to produce goods and make decisions based on efficiency.

As for organizing the Tier System better, I have a question:
'''Should {{L|container}}s be taken into consideration to determine the Tier?'''
Currently, a few workshops (Still, Quern, and Millstone) are listed to consider containers as part of the materials used and, as a result, the goods produced are classified much higher in the Tier than they would otherwise. But most workshops do not do this. I feel a rule should be decided upon to make the Tier System more consistent and clear.

Should containers ever be considered part of the raw materials, such as when a certain container is absolutely necessary? Or should containers always be left out of Tier considerations? IMO, I feel the latter makes much more sense. First, containers usually store stacks of multiple items, so they don't count much toward the labor cost producing 1 unit of a finished good. Secondly, containers are reusable (with the exception of {{L|trading}} products such as liquids or powders to caravans that ''must'' be sold in a container). Since containers are reusable, the dwarf labor and time to make them is inconsequential compared with the actual goods. As long as the goods are consumed or used in the fort, containers are a one-time investment.

If containers were always considered, then the Tiers of materials used and goods produced would have to be greatly expanded, making it vastly more complicated. For instance, bags produced from silk cloth should be Tier 2 because they only require a Tier 1 material. (Silk cloth comes from silk thread, which is produced automatically by a dwarf with the gather web labor. The latter does not require a workshop, so it's Tier 0.) But bags produced with Rope reed thread, Pig tail thread, or Yarn (from Wool) require more processing, so such bags are Tier 3. And anything stored in them would be Tier 4. Similarly, Alcohol can be stored in wood barrels (Tier 1), metal barrels (Tier 2), or a metal {{L|metal#Alloys_2|alloy}} barrel (Tier 3). And it can be stored in {{L|large pot|glazed large pots}} (Tier 2). This makes alcohol fit either Tier 2, Tier 3, or Tier 4, depending on the type and materials of the container. Then, when you try to determine the Tiers of workshops further down which use liquids or powders as ingredients, the complications get compounded. --[[User:Thundercraft|Thundercraft]] 09:15, 20 June 2011 (UTC)

v0.31 Talk:Still

2011-06-20T04:16:45Z

Thundercraft: /* Seeds from Brewing */

==Seeds from Brewing==
This {{L|Still}} article is ranked "≡EXCEPTIONAL≡"?

Strangely, there is no mention of how brewing returns the seeds of the plant you brew. Specifically, it would be helpful to mention that 1 to 2 seeds are produced per plant from brewing (with the exception of Muck root and Bloated tuber). Also, it might be worth mentioning that the seeds are stored in {{L|bag}}s and that it might help speed production to have stockpile(s) of bags, barrels, and/or glazed large pots nearby. Finally, if {{L|Barrel}}, {{L|Kobold bulb}}, and {{L|Vial}} is listed under '''Materials Used''' in the sidebar, why not also mention {{L|large pot|Glazed large pot}} and {{L|Bag}} there? --[[User:Thundercraft|Thundercraft]] 04:14, 20 June 2011 (UTC)

v0.31 Talk:Still

2011-06-20T04:14:29Z

Thundercraft: Seeds from Brewing: Why not mention that seeds are produced? Or that bags would be useful?

==Seeds from Brewing==
Strangely, there is no mention of how brewing returns the seeds of the plant you brew. Specifically, it would be helpful to mention that 1 to 2 seeds are produced per plant from brewing (with the exception of Muck root and Bloated tuber). Also, it might be worth mentioning that the seeds are stored in {{L|bag}}s and that it might help speed production to have stockpile(s) of bags, barrels, and/or glazed large pots nearby. Finally, if {{L|Barrel}}, {{L|Kobold bulb}}, and {{L|Vial}} is listed under '''Materials Used''' in the sidebar, why not also mention {{L|large pot|Glazed large pot}} and {{L|Bag}} there? --[[User:Thundercraft|Thundercraft]] 04:14, 20 June 2011 (UTC)

v0.31 Talk:Millstone

2011-06-20T02:19:17Z

Thundercraft:

== Quality Discussions ==
I think this should be downgraded to an Elven article. It looks like a stub to me. – [[template:unsigned|unsigned]] comment by [[User:Me|Me]]
:Well.. it doesn't have any red links, with many blues. – [[template:unsigned|unsigned]] comment by [[User:92.10.72.113|92.10.72.113]]

I think it should be downgraded to +Fine+. There is a small, basic amount of information. No illustrations of how to hook up millstone to anything, no tips, etc.

Too many articles are marked as +Exceptional+ currently, due to the switch from "Elven", "Human", "Dwarven" to "Tattered", "Exceptional", and "Masterwork". Fine was added later, so most articles that SHOULD be marked "Fine" are currently marked "Exceptional".

I'm bumping this article down to "+Fine+". Others can bump it up if they disagree with me. --[[User:Darkstar|Darkstar]] 21:24, 28 June 2010 (UTC)
:Ehhh... y'know, you could ADD those things you think should be in the article. See? I just did. And then I put it back to Exceptional. --[[User:DeMatt|DeMatt]] 21:55, 28 June 2010 (UTC)

== Millstone in general ==

... What's the advantage of a millstone over a quern? Is there any, really? --[[User:Aescula|Aescula]] 00:52, 1 September 2010 (UTC)
:: Not 100% sure of this, but I imagine it's speed. I don't know how fast a legendary miller can work a quern, whether it's still an appreciable amount of time, but milling with a powered millstone is just this side of instant. [[User:Niveras|Niveras]] 01:33, 1 September 2010 (UTC)

== Mill Plant, Receive Seed ==

Does milling a plant produce or a seed/spawn, or is the seed destroyed?--[[Special:Contributions/208.81.12.34|208.81.12.34]] 18:51, 1 September 2010 (UTC)
:Milling a plant produces seeds. The only thing that '''doesn't''' yield seeds is cooking (and rotting, but that should be obvious enough). --[[User:Quietust|Quietust]] 19:20, 1 September 2010 (UTC)

== Mill Plant - Closest Plant Not Milled First ==

I surrounded a millstone with a stockpile of sliver barbs (hoping to get Sliver Dye quickly) and my millers still went to the more distant food pile to mill plants. It seems that the proximity of plants does not determine which one is chosen for milling.--[[Special:Contributions/208.81.12.34|208.81.12.34]] 17:47, 13 September 2010 (UTC)
:The plant chosen is the one closest to the '''miller''' (i.e. the dwarf who takes the job), not the closest to the millstone. Once the dwarf has completed one job ''at'' the millstone, then "cloest to the miller" will happen to be the same as "closest to the millstone". --[[User:Quietust|Quietust]] 18:07, 13 September 2010 (UTC)

== Rock Nut Paste ==

The {{L|quarry bush}} and {{L|screw press}} pages mention that "Rock nuts can also be milled at a millstone or quern into rock nut paste." However, the {{L|workshop}}, {{L|millstone}}, and {{L|quern}} pages fail to list {{L|Quarry bush|rock nuts}} as Materials Used or rock nut ''paste'' as Goods Created. In fact, only the quern page has a brief mention of using the quern to produce a paste.

Obviously, these pages need updating. I'd do this myself, but I'm still learning this wiki format and I still need to verify with in-game experience first. --[[User:Thundercraft|Thundercraft]] 02:19, 20 June 2011 (UTC)

v0.31:Furnace

2011-06-20T00:51:45Z

Thundercraft: /* {{L|Kiln}} */ Updated Kiln to include materials used and products of the ceramic/clay industry

{{quality|Exceptional|23:22, 17 April 2011 (UTC)}}{{av}}

'''Furnace''' is an umbrella term for different {{L|workshop}}s that are used to heat materials, and that often produce only intermediary--products, items that are then used to create something else for the final product.

Every furnace must be built from {{L|fire-safe}} materials and designed by a {{L|building designer}}. It can be powered by {{L|fuel}} or, in the case of magma furnaces, by the heat from {{L|magma}} - if the latter, they do not consume the magma, merely must be over it. Magma furnaces must be placed with one of their edge tiles above magma with depth of 4 or more; this can be accomplished by digging a channel for the magma, or hanging it directly over open {{L|Magma#Magma_sources|magma source}}.

All these are constructed using the Furnaces submenu (via {{k|b}}, {{k|e}} ).

See main articles for a full discussion, esp of magma versions.

== {{L|Wood furnace}} ==
:*''Shortcut:'' {{k|b}}, {{k|e}}, {{k|w}} 
:*''Materials used:'' {{L|wood}} 
:*''Items made:'' {{L|ash}}, {{L|charcoal}}
::*''Feeds into:'' fuel for other furnaces, {{L|steel}} making, {{L|Ashery|asheries}} and {{L|soap}} production

== {{L|Smelter}} ==
:*''Shortcut:'' {{k|b}}, {{k|e}}, {{k|s}}
:*''Materials used:'' {{L|bituminous coal}}, {{L|lignite}}, {{L|ore}}, {{L|metal}} {{L|bar}}s, {{L|flux}}, {{L|fuel}} (and metal objects to be {{L|melt}}ed)
:*''Items made:'' {{L|coke}}, metal {{L|bar}}s
::*''Feeds into:'' {{L|Forge}}s

=={{L|Magma smelter}}==
:*''Shortcut:'' {{k|b}}, {{k|e}}, {{k|l}}
Magma versions use {{L|charcoal}} or {{L|coke}} for {{L|pig iron}} and {{L|steel}} production ''only''. If the magma source fails, they cannot be powered by {{L|fuel}}.

== {{L|Glass furnace}} ==
:*''Shortcut:'' {{k|b}}, {{k|e}}, {{k|g}}
:*''Materials used:'' {{L|sand}}, {{L|pearlash}}, {{L|rock crystal}}, {{L|fuel}}
:*''Items made:'' {{L|glass}} objects
::*Glass objects are final products

=={{L|Magma glass furnace}}==
:*''Shortcut:'' {{k|b}}, {{k|e}}, {{k|a}}
Magma glass furnaces must be powered by magma, and thus require no additional {{L|fuel}}. Produces same objects as a regular Glass Furnace.

== {{L|Kiln}} ==
:*''Shortcut:'' {{k|b}}, {{k|e}}, {{k|k}}
:*''Materials used:'' {{L|potash}}, {{L|ash}}, {{L|cassiterite}}, {{L|clay}}, {{L|clay loam}}, {{L|sandy clay}}, {{L|silty clay}}, {{L|fire clay}}, {{L|kaolinite}}, {{L|gypsum}}, {{L|alabaster}}, {{L|selenite}}, {{L|satinspar}}, {{L|fuel}}
:*''Items made:'' {{L|ceramic|ceramic/clay items}}, {{L|pearlash}} and {{L|plaster powder}}
::*''Feeds into:'' pearlash for higher quality {{L|glass}} production
::*Plaster powder is a final product used by healthcare professionals.
::*Ceramic/clay (earthenware, stoneware, and porcelain) items are final products.

=={{L|Magma kiln}}==
:*''Shortcut:'' {{k|b}}, {{k|e}}, {{k|n}}
Functions just like a regular kiln, but must be powered by magma instead of {{L|fuel}}.

{{Workshops}}
{{Buildings}}

v0.31:Furnace

2011-06-20T00:30:05Z

Thundercraft: /* {{L|Magma kiln}} */ Mentioned that Magma kiln does not use fuel

{{quality|Exceptional|23:22, 17 April 2011 (UTC)}}{{av}}

'''Furnace''' is an umbrella term for different {{L|workshop}}s that are used to heat materials, and that often produce only intermediary--products, items that are then used to create something else for the final product.

Every furnace must be built from {{L|fire-safe}} materials and designed by a {{L|building designer}}. It can be powered by {{L|fuel}} or, in the case of magma furnaces, by the heat from {{L|magma}} - if the latter, they do not consume the magma, merely must be over it. Magma furnaces must be placed with one of their edge tiles above magma with depth of 4 or more; this can be accomplished by digging a channel for the magma, or hanging it directly over open {{L|Magma#Magma_sources|magma source}}.

All these are constructed using the Furnaces submenu (via {{k|b}}, {{k|e}} ).

See main articles for a full discussion, esp of magma versions.

== {{L|Wood furnace}} ==
:*''Shortcut:'' {{k|b}}, {{k|e}}, {{k|w}} 
:*''Materials used:'' {{L|wood}} 
:*''Items made:'' {{L|ash}}, {{L|charcoal}}
::*''Feeds into:'' fuel for other furnaces, {{L|steel}} making, {{L|Ashery|asheries}} and {{L|soap}} production

== {{L|Smelter}} ==
:*''Shortcut:'' {{k|b}}, {{k|e}}, {{k|s}}
:*''Materials used:'' {{L|bituminous coal}}, {{L|lignite}}, {{L|ore}}, {{L|metal}} {{L|bar}}s, {{L|flux}}, {{L|fuel}} (and metal objects to be {{L|melt}}ed)
:*''Items made:'' {{L|coke}}, metal {{L|bar}}s
::*''Feeds into:'' {{L|Forge}}s

=={{L|Magma smelter}}==
:*''Shortcut:'' {{k|b}}, {{k|e}}, {{k|l}}
Magma versions use {{L|charcoal}} or {{L|coke}} for {{L|pig iron}} and {{L|steel}} production ''only''. If the magma source fails, they cannot be powered by {{L|fuel}}.

== {{L|Glass furnace}} ==
:*''Shortcut:'' {{k|b}}, {{k|e}}, {{k|g}}
:*''Materials used:'' {{L|sand}}, {{L|pearlash}}, {{L|rock crystal}}, {{L|fuel}}
:*''Items made:'' {{L|glass}} objects
::*Glass objects are final products

=={{L|Magma glass furnace}}==
:*''Shortcut:'' {{k|b}}, {{k|e}}, {{k|a}}
Magma glass furnaces must be powered by magma, and thus require no additional {{L|fuel}}. Produces same objects as a regular Glass Furnace.

== {{L|Kiln}} ==
:*''Shortcut:'' {{k|b}}, {{k|e}}, {{k|k}}
:*''Materials used:'' {{L|potash}}, {{L|fuel}}
:*''Items made:'' {{L|pearlash}} and {{L|plaster powder}}
::*''Feeds into:'' higher quality {{L|glass}} production
::*Plaster powder is a final product used by healthcare professionals.

=={{L|Magma kiln}}==
:*''Shortcut:'' {{k|b}}, {{k|e}}, {{k|n}}
Functions just like a regular kiln, but must be powered by magma instead of {{L|fuel}}.

{{Workshops}}
{{Buildings}}

v0.31:Screw pump

2011-06-18T09:09:23Z

Thundercraft: /* Construction */

{{quality|Masterwork|21:05, 26 April 2011 (UTC)}}{{av}}

{{Machine_component|name=Screw pump|key=s|job={{L|Pump operator}}
|construction=
* {{L|Trap component#Enormous corkscrew|Enormous corkscrew}}
* {{L|Pipe section}}
* {{L|Block}}
|construction_job=
* {{L|Architecture}}
* 1 of
** {{L|Carpentry}}
** {{L|Masonry}}
** {{L|Metalsmithing}}
|power=Needs 10 power.
}}

A '''screw pump''' is a small {{L|building}} that can lift liquids ({{L|water}} or {{L|magma}}) from one level below onto the same {{L|Z-level}} as the pump. It is two tiles by one tile in size, and it can be either manually operated by a {{L|dwarf}} with the {{L|pump operator}} job or by being {{L|power}}ed by {{L|water wheel}}s and/or {{L|windmill}}s.

The direction you want the fluid to travel must be chosen at the time of construction. Pumping only occurs in a straight line, and involves a total of 4 tiles in a row - the liquid source, two for the pump, and the output. The "rise" in levels occurs on the first tile, the intake side, from one level below up to the level of the pump*. Pumped fluids can and will flow immediately after being pumped, as normal for that fluid. Pumped fluids will have a {{L|pressure}} equal to the exit {{L|z-level}} - a pump never "forces" water to a higher {{L|z-level}} than the output tile.

:''(* A DF pump can best be imagined as a simple [http://en.wikipedia.org/wiki/Archimedes%27_screw archimedes screw].)''

Salt water pumped through a pump will desalinate and become drinkable. However if the water then touches any natural water or tiles, smoothed or not, it will immediately be undrinkable again. So it is important to pump into a reservoir that is made entirely of constructed material. Please note that the block/tile underneath the reservoir-side of the pump also needs to be a construction.

Stagnant water pumped through a pump will become clean, letting dwarves drink it without getting an unhappy {{L|thought}} and letting {{L|doctor}}s clean {{L|wound}}s without causing an {{L|Health care#Infection|infection}}. Unlike with desalination, stagnation-removal doesn't require avoidance of natural tiles, even in a wetlands biome.

''For a basic overview of how the different machine parts work and work together, see {{L|machinery}}.''

== Construction ==

Building a screw pump requires an {{L|Trap component#Enormous corkscrew|enormous corkscrew}}, a {{L|block}}, and a {{L|pipe section}}. The construction itself is completed in two stages. First a dwarf with the {{L|architect}} labor must design it. Then a dwarf (the same or a different one) with the appropriate labor must complete the building. This could be {{L|carpentry}}, {{L|metalsmithing}}, or {{L|masonry}}, depending on the material of the block.

To select pump, use keys {{k|b}}-{{k|M}}-{{k|s}}. It's important to choose the proper orientation for your pump, where it will draw water from and where it will deliver the water. This is determined before placement with the {{k|u}}, {{k|m}}, {{k|k}}, or {{k|h}} keys, and the text at the top of the sub-menu will change to confirm your choice. The default (as shown above in the sidebar), "pumps from the north" (top). The ''light'' green X must be next to the liquid source and the ''dark'' green X is where the liquid exits the pump.

[[Image:Small pump.jpg|thumb|right|300px|'''Basic Side View of a Pump'''. This pump "pumps from the west", from left to right. The area to the right may fill to the top of that level, but no more (See {{L|pressure}}; see {{L|Screw pump#Pump Stack|Pump stack}}). Note that the entire space required is 4 tiles long by 1 tile wide, not including any retaining walls for the outflow. If pumped manually, the {{L|pump operator}} stands in the light-colored area, as the dark-colored is impassable to both fluid and movement. ''(Although the "liquid" is shown as blue, this can work for {{L|magma|magma}} as well, with the {{L|magma-safe|appropriate precautions}}.)'']]

The example shown in the infobox above "pumps from the north" (top) to the south (bottom). If pumped manually, the dwarf stands on the light-colored tile, as the dark-colored is impassable.

The orientation is visible after placement by using {{k|q}}uery over or near that pump or during placement, using UMKH to select the direction of input. Orientation of a pump cannot be changed after being constructed, but, as with any building, it can be deconstructed into its component parts and rebuilt as and where desired.

Having specified the direction of travel, you must ensure that the source side of the pump is placed adjacent to and above (in the {{L|z-axis}}) a liquid. The screw pump will draw the liquid up from below its level, and distribute it out of the other side of the pump.

== Notes ==

* The source of the pump must be directionally adjacent to "Open Space" that is directly above a source of liquid. The adjacent space cannot be a floor, stairway or wall suspended over water. Screw pumps can pull water through a {{L|grate}}, floor {{L|bars}}, or a {{L|construction|constructed}} {{L|fortification}} on the Z-level below.
* The light pump tile is where a pump operator will stand (if the pump is not powered mechanically). Liquids to be pumped must be 1 level below the (empty) area adjacent to this tile.
* Dwarves must be able to access and stand on the light tile of the pump in order to build the pump and then to be able to operate the pump manually.
* The dark pump tile is on the output side. Liquids will appear in the tile adjacent to this.
* The dark pump tile blocks liquids flow and creature movement, and can be built into a wall to create a solid barrier. The light tile of the pump does not block flow or movement.
* Pumps can also be used in conjunction with a {{L|water wheel}} or a {{L|windmill}} to become self-powered.
* Active mechanisms connected to the pump will automatically start the pump; to prevent this either restrict liquid flow using floodgates or hatches, or put in a {{L|gear assembly}} linked to a {{L|lever}} to disconnect the {{L|power}}.
* Adjacent pumps ''automatically'' transfer mechanical power to any other adjacent pump(s), no {{L|axle}} or {{L|mechanism}} is required. If too many pumps are adjacent, there may be insufficient power to power them.
* A hatch above the input tile (on the same level as the pump) that is linked to a trigger (a {{L|lever}} or {{L|pressure plate}}) makes an effective on/off switch for that pump.
* In order to build pumps in a "hanging" state, as in the stacked screw pump example (below), one of its tiles must be able to connect to a nearby machine, either already existing or designated to be built. If, when the screw pump's construction is completed, the supporting mechanism has not yet been completed, it will promptly collapse into its component parts.
* Pumps do '''not''' push liquids '''up''' additional Z-levels above them. They only deliver water to their own level. That is, if you direct the output of a screw pump into a 1-square space surrounded by walls, the water will not "overflow" the walls. Consequently, a pump will refuse to move liquid if the level it is pumping to is completely filled. Higher levels can be achieved using a "pump stack" (below). (See {{L|Pressure}})
* In order to safely pump magma, you must use {{L|magma-safe}} materials, though magma-unsafe metals have been observed to be safe unless the open tile is going to be submerged in magma. Wooden parts will burst into flames the instant the pump is activated, and magma-unsafe stone {{L|block}}s melt after a short time.
* Magma, which normally has no pressure, will behave as though pressurized when pumped. For example, when pumped into an U-turn, magma will come out at the other end. Normal (non-pumped) magma would just pool at the lowest level. This may be either very useful (can be used to build pressure towers for magma) or deadly (forge level flooded with magma, because someone tried to pump magma into a volcano).
* Pump's pseudo-pressure doesn't work across diagonals. If there is a diagonal-only passage in your tunnel, liquids will seep slowly through it, instead of bursting through above their normal maximal speed, like they would if there was good passage.
* The liquid in a pump's intake tile must have a depth of at least 2/7 for the pump to be able to remove any amount of liquid from it.
* If a pump's intake tile on the z-level below the pump becomes blocked (as with a cave-in or magma cooling into obsidian) the pump will still run but not pump any fluid.
* If a pump's output tile has magma but the pump is pumping water (or vice versa), the output tile will be turned into {{L|obsidian}}.

====Common mistakes====
* Orienting a pump incorrectly, and/or not having a proper open liquid source.
* Pumping water into an area with a path to other parts of your fortress. (The pump may work perfectly - the fortress quickly {{L|flood}}s.)
* Expecting water to rise up above the same level of a pump.
* Building a wall attached only to the light tile - this leaves a diagonal leak between the wall and the dark tile unless sealed there. (If that's not a problem, don't worry about it.)
* Having stairs as input tile. Stairs block input tile, thus rendering the pump useless, even though liquids usually ignore stairs. Output tile can be any liquid-passable tile.
* Not channeling below the impassable tile of an individual pump in a pump stack. This is how power is transmitted to the pump below.
* Pumping magma into a lower z-level (same as the source) and then being surprised it is forced back up to the same z-level further down the line (where you were planning your magma forges, for example.)

== Example layouts ==
=== Single pump ===

[[Image:jt_screwpump.png|frame|left|A screw pump delivers from the level below to the tile in front. This pump pumps from the right to the left. The "dark tile" would be on the left - that entire tile is impassible to movement and fluids.]] 
=== Pump stack ===
[[File:PumpStack2010.png|thumb|right|300px|'''Illustrated Side View of a Pump Stack.''']]
[[File:PumpStackTopView.png|thumb|right|300px|'''Illustrated Top View of a Pump Stack Layer.''']]
[[File:Pumpstack.gif|thumb|right|'''Animation showing the general construction using an isometric projection.''']]

A Pump stack is a method used to draw water or magma vertically across multiple z-levels requiring a minimum of parts. The basic functionality is possible because the Output (dark) side of the pump can be built over open space with a machine component located directly below, in this case another Screw Pump. Note that for power to properly transfer the intake (light) side of the pump must line up with the output (dark) side of the pump on the floor above it through a space in the floor, as in the illustration.

A pump stack minimizes the amount of machinery required to lift water or magma by allowing for power to be supplied directly to only the most accessible pump (typically the topmost) which in turn allows the player to operate a stack limited only by how many windmills/water wheels they can fit into the area. The price of optimal parts density is fragility: each pump relies on the pump below it for support. If {{L|forgotten beast|anything}} breaks a pump in your stack, every pump above it will be disassembled. This means that a single pump accidentally assembled with non-magma-safe parts can cause an entire magma pump stack to spontaneously disassemble.

Typical applications for a pump stack include moving magma from a lower level (often the {{L|magma sea}}) up to a convenient level for forges and furnaces, extracting water from a flooded fort, raising water for a decorative {{l|waterfall}} (and extracting it afterwards), or any other purpose that requires water/magma on a z-level significantly above its current location.

The Illustrated Top View of a Pump Stack Layer shows a basic section of a pump stack. Only the door (or a floodgate) on the Containment side is strictly necessary in order to prevent flooding. Two doorways are used here, each lining up with the solid ground within the pump assembly, in order to prevent workers from trapping themselves after digging channels or assembling the pump.

Be warned: pump stacks move water '''fast.''' If you are pumping from a large reservoir into an open area, be prepared for a huge outflow, roughly akin to the kind of water dump you'd get if the whole reservoir was balanced above the pump output and then released. If you are using pumps to empty a large underground reservoir (or, say, a flooded fortress) onto open land, use an aqueduct or some other method to make sure the pump system outlet is a good distance away from anything you wouldn't want to get drenched.

As an alternative to a large reservoir, it is also possible to combine a {{L|Dwarven Atom Smasher}} with the top layer of the Pump Stack to create a "vacuum cleaner" of sorts.

====Tips====

* Ramps can be used in place of channeling. Liquids will transmit through ramps, unlike stairs, and when pumps are constructed they annihilate the ramp they're built on much as walls do. Power will still be transmitted, so they don't need to be removed by miners prior to pump construction. Ramps make it virtually impossible to strand your miners and allows the stack to be dug out using only access doorways on the intake side of the pump, so no construction or doors are later needed to eliminate leaks. A pump stack can be very rapidly carved out with this method as even if a miner/builder is trapped on the containment side of a pump, they can walk up the ramp to the intake side of the pump above and walk out.
* Power can be transmitted to the stack by channeling out the tile directly above the intake (light) tile of the topmost pump and mounting a gear assembly. If the gear assembly is supported by an adjacent gear assembly or horizontal axle on a stable floor (be careful to not have that adjacent gear assembly disengage via lever), this will allow the stack to hang from the gear assembly. If a lower pump needs to be removed, or should self-destruct, the problem of the entire pump stack disassembling described above is eliminated. Further, if the supported gear assembly is built first, the pump stack can be built both from the top and bottom simultaneously, halving construction time, assuming that sufficient attention is paid to make sure that the pumps will align with the proper orientation when the two partial stacks meet. Properly channeling/ramping out the stack should ensure this.
* When pumping magma, make sure any underground soil tiles on the containment side of the stack are covered with a stone floor (need not be magma safe) to prevent subterranean trees from growing and blocking flow of the stack. When pumping water, it's safest to construct a paved road or slab on any underground tiles on the containment side to prevent subterranean trees from growing and blocking flow. Roads block tree growth, but smoothed or constructed tiles do not when muddied. Currently, designating a stockpile will serve the same goal, but that may not work in the future and if you accidentally de-designate the stockpile, a tree may instantly spring up blocking flow as they do grow 'underneath' the stockpile, hidden until the stockpile is removed.

===Improved Magma Pump Stack===

Because a pump stack pumping magma is known to cause significant {{L|Maximizing_framerate|lag}}, a [http://www.bay12forums.com/smf/index.php?topic=72296.0 new type of pump stack] was developed by [http://www.bay12forums.com/smf/index.php?action=profile;u=19835 NecroRebel] that causes a much smaller drop in [[FPS]]. Changing the single tile magma chamber at the output of every pump from a 1 by 1 to a 3 by 3 area reduces the lag to 1/15th of that caused by the original pump stack. The designer hypothesizes that the larger chamber requires many fewer temperature calculations when magma is pumped in or out; that also implies that there will be no improvement for water pumps.

====Newer Magma Pump Breakthroughs====

Newer breakthroughs in magma pump design has since made the 3x3 reservoir design obsolete.
NecroRebel has tested a [http://www.bay12forums.com/smf/index.php?topic=72296.msg1772802#msg1772802 1x3 head-over-tail variation] (which is very similar to {{L|Screw_pump#Pump_stack|the typical 1 by 1 pump stack}}) as well as a [http://www.bay12forums.com/smf/index.php?topic=72296.msg1795907#msg1795907 2x3 head-over-head variation]. Both of these new designs require less space and work as effective as his original 3x3 reservoir head-over-head design, with no significant drop in FPS. The 1x3 head-over-tail design has the advantages of requiring the least amount of space and it being simple to retrofit from the standard 1 by 1 water pump stack.

{{buildings}}

v0.31:Screw pump

2011-06-18T04:46:21Z

Thundercraft: /* Newer Magma Pump Breakthroughs */

{{quality|Masterwork|21:05, 26 April 2011 (UTC)}}{{av}}

{{Machine_component|name=Screw pump|key=s|job={{L|Pump operator}}
|construction=
* {{L|Trap component#Enormous corkscrew|Enormous corkscrew}}
* {{L|Pipe section}}
* {{L|Block}}
|construction_job=
* {{L|Architecture}}
* 1 of
** {{L|Carpentry}}
** {{L|Masonry}}
** {{L|Metalsmithing}}
|power=Needs 10 power.
}}

A '''screw pump''' is a small {{L|building}} that can lift liquids ({{L|water}} or {{L|magma}}) from one level below onto the same {{L|Z-level}} as the pump. It is two tiles by one tile in size, and it can be either manually operated by a {{L|dwarf}} with the {{L|pump operator}} job or by being {{L|power}}ed by {{L|water wheel}}s and/or {{L|windmill}}s.

The direction you want the fluid to travel must be chosen at the time of construction. Pumping only occurs in a straight line, and involves a total of 4 tiles in a row - the liquid source, two for the pump, and the output. The "rise" in levels occurs on the first tile, the intake side, from one level below up to the level of the pump*. Pumped fluids can and will flow immediately after being pumped, as normal for that fluid. Pumped fluids will have a {{L|pressure}} equal to the exit {{L|z-level}} - a pump never "forces" water to a higher {{L|z-level}} than the output tile.

:''(* A DF pump can best be imagined as a simple [http://en.wikipedia.org/wiki/Archimedes%27_screw archimedes screw].)''

Salt water pumped through a pump will desalinate and become drinkable. However if the water then touches any natural water or tiles, smoothed or not, it will immediately be undrinkable again. So it is important to pump into a reservoir that is made entirely of constructed material. Please note that the block/tile underneath the reservoir-side of the pump also needs to be a construction.

Stagnant water pumped through a pump will become clean, letting dwarves drink it without getting an unhappy {{L|thought}} and letting {{L|doctor}}s clean {{L|wound}}s without causing an {{L|Health care#Infection|infection}}. Unlike with desalination, stagnation-removal doesn't require avoidance of natural tiles, even in a wetlands biome.

''For a basic overview of how the different machine parts work and work together, see {{L|machinery}}.''

== Construction ==

Building a screw pump requires an {{L|Trap component#Enormous corkscrew|enormous corkscrew}}, a {{L|block}}, and a {{L|pipe section}}. The construction itself is completed in two stages. First a dwarf with the {{L|architect}} labor must design it. Then a dwarf (the same or a different one) with the appropriate labor must complete the building. This could be {{L|carpentry}}, {{L|metalsmithing}}, or {{L|masonry}}, depending on the material of the block.

To select pump, use keys {{k|b}}-{{k|M}}-{{k|s}}. It's important to choose the proper orientation for your pump, where it will draw water from and where it will deliver the water. This is determined before placement with the {{k|u}}, {{k|k}}, {{k|m}}, or {{k|h}} keys, and the text at the top of the sub-menu will change to confirm your choice. The default (as shown above in the sidebar), "pumps from the north" (top). The ''light'' green X must be next to the liquid source and the ''dark'' green X is where the liquid exits the pump.

[[Image:Small pump.jpg|thumb|right|300px|'''Basic Side View of a Pump'''. This pump "pumps from the west", from left to right. The area to the right may fill to the top of that level, but no more (See {{L|pressure}}; see {{L|Screw pump#Pump Stack|Pump stack}}). Note that the entire space required is 4 tiles long by 1 tile wide, not including any retaining walls for the outflow. If pumped manually, the {{L|pump operator}} stands in the light-colored area, as the dark-colored is impassable to both fluid and movement. ''(Although the "liquid" is shown as blue, this can work for {{L|magma|magma}} as well, with the {{L|magma-safe|appropriate precautions}}.)'']]

The example shown in the infobox above "pumps from the north" (top) to the south (bottom). If pumped manually, the dwarf stands on the light-colored tile, as the dark-colored is impassable.

The orientation is visible after placement by using {{k|q}}uery over or near that pump or during placement, using UMKH to select the direction of input. Orientation of a pump cannot be changed after being constructed, but, as with any building, it can be deconstructed into its component parts and rebuilt as and where desired.

Having specified the direction of travel, you must ensure that the source side of the pump is placed adjacent to and above (in the {{L|z-axis}}) a liquid. The screw pump will draw the liquid up from below its level, and distribute it out of the other side of the pump.

== Notes ==

* The source of the pump must be directionally adjacent to "Open Space" that is directly above a source of liquid. The adjacent space cannot be a floor, stairway or wall suspended over water. Screw pumps can pull water through a {{L|grate}}, floor {{L|bars}}, or a {{L|construction|constructed}} {{L|fortification}} on the Z-level below.
* The light pump tile is where a pump operator will stand (if the pump is not powered mechanically). Liquids to be pumped must be 1 level below the (empty) area adjacent to this tile.
* Dwarves must be able to access and stand on the light tile of the pump in order to build the pump and then to be able to operate the pump manually.
* The dark pump tile is on the output side. Liquids will appear in the tile adjacent to this.
* The dark pump tile blocks liquids flow and creature movement, and can be built into a wall to create a solid barrier. The light tile of the pump does not block flow or movement.
* Pumps can also be used in conjunction with a {{L|water wheel}} or a {{L|windmill}} to become self-powered.
* Active mechanisms connected to the pump will automatically start the pump; to prevent this either restrict liquid flow using floodgates or hatches, or put in a {{L|gear assembly}} linked to a {{L|lever}} to disconnect the {{L|power}}.
* Adjacent pumps ''automatically'' transfer mechanical power to any other adjacent pump(s), no {{L|axle}} or {{L|mechanism}} is required. If too many pumps are adjacent, there may be insufficient power to power them.
* A hatch above the input tile (on the same level as the pump) that is linked to a trigger (a {{L|lever}} or {{L|pressure plate}}) makes an effective on/off switch for that pump.
* In order to build pumps in a "hanging" state, as in the stacked screw pump example (below), one of its tiles must be able to connect to a nearby machine, either already existing or designated to be built. If, when the screw pump's construction is completed, the supporting mechanism has not yet been completed, it will promptly collapse into its component parts.
* Pumps do '''not''' push liquids '''up''' additional Z-levels above them. They only deliver water to their own level. That is, if you direct the output of a screw pump into a 1-square space surrounded by walls, the water will not "overflow" the walls. Consequently, a pump will refuse to move liquid if the level it is pumping to is completely filled. Higher levels can be achieved using a "pump stack" (below). (See {{L|Pressure}})
* In order to safely pump magma, you must use {{L|magma-safe}} materials, though magma-unsafe metals have been observed to be safe unless the open tile is going to be submerged in magma. Wooden parts will burst into flames the instant the pump is activated, and magma-unsafe stone {{L|block}}s melt after a short time.
* Magma, which normally has no pressure, will behave as though pressurized when pumped. For example, when pumped into an U-turn, magma will come out at the other end. Normal (non-pumped) magma would just pool at the lowest level. This may be either very useful (can be used to build pressure towers for magma) or deadly (forge level flooded with magma, because someone tried to pump magma into a volcano).
* Pump's pseudo-pressure doesn't work across diagonals. If there is a diagonal-only passage in your tunnel, liquids will seep slowly through it, instead of bursting through above their normal maximal speed, like they would if there was good passage.
* The liquid in a pump's intake tile must have a depth of at least 2/7 for the pump to be able to remove any amount of liquid from it.
* If a pump's intake tile on the z-level below the pump becomes blocked (as with a cave-in or magma cooling into obsidian) the pump will still run but not pump any fluid.
* If a pump's output tile has magma but the pump is pumping water (or vice versa), the output tile will be turned into {{L|obsidian}}.

====Common mistakes====
* Orienting a pump incorrectly, and/or not having a proper open liquid source.
* Pumping water into an area with a path to other parts of your fortress. (The pump may work perfectly - the fortress quickly {{L|flood}}s.)
* Expecting water to rise up above the same level of a pump.
* Building a wall attached only to the light tile - this leaves a diagonal leak between the wall and the dark tile unless sealed there. (If that's not a problem, don't worry about it.)
* Having stairs as input tile. Stairs block input tile, thus rendering the pump useless, even though liquids usually ignore stairs. Output tile can be any liquid-passable tile.
* Not channeling below the impassable tile of an individual pump in a pump stack. This is how power is transmitted to the pump below.
* Pumping magma into a lower z-level (same as the source) and then being surprised it is forced back up to the same z-level further down the line (where you were planning your magma forges, for example.)

== Example layouts ==
=== Single pump ===

[[Image:jt_screwpump.png|frame|left|A screw pump delivers from the level below to the tile in front. This pump pumps from the right to the left. The "dark tile" would be on the left - that entire tile is impassible to movement and fluids.]] 
=== Pump stack ===
[[File:PumpStack2010.png|thumb|right|300px|'''Illustrated Side View of a Pump Stack.''']]
[[File:PumpStackTopView.png|thumb|right|300px|'''Illustrated Top View of a Pump Stack Layer.''']]
[[File:Pumpstack.gif|thumb|right|'''Animation showing the general construction using an isometric projection.''']]

A Pump stack is a method used to draw water or magma vertically across multiple z-levels requiring a minimum of parts. The basic functionality is possible because the Output (dark) side of the pump can be built over open space with a machine component located directly below, in this case another Screw Pump. Note that for power to properly transfer the intake (light) side of the pump must line up with the output (dark) side of the pump on the floor above it through a space in the floor, as in the illustration.

A pump stack minimizes the amount of machinery required to lift water or magma by allowing for power to be supplied directly to only the most accessible pump (typically the topmost) which in turn allows the player to operate a stack limited only by how many windmills/water wheels they can fit into the area. The price of optimal parts density is fragility: each pump relies on the pump below it for support. If {{L|forgotten beast|anything}} breaks a pump in your stack, every pump above it will be disassembled. This means that a single pump accidentally assembled with non-magma-safe parts can cause an entire magma pump stack to spontaneously disassemble.

Typical applications for a pump stack include moving magma from a lower level (often the {{L|magma sea}}) up to a convenient level for forges and furnaces, extracting water from a flooded fort, raising water for a decorative {{l|waterfall}} (and extracting it afterwards), or any other purpose that requires water/magma on a z-level significantly above its current location.

The Illustrated Top View of a Pump Stack Layer shows a basic section of a pump stack. Only the door (or a floodgate) on the Containment side is strictly necessary in order to prevent flooding. Two doorways are used here, each lining up with the solid ground within the pump assembly, in order to prevent workers from trapping themselves after digging channels or assembling the pump.

Be warned: pump stacks move water '''fast.''' If you are pumping from a large reservoir into an open area, be prepared for a huge outflow, roughly akin to the kind of water dump you'd get if the whole reservoir was balanced above the pump output and then released. If you are using pumps to empty a large underground reservoir (or, say, a flooded fortress) onto open land, use an aqueduct or some other method to make sure the pump system outlet is a good distance away from anything you wouldn't want to get drenched.

As an alternative to a large reservoir, it is also possible to combine a {{L|Dwarven Atom Smasher}} with the top layer of the Pump Stack to create a "vacuum cleaner" of sorts.

====Tips====

* Ramps can be used in place of channeling. Liquids will transmit through ramps, unlike stairs, and when pumps are constructed they annihilate the ramp they're built on much as walls do. Power will still be transmitted, so they don't need to be removed by miners prior to pump construction. Ramps make it virtually impossible to strand your miners and allows the stack to be dug out using only access doorways on the intake side of the pump, so no construction or doors are later needed to eliminate leaks. A pump stack can be very rapidly carved out with this method as even if a miner/builder is trapped on the containment side of a pump, they can walk up the ramp to the intake side of the pump above and walk out.
* Power can be transmitted to the stack by channeling out the tile directly above the intake (light) tile of the topmost pump and mounting a gear assembly. If the gear assembly is supported by an adjacent gear assembly or horizontal axle on a stable floor (be careful to not have that adjacent gear assembly disengage via lever), this will allow the stack to hang from the gear assembly. If a lower pump needs to be removed, or should self-destruct, the problem of the entire pump stack disassembling described above is eliminated. Further, if the supported gear assembly is built first, the pump stack can be built both from the top and bottom simultaneously, halving construction time, assuming that sufficient attention is paid to make sure that the pumps will align with the proper orientation when the two partial stacks meet. Properly channeling/ramping out the stack should ensure this.
* When pumping magma, make sure any underground soil tiles on the containment side of the stack are covered with a stone floor (need not be magma safe) to prevent subterranean trees from growing and blocking flow of the stack. When pumping water, it's safest to construct a paved road or slab on any underground tiles on the containment side to prevent subterranean trees from growing and blocking flow. Roads block tree growth, but smoothed or constructed tiles do not when muddied. Currently, designating a stockpile will serve the same goal, but that may not work in the future and if you accidentally de-designate the stockpile, a tree may instantly spring up blocking flow as they do grow 'underneath' the stockpile, hidden until the stockpile is removed.

===Improved Magma Pump Stack===

Because a pump stack pumping magma is known to cause significant {{L|Maximizing_framerate|lag}}, a [http://www.bay12forums.com/smf/index.php?topic=72296.0 new type of pump stack] was developed by [http://www.bay12forums.com/smf/index.php?action=profile;u=19835 NecroRebel] that causes a much smaller drop in [[FPS]]. Changing the single tile magma chamber at the output of every pump from a 1 by 1 to a 3 by 3 area reduces the lag to 1/15th of that caused by the original pump stack. The designer hypothesizes that the larger chamber requires many fewer temperature calculations when magma is pumped in or out; that also implies that there will be no improvement for water pumps.

====Newer Magma Pump Breakthroughs====

Newer breakthroughs in magma pump design has since made the 3x3 reservoir design obsolete.
NecroRebel has tested a [http://www.bay12forums.com/smf/index.php?topic=72296.msg1772802#msg1772802 1x3 head-over-tail variation] (which is very similar to {{L|Screw_pump#Pump_stack|the typical 1 by 1 pump stack}}) as well as a [http://www.bay12forums.com/smf/index.php?topic=72296.msg1795907#msg1795907 2x3 head-over-head variation]. Both of these new designs require less space and work as effective as his original 3x3 reservoir head-over-head design, with no significant drop in FPS. The 1x3 head-over-tail design has the advantages of requiring the least amount of space and it being simple to retrofit from the standard 1 by 1 water pump stack.

{{buildings}}

v0.31:Screw pump

2011-06-18T04:45:16Z

Thundercraft: /* Improved Magma Pump Stack */ Updating 'Improved Magma Pump Stack' with NecroRebel's newest design

{{quality|Masterwork|21:05, 26 April 2011 (UTC)}}{{av}}

{{Machine_component|name=Screw pump|key=s|job={{L|Pump operator}}
|construction=
* {{L|Trap component#Enormous corkscrew|Enormous corkscrew}}
* {{L|Pipe section}}
* {{L|Block}}
|construction_job=
* {{L|Architecture}}
* 1 of
** {{L|Carpentry}}
** {{L|Masonry}}
** {{L|Metalsmithing}}
|power=Needs 10 power.
}}

A '''screw pump''' is a small {{L|building}} that can lift liquids ({{L|water}} or {{L|magma}}) from one level below onto the same {{L|Z-level}} as the pump. It is two tiles by one tile in size, and it can be either manually operated by a {{L|dwarf}} with the {{L|pump operator}} job or by being {{L|power}}ed by {{L|water wheel}}s and/or {{L|windmill}}s.

The direction you want the fluid to travel must be chosen at the time of construction. Pumping only occurs in a straight line, and involves a total of 4 tiles in a row - the liquid source, two for the pump, and the output. The "rise" in levels occurs on the first tile, the intake side, from one level below up to the level of the pump*. Pumped fluids can and will flow immediately after being pumped, as normal for that fluid. Pumped fluids will have a {{L|pressure}} equal to the exit {{L|z-level}} - a pump never "forces" water to a higher {{L|z-level}} than the output tile.

:''(* A DF pump can best be imagined as a simple [http://en.wikipedia.org/wiki/Archimedes%27_screw archimedes screw].)''

Salt water pumped through a pump will desalinate and become drinkable. However if the water then touches any natural water or tiles, smoothed or not, it will immediately be undrinkable again. So it is important to pump into a reservoir that is made entirely of constructed material. Please note that the block/tile underneath the reservoir-side of the pump also needs to be a construction.

Stagnant water pumped through a pump will become clean, letting dwarves drink it without getting an unhappy {{L|thought}} and letting {{L|doctor}}s clean {{L|wound}}s without causing an {{L|Health care#Infection|infection}}. Unlike with desalination, stagnation-removal doesn't require avoidance of natural tiles, even in a wetlands biome.

''For a basic overview of how the different machine parts work and work together, see {{L|machinery}}.''

== Construction ==

Building a screw pump requires an {{L|Trap component#Enormous corkscrew|enormous corkscrew}}, a {{L|block}}, and a {{L|pipe section}}. The construction itself is completed in two stages. First a dwarf with the {{L|architect}} labor must design it. Then a dwarf (the same or a different one) with the appropriate labor must complete the building. This could be {{L|carpentry}}, {{L|metalsmithing}}, or {{L|masonry}}, depending on the material of the block.

To select pump, use keys {{k|b}}-{{k|M}}-{{k|s}}. It's important to choose the proper orientation for your pump, where it will draw water from and where it will deliver the water. This is determined before placement with the {{k|u}}, {{k|k}}, {{k|m}}, or {{k|h}} keys, and the text at the top of the sub-menu will change to confirm your choice. The default (as shown above in the sidebar), "pumps from the north" (top). The ''light'' green X must be next to the liquid source and the ''dark'' green X is where the liquid exits the pump.

[[Image:Small pump.jpg|thumb|right|300px|'''Basic Side View of a Pump'''. This pump "pumps from the west", from left to right. The area to the right may fill to the top of that level, but no more (See {{L|pressure}}; see {{L|Screw pump#Pump Stack|Pump stack}}). Note that the entire space required is 4 tiles long by 1 tile wide, not including any retaining walls for the outflow. If pumped manually, the {{L|pump operator}} stands in the light-colored area, as the dark-colored is impassable to both fluid and movement. ''(Although the "liquid" is shown as blue, this can work for {{L|magma|magma}} as well, with the {{L|magma-safe|appropriate precautions}}.)'']]

The example shown in the infobox above "pumps from the north" (top) to the south (bottom). If pumped manually, the dwarf stands on the light-colored tile, as the dark-colored is impassable.

The orientation is visible after placement by using {{k|q}}uery over or near that pump or during placement, using UMKH to select the direction of input. Orientation of a pump cannot be changed after being constructed, but, as with any building, it can be deconstructed into its component parts and rebuilt as and where desired.

Having specified the direction of travel, you must ensure that the source side of the pump is placed adjacent to and above (in the {{L|z-axis}}) a liquid. The screw pump will draw the liquid up from below its level, and distribute it out of the other side of the pump.

== Notes ==

* The source of the pump must be directionally adjacent to "Open Space" that is directly above a source of liquid. The adjacent space cannot be a floor, stairway or wall suspended over water. Screw pumps can pull water through a {{L|grate}}, floor {{L|bars}}, or a {{L|construction|constructed}} {{L|fortification}} on the Z-level below.
* The light pump tile is where a pump operator will stand (if the pump is not powered mechanically). Liquids to be pumped must be 1 level below the (empty) area adjacent to this tile.
* Dwarves must be able to access and stand on the light tile of the pump in order to build the pump and then to be able to operate the pump manually.
* The dark pump tile is on the output side. Liquids will appear in the tile adjacent to this.
* The dark pump tile blocks liquids flow and creature movement, and can be built into a wall to create a solid barrier. The light tile of the pump does not block flow or movement.
* Pumps can also be used in conjunction with a {{L|water wheel}} or a {{L|windmill}} to become self-powered.
* Active mechanisms connected to the pump will automatically start the pump; to prevent this either restrict liquid flow using floodgates or hatches, or put in a {{L|gear assembly}} linked to a {{L|lever}} to disconnect the {{L|power}}.
* Adjacent pumps ''automatically'' transfer mechanical power to any other adjacent pump(s), no {{L|axle}} or {{L|mechanism}} is required. If too many pumps are adjacent, there may be insufficient power to power them.
* A hatch above the input tile (on the same level as the pump) that is linked to a trigger (a {{L|lever}} or {{L|pressure plate}}) makes an effective on/off switch for that pump.
* In order to build pumps in a "hanging" state, as in the stacked screw pump example (below), one of its tiles must be able to connect to a nearby machine, either already existing or designated to be built. If, when the screw pump's construction is completed, the supporting mechanism has not yet been completed, it will promptly collapse into its component parts.
* Pumps do '''not''' push liquids '''up''' additional Z-levels above them. They only deliver water to their own level. That is, if you direct the output of a screw pump into a 1-square space surrounded by walls, the water will not "overflow" the walls. Consequently, a pump will refuse to move liquid if the level it is pumping to is completely filled. Higher levels can be achieved using a "pump stack" (below). (See {{L|Pressure}})
* In order to safely pump magma, you must use {{L|magma-safe}} materials, though magma-unsafe metals have been observed to be safe unless the open tile is going to be submerged in magma. Wooden parts will burst into flames the instant the pump is activated, and magma-unsafe stone {{L|block}}s melt after a short time.
* Magma, which normally has no pressure, will behave as though pressurized when pumped. For example, when pumped into an U-turn, magma will come out at the other end. Normal (non-pumped) magma would just pool at the lowest level. This may be either very useful (can be used to build pressure towers for magma) or deadly (forge level flooded with magma, because someone tried to pump magma into a volcano).
* Pump's pseudo-pressure doesn't work across diagonals. If there is a diagonal-only passage in your tunnel, liquids will seep slowly through it, instead of bursting through above their normal maximal speed, like they would if there was good passage.
* The liquid in a pump's intake tile must have a depth of at least 2/7 for the pump to be able to remove any amount of liquid from it.
* If a pump's intake tile on the z-level below the pump becomes blocked (as with a cave-in or magma cooling into obsidian) the pump will still run but not pump any fluid.
* If a pump's output tile has magma but the pump is pumping water (or vice versa), the output tile will be turned into {{L|obsidian}}.

====Common mistakes====
* Orienting a pump incorrectly, and/or not having a proper open liquid source.
* Pumping water into an area with a path to other parts of your fortress. (The pump may work perfectly - the fortress quickly {{L|flood}}s.)
* Expecting water to rise up above the same level of a pump.
* Building a wall attached only to the light tile - this leaves a diagonal leak between the wall and the dark tile unless sealed there. (If that's not a problem, don't worry about it.)
* Having stairs as input tile. Stairs block input tile, thus rendering the pump useless, even though liquids usually ignore stairs. Output tile can be any liquid-passable tile.
* Not channeling below the impassable tile of an individual pump in a pump stack. This is how power is transmitted to the pump below.
* Pumping magma into a lower z-level (same as the source) and then being surprised it is forced back up to the same z-level further down the line (where you were planning your magma forges, for example.)

== Example layouts ==
=== Single pump ===

[[Image:jt_screwpump.png|frame|left|A screw pump delivers from the level below to the tile in front. This pump pumps from the right to the left. The "dark tile" would be on the left - that entire tile is impassible to movement and fluids.]] 
=== Pump stack ===
[[File:PumpStack2010.png|thumb|right|300px|'''Illustrated Side View of a Pump Stack.''']]
[[File:PumpStackTopView.png|thumb|right|300px|'''Illustrated Top View of a Pump Stack Layer.''']]
[[File:Pumpstack.gif|thumb|right|'''Animation showing the general construction using an isometric projection.''']]

A Pump stack is a method used to draw water or magma vertically across multiple z-levels requiring a minimum of parts. The basic functionality is possible because the Output (dark) side of the pump can be built over open space with a machine component located directly below, in this case another Screw Pump. Note that for power to properly transfer the intake (light) side of the pump must line up with the output (dark) side of the pump on the floor above it through a space in the floor, as in the illustration.

A pump stack minimizes the amount of machinery required to lift water or magma by allowing for power to be supplied directly to only the most accessible pump (typically the topmost) which in turn allows the player to operate a stack limited only by how many windmills/water wheels they can fit into the area. The price of optimal parts density is fragility: each pump relies on the pump below it for support. If {{L|forgotten beast|anything}} breaks a pump in your stack, every pump above it will be disassembled. This means that a single pump accidentally assembled with non-magma-safe parts can cause an entire magma pump stack to spontaneously disassemble.

Typical applications for a pump stack include moving magma from a lower level (often the {{L|magma sea}}) up to a convenient level for forges and furnaces, extracting water from a flooded fort, raising water for a decorative {{l|waterfall}} (and extracting it afterwards), or any other purpose that requires water/magma on a z-level significantly above its current location.

The Illustrated Top View of a Pump Stack Layer shows a basic section of a pump stack. Only the door (or a floodgate) on the Containment side is strictly necessary in order to prevent flooding. Two doorways are used here, each lining up with the solid ground within the pump assembly, in order to prevent workers from trapping themselves after digging channels or assembling the pump.

Be warned: pump stacks move water '''fast.''' If you are pumping from a large reservoir into an open area, be prepared for a huge outflow, roughly akin to the kind of water dump you'd get if the whole reservoir was balanced above the pump output and then released. If you are using pumps to empty a large underground reservoir (or, say, a flooded fortress) onto open land, use an aqueduct or some other method to make sure the pump system outlet is a good distance away from anything you wouldn't want to get drenched.

As an alternative to a large reservoir, it is also possible to combine a {{L|Dwarven Atom Smasher}} with the top layer of the Pump Stack to create a "vacuum cleaner" of sorts.

====Tips====

* Ramps can be used in place of channeling. Liquids will transmit through ramps, unlike stairs, and when pumps are constructed they annihilate the ramp they're built on much as walls do. Power will still be transmitted, so they don't need to be removed by miners prior to pump construction. Ramps make it virtually impossible to strand your miners and allows the stack to be dug out using only access doorways on the intake side of the pump, so no construction or doors are later needed to eliminate leaks. A pump stack can be very rapidly carved out with this method as even if a miner/builder is trapped on the containment side of a pump, they can walk up the ramp to the intake side of the pump above and walk out.
* Power can be transmitted to the stack by channeling out the tile directly above the intake (light) tile of the topmost pump and mounting a gear assembly. If the gear assembly is supported by an adjacent gear assembly or horizontal axle on a stable floor (be careful to not have that adjacent gear assembly disengage via lever), this will allow the stack to hang from the gear assembly. If a lower pump needs to be removed, or should self-destruct, the problem of the entire pump stack disassembling described above is eliminated. Further, if the supported gear assembly is built first, the pump stack can be built both from the top and bottom simultaneously, halving construction time, assuming that sufficient attention is paid to make sure that the pumps will align with the proper orientation when the two partial stacks meet. Properly channeling/ramping out the stack should ensure this.
* When pumping magma, make sure any underground soil tiles on the containment side of the stack are covered with a stone floor (need not be magma safe) to prevent subterranean trees from growing and blocking flow of the stack. When pumping water, it's safest to construct a paved road or slab on any underground tiles on the containment side to prevent subterranean trees from growing and blocking flow. Roads block tree growth, but smoothed or constructed tiles do not when muddied. Currently, designating a stockpile will serve the same goal, but that may not work in the future and if you accidentally de-designate the stockpile, a tree may instantly spring up blocking flow as they do grow 'underneath' the stockpile, hidden until the stockpile is removed.

===Improved Magma Pump Stack===

Because a pump stack pumping magma is known to cause significant {{L|Maximizing_framerate|lag}}, a [http://www.bay12forums.com/smf/index.php?topic=72296.0 new type of pump stack] was developed by [http://www.bay12forums.com/smf/index.php?action=profile;u=19835 NecroRebel] that causes a much smaller drop in [[FPS]]. Changing the single tile magma chamber at the output of every pump from a 1 by 1 to a 3 by 3 area reduces the lag to 1/15th of that caused by the original pump stack. The designer hypothesizes that the larger chamber requires many fewer temperature calculations when magma is pumped in or out; that also implies that there will be no improvement for water pumps.

====Newer Magma Pump Breakthroughs====

Newer breakthroughs in magma pump design has since made the 3x3 reservoir design obsolete.
NecroRebel has since tested a [http://www.bay12forums.com/smf/index.php?topic=72296.msg1772802#msg1772802 1x3 head-over-tail variation] (which is very similar to {{L|Screw_pump#Pump_stack|the typical 1 by 1 pump stack}}) as well as a [http://www.bay12forums.com/smf/index.php?topic=72296.msg1795907#msg1795907 2x3 head-over-head variation]. Both of these new designs require less space and work as effective as his original 3x3 reservoir head-over-head design, with no significant drop in FPS. The 1x3 head-over-tail design has the advantages of requiring the least amount of space and it being simple to retrofit from the standard 1 by 1 water pump stack.

{{buildings}}

v0.31:Temperature

2011-06-13T01:46:54Z

Thundercraft: /* Conversion */ Mentioned the Temperature Conversion Utility as an alternative to converting manually

{{quality|Fine|08:00, 22 May 2010 (UTC)}}{{av}}

''For temperature as it relates to choosing an embarkation site, see [[DF2010:Climate|Climate]].''

==Temperature scale==
Dwarf Fortress uses its own temperature scale in most cases, often called "Degrees [[Urist]]" on this wiki.
So if you see something like [HOMEOTHERM:10067], don't be amazed.

[[Magma]]'s temperature is 12,000° Urist.

The highest possible temperature in Dwarf Fortress is 60,000°U - the temperature 60,001°U is used internally for temperatures which have been set to "NONE".

===Conversion===

[DF scale] = [FAHRENHEIT] + 9968

[DF scale] = [CELSIUS] * 9/5 + 10000

[DF scale] = [KELVIN] * 9/5 + 9508.33

[DF scale] = [RANKINE] + 9508.33

''(Note: Mod-makers may find this [http://www.bay12forums.com/smf/index.php?topic=80523.0 Temperature Conversion Utility] handy if they find themselves having to convert a lot of temperatures to and/or from Degrees Urist.)''

===Reference Chart===

{| {{prettytable}}
|- bgcolor="#ddd"
! Significance
! DF Scale
! Fahrenheit
! Celsius
! Kelvin
! Rankine

|-
|Human Body Temperature
| 10066.62
| 98.6
| 37.0
| 310.15
| 558.27

|-
| Freezing Point of Water
| 10000
| 32
| 0
| 273.15
| 491.67

|-
| Boiling Point of Water
| 10180
| 212
| 100
| 373.15
| 671.67

|-
| Absolute Zero
| 9508.332
| -459.67
| −273.15
| 0
| 0

|-
| DF Scale's Zero1
| 0
| -9968
| -5555.555...
| -5282.40555...
| -9508.33
|}


:1 - Yes, temperatures in Dwarf Fortress can go '''far, far''' below absolute zero, which is physically impossible. Considering Dwarf Fortress also allows {{L|water wheel#Perpetual motion|perpetual motion}}, it's best not to ask questions.
:2 - Technically, fractional/decimal temperatures are not possible in Dwarf Fortress, as they are stored as unsigned 16-bit integers. For instance, body temp for humans in the raws is rounded to 10067.


Some general information about temperatures in DF (copied from somewhere on the forums):
{| class="prettytable"
|-
! Event / location
! Temperature
|-
| alcohol freezes
| 9850 U
|-
| water freezes
| 10000 U
|-
| underground
| 10015 U
|-
| outside (varies)
| 10048 U
|-
| dwarf/human body temp
| 10067 U
|-
| floor above magma
| 10075 U
|-
| fat melts
| 10078 U
|-
| water boils
| 10180 U
|-
| common stone melts
| 11500 U
|-
| magma
| 12000 U
|-
|}

==Melting point==

This is the temperature at which an object will melt. Any material with a melting point over 12,000 °U is {{L|magma-safe}}.

==Boiling point==

This is the temperature at which an object will evaporate.

==Ignition point==

This is the temperature at which an object will catch fire.

==Heat damage point==

This is the temperature above which an object will begin to take {{L|wear|damage}}. Flammable items without a heat damage point (or with an exceptionally high one) will take damage very slowly, causing them to burn for about 9-10 months before disappearing.

==Cold damage point==

This is the temperature below which an object will begin to take {{L|wear|damage}}.

==Specific heat==

This determines how long it takes an object to heat up or cool down. An object with high specific heat will change temperature more slowly.

v0.31:Screw pump

2011-06-09T23:09:51Z

Thundercraft: /* Improved Magma Pump Stack */ Minor clarification

{{quality|Masterwork|21:05, 26 April 2011 (UTC)}}{{av}}

{{Machine_component|name=Screw pump|key=s|job={{L|Pump operator}}
|construction=
* {{L|Trap component#Enormous corkscrew|Enormous corkscrew}}
* {{L|Pipe section}}
* {{L|Block}}
|construction_job=
* {{L|Architecture}}
* 1 of
** {{L|Carpentry}}
** {{L|Masonry}}
** {{L|Metalsmithing}}
|power=Needs 10 power.
}}

A '''screw pump''' is a small {{L|building}} that can lift liquids ({{L|water}} or {{L|magma}}) from one level below onto the same {{L|Z-level}} as the pump. It is two tiles by one tile in size, and it can be either manually operated by a {{L|dwarf}} with the {{L|pump operator}} job or by being {{L|power}}ed by {{L|water wheel}}s and/or {{L|windmill}}s.

The direction you want the fluid to travel must be chosen at the time of construction. Pumping only occurs in a straight line, and involves a total of 4 tiles in a row - the liquid source, two for the pump, and the output. The "rise" in levels occurs on the first tile, the intake side, from one level below up to the level of the pump*. Pumped fluids can and will flow immediately after being pumped, as normal for that fluid. Pumped fluids will have a {{L|pressure}} equal to the exit {{L|z-level}} - a pump never "forces" water to a higher {{L|z-level}} than the output tile.

:''(* A DF pump can best be imagined as a simple [http://en.wikipedia.org/wiki/Archimedes%27_screw archimedes screw].)''

Salt water pumped through a pump will desalinate and become drinkable. However if the water then touches any natural water or tiles, smoothed or not, it will immediately be undrinkable again. So it is important to pump into a reservoir that is made entirely of constructed material. Please note that the block/tile underneath the reservoir-side of the pump also needs to be a construction.

''For a basic overview of how the different machine parts work and work together, see {{L|machinery}}.''

== Construction ==

Building a screw pump requires an {{L|Trap component#Enormous corkscrew|enormous corkscrew}}, a {{L|block}}, and a {{L|pipe section}}. The construction itself is completed in two stages. First a dwarf with the {{L|architect}} labor must design it. Then a dwarf (the same or a different one) with the appropriate labor must complete the building. This could be {{L|carpentry}}, {{L|metalsmithing}}, or {{L|masonry}}, depending on the material of the block.

To select pump, use keys {{k|b}}-{{k|M}}-{{k|s}}. It's important to choose the proper orientation for your pump, where it will draw water from and where it will deliver the water. This is determined before placement with the {{k|u}}, {{k|k}}, {{k|m}}, or {{k|h}} keys, and the text at the top of the sub-menu will change to confirm your choice. The default (as shown above in the sidebar), "pumps from the north" (top). The ''light'' green X must be next to the liquid source and the ''dark'' green X is where the liquid exits the pump.

[[Image:Small pump.jpg|thumb|right|300px|'''Basic Side View of a Pump'''. This pump "pumps from the west", from left to right. The area to the right may fill to the top of that level, but no more (See {{L|pressure}}; see {{L|Screw pump#Pump Stack|Pump stack}}). Note that the entire space required is 4 tiles long by 1 tile wide, not including any retaining walls for the outflow. If pumped manually, the {{L|pump operator}} stands in the light-colored area, as the dark-colored is impassable to both fluid and movement. ''(Although the "liquid" is shown as blue, this can work for {{L|magma|magma}} as well, with the {{L|magma-safe|appropriate precautions}}.)'']]

The example shown in the infobox above "pumps from the north" (top) to the south (bottom). If pumped manually, the dwarf stands on the light-colored tile, as the dark-colored is impassable.

The orientation is visible after placement by using {{k|q}}uery over or near that pump or during placement, using UMKH to select the direction of input. Orientation of a pump cannot be changed after being constructed, but, as with any building, it can be deconstructed into its component parts and rebuilt as and where desired.

Having specified the direction of travel, you must ensure that the source side of the pump is placed adjacent to and above (in the {{L|z-axis}}) a liquid. The screw pump will draw the liquid up from below its level, and distribute it out of the other side of the pump.

== Notes ==

* The source of the pump must be directionally adjacent to "Open Space" that is directly above a source of liquid. The adjacent space cannot be a floor, stairway or wall suspended over water. Screw pumps can pull water through a {{L|grate}}, floor {{L|bars}}, or a {{L|construction|constructed}} {{L|fortification}} on the Z-level below.
* The light pump tile is where a pump operator will stand (if the pump is not powered mechanically). Liquids to be pumped must be 1 level below the (empty) area adjacent to this tile.
* Dwarves must be able to access and stand on the light tile of the pump in order to build the pump and then to be able to operate the pump manually.
* The dark pump tile is on the output side. Liquids will appear in the tile adjacent to this.
* The dark pump tile blocks liquids flow and creature movement, and can be built into a wall to create a solid barrier. The light tile of the pump does not block flow or movement.
* Pumps can also be used in conjunction with a {{L|water wheel}} or a {{L|windmill}} to become self-powered.
* Active mechanisms connected to the pump will automatically start the pump; to prevent this either restrict liquid flow using floodgates or hatches, or put in a {{L|gear assembly}} linked to a {{L|lever}} to disconnect the {{L|power}}.
* Adjacent pumps ''automatically'' transfer mechanical power to any other adjacent pump(s), no {{L|axle}} or {{L|mechanism}} is required. If too many pumps are adjacent, there may be insufficient power to power them.
* A hatch above the input tile (on the same level as the pump) that is linked to a trigger (a {{L|lever}} or {{L|pressure plate}}) makes an effective on/off switch for that pump.
* In order to build pumps in a "hanging" state, as in the stacked screw pump example (below), one of its tiles must be able to connect to a nearby machine, either already existing or designated to be built. If, when the screw pump's construction is completed, the supporting mechanism has not yet been completed, it will promptly collapse into its component parts.
* Pumps do '''not''' push liquids '''up''' additional Z-levels above them. They only deliver water to their own level. That is, if you direct the output of a screw pump into a 1-square space surrounded by walls, the water will not "overflow" the walls. Consequently, a pump will refuse to move liquid if the level it is pumping to is completely filled. Higher levels can be achieved using a "pump stack" (below). (See {{L|Pressure}})
* In order to safely pump magma, you must use {{L|magma-safe}} materials, though magma-unsafe metals have been observed to be safe unless the open tile is going to be submerged in magma. Wooden parts will burst into flames the instant the pump is activated, and magma-unsafe stone {{L|block}}s melt after a short time.
* Magma, which normally has no pressure, will behave as though pressurized when pumped. For example, when pumped into an U-turn, magma will come out at the other end. Normal (non-pumped) magma would just pool at the lowest level. This may be either very useful (can be used to build pressure towers for magma) or deadly (forge level flooded with magma, because someone tried to pump magma into a volcano).
* Pump's pseudo-pressure doesn't work across diagonals. If there is a diagonal-only passage in your tunnel, liquids will seep slowly through it, instead of bursting through above their normal maximal speed, like they would if there was good passage.
* The liquid in a pump's intake tile must have a depth of at least 2/7 for the pump to be able to remove any amount of liquid from it.
* If a pump's intake tile on the z-level below the pump becomes blocked (as with a cave-in or magma cooling into obsidian) the pump will still run but not pump any fluid.
* If a pump's output tile has magma but the pump is pumping water (or vice versa), the output tile will be turned into {{L|obsidian}}.

====Common mistakes====
* Orienting a pump incorrectly, and/or not having a proper open liquid source.
* Pumping water into an area with a path to other parts of your fortress. (The pump may work perfectly - the fortress quickly {{L|flood}}s.)
* Expecting water to rise up above the same level of a pump.
* Building a wall attached only to the light tile - this leaves a diagonal leak between the wall and the dark tile unless sealed there. (If that's not a problem, don't worry about it.)
* Having stairs as input tile. Stairs block input tile, thus rendering the pump useless, even though liquids usually ignore stairs. Output tile can be any liquid-passable tile.
* Not channeling below the impassable tile of an individual pump in a pump stack. This is how power is transmitted to the pump below.
* Pumping magma into a lower z-level (same as the source) and then being surprised it is forced back up to the same z-level further down the line (where you were planning your magma forges, for example.)

== Example layouts ==
=== Single pump ===

[[Image:jt_screwpump.png|frame|left|A screw pump delivers from the level below to the tile in front. This pump pumps from the right to the left. The "dark tile" would be on the left - that entire tile is impassible to movement and fluids.]] 
=== Pump stack ===
[[File:PumpStack2010.png|thumb|right|300px|'''Illustrated Side View of a Pump Stack.''']]
[[File:PumpStackTopView.png|thumb|right|300px|'''Illustrated Top View of a Pump Stack Layer.''']]
[[File:Pumpstack.gif|thumb|right|'''Animation showing the general construction using an isometric projection.''']]

A Pump stack is a method used to draw water or magma vertically across multiple z-levels requiring a minimum of parts. The basic functionality is possible because the Output (dark) side of the pump can be built over open space with a machine component located directly below, in this case another Screw Pump. Note that for power to properly transfer the intake (light) side of the pump must line up with the output (dark) side of the pump on the floor above it through a space in the floor, as in the illustration.

A pump stack minimizes the amount of machinery required to lift water or magma by allowing for power to be supplied directly to only the most accessible pump (typically the topmost) which in turn allows the player to operate a stack limited only by how many windmills/water wheels they can fit into the area. The price of optimal parts density is fragility: each pump relies on the pump below it for support. If {{L|forgotten beast|anything}} breaks a pump in your stack, every pump above it will be disassembled. This means that a single pump accidentally assembled with non-magma-safe parts can cause an entire magma pump stack to spontaneously disassemble.

Typical applications for a pump stack include moving magma from a lower level (often the {{L|magma sea}}) up to a convenient level for forges and furnaces, extracting water from a flooded fort, raising water for a decorative {{l|waterfall}} (and extracting it afterwards), or any other purpose that requires water/magma on a z-level significantly above its current location.

The Illustrated Top View of a Pump Stack Layer shows a basic section of a pump stack. Only the door (or a floodgate) on the Containment side is strictly necessary in order to prevent flooding. Two doorways are used here, each lining up with the solid ground within the pump assembly, in order to prevent workers from trapping themselves after digging channels or assembling the pump.

Be warned: pump stacks move water '''fast.''' If you are pumping from a large reservoir into an open area, be prepared for a huge outflow, roughly akin to the kind of water dump you'd get if the whole reservoir was balanced above the pump output and then released. If you are using pumps to empty a large underground reservoir (or, say, a flooded fortress) onto open land, use an aqueduct or some other method to make sure the pump system outlet is a good distance away from anything you wouldn't want to get drenched.

As an alternative to a large reservoir, it is also possible to combine a {{L|Dwarven Atom Smasher}} with the top layer of the Pump Stack to create a "vacuum cleaner" of sorts.

====Tips====

* Ramps can be used in place of channeling. Liquids will transmit through ramps, unlike stairs, and when pumps are constructed they annihilate the ramp they're built on much as walls do. Power will still be transmitted, so they don't need to be removed by miners prior to pump construction. Ramps make it virtually impossible to strand your miners and allows the stack to be dug out using only access doorways on the intake side of the pump, so no construction or doors are later needed to eliminate leaks. A pump stack can be very rapidly carved out with this method as even if a miner/builder is trapped on the containment side of a pump, they can walk up the ramp to the intake side of the pump above and walk out.
* Power can be transmitted to the stack by channeling out the tile directly above the intake (light) tile of the topmost pump and mounting a gear assembly. If the gear assembly is supported by an adjacent gear assembly or horizontal axle on a stable floor (be careful to not have that adjacent gear assembly disengage via lever), this will allow the stack to hang from the gear assembly. If a lower pump needs to be removed, or should self-destruct, the problem of the entire pump stack disassembling described above is eliminated. Further, if the supported gear assembly is built first, the pump stack can be built both from the top and bottom simultaneously, halving construction time, assuming that sufficient attention is paid to make sure that the pumps will align with the proper orientation when the two partial stacks meet. Properly channeling/ramping out the stack should ensure this.
* When pumping magma, make sure any underground soil tiles on the containment side of the stack are covered with a stone floor (need not be magma safe) to prevent subterranean trees from growing and blocking flow of the stack. When pumping water, it's safest to construct a paved road or slab on any underground tiles on the containment side to prevent subterranean trees from growing and blocking flow. Roads block tree growth, but smoothed or constructed tiles do not when muddied. Currently, designating a stockpile will serve the same goal, but that may not work in the future and if you accidentally de-designate the stockpile, a tree may instantly spring up blocking flow as they do grow 'underneath' the stockpile, hidden until the stockpile is removed.

====Improved Magma Pump Stack====

Because a pump stack pumping magma is known to cause significant {{L|Maximizing_framerate|lag}}, a [http://www.bay12forums.com/smf/index.php?topic=72296.0 new type of pump stack] was developed by [http://www.bay12forums.com/smf/index.php?action=profile;u=19835 NecroRebel] that causes a much smaller drop in [[FPS]]. Changing the single tile magma chamber at the output of every pump from a 1 by 1 to a 3 by 3 area reduces the lag to 1/15th of that caused by the original pump stack. (NecroRebel has since tested [http://www.bay12forums.com/smf/index.php?topic=72296.msg1795907#msg1795907 a 2x3 head-over-head reservoir variation] and the results so far suggest it's just as effective as his original 3x3 design, with no significant drop in FPS.) The designer hypothesizes that the larger chamber requires many fewer temperature calculations when magma is pumped in or out; that also implies that there will be no improvement for water pumps.

{{buildings}}

v0.31:Screw pump

2011-06-09T00:26:11Z

Thundercraft: /* Improved Magma Pump Stack */ Updated the improve magma pump stack info, credited NecroRebel, added links

{{quality|Masterwork|21:05, 26 April 2011 (UTC)}}{{av}}

{{Machine_component|name=Screw pump|key=s|job={{L|Pump operator}}
|construction=
* {{L|Trap component#Enormous corkscrew|Enormous corkscrew}}
* {{L|Pipe section}}
* {{L|Block}}
|construction_job=
* {{L|Architecture}}
* 1 of
** {{L|Carpentry}}
** {{L|Masonry}}
** {{L|Metalsmithing}}
|power=Needs 10 power.
}}

A '''screw pump''' is a small {{L|building}} that can lift liquids ({{L|water}} or {{L|magma}}) from one level below onto the same {{L|Z-level}} as the pump. It is two tiles by one tile in size, and it can be either manually operated by a {{L|dwarf}} with the {{L|pump operator}} job or by being {{L|power}}ed by {{L|water wheel}}s and/or {{L|windmill}}s.

The direction you want the fluid to travel must be chosen at the time of construction. Pumping only occurs in a straight line, and involves a total of 4 tiles in a row - the liquid source, two for the pump, and the output. The "rise" in levels occurs on the first tile, the intake side, from one level below up to the level of the pump*. Pumped fluids can and will flow immediately after being pumped, as normal for that fluid. Pumped fluids will have a {{L|pressure}} equal to the exit {{L|z-level}} - a pump never "forces" water to a higher {{L|z-level}} than the output tile.

:''(* A DF pump can best be imagined as a simple [http://en.wikipedia.org/wiki/Archimedes%27_screw archimedes screw].)''

Salt water pumped through a pump will desalinate and become drinkable. However if the water then touches any natural water or tiles, smoothed or not, it will immediately be undrinkable again. So it is important to pump into a reservoir that is made entirely of constructed material. Please note that the block/tile underneath the reservoir-side of the pump also needs to be a construction.

''For a basic overview of how the different machine parts work and work together, see {{L|machinery}}.''

== Construction ==

Building a screw pump requires an {{L|Trap component#Enormous corkscrew|enormous corkscrew}}, a {{L|block}}, and a {{L|pipe section}}. The construction itself is completed in two stages. First a dwarf with the {{L|architect}} labor must design it. Then a dwarf (the same or a different one) with the appropriate labor must complete the building. This could be {{L|carpentry}}, {{L|metalsmithing}}, or {{L|masonry}}, depending on the material of the block.

To select pump, use keys {{k|b}}-{{k|M}}-{{k|s}}. It's important to choose the proper orientation for your pump, where it will draw water from and where it will deliver the water. This is determined before placement with the {{k|u}}, {{k|k}}, {{k|m}}, or {{k|h}} keys, and the text at the top of the sub-menu will change to confirm your choice. The default (as shown above in the sidebar), "pumps from the north" (top). The ''light'' green X must be next to the liquid source and the ''dark'' green X is where the liquid exits the pump.

[[Image:Small pump.jpg|thumb|right|300px|'''Basic Side View of a Pump'''. This pump "pumps from the west", from left to right. The area to the right may fill to the top of that level, but no more (See {{L|pressure}}; see {{L|Screw pump#Pump Stack|Pump stack}}). Note that the entire space required is 4 tiles long by 1 tile wide, not including any retaining walls for the outflow. If pumped manually, the {{L|pump operator}} stands in the light-colored area, as the dark-colored is impassable to both fluid and movement. ''(Although the "liquid" is shown as blue, this can work for {{L|magma|magma}} as well, with the {{L|magma-safe|appropriate precautions}}.)'']]

The example shown in the infobox above "pumps from the north" (top) to the south (bottom). If pumped manually, the dwarf stands on the light-colored tile, as the dark-colored is impassable.

The orientation is visible after placement by using {{k|q}}uery over or near that pump or during placement, using UMKH to select the direction of input. Orientation of a pump cannot be changed after being constructed, but, as with any building, it can be deconstructed into its component parts and rebuilt as and where desired.

Having specified the direction of travel, you must ensure that the source side of the pump is placed adjacent to and above (in the {{L|z-axis}}) a liquid. The screw pump will draw the liquid up from below its level, and distribute it out of the other side of the pump.

== Notes ==

* The source of the pump must be directionally adjacent to "Open Space" that is directly above a source of liquid. The adjacent space cannot be a floor, stairway or wall suspended over water. Screw pumps can pull water through a {{L|grate}}, floor {{L|bars}}, or a {{L|construction|constructed}} {{L|fortification}} on the Z-level below.
* The light pump tile is where a pump operator will stand (if the pump is not powered mechanically). Liquids to be pumped must be 1 level below the (empty) area adjacent to this tile.
* Dwarves must be able to access and stand on the light tile of the pump in order to build the pump and then to be able to operate the pump manually.
* The dark pump tile is on the output side. Liquids will appear in the tile adjacent to this.
* The dark pump tile blocks liquids flow and creature movement, and can be built into a wall to create a solid barrier. The light tile of the pump does not block flow or movement.
* Pumps can also be used in conjunction with a {{L|water wheel}} or a {{L|windmill}} to become self-powered.
* Active mechanisms connected to the pump will automatically start the pump; to prevent this either restrict liquid flow using floodgates or hatches, or put in a {{L|gear assembly}} linked to a {{L|lever}} to disconnect the {{L|power}}.
* Adjacent pumps ''automatically'' transfer mechanical power to any other adjacent pump(s), no {{L|axle}} or {{L|mechanism}} is required. If too many pumps are adjacent, there may be insufficient power to power them.
* A hatch above the input tile (on the same level as the pump) that is linked to a trigger (a {{L|lever}} or {{L|pressure plate}}) makes an effective on/off switch for that pump.
* In order to build pumps in a "hanging" state, as in the stacked screw pump example (below), one of its tiles must be able to connect to a nearby machine, either already existing or designated to be built. If, when the screw pump's construction is completed, the supporting mechanism has not yet been completed, it will promptly collapse into its component parts.
* Pumps do '''not''' push liquids '''up''' additional Z-levels above them. They only deliver water to their own level. That is, if you direct the output of a screw pump into a 1-square space surrounded by walls, the water will not "overflow" the walls. Consequently, a pump will refuse to move liquid if the level it is pumping to is completely filled. Higher levels can be achieved using a "pump stack" (below). (See {{L|Pressure}})
* In order to safely pump magma, you must use {{L|magma-safe}} materials, though magma-unsafe metals have been observed to be safe unless the open tile is going to be submerged in magma. Wooden parts will burst into flames the instant the pump is activated, and magma-unsafe stone {{L|block}}s melt after a short time.
* Magma, which normally has no pressure, will behave as though pressurized when pumped. For example, when pumped into an U-turn, magma will come out at the other end. Normal (non-pumped) magma would just pool at the lowest level. This may be either very useful (can be used to build pressure towers for magma) or deadly (forge level flooded with magma, because someone tried to pump magma into a volcano).
* Pump's pseudo-pressure doesn't work across diagonals. If there is a diagonal-only passage in your tunnel, liquids will seep slowly through it, instead of bursting through above their normal maximal speed, like they would if there was good passage.
* The liquid in a pump's intake tile must have a depth of at least 2/7 for the pump to be able to remove any amount of liquid from it.
* If a pump's intake tile on the z-level below the pump becomes blocked (as with a cave-in or magma cooling into obsidian) the pump will still run but not pump any fluid.
* If a pump's output tile has magma but the pump is pumping water (or vice versa), the output tile will be turned into {{L|obsidian}}.

====Common mistakes====
* Orienting a pump incorrectly, and/or not having a proper open liquid source.
* Pumping water into an area with a path to other parts of your fortress. (The pump may work perfectly - the fortress quickly {{L|flood}}s.)
* Expecting water to rise up above the same level of a pump.
* Building a wall attached only to the light tile - this leaves a diagonal leak between the wall and the dark tile unless sealed there. (If that's not a problem, don't worry about it.)
* Having stairs as input tile. Stairs block input tile, thus rendering the pump useless, even though liquids usually ignore stairs. Output tile can be any liquid-passable tile.
* Not channeling below the impassable tile of an individual pump in a pump stack. This is how power is transmitted to the pump below.
* Pumping magma into a lower z-level (same as the source) and then being surprised it is forced back up to the same z-level further down the line (where you were planning your magma forges, for example.)

== Example layouts ==
=== Single pump ===

[[Image:jt_screwpump.png|frame|left|A screw pump delivers from the level below to the tile in front. This pump pumps from the right to the left. The "dark tile" would be on the left - that entire tile is impassible to movement and fluids.]] 
=== Pump stack ===
[[File:PumpStack2010.png|thumb|right|300px|'''Illustrated Side View of a Pump Stack.''']]
[[File:PumpStackTopView.png|thumb|right|300px|'''Illustrated Top View of a Pump Stack Layer.''']]
[[File:Pumpstack.gif|thumb|right|'''Animation showing the general construction using an isometric projection.''']]

A Pump stack is a method used to draw water or magma vertically across multiple z-levels requiring a minimum of parts. The basic functionality is possible because the Output (dark) side of the pump can be built over open space with a machine component located directly below, in this case another Screw Pump. Note that for power to properly transfer the intake (light) side of the pump must line up with the output (dark) side of the pump on the floor above it through a space in the floor, as in the illustration.

A pump stack minimizes the amount of machinery required to lift water or magma by allowing for power to be supplied directly to only the most accessible pump (typically the topmost) which in turn allows the player to operate a stack limited only by how many windmills/water wheels they can fit into the area. The price of optimal parts density is fragility: each pump relies on the pump below it for support. If {{L|forgotten beast|anything}} breaks a pump in your stack, every pump above it will be disassembled. This means that a single pump accidentally assembled with non-magma-safe parts can cause an entire magma pump stack to spontaneously disassemble.

Typical applications for a pump stack include moving magma from a lower level (often the {{L|magma sea}}) up to a convenient level for forges and furnaces, extracting water from a flooded fort, raising water for a decorative {{l|waterfall}} (and extracting it afterwards), or any other purpose that requires water/magma on a z-level significantly above its current location.

The Illustrated Top View of a Pump Stack Layer shows a basic section of a pump stack. Only the door (or a floodgate) on the Containment side is strictly necessary in order to prevent flooding. Two doorways are used here, each lining up with the solid ground within the pump assembly, in order to prevent workers from trapping themselves after digging channels or assembling the pump.

Be warned: pump stacks move water '''fast.''' If you are pumping from a large reservoir into an open area, be prepared for a huge outflow, roughly akin to the kind of water dump you'd get if the whole reservoir was balanced above the pump output and then released. If you are using pumps to empty a large underground reservoir (or, say, a flooded fortress) onto open land, use an aqueduct or some other method to make sure the pump system outlet is a good distance away from anything you wouldn't want to get drenched.

As an alternative to a large reservoir, it is also possible to combine a {{L|Dwarven Atom Smasher}} with the top layer of the Pump Stack to create a "vacuum cleaner" of sorts.

====Tips====

* Ramps can be used in place of channeling. Liquids will transmit through ramps, unlike stairs, and when pumps are constructed they annihilate the ramp they're built on much as walls do. Power will still be transmitted, so they don't need to be removed by miners prior to pump construction. Ramps make it virtually impossible to strand your miners and allows the stack to be dug out using only access doorways on the intake side of the pump, so no construction or doors are later needed to eliminate leaks. A pump stack can be very rapidly carved out with this method as even if a miner/builder is trapped on the containment side of a pump, they can walk up the ramp to the intake side of the pump above and walk out.
* Power can be transmitted to the stack by channeling out the tile directly above the intake (light) tile of the topmost pump and mounting a gear assembly. If the gear assembly is supported by an adjacent gear assembly or horizontal axle on a stable floor (be careful to not have that adjacent gear assembly disengage via lever), this will allow the stack to hang from the gear assembly. If a lower pump needs to be removed, or should self-destruct, the problem of the entire pump stack disassembling described above is eliminated. Further, if the supported gear assembly is built first, the pump stack can be built both from the top and bottom simultaneously, halving construction time, assuming that sufficient attention is paid to make sure that the pumps will align with the proper orientation when the two partial stacks meet. Properly channeling/ramping out the stack should ensure this.
* When pumping magma, make sure any underground soil tiles on the containment side of the stack are covered with a stone floor (need not be magma safe) to prevent subterranean trees from growing and blocking flow of the stack. When pumping water, it's safest to construct a paved road or slab on any underground tiles on the containment side to prevent subterranean trees from growing and blocking flow. Roads block tree growth, but smoothed or constructed tiles do not when muddied. Currently, designating a stockpile will serve the same goal, but that may not work in the future and if you accidentally de-designate the stockpile, a tree may instantly spring up blocking flow as they do grow 'underneath' the stockpile, hidden until the stockpile is removed.

====Improved Magma Pump Stack====

Because a pump stack pumping magma is known to cause significant {{L|Maximizing_framerate|lag}}, a [http://www.bay12forums.com/smf/index.php?topic=72296.0 new type of pump stack] was developed by [http://www.bay12forums.com/smf/index.php?action=profile;u=19835 NecroRebel] that causes a much smaller drop in [[FPS]]. Changing the single tile magma chamber at the output of every pump from a 1 by 1 to a 3 by 3 area reduces the lag to 1/15th of that caused by the original pump stack. (NecroRebel has since tested [http://www.bay12forums.com/smf/index.php?topic=72296.msg1795907#msg1795907 a variation with a T-shaped 3 by 2 output] and the results so far suggest it's just as effective as the 3 by 3 output, with no significant drop in FPS.) The designer hypothesizes that the larger chamber requires many fewer temperature calculations when magma is pumped in or out; that also implies that there will be no improvement for water pumps.

{{buildings}}

v0.31 Talk:Shell

2011-06-07T09:31:30Z

Thundercraft: /* Bugs with shells/bone carvers? */ Changed subsection title to make it easier to navigate

Is there a stockpile for shells currently?--[[User:Albedo|Albedo]] 21:16, 5 April 2010 (UTC)

I currently have "turtle" in my ingredients list, and am getting error messages if I try to "extract" at a fishery. I did some poking around the RAWs and the stockpile options, and apparently "shell" is treated much like a special kind of bone now. It's a type of inedible tissue that turtles have. You can find it in refuse piles, like bones. If you wanted a custom shell stockpile, you might make a refuse pile that is set to only accept turtle remains. I wonder if butcher shops can separate animal materials... Hope this helps. [[User:Theothersteve7|Theothersteve7]] 19:25, 10 April 2010 (UTC)

:: I had 3 turtles, but it was impossible to buthcer them at fishery. Eventually took the savegame raws and added shell to hooves (method 2). Saved my second shell-moody dorf ^^ [[Special:Contributions/90.191.16.52|90.191.16.52]] 18:53, 11 June 2010 (UTC)

All our current rescourses of shells are water animals. We really need an land animal that has a shell. Like a giant cave snail or something like that.--[[User:Niggy|Niggy]] 08:47, 14 June 2010 (UTC)

::If you're not averse to modding, there's a couple of custom domestic animals you can use. If I'm allowed advertise my own creation, there's the Dwarven honey beetles[http://www.bay12forums.com/smf/index.php?topic=59353.0]. There's also the Dwarven pig[http://www.bay12forums.com/smf/index.php?topic=53533.0]. A giant cave snail is a good idea, though. I might add those, too... [[User:ObliqueFault|ObliqueFault]] 22:40, 16 June 2010 (UTC)

== Bugs with shells ==

I had an odd thing happen with a bone carver. He went into a strange mood and produced an artifact at a craftsdwarf shop, but it turned out to be an iron item, an "iron figurine." (decorated with shell) The bone carver became a legendary bone carver.

More importantly, making shell objects seems to result in nothing, only an unchanged shell left behind. Has anyone else had either of these problems, or is it just me?

 
Just prior to the release of 0.31.11 Toady posted the following: 
"07/13/2010: [...] Shell crafts and other shell objects should work for next time. Artifacts made from body parts (shells, bone, etc.) should get the right material. " 
Can we get confirmation on this? [[User:Bungler|Bungler]] 02:38, 2 August 2010 (UTC)

It seems nobody has bothered to update the wiki on this shell problem. There are several relevant reports on the Dwarf Fortress Bug Tracker. Speficially:

[http://www.bay12games.com/dwarves/mantisbt/view.php?id=206 0000206: turtle shell crafts not producing - Dwarf Fortress Bug Tracker]
<blockquote>
Toady One (administrator) 2010-07-13 05:28
Turtle shell crafts/helms/etc. should all be fixed up for 0.31.11 now.
</blockquote>
[http://www.bay12games.com/dwarves/mantisbt/view.php?id=808 0000808: Processing Raw Turtles only makes one shell per stack]
<blockquote>
JmzLost (reporter) 2011-03-24 22:17
Still happening in 31.22. However, when a stack of turtles rots I get 1 shell per turtle.
</blockquote>
<blockquote>
Kumquat (reporter) 2011-04-16 05:55
Stacks of rotting mussels only leave behind a single shell, too.
</blockquote>
[http://www.bay12games.com/dwarves/mantisbt/view.php?id=4506 0004506: Cave lobsters produce no shell when processed - Dwarf Fortress Bug Tracker]

:Product Version: 0.31.25
:Date Submitted: 2011-04-12 00:46
:Last Update: 2011-04-12 07:27

Looks like turtle shells have been fixed, aside from the fact that processing turtles may only result in 1 shell per stack. But I believe that is related to a more general bug which makes DF ignore stacks of items when processing them.
Also, it appears that cave lobsters still do not produce shells. Which is a shame...
It should be possible to mod lobsters to fix this, however. As the bug report states, the raw entry is '''still''' missing [USE_MATERIAL_TEMPLATE:SHELL:SHELL_TEMPLATE] and [USE_TISSUE_TEMPLATE:SHELL:SHELL_TEMPLATE]. Putting these back should help, but it might be more complicated that this FAIK...
Anyway, the Shell page should definitely be updated to reflect these things. --[[User:Thundercraft|Thundercraft]] 09:25, 7 June 2011 (UTC)

== Crash problem ==

If I try either of the two methods of getting shells for moods listed in the page, my game crashes just after i load the save. Anybody knows why? --[[Special:Contributions/151.49.233.194|151.49.233.194]] 12:32, 19 May 2010 (UTC)

Ok, it crashes even if delete every modification... Damn, this is the last time I try to mod anything... --[[Special:Contributions/151.49.233.194|151.49.233.194]] 12:37, 19 May 2010 (UTC)

I tried the same thing, and had the game crash on load (.05). I copied the RAW folder back across from one of my backup saves (to both the DF and save folders) and it continued to crash. However, loading the backup copy did work. Therefore I'm assuming that this is an intentional crash when the modification date of the RAW files in a save are different then expected.

=Shell Side Effect?=

I used these instructions to give my fort's dogs shells. Though I've yet to see if it works, I can say that it made all of their blood turn pink. Loo[k]ing at it, it says "a spattering of dog n/a.

v0.31 Talk:Shell

2011-06-07T09:25:22Z

Thundercraft: /* Bugs with shells/bone carvers? */ Turtle shells are fixed, but lobster shells still broken

Is there a stockpile for shells currently?--[[User:Albedo|Albedo]] 21:16, 5 April 2010 (UTC)

I currently have "turtle" in my ingredients list, and am getting error messages if I try to "extract" at a fishery. I did some poking around the RAWs and the stockpile options, and apparently "shell" is treated much like a special kind of bone now. It's a type of inedible tissue that turtles have. You can find it in refuse piles, like bones. If you wanted a custom shell stockpile, you might make a refuse pile that is set to only accept turtle remains. I wonder if butcher shops can separate animal materials... Hope this helps. [[User:Theothersteve7|Theothersteve7]] 19:25, 10 April 2010 (UTC)

:: I had 3 turtles, but it was impossible to buthcer them at fishery. Eventually took the savegame raws and added shell to hooves (method 2). Saved my second shell-moody dorf ^^ [[Special:Contributions/90.191.16.52|90.191.16.52]] 18:53, 11 June 2010 (UTC)

All our current rescourses of shells are water animals. We really need an land animal that has a shell. Like a giant cave snail or something like that.--[[User:Niggy|Niggy]] 08:47, 14 June 2010 (UTC)

::If you're not averse to modding, there's a couple of custom domestic animals you can use. If I'm allowed advertise my own creation, there's the Dwarven honey beetles[http://www.bay12forums.com/smf/index.php?topic=59353.0]. There's also the Dwarven pig[http://www.bay12forums.com/smf/index.php?topic=53533.0]. A giant cave snail is a good idea, though. I might add those, too... [[User:ObliqueFault|ObliqueFault]] 22:40, 16 June 2010 (UTC)

== Bugs with shells/bone carvers? ==

I had an odd thing happen with a bone carver. He went into a strange mood and produced an artifact at a craftsdwarf shop, but it turned out to be an iron item, an "iron figurine." (decorated with shell) The bone carver became a legendary bone carver.

More importantly, making shell objects seems to result in nothing, only an unchanged shell left behind. Has anyone else had either of these problems, or is it just me?

 
Just prior to the release of 0.31.11 Toady posted the following: 
"07/13/2010: [...] Shell crafts and other shell objects should work for next time. Artifacts made from body parts (shells, bone, etc.) should get the right material. " 
Can we get confirmation on this? [[User:Bungler|Bungler]] 02:38, 2 August 2010 (UTC)

It seems nobody has bothered to update the wiki on this shell problem. There are several relevant reports on the Dwarf Fortress Bug Tracker. Speficially:

[http://www.bay12games.com/dwarves/mantisbt/view.php?id=206 0000206: turtle shell crafts not producing - Dwarf Fortress Bug Tracker]
<blockquote>
Toady One (administrator) 2010-07-13 05:28
Turtle shell crafts/helms/etc. should all be fixed up for 0.31.11 now.
</blockquote>
[http://www.bay12games.com/dwarves/mantisbt/view.php?id=808 0000808: Processing Raw Turtles only makes one shell per stack]
<blockquote>
JmzLost (reporter) 2011-03-24 22:17
Still happening in 31.22. However, when a stack of turtles rots I get 1 shell per turtle.
</blockquote>
<blockquote>
Kumquat (reporter) 2011-04-16 05:55
Stacks of rotting mussels only leave behind a single shell, too.
</blockquote>
[http://www.bay12games.com/dwarves/mantisbt/view.php?id=4506 0004506: Cave lobsters produce no shell when processed - Dwarf Fortress Bug Tracker]

:Product Version: 0.31.25
:Date Submitted: 2011-04-12 00:46
:Last Update: 2011-04-12 07:27

Looks like turtle shells have been fixed, aside from the fact that processing turtles may only result in 1 shell per stack. But I believe that is related to a more general bug which makes DF ignore stacks of items when processing them.
Also, it appears that cave lobsters still do not produce shells. Which is a shame...
It should be possible to mod lobsters to fix this, however. As the bug report states, the raw entry is '''still''' missing [USE_MATERIAL_TEMPLATE:SHELL:SHELL_TEMPLATE] and [USE_TISSUE_TEMPLATE:SHELL:SHELL_TEMPLATE]. Putting these back should help, but it might be more complicated that this FAIK...
Anyway, the Shell page should definitely be updated to reflect these things. --[[User:Thundercraft|Thundercraft]] 09:25, 7 June 2011 (UTC)

== Crash problem ==

If I try either of the two methods of getting shells for moods listed in the page, my game crashes just after i load the save. Anybody knows why? --[[Special:Contributions/151.49.233.194|151.49.233.194]] 12:32, 19 May 2010 (UTC)

Ok, it crashes even if delete every modification... Damn, this is the last time I try to mod anything... --[[Special:Contributions/151.49.233.194|151.49.233.194]] 12:37, 19 May 2010 (UTC)

I tried the same thing, and had the game crash on load (.05). I copied the RAW folder back across from one of my backup saves (to both the DF and save folders) and it continued to crash. However, loading the backup copy did work. Therefore I'm assuming that this is an intentional crash when the modification date of the RAW files in a save are different then expected.

=Shell Side Effect?=

I used these instructions to give my fort's dogs shells. Though I've yet to see if it works, I can say that it made all of their blood turn pink. Loo[k]ing at it, it says "a spattering of dog n/a.

v0.31 Talk:Lever

2011-05-31T16:16:09Z

Thundercraft: What does "activates 100 steps after being triggered" mean?

Please do '''NOT''' simply copy/paste old articles into new version namespace.

If you are not willing and confident enough to screen an article for accuracy, don't toss out potentially inaccurate information, not even with a "disclaimer". Thanks.

What can levers be hooked up to? And what is the effect of pulling the lever on each of these items?

- I moved this from the article page. [[User:Studoku|Studoku]] 02:33, 13 April 2010 (UTC)
:They can still be linked to doors, and it still functions exactly as in 40d. --[[User:Tarran|Tarran]] 02:36, 13 April 2010 (UTC)

==Linked==
how exactly do they get linked..? i've been looking through a load of pages, and none of them say EXACTLY how to link; they just say "CAN be linked". is it automatically linked? can you choose from a list? do you have to use axles, or something? can someone tell me how to actually link them? thanks--[[User:DJ Devil|DJ Devil]] 20:54, 26 June 2010 (UTC)
:DJ- build the lever, then use Q to go into the lever's tasks. do "link up to a floodgate" or "link up to a door" and then choose from the list which item you want to hook it up to. you can hook a lever up to more than one item.
so no axles? no cog-things? no.. anything? just build the mechanism and hit "link to floodgate", basically? wow.. i thought it'd be a little bit more complicated than that, hence i've never used them.. xD --[[User:DJ Devil|DJ Devil]] 15:54, 27 June 2010 (UTC)

And what labor does lever-linking use ? I have a lever that has to be linked pretty fast to avoid a flood, and no-one seems to take the job...--[[Special:Contributions/88.164.17.40|88.164.17.40]] 22:12, 9 September 2010 (UTC)
:The same labor as constructing the mechanisms and building the lever - Mechanics. --[[User:Quietust|Quietust]] 04:13, 10 September 2010 (UTC)

== Coupled floodgates ==

I don't know if other linkables operate this way, haven't had time to test, but floodgates linked to the same lever will match the same open/shut state, no matter which state you installed the link. So you can't make safety gates, where one opens and the other closes, not without another lever and ''another'' 'Pull the Lever' task.[[User:Uzu Bash|Uzu Bash]] 15:33, 22 October 2010 (UTC)

== Activates 100 steps after being triggered ==

What does "activates 100 steps after being triggered" mean, ''exactly''? I understand the underlying connotation. But does this '''only''' mean that there's a 100 a step delay after an "on" signal before a bridge/floodgate/grate will ''open''? '''Or''', does it ''also'' mean that there's also a 100 step delay after an "off" signal before a bridge/floodgate/grate will ''close''? The page did not make that clear, especially since the '''On/Off''' states are mentioned directly underneath such statements.

Also, I believe the wiki pages for {{l|bridge}}, {{l|floodgate}}, and {{l|bars}} all fail to mention this 100 tick delay, even though such knowledge can be very important to a particular application. (But, the {{l|grate}} page ''does'' mention a "100-tick delay".) --[[User:Thundercraft|Thundercraft]] 16:16, 31 May 2011 (UTC)

v0.31:Gear assembly

2011-05-31T04:18:43Z

Thundercraft: A gear assembly does not necessarily block movement

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

{{Machine_component|name=Gear assembly|key=g
|construction=
* {{L|Mechanism}}s
|construction_job=
* {{L|Mechanic}}s
|power=Needs 5 power.
}}

A '''gear assembly''' is a {{L|machine component}} that is used to transmit {{L|power}} from one adjacent machine component to another, such as {{L|water wheel}}s, {{L|windmill}}s, {{L|axle}}s, {{L|pump}}s, {{L|millstone}}s and other gear assemblies. This allows the transfer of vertical motion (z-axis) to horizontal (x and y-axis) and vice versa, that is, a change in direction of 90°.

Gear assemblies require 5 units of power each.

Gear assemblies do not block unit movement and can be crossed by dwarves without being spooled around them. But digging a channel to transfer the power (such as for an axle or a pump) below a gear assembly can result in a hole that can not be crossed.

''For a basic overview of how the different machine parts work and work together, see {{L|machinery}}.''

==Construction==
Gears can be constructed from the {{K|b}}uild menu under {{K|M}}achine Components and {{K|g}}ear. They require one {{L|mechanism}} to construct.

After the gear assembly has been constructed, it will automatically draw power from an adjacent power source. Further components can then be connected to the other available sides (East, West, North, South, Above, Below) of the gear assembly, and will automatically draw power from the power source via the assembly. Note that gear assemblies do not transfer power diagonally; they only work orthogonally (N-S, E-W, up-down).

In order to transfer power between {{L|z-level}}s with a gear assembly, you must first dig a channel, and then place the gear over the opening. Then place either another gear assembly, a vertical axle, or a machine (screw pump, etc.) on the z-level below in the same square, and power will be routed to it.

==Disconnected gears==

Gears can be "disconnected" by being connected to a {{L|lever}}, and then pulling that lever. However, be warned that if a device is supported entirely by a gear, it may collapse when the gear is disconnected. The same is true of a horizontally connected hanging device. An example is a windmill built directly on top of a gear with no floor: in this case, disconnecting the gear via the lever will cause the windmill construction to collapse. In order to avoid this, create a second gear adjacent to the linked gear but not otherwise connected to the system; this gear will support the windmill if the linked gear is disconnected, but will not transfer power, since it only draws it from the now-disconnected gear.

Note that the above is only necessary if the machine component is entirely unsupported outside of the gear on which it rests. Components which have "Stable foundation" in their {{K|q}} view should not collapse if a gear beneath them is disconnected.

{{Category|Machine components}}

{{buildings}}

v0.31 Talk:Gear assembly

2011-05-31T04:12:12Z

Thundercraft: A gear assembly does not block unit movement

== Gear assemblies and unit movement ==

{{l|Axle}}s do not block unit movement, as stated on the {{l|axle}} wiki page. However, I wondered whether a {{l|gear assembly}} would block movement. The wiki page does not say. Though, I did find [http://www.bay12forums.com/smf/index.php?topic=43156.msg810495#msg810495 this forum post]:
<blockquote>"...It is perfectly possible (I am looking at my active pump powered by this method right now) to connect power to the open tile (the one that dwarves pump from) which avoids leaks entirely and presents no disadvantages since '''axles and gear assemblies do not block movement'''."
</blockquote>
Update: I just tested and confirmed that a gear assembly does not block movement, so I will edit the wiki page to mention this. --[[User:Thundercraft|Thundercraft]] 04:12, 31 May 2011 (UTC)

v0.31 Talk:Hatch cover

2011-05-30T20:10:17Z

Thundercraft: Are locked hatches still immune to building destroyers?

'''Building destroyers'''

Hatch covers seem to no longer stop building destroyers attacking from below. I just had a locked hatch cover destroyed by a Titan from the bottom of the stairway one Z-level down.

What about attacks from above? [[Special:Contributions/98.181.12.207|98.181.12.207]]

:It seems the above observation was posted in August of 2010. Is anyone able to confirm whether this can happen in version 0.31.25 or later? Last I heard locked hatches were still immune to building destroyers from below. If they're not, then a lot of folks are wrong and designing defenses against building destroyers just became a lot more challenging... --[[User:Thundercraft|Thundercraft]] 20:10, 30 May 2011 (UTC)

== Deconstructing hatch covers ==

When you remove a hatch cover, the dwarves seem not to check if some other dwarves is standing on top. I just had a dwarf dying in my to-be-created well because of this. Should this be mentioned on the article page, or is this rather obvious come to think of it? [[User:Qwertyu|Qwertyu]] 13:46, 10 January 2011 (UTC)

== Spring flood ==

I noticed that spring flood (when ice (espetially newly formed, or transported) melts) seem to simply wash away or destroy your hatch.

v0.31 Talk:Obsidian

2011-05-30T19:39:22Z

Thundercraft: /* Melting obsidian */ "Boiling Magma" label is a known bug

It looks like obsidian will still be used for constructing items out of stone- I'm staring at some obsidian mechanisms right now. I haven't checked yet if it works for items made at a mason's workshop. --[[User:Vaniver|Vaniver]] 21:24, 11 April 2010 (UTC)

:Actually, what happens is that obsidian is just not being listed in the "economic stone" menu. If it is a layer in your starting location, it will be allowed for construction (green), if it is not a layer, it won't be allowed (red). Since it is not listed, you cannot switch between these two states. To allow obsidian to be listed, you have to remove its "max edge" tag from the raws. You can add it back after switching, and the game will remember its "cannot use" status. [[Special:Contributions/157.82.24.21|157.82.24.21]] 08:01, 16 April 2010 (UTC)

::Confirmed. I'm using mayday edition v0.31.08, and it worked like you described (thanks!). To clarify, the tag is [MAX_EDGE:20000] under [INORGANIC:OBSIDIAN] in the file data\save\regionX\raw\objects\inorganic_stone_layer.txt --[[Special:Contributions/83.183.240.185|83.183.240.185]] 18:24, 27 July 2010 (UTC)

im confuzed. whn i make rock short swords they show up as cedar short sword ect not obsidian short sword. it this correct? --gareth 10:26 08 June 2010

v0.31.06 - Also seeing obsidian swords being created as random-wood swords. --awilson

I was not able to make obsidian by dumping a bucket full of water onto magma. Instead I ended up with a 1/7 water tile. Not even any steam.--[[User:Passive Fist|Passive Fist]] 12:47, 3 July 2010 (UTC)

So if I make an obsidian short sword, does it deal damage like a regular wooden sword or like the 40D obsidian short swords?

: As obsidian. The bug is fixed as of v.x.16, btw.

::The sword one may be, but the economic stone listing one isn't. Gaah, I wanted a road paved with obsidian blocks.

== Magma-safe items ==

I've gone ahead and edited the part about "all items being destroyed" in a water+magma reaction tile. Magma-safe items are not destroyed, but are entombed within the tile. If the tile is mined, the items will re-appear. This is quite easy to test. --Heavenfall

''This could be quite useful for [[trap]]s. --GaxkangtheUnbound''

I actually just entombed a group of caged goblin invaders in my obsidian farm and I was surprised to find a copper cage and most of the goblins copper items when I mined out the following obsidian. AS I'm running an unmodified DF I'm changing the text to show that not even all magma un-safe items are destroyed. --[[User:Egodeus|Egodeus]] 14:53, 29 May 2011 (UTC)
:I've observed that copper and bronze usually survives brief magma-baths, but silver almost always melts if left in too long. It might be due to other material properties. --[[User:Quietust|Quietust]] 16:00, 29 May 2011 (UTC)
::Bones can survive entombing, especially if you flood the creatures with water and then cover them with magma, not the other way. --[[User:Someone-else|Someone-else]] 16:37, 29 May 2011 (UTC)

== effect on outside ==
If you cast obsidian outside for living space rather than stone
then does the tile become inside and/or subterranean again since there's a "natural wall" above it?
[[User:Cpad|Cpad]] 07:17, 24 May 2011 (UTC)

== Melting obsidian ==

I was in the middle of making a flooding trap through an obsidian layer. I suddenly get the message that a section of the cavern has collapsed. I also see a combat report, which was the first time on that fortress. It mentioned the dwarf caught in the collapsing being caught in BOILING MAGMA. Eight times. Is this normal behaviour with obsidian, or a bug? -[[Special:Contributions/121.44.251.31|121.44.251.31]] 07:35, 27 May 2011 (UTC)

:It's a known bug. The game mistakenly labels the dust cloud generated by a [[cave-in]] as "boiling magma". (The rock ''dust'' gets labeled as ''rock gas''. And, ''technically'', the material is roughly equivalent to [[magma mist]], minus the ''toxicity'' and lethally hot ''temperature''. Meaning, it's rock in a form that is neither liquid nor solid.) To wit:
::[http://www.bay12forums.com/smf/index.php?topic=74052.msg1840512#msg1840512 Boiling Magma where there is none]
:<blockquote>Cave-in dust is sometimes mistakenly labeled using the material's gas state rather than its solid powder state (i.e. it's equivalent to it saying "steam" instead of "snow") - thus, while it may have said "boiling magma", it actually meant "stone dust".</blockquote>
::[http://www.bay12forums.com/smf/index.php?topic=78002.msg2007085#msg2007085 The Bowyer has been caught in a cloud of boiling magma!]
:<blockquote>Don't worry, it's a known bug. The bowyer was hit by rock dust from the cave-in, but the dust uses the "gas" name of rock rather than the "powder" name. It isn't actually hot, but it can fling them through the air with some force.</blockquote>
:--[[User:Thundercraft|Thundercraft]] 19:39, 30 May 2011 (UTC)

v0.31:Bridge

2011-05-23T08:29:18Z

Thundercraft: Made link friendly: http://df.magmawiki.com/index.php/DF2010:Bridge#Raising_and_Retracting_Bridges "Raising/Retracting Bridges"

{{quality|Exceptional|22:21, 10 November 2010 (UTC)}}{{av}}

'''Bridges''' are extremely useful buildings for crossing dangerous terrain and also for fortress defence. Using them to control [[flow|fluids]] can save a ton of mechanisms and time, especially when the fluid in question is free-flowing and not pressurized (by {{L|pump}}, {{L|river}} or hydrostatic anything) and needs a wide tunnel.

==Building Bridges==

Bridges can be built ({{k|b}} -> {{k|g}}) of {{L|metal}}, {{L|stone}} or {{L|wood}}. They are first designed by an {{L|architect}}, then require a specialist worker for the material used (e.g. a {{L|mason}} for a stone bridge). The size of the bridge can be altered with {{k|u}}{{k|m}}{{k|k}}{{k|h}} while placing it, up to a maximum size of 10 squares in each direction. The bridge must be anchored to a solid surface on at least one edge. Before placing the bridge ensure that the bridge raises in the direction you want it to using {{k|w}}{{k|a}}{{k|d}}{{k|x}} or retracts using {{k|s}}.

==Raising and Retracting Bridges==

All bridges in DF can be raised or retracted by linking it to a {{L|lever}}. This requires a {{L|mechanic's workshop}} and a dwarf with the {{l|mechanics}} labor activated.

If a bridge is set to retract when the lever is pulled, the bridge essentially disappears dropping anything (friend, foe, or object) on the bridge onto whatever is underneath. Clearly this can be used to drop your enemies to rocky/watery/fiery deaths (or anything more imaginative you can think up!).

If a bridge is set to raise when the lever is pulled, the bridge becomes a wall along the edge selected with the {{k|w}}{{k|a}}{{k|d}}{{k|x}} keys when placing the bridge. The resulting wall is always one z-level tall, regardless of the length of the bridge. The bridge also "moves" to this position very fast, firing anything on the bridge into the air. The key advantage to raising bridges is the creation of a wall when the bridge is raised. This can be used to block fortress entrances/corridors. Using 2 bridges at opposite ends of a corridor creates a very large and simple trap by walling in enemies.

Walls cannot be built along map edges. Because bridges can be built along map edges and then raised to act as walls, they can be used to control where enemies spawn on the map.

The lowering of a drawbridge can also be used as a waste disposal for unwanted stones, {{L|refuse}}, {{l|goblin}}s (dead or alive), legendary {{l|cheese}} makers and {{L|nobles}}, to name a few. Even fluids get destroyed (this is especially useful considering lack of chasms in the new version). However, lowering a drawbridge onto a sufficiently large creature (such as a {{L|forgotten beast}}) simply destroys the bridge.

==Bugs==

Retractable bridges will not retract when a mounted unit (a unit riding another) is on the bridge. Attempting to do so will create odd results if multiple bridges are connected to the same lever[http://www.youtube.com/watch?v=mS5f_Snz-Y8].
*This is true except that I was able to retract the bridge if only 1 or 2 mounted units were standing on it. Could it have to do with a weight limit?
*Can't retract bridge with 7 goblins on. Seems like a weight limit...
*The same applies to raiseable bridges.

It is impossible to channel out stone that is directly under a raiseable bridge when its in the raised position.

Non-[[magma-safe]] bridge will heat up and eventually melt if a tile, which would be normally part of a lowered bridge gets covered in magma. State of the bridge (raised/lowered) doesn't matter, if it's within the bridge's rectangle, it endangers the whole bridge. This is also true if a dragon breathes fire across your bridge.

Bridges do not provide structural support -- but the game thinks they do. Sorry two random masons. I already forgot you.

Traders might expect 5 tiles wide bridges. One tile width apparently wasn't good enough for them and they went insane. (.31.12)

A raised bridge cannot be linked to a lever from the inside.

You can steal from traders with bridges (depends on the bridge's thieving skill).{{bug|3128}}

{{buildings}}

v0.31 Talk:Mist

2011-05-21T05:53:17Z

Thundercraft: AncientEnemy's illustration & some suggestions

I reworked the page to hopefully make it easier to understand. I removed this bit, since I have not seen it with .25 (I saw it in the beginning, but I don't think pets clean themselves anymore?):

*Animals wanting to clean themselves will see the water and go to clean themselves in it. Then it will disappear, as it is pumped around. This will generating a messages about the water source disappearing, and can result in spam.

Please put this back in if you've seen it in .25--[[User:Kwieland|Kwieland]] 17:15, 28 April 2011 (UTC)

: I definitely prefer AncientEnemy's original illustration of his mist generator (even if it's for an outdated design that has since been improved upon). The ASCII illustration is lacking. It simply can not convey the same information. The ASCII art does not show the gear assembly + axles. And no mention is made of AncientEnemy's suggestion to place statues underneath the mist to prevent job cancellation spam.

: I'm leaving the ASCII illustration in. But, to make things clearer, I'm reintroducing the thumbnail of AncientEnemy's illustration and making mention of the use of statues to prevent job cancellation spam and muddied tiles. I'm also mentioning restricted traffic areas as a way to reduce job cancellation spam and a couple suggestions to reduce the FPS load of multiple mist generators. --[[User:Thundercraft|Thundercraft]] 05:53, 21 May 2011 (UTC)

v0.31:Mist

2011-05-21T05:44:57Z

Thundercraft: Reintroduced AncientEnemy's illustration, added a few more tips

{{av}} {{Quality|Fine}}
Mist is created by {{l|water}} falling from one {{l|Z-level}} to another. The mist is generated on levels below the top level (from which the water drops), but spreads out similar to miasma and therefore can appear even on the top level. Walking through mist generates a happy {{l|thought}} for a dwarf. 

==Generating Mist==
AncientEnemy [http://www.bay12games.com/forum/index.php?topic=34407.0] devised a convenient way to generate mist. This method relies on the fact that {{l|screw pump|screw pumps}} pump {{l|water}} faster than water spreads out.

Simply put, screw pumps are daisy chained (output to input) in a circle and then water is added to the system. Water is typically added by designating one of the inputs to the pump a {{l|Pond|Pond}} and having dwarves fill it up. Once water is dropped from the floor above it is immediately sucked up by the next pump. Since there is falling water, mist is generated. Ahh, lovely waterfalls!

Below is an example of a simple mist generator. The Z=0 level can be anything, a booze stockpile, barracks or even your {{L|Dwarven_atom_smasher|atom smasher}}.

Pump Floor (z=1)
▒▒▒▒▒▒
▒.÷÷.▒
▒÷ ÷▒ The water can go clockwise or counter clockwise.
▒÷ ÷▒ Make sure your pumps are correctly aligned.
▒.÷÷.▒
▒▒▒▒▒▒
Some important considerations:[[Image:newmist.jpg|thumb|AncientEnemy's original simple mist generator.]]

*Evaporation is nonexistent as long as the pumps are working and the water is moving even above ground.{{Verify}}
*Job cancellation spam is possible if the water is filled to greater than 4/7 and a dwarf walks were the water falls. Even then, this can be prevented by blocking access to these tiles without blocking the water, such as by placing a {{L|statue}} underneath or greatly reduced by setting them as {{l|traffic#Setting Traffic Areas|restricted traffic}} areas.
*Mud will form where ever the water falls. Subterranean {{L|tree}}s can sprout up and clog the system. Solutions to this problem include: {{L|statue}}s, {{l|road|paved roads}}, constructed floors or {{L|fortification}}s, or to simply channel out the space once the mist generator is running.
*The z=-1 layer can also be identical to the z=0 level. Mist will also be generated there. Because the water never touches the floor there, you don't have to worry about muddy tiles.
*This system is generally only capable of maintaining a single 7/7 square of water, due to the way water descends z-levels. Any additional water put into the system will quickly overflow into the pump chamber (z=1).
*Automated mist generators may significantly lower your {{l|Frames per second|FPS}}, particularly if multiple generators are used.{{Verify}} This might be remedied by triggering via a {{L|repeater}} with a long delay or by one or more {{L|pressure plate}}s (perhaps set to activate by a passing dwarf).{{Verify}}
A movie [http://mkv25.net/dfma/movie-1292-ubermistgenerator] best illustrates the operation.
For {{l|fun}}, this same configuration can be used with {{l|magma}} [http://mkv25.net/dfma/movie-1303-crispyorc] as long as magma safe {{L|Screw pump|screwpump}}s are used.
 
 
 
{{Category|Thoughts}}
{{Category|World}}
{{Category|Physics}}