|Anonymous | Login | Signup for a new account||2018-05-24 23:00 PDT|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000340||Dwarf Fortress||Dwarf Mode -- Jobs, Hauling||public||2010-04-03 18:58||2017-02-01 14:34|
|Platform||OS||Windows XP||OS Version|
|Target Version||Fixed in Version|
|Summary||0000340: Dwarf repeatedly try to store job-based weapons in burrow-forbidden stockpiles|
|Description||I have an ex-miner dwarf that is repeatedly trying to haul a carried pick to a weapon stockpile that is outside his burrow, causing job cancellation spam.|
|Steps To Reproduce||Assign Urist McMiner the Mining labor, let him get a pick.|
Create a weapon stockpile that accepts picks; make sure it's the only such stockpile.
Create a burrow that does *not* include the weapon stockpile.
Pause the game.
Turn off the mining labor on Urist.
Assign Urist to the burrow created previously.
Unpause the game.
Now Urist will spam "Urist McMiner cancels Store Item in Stockpile: Drop-off inaccessible". He is trying to store his carried pick (which no longer matches his enabled labors), but the target stockpile is outside his burrow. He never works out to either just drop the pick on the ground, or to override the burrow restriction.
|Saves posted at 0001199:0013755 and 0003733:0014539.|
|Dwarves do the same thing when pasturing animals, attempting to pasture animals not in their burrow into pastures not in their burrow, then cancel-spamming.|
edited on: 2012-03-16 08:02
Problem still occurs in 34.05 and personally I would set the severity to "major".
Only survivor of my fort is a vampire who usually is safely locked away in his own burrow behind raised drawbridges. I let him out (he has a lever for the drawbridge in his rooms) to do burial and some other hauling. Now new migrants arrived and I told him to return to his burrow. But he was carrying something to a stockpile and started spamming that the drop-off is inaccessible. Instead of going to his burrow he is standing in front of the stockpile and doesn´t move.
Now this situation is not really severe, but in other cases (tell citizens to retreat to a safe burrow during a siege/ambush) this might end deadly.
I tried a bit around...
- The item in question is a sock. So I created a 1-tile stockpile for finished goods inside his burrow. The spamming continued.
- I added one of the tiles of the finished good pile to his burrow. The spamming continued.
Obviously a specific tile of the stockpile was set as destination and the destination did not change (by for example checking if another finished good pile is inside his burrow).
Suggestion: make haulers simply drop whatever they are carrying in such a situation.
Reminder sent to: robertheinrich
That's 0000597. Please upload a save to http://dffd.wimbli.com/ [^] and post the link at that report.
|It´s a known problem for years. Why should I bother with uploading a save?|
edited on: 2012-08-25 00:20
I find this to be a pretty common problem. Usual causes for me:
- 1) burrows-restricted doctors who pick up cloth or thread for doctoring which was stored in the hospital zone (and burrow), but when finished, want to store the leftovers in the cloth stockpile. Specific workaround: add the cloth stockpile to the doctors' burrow.
- 2) other burrows-restricted dwarves who drink from a barrel with one drink in it, but when finished want to put the now-empty barrel in the furniture stockpile. Specific workaround: add the furniture stockpile to all burrows.
General workaround: forbid the item the spamming dwarf is hauling. The next time he cancels the job, he'll also drop the item where he's standing, and it can then be unforbidden.
|0.43.05: latias1290 reported relieved soldiers confined to a burrow get stuck trying to haul their equipment to a stockpile outside their burrow (0010122)|
|2010-04-03 18:58||oliver||New Issue|
|2010-04-03 18:59||oliver||Tag Attached: hauling|
|2010-04-03 18:59||oliver||Tag Attached: burrow|
|2010-04-20 01:05||Footkerchief||Relationship added||child of 0000600|
|2010-07-16 09:13||Footkerchief||Relationship replaced||related to 0000600|
|2010-07-16 09:14||Footkerchief||Relationship added||related to 0000535|
|2010-12-19 09:35||Footkerchief||Relationship added||related to 0003221|
|2011-02-28 21:43||Footkerchief||Relationship added||related to 0001451|
|2011-02-28 21:43||Footkerchief||Relationship deleted||related to 0000535|
|2011-02-28 21:44||Footkerchief||Relationship added||parent of 0001199|
|2011-02-28 21:45||Footkerchief||Relationship added||parent of 0003733|
|2011-02-28 21:46||Footkerchief||Note Added: 0015620|
|2011-02-28 21:47||Footkerchief||Sticky Issue||No => Yes|
|2011-03-19 08:57||Hieronymous Alloy||Issue Monitored: Hieronymous Alloy|
|2011-07-15 06:42||theothersteve7||Note Added: 0018240|
|2012-03-16 07:52||robertheinrich||Note Added: 0021507|
|2012-03-16 08:02||robertheinrich||Note Edited: 0021507||View Revisions|
|2012-03-17 06:32||Footkerchief||Issue Monitored: robertheinrich|
|2012-03-17 06:32||Footkerchief||Note Added: 0021528|
|2012-03-17 15:01||robertheinrich||Note Added: 0021539|
|2012-03-27 04:02||Steb||Issue Monitored: Steb|
|2012-08-25 00:15||UristMcDorf||Note Added: 0023487|
|2012-08-25 00:20||UristMcDorf||Note Edited: 0023487||View Revisions|
|2013-03-04 01:08||Dwarfu||Relationship deleted||parent of 0001199|
|2015-12-12 12:44||Calite||Issue Monitored: Calite|
|2017-02-01 14:30||Loci||Relationship added||has duplicate 0010122|
|2017-02-01 14:34||Loci||Note Added: 0036248|
|Copyright © 2000 - 2010 MantisBT Group|