0000733: A digging dwarf who is assigned to a burrow mid task becomes stuck

Notes
(0001831) 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.

(0001976) 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.

(0002774) 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.

(0002878) 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

(0029259) 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.

(0029260) 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.

(0029364) 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 )

(0030139) 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