Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0004851Dwarf FortressDwarf Mode -- Interface, Taskspublic2011-08-21 15:252014-08-25 08:15
ReporterXen0n 
Assigned ToToady One 
PrioritynormalSeveritymajorReproducibilityalways
StatusresolvedResolutionfixed 
PlatformPC LaptopOSWindows 7 HomeOS Version
Product Version0.31.25 
Target VersionFixed in Version0.40.01 
Summary0004851: Dwarves assigned to newly created burrows just stand still with "No job"
DescriptionBurrows have been working more or less fine for me, and my existing burrows seem to be working fine. However, a few minutes ago, any new burrow I create does not work. No matter what dwarf I assign to it, no matter where I put it, any dwarf assigned to a new burrow will just stand still wherever they are with "No Job." I've noticed this same behaviour when assigning a dwarf to an unreachable burrow, but I will put burrows 5 tiles away from a dwarf and the reaction is the same.

I've tried toggling through different civilian alerts before going back to "Inactive alert," but nothing helps so far.

I'm not sure if this is because I've created over 100 burrows (Not all at once, I create and quickly delete burrows as I need them.) New Burrows display the name "Burrow 115", "Burrow 116" etc.

Sort of a big hit, as I rely on burrows to get my dwarves to most anything; patients die in the hospitals, trade depot / liaisons get ignored, mining happens in a very inefficient manner, urgent tasks don't happen on time etc. without burrows.
Steps To Reproduce1) Create a new burrow, placing burrow area anywhere on the map.
2) Assign a dwarf or dwarves to the burrow.
3) The dwarf stops wherever they are, and displays "No Job" until they are no longer assigned to that burrow.
Additional InformationSave file here :
http://dffd.wimbli.com/file.php?id=4875 [^]
Tagsburrow, burrows, tasks
Attached Files

- Relationships
related to 0000597confirmedFootkerchief Civilians assigned to burrows while hauling something spam "dropoff inaccessible" 
child of 0000733resolvedToady One A digging dwarf who is assigned to a burrow mid task becomes stuck 

-  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


Copyright © 2000 - 2010 MantisBT Group
Powered by Mantis Bugtracker