Anonymous | Login | Signup for a new account | 2024-10-12 14:40 PDT |
Main | My View | View Issues | Change Log | Roadmap |
View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | |||||
ID | Project | Category | View Status | Date Submitted | Last Update | |
0004851 | Dwarf Fortress | Dwarf Mode -- Interface, Tasks | public | 2011-08-21 15:25 | 2014-08-25 08:15 | |
Reporter | Xen0n | |||||
Assigned To | Toady One | |||||
Priority | normal | Severity | major | Reproducibility | always | |
Status | resolved | Resolution | fixed | |||
Platform | PC Laptop | OS | Windows 7 Home | OS Version | ||
Product Version | 0.31.25 | |||||
Target Version | Fixed in Version | 0.40.01 | ||||
Summary | 0004851: Dwarves assigned to newly created burrows just stand still with "No job" | |||||
Description | Burrows 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 Reproduce | 1) 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 Information | Save file here : http://dffd.wimbli.com/file.php?id=4875 [^] | |||||
Tags | burrow, burrows, tasks | |||||
Attached Files | ||||||
Relationships | |||||||||||
|
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 |