View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000235 | Dwarf Fortress | Dwarf Mode -- Jobs, Designations | public | 2010-04-02 21:57 | 2014-01-22 12:27 |
| Reporter | CaptainFailmore | Assigned To | |||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | resolved | Resolution | duplicate | ||
| Summary | 0000235: Stuck Dwarfs Cause Problems | ||||
| Description | PROBLEM SUMMARY - Any time one dwarf can't path to a designation-related task, he may cancel it for everyone. --- PROBLEM DETAILS - 1. This only occurs with non-hidden tiles. 2. When a dwarf is unable to path to a task he wants to perform (which includes loitering in a meeting area) he will begin blinking with a teal question mark for upwards of a minute or more. During this time, the game slows considerably. 3. While a dwarf is blinking and stuck, tasks that he should be able to perform (such as mining tiles that are accessible to him) can be canceled by other dwarfs with the same labor enabled, who cannot access those tiles. 4. Once the dwarf has stopped blinking, 0000002 and 0000003 no longer apply. The frame rate returns to normal, and designations won't be canceled by other dwarfs anymore. A dwarf in a disconnected space will be able to perform tasks he can reach without having them canceled by other dwarfs before he can get to them. When dealing with disconnected spaces, miners, channeling, and so forth, this can cause a great deal of frustration and dramatically slowed performance even though the problem eventually resolves itself. As with other path-related issues, this one can be solved by saving and reloading. (Which I'm assuming rebuilds all of the path information from scratch.) Making it so tasks and designations aren't canceled or suspended just because one dwarf can't reach them would probably clean this up. | ||||
| Steps To Reproduce | Start a game with two miners. Dig two 3x3 rooms underground with an upward ramp in the center and no other exits. One miner should become trapped in each room. The moment one of them is trapped, problems should begin. | ||||
| Tags | job cancellations, pathfinding | ||||
|
|
The above links to other issues should be #-numbers. Sorry! |
|
|
yes, #xxxx creates a link to another issue. careful with that. I like this report, I had seen this effect but was trying to understand it a bit better before trying to report it. |
|
|
0000140 0000371 |
|
|
It sounds like the 'thirsty dwarf in crisis' issue is related to this. After investigating a bit more it seems like there's a lagging time between path updates, and if any dwarf thinks he can't reach a task, he cancels it globally. However, this extends to cancellations for -ANY- reason, including thirst, hunger, and after watching a stream of one of my colleagues playing it looks like panicking dwarfs can cause this to happen too. (Miner goes to mine, gets scared, and cancels the job completely.) In short, any time a dwarf abandons a task involving a designation, the designation is canceled. |
|
|
yes, that's why I crosslinked them up. I think 235 is the clearest example, I'll probably test this a tad more on a new map tomorrow. and I agree with what you're saying. I haven't done enough testing to say for certain, but it sounds plausible with what we know so far. |
|
|
After a little bit more testing, I've determined that this problem does not apply to workshops. If a workshop task becomes active and the dwarf attempting to perform it becomes cut off, the task is neither suspended nor canceled but it does become inactive. Any dwarf attempting to but no longer able to perform the task drops what he's doing and goes back to minding his business. Once the workshop becomes accessible to any dwarf with the appropriate labor - in this case, carpentry - the task will become active again. So, that all works as it should. When mining isn't involved, however, the nature of the problem changes. I trapped my only woodcutter in a test game underground, and then designated some trees to be cut. He never canceled any designations - but he spammed the message log with over 30 'could not find path' cancellations in a matter of seconds. Game performance slowed noticeably and my CPU fan started to get nice and noisy. After assigning another dwarf to woodcutting, he took up the spare axe I had and started felling trees. To observe if the problem fixed itself again this time, I deactivated my second woodcutter shortly after. Just like before, after a short time the original woodcutter shut up and stopped dragging the frame rate down. After turning him loose, everything was as it should be. A second test, which came later, involved plant gathering. Again, the same behavior as woodcutting was observed, with no designations canceled - but lots of messages, and noticeable slowdown. A third test, performed immediately after the second test, was to see if engraving designations were canceled. They were not. A fourth and final test involved removing constructions. I built a section of wall above ground and then trapped all of my dwarfs below ground. I then designated that wall to be deconstructed. Any time someone canceled the removal task, the designation was canceled as well. This isolates the designation canceling problem to any digging designations and demolishing constructions. Cancellation-related spam and associated performance issues are another problem entirely. |
|
|
I can confirm that walling your dwarves in (to prevent those pesky immigrants) reproduces this problem as well, it ground all mining jobs in my fort to a halt instantly. Most annoying. I expect a moat/bridge that is left up would probably recreate this as well. |
|
|
I got this bug too while doing a succession fort. I had a mason (with hauling labors enabled) wall himself in temporarily at the same time as I was building a bedroom complex elsewhere. He attempted to do every available furniture hauling job and when he "couldn't find path" he canceled the jobs, suspending the build order. Very inconvenient. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2010-04-02 21:57 | CaptainFailmore | New Issue | |
| 2010-04-02 21:58 | CaptainFailmore | Note Added: 0000426 | |
| 2010-04-02 22:38 | DoctorZuber | Note Added: 0000427 | |
| 2010-04-03 11:29 |
|
Relationship added | related to 0000018 |
| 2010-04-04 01:29 | DoctorZuber | Note Added: 0000817 | |
| 2010-04-04 01:35 | CaptainFailmore | Note Added: 0000821 | |
| 2010-04-04 01:56 | DoctorZuber | Note Added: 0000826 | |
| 2010-04-04 02:01 | DoctorZuber | Note Edited: 0000826 | |
| 2010-04-04 13:46 |
|
Relationship added | has duplicate 0000371 |
| 2010-04-04 19:31 | CaptainFailmore | Note Added: 0000981 | |
| 2010-04-04 19:42 | Qloos | Tag Attached: pathfinding | |
| 2010-04-04 19:42 | Qloos | Tag Attached: job cancellations | |
| 2010-04-06 18:44 | DoctorZuber | Note Added: 0001643 | |
| 2010-04-12 12:27 |
|
Relationship added | child of 0000140 |
| 2010-04-12 12:27 |
|
Relationship deleted | related to 0000018 |
| 2010-04-12 12:27 |
|
Relationship deleted | has duplicate 0000371 |
| 2010-04-13 18:09 | Chicken Launcher | Note Added: 0003351 | |
| 2010-04-29 13:14 |
|
Category | General => Dwarf Mode -- Jobs, Designations |
| 2014-01-22 12:27 |
|
Relationship replaced | duplicate of 0000140 |
| 2014-01-22 12:27 |
|
Status | new => resolved |
| 2014-01-22 12:27 |
|
Resolution | open => duplicate |
| 2014-01-22 12:27 |
|
Assigned To | => user6 |
