Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000733Dwarf FortressPathfindingpublic2010-04-07 13:052014-09-12 09:55
Assigned ToToady One 
PlatformPCOSWindows VistaOS Versionmeh
Product Version0.31.01 
Target VersionFixed in Version 
Summary0000733: A digging dwarf who is assigned to a burrow mid task becomes stuck
DescriptionThe stuck dwarf will finish the tile he is currently digging and then stop at or near his current tile. He fails to actually go to the burrow.
Steps To Reproduce1. remove the mining labor from all but one dwarf
2. Designate an area for digging
3. wait for a tile to blink yellow indicating that the task is assigned
4. pause and create a small burrow
5. assign this dwarf to that burrow
5a. Alternatively declare an alert state assigning all dwarves to a burrow.
Additional InformationReleasing the stuck dwarf from the burrow returns him to normal motion.
Tagsburrow, designation, pathfinding, stuck
Attached Files

- Relationships
parent of 0004851resolvedToady One Dwarves assigned to newly created burrows just stand still with "No job" 
has duplicate 0001640closedFootkerchief Dwarfs just assigned to a burrow will stop and stand still 
related to 0000597confirmedFootkerchief Civilians assigned to burrows while hauling something spam "dropoff inaccessible" 

-  Notes
DoctorZuber (reporter)
2010-04-07 13:16
edited on: 2010-04-07 13:18

more testing...
works on dig, ramp, down ramp, up stair, channel...
without bothering to systematically test the rest I'm going to say it works on all designations unless proven otherwise.

repeating these steps several times in a row results in the dwarf returning to the same exact tile every time. This will be the tile he was at when this was first attempted.

deleting the burrow releases the dwarf as well.

babbalo (reporter)
2010-04-08 01:05
edited on: 2010-04-08 01:08

I'm also suffering from organization problems with miners and burrows. If I declare a burrow and put mining designations on its edges, the first tiles are dug correctly by the dwarf assigned to this burrow. Then he/she continues digging outside the burrow edges, and as soon as he manages to dig a tunnel out of the previously designated burrow, the rest of the miners see the designated digging area as free-for-all. All the solutions that fix this involve continuous micromanaging of the miners. I propose that any new tiles dug by a dwarf assigned and located in their burrow are appended to the aforementioned burrow.

Not quite the same problem, but relates to it.

DoctorZuber (reporter)
2010-04-11 03:45
edited on: 2010-04-15 10:04

I'm getting a funny feeling this odd little behavior is responsible for a good percentage of the pathfinding issues we are seeing. While this is easily illustrated with a burrow assignment I don't think this bug has anything to do with burrows at all.

I think it is actually a flaw in the new dwarven work ethic (0000008) which is preventing dwarves from being reassigned to other tasks. If that is the case, this little behavior could easily be responsible for a lot of our pathfinding problems.

DoctorZuber (reporter)
2010-04-11 14:14

a few updates, checked this on other behaviors and found that most tasks will insist on being completed BEFORE the burrow assignment tries to take over. When a dwarf finishes the task first he invariably becomes stuck as described.

I also noticed that if you wait long enough, several minutes maybe, the dwarf will eventually 'try again' to path back to the burrow and this time he succeeds. so this isn't permanently stuck, just for a good long time potentially in the middle of a crisis.

Another oddity, interrupting a hauling job with a burrow assignment results in dwarf being stuck as described again, only this time with the difference that the dwarf will sit there repeatedly spamming "cancels store item in stockpile: Drop off Inaccessible"

For a feature that's supposed to be your panic tool for getting all dwarves someplace safe in a crisis, it doesn't work very good. ;P
JayJayForce (reporter)
2014-08-18 14:42

I did a few experiments in 0.34.11 and could not get the bug to repeat though I admittedly have little experience with burrows.

I request someone else have a look at this, but I believe the bug to be fixed.
Talvieno (reporter)
2014-08-18 14:46
edited on: 2014-08-20 11:24

I just tested it. I'm fairly sure you're right, and that it's resolved.

JayJayForce (reporter)
2014-08-20 10:22

I've done more testing of this ( 0.40.09 ) having my miners dig one tile wide tunnels and have a better understanding of dwarf behaviour.

Dwarf Miners can hang for a few moments in indecision, but don't get stuck permanently.

Set up: I designated a one tile wide tunnel to be dug so that only one miner could work at a time. I also set up a burrow far away from the mining set.

Execution: Once Urist McMiner is almost done mining his block, I pause and increment time one unit at a time. Once his block is gone, I immediately assign him to the burrow.

Results: Urist mines the next block before heading to the burrow, however, he can get stuck for a short while as he decides what to do. It doesn't always happen and time lengths can vary from maybe half a second to 5. ( Note, I didn't time it, just a guess )
Footkerchief (manager)
2014-09-12 09:55

Thanks for testing. Please PM a manager on the forums if this bug is still present.

- Issue History
Date Modified Username Field Change
2010-04-07 13:05 DoctorZuber New Issue
2010-04-07 13:16 DoctorZuber Note Added: 0001831
2010-04-07 13:18 DoctorZuber Note Edited: 0001831 View Revisions
2010-04-07 19:40 DoctorZuber Tag Attached: stuck
2010-04-07 19:40 DoctorZuber Tag Attached: burrow
2010-04-07 19:40 DoctorZuber Tag Attached: designation
2010-04-08 01:05 babbalo Note Added: 0001976
2010-04-08 01:08 babbalo Note Edited: 0001976 View Revisions
2010-04-09 03:40 Khym Chanur Issue Monitored: Khym Chanur
2010-04-11 03:38 DoctorZuber Tag Attached: pathfinding
2010-04-11 03:45 DoctorZuber Note Added: 0002774
2010-04-11 03:52 DoctorZuber Note Edited: 0002774 View Revisions
2010-04-11 14:14 DoctorZuber Note Added: 0002878
2010-04-12 18:55 Death Issue Monitored: Death
2010-04-14 04:30 Death Issue End Monitor: Death
2010-04-15 10:04 DoctorZuber Note Edited: 0002774 View Revisions
2010-04-20 01:06 Footkerchief Relationship added child of 0000597
2010-04-29 12:42 Footkerchief Relationship added has duplicate 0001640
2011-08-27 08:47 Logical2u Relationship added parent of 0004851
2012-02-19 08:23 Footkerchief Relationship replaced related to 0000597
2014-08-18 14:42 JayJayForce Note Added: 0029259
2014-08-18 14:46 Talvieno Note Added: 0029260
2014-08-18 14:59 Footkerchief Assigned To => Footkerchief
2014-08-18 14:59 Footkerchief Status new => needs feedback
2014-08-20 10:22 JayJayForce Note Added: 0029364
2014-08-20 11:24 Talvieno Note Edited: 0029260 View Revisions
2014-09-12 09:55 Footkerchief Note Added: 0030139
2014-09-12 09:55 Footkerchief Status needs feedback => resolved
2014-09-12 09:55 Footkerchief Resolution open => fixed
2014-09-12 09:55 Footkerchief Assigned To Footkerchief => Toady One

Copyright © 2000 - 2010 MantisBT Group
Powered by Mantis Bugtracker