View Issue Details

IDProjectCategoryView StatusLast Update
0000733Dwarf FortressPathfindingpublic2014-09-12 09:55
ReporterDoctorZuber Assigned ToToady One  
PrioritynormalSeveritymajorReproducibilityalways
Status resolvedResolutionfixed 
PlatformPCOSWindows VistaOS Versionmeh
Product Version0.31.01 
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

Relationships

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

Activities

DoctorZuber

2010-04-07 13:16

reporter   ~0001831

Last edited: 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

2010-04-08 01:05

reporter   ~0001976

Last edited: 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

2010-04-11 03:45

reporter   ~0002774

Last edited: 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

2010-04-11 14:14

reporter   ~0002878

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

2014-08-18 14:42

reporter   ~0029259

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

2014-08-18 14:46

manager   ~0029260

Last edited: 2014-08-20 11:24

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

JayJayForce

2014-08-20 10:22

reporter   ~0029364

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 )

user6

2014-09-12 09:55

  ~0030139

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
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
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
2010-04-11 14:14 DoctorZuber Note Added: 0002878
2010-04-15 10:04 DoctorZuber Note Edited: 0002774
2010-04-20 01:06 user6 Relationship added child of 0000597
2010-04-29 12:42 user6 Relationship added has duplicate 0001640
2011-08-27 08:47 Logical2u Relationship added parent of 0004851
2012-02-19 08:23 user6 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 user6 Assigned To => user6
2014-08-18 14:59 user6 Status new => feedback
2014-08-20 10:22 JayJayForce Note Added: 0029364
2014-08-20 11:24 Talvieno Note Edited: 0029260
2014-09-12 09:55 user6 Note Added: 0030139
2014-09-12 09:55 user6 Status feedback => resolved
2014-09-12 09:55 user6 Resolution open => fixed
2014-09-12 09:55 user6 Assigned To user6 => Toady One