View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0010396 | Dwarf Fortress | Dwarf Mode -- Jobs, Burial | public | 2017-11-30 23:22 | 2018-04-23 00:54 |
Reporter | FakerFangirl | Assigned To | Loci | ||
Priority | normal | Severity | minor | Reproducibility | always |
Status | confirmed | Resolution | open | ||
OS | Windows 7 | OS Version | x64 Home Edition | ||
Product Version | 0.44.02 | ||||
Summary | 0010396: Cannot Bury Reanimated Corpses | ||||
Description | My dwarves cannot 'place item in tomb'. They carry the bodyparts to the burial/tomb casket, place it on top, walk away, and then try again after a moving a few tiles with 'no job'. The bodyparts count as separate individuals in the dead/missing list (deceased). I think one of the bodyparts had been dumped prior to burial, but reclaiming and moving the burial site elsewhere just reproduced the loop. | ||||
Steps To Reproduce | Drown a dorf in haunted biome. Wait for it to reanimate. Kill it. Make a casket available for burial. Repeat. | ||||
Additional Information | The miasma in the hallways became too obnoxious, so we found a nice hole in the ground to stuff them in. Second corpse reanimates: https://www.youtube.com/watch?v=delpvGJ3PDo&t=1h07m04s&list=PL22FmIq3wbUgYfTdoVx1NAquLujBStGMZ&index=129 Reconstructing the caskets: https://www.youtube.com/watch?v=delpvGJ3PDo&t=838s&list=PL22FmIq3wbUgYfTdoVx1NAquLujBStGMZ&index=129&t=1h31m05s | ||||
Tags | No tags attached. | ||||
related to | 0005431 | acknowledged | Dwarves that die in werebeast form are carried back and forth between tomb and (wrong) stockpile | |
has duplicate | 0010715 | resolved | Loci | Corpse keeps leaping out of coffin |
related to | 0011119 | feedback | Loci | if something is marked to be dumped and then reanimates, this sometimes breaks dumping |
|
v0.44.09: a52 posted a save in 0010715: http://dffd.bay12games.com/file.php?id=13691 |
|
Dead-dwarf true indicates which pile the body should reside in with relevant checks, the undead would be difficult to categorize because they are hostile and unintelligent but inherit the historical ties to the unit. Activating or deactivating dead_dwarf=true will make them swap graveyard pile to refuse pile on virtually any corpse if induced with DF_Hack. Scripts have been written before to get around this issue of ethics being OTT with its selection, though it wont work retrospectively on the saves (except maybe the next time the reanimated body is put down), but will in theory proactively stop this issue reappearing if you wouldn't mind accidentally funneling in illicit butchering targets into your workshops from piles until its fixed at a later date by nullifying all instances of 'dead_dwarf=true' besides your own race. http://www.bay12forums.com/smf/index.php?topic=165414.msg7553808#msg7553808 Point being that state changed non-citzens with the data would likely be root cause of a conflict with coffins being citizenry only chose by dead_dwarf true, burial and pet controls, but the unintelligent/outsider creatures are normally not interrable via the coffins own ruleset and rely on slabs. All of the child report examples given are fortress tagged 'once dwarves' who inherit the historical data but would otherwise be sorted into the refuse pile with other non fortress associated beings post transformation. Pets who are fortress aligned also recieve graveyard/entombment treatment and protection from butcher workshops. |
|
I suspect FantasticDorf is somewhat off target/out of date here. Corpses of any sapients go into the corpse stockpile since 0.42.01, while non sapients (including reanimated former sapients, but excluding pets) go into the refuse one. It appears the "dead_dwarf" flag controls that behavior. However, butchering won't happen unless raws are modded to allow butchering, and the issue here is failure to bury, rather than issues with modding sapient butchering behavior. Using DFHack to change the "dead_dwarf" flag on the skeleton in a52's save causes the corpse to be laid to rest in the coffin, while without that hack there is indeed a repeating task to put the corpse into the coffin. Setting up a corpse stockpile did not cause the flag hacked corpse to be tasked for hauling to it, so it seems setting that flag might be sufficient to solve (or at least work around) the problem. |
|
I was counter proposing that players should either destroy or have them sorted into the refuse pile explicitly and ideally using the linked DF-Hack script until its fixed, but the last two paragraphs are more closely aligned to your response. I used the term 'graveyard' because through repeated trial and error, players consistently mistake the two because they make snap assumptions based on the stockpile name for (corpses) & ((refuse) - corpses) and i just wanted to try and avoid any ambiguity for the reader as to where the corpses were meant to go with priority linked to dead_dwarf=true, i apologize if i managed to confuse you further. |
|
It's probably not ideal to use the term "graveyard" for a corpse ('y') stockpile, as graveyards are where the dead are buried, i.e. where the coffins and slabs are. A morgue is a transient storage for the dead, so that would work better, but I still doubt it will be understood without an explanation (at least until the term, or an alternative, takes root). It's unfortunate that it's so easy to confuse corpse ('y') stockpiles with corpse ('r'/corpse) refuse sub stockpiles, though, as it happens rather frequently, as noted. |
Date Modified | Username | Field | Change |
---|---|---|---|
2017-11-30 23:22 | FakerFangirl | New Issue | |
2018-04-19 05:43 | Loci | Relationship added | related to 0005431 |
2018-04-19 05:44 | Loci | Relationship added | has duplicate 0010715 |
2018-04-19 05:45 | Loci | Note Added: 0038187 | |
2018-04-19 05:52 | Loci | Assigned To | => Loci |
2018-04-19 05:52 | Loci | Status | new => confirmed |
2018-04-21 10:18 | FantasticDorf | Note Added: 0038190 | |
2018-04-21 15:08 | PatrikLundell | Note Added: 0038191 | |
2018-04-22 02:44 | FantasticDorf | Note Added: 0038192 | |
2018-04-23 00:54 | PatrikLundell | Note Added: 0038194 | |
2019-07-10 18:47 | lethosor | Relationship added | related to 0011119 |