0004851: Dwarves assigned to newly created burrows just stand still with "No job"

Notes
(0018613) Xen0n (reporter) 2011-08-22 16:44	Update: If I add a task the dwarf is capable of (designate a square in the burrow to be mined, and assign a miner to the burrow), the dwarf will go to the task, perform, it, then wait in the burrow as expected. However, with all my previous burrows (and the 7 remaining burrows I had created before yesterday,) I did not have to assign jobs to get dwarves to move to the burrow. When I set my civilian alert or add dwarves to my 'Hospital' burrow (Which I created before yesterday,) they will go to the burrow even without a task. So the "limit tasks to the burrow" part is working, but the 'limit movement within the burrow' is not.

(0018620) ellindsey (reporter) 2011-08-23 16:46	As far as I can tell, this is the intended behavior. Burrows don't limit movement, they just make all objects and buildings outside the burrow forbidden to dwarves assigned to the burrow.

(0018622) Xen0n (reporter) 2011-08-24 05:23 edited on: 2011-08-24 05:23	I was under the impression it also limited movement from the wiki: "After defining the area of the burrow, you can add citizens, who will then attempt to move directly to the area and not leave it unless they are starving or dehydrated and there is no food and water in the burrow. " If that's not intended behaviour, then I suppose I have a different bug, because up until Monday burrows in my fort did limit movement, and even now my old burrows will limit movement for idle dwarves, but any newly created burrows only limit jobs and tasks. So either way, something is not right because the way my burrows function changed on Monday.

(0018636) Logical2u (manager) 2011-08-27 08:46	This might be a duplicate of 0000733. Xen0n, would you agree?

(0018663) Xen0n (reporter) 2011-08-31 19:37	Hmm I'm not sure... if I understand correctly, 0000733 is specific to mining? In my case it is for all dwarves, but only assuming burrows are intended to limit the movement of dwarves, as the wiki states. If burrows are not intended to limit movement, then I had the reverse of this bug (since it used to limit movement for me), and the wiki article on burrows should probably be changed to reflect this.

(0018667) Logical2u (manager) 2011-09-01 20:32	You're right in that 733 was originally specific to mining, but it seems like it otherwise matches your bug. Burrows are usually intended to limit movement if they are active - dwarves consider only areas designated part of their burrow to be 'livable'. "Dwarves will only use workshops, dig walls, use rooms, etc. in burrows they are assigned to, though dwarves not assigned to any burrow will still use workshops etc. even if they are located in a burrow assigned to some other dwarves. "

(0018668) Xen0n (reporter) 2011-09-02 07:25	Yes in that case it does match up rather well, though I believe this occured regardless of whether or not they were currently mid-task. I will experiment some more to confirm it affects "No-job" dwarves as well as mid-task dwarves. Also so far I have waited a minute or two until a dwarf got thirsty before releasing them, I will attempt keeping the burrow for a longer time and see if it corrects itself as in 0000733. (Sorry to ask, how do I make bug IDs linkable?)

(0018669) kwieland (reporter) 2011-09-02 12:12 edited on: 2011-09-02 12:14	put the number sign (#) and then the four digit of the ID. In other words, #_0733 without the underscore (0000733) There really should be and FAQ for the bug site. Searching especially is tough at first.

(0018670) Xen0n (reporter) 2011-09-02 19:58	Ah, thanks. Well I tried it out some more, and same results. Even No-job status dwarves do not move to an assigned burrow if there is no task for them in the burrow. I waited several minutes for a few dwarves, until either they finally moved from their standing spot to go sleep in their bed or decided to store an item they were holding and began spamming store item cancellations. So it seems I couldn't 'wait it out' as 0000733 seemed to be able to do. Again, I'm not 100% what the actual intended behaviour for burrows is; I often hear things that conflict with both the wiki and my previous experience. It also seems a bit silly to need to add a task to get a dwarf to move to a burrow, after which he should by definition never have a reason to leave again (excepting food and sleep if not provided)

(0024249) AWellTrainedFerret (reporter) 2014-01-02 08:25	I've had this problem a lot recently. From what I've noticed, every time it occurs, it was because I assigned a dorf to a burrow while they were hauling an item outside that burrow. They drop the item immediately as expected, however they ignore the actual burrow and go stand idle somewhere else. In order to correct it, what I do is this: Delete that burrow. Then re-designate it. Then, BEFORE I assign the dorf to the burrow, I create some type of job within that burrow that only the assignee can perform. Once he's inside doing his job, assign him to the burrow.

(0029261) lethosor (manager) 2014-08-18 15:01	Is this reproducible in 0.40.xx?

(0029263) Talvieno (reporter) 2014-08-18 15:15	I just tried it, and I don't think so, no.

(0029611) lethosor (manager) 2014-08-25 08:15	All right, I'll mark it as resolved. If anyone can reproduce this in v0.40.xx, please PM me or another manager (see http://www.bay12forums.com/smf/index.php?topic=63640.0 [^]) on the forums to reopen this report. Thanks!

Issue History
Date Modified	Username	Field	Change
2011-08-21 15:25	Xen0n	New Issue
2011-08-21 17:10	Xen0n	Tag Attached: burrow
2011-08-21 17:10	Xen0n	Tag Attached: burrows
2011-08-21 17:10	Xen0n	Tag Attached: tasks
2011-08-22 16:44	Xen0n	Note Added: 0018613
2011-08-23 16:46	ellindsey	Note Added: 0018620
2011-08-24 05:23	Xen0n	Note Added: 0018622
2011-08-24 05:23	Xen0n	Note Edited: 0018622	View Revisions
2011-08-27 08:46	Logical2u	Note Added: 0018636
2011-08-27 08:47	Logical2u	Relationship added	child of 0000733
2011-08-31 19:37	Xen0n	Note Added: 0018663
2011-09-01 20:32	Logical2u	Note Added: 0018667
2011-09-02 07:25	Xen0n	Note Added: 0018668
2011-09-02 12:12	kwieland	Note Added: 0018669
2011-09-02 12:13	kwieland	Note Edited: 0018669	View Revisions
2011-09-02 12:13	kwieland	Note Edited: 0018669	View Revisions
2011-09-02 12:14	kwieland	Note Edited: 0018669	View Revisions
2011-09-02 19:58	Xen0n	Note Added: 0018670
2012-02-19 08:23	Footkerchief	Relationship added	child of 0000597
2012-02-19 08:24	Footkerchief	Relationship replaced	related to 0000597
2014-01-02 08:25	AWellTrainedFerret	Note Added: 0024249
2014-08-18 15:01	lethosor	Note Added: 0029261
2014-08-18 15:01	lethosor	Assigned To	=> lethosor
2014-08-18 15:01	lethosor	Status	new => needs feedback
2014-08-18 15:15	Talvieno	Note Added: 0029263
2014-08-25 08:15	lethosor	Note Added: 0029611
2014-08-25 08:15	lethosor	Status	needs feedback => resolved
2014-08-25 08:15	lethosor	Fixed in Version	=> 0.40.01
2014-08-25 08:15	lethosor	Resolution	open => fixed
2014-08-25 08:15	lethosor	Assigned To	lethosor => Toady One