Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000235Dwarf FortressDwarf Mode -- Jobs, Designationspublic2010-04-02 21:572014-01-22 12:27
ReporterCaptainFailmore 
Assigned ToFootkerchief 
PrioritynormalSeveritymajorReproducibilityalways
StatusresolvedResolutionduplicate 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0000235: Stuck Dwarfs Cause Problems
DescriptionPROBLEM 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 ReproduceStart 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.
Tagsjob cancellations, pathfinding
Attached Files

- Relationships
duplicate of 0000140resolvedToady One Miner cancels mine, and the designation. 

-  Notes
(0000426)
CaptainFailmore (reporter)
2010-04-02 21:58

The above links to other issues should be #-numbers. Sorry!
(0000427)
DoctorZuber (reporter)
2010-04-02 22:38

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.
(0000817)
DoctorZuber (reporter)
2010-04-04 01:29

0000140 0000371
(0000821)
CaptainFailmore (reporter)
2010-04-04 01:35

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.
(0000826)
DoctorZuber (reporter)
2010-04-04 01:56
edited on: 2010-04-04 02:01

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.

(0000981)
CaptainFailmore (reporter)
2010-04-04 19:31

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.
(0001643)
DoctorZuber (reporter)
2010-04-06 18:44

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.
(0003351)
Chicken Launcher (reporter)
2010-04-13 18:09

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.

- Issue History
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 Footkerchief 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 View Revisions
2010-04-04 13:46 Footkerchief 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-07 04:03 RusAnon Issue Monitored: RusAnon
2010-04-09 18:15 Khym Chanur Issue Monitored: Khym Chanur
2010-04-12 12:27 Footkerchief Relationship added child of 0000140
2010-04-12 12:27 Footkerchief Relationship deleted related to 0000018
2010-04-12 12:27 Footkerchief Relationship deleted has duplicate 0000371
2010-04-13 18:09 Chicken Launcher Note Added: 0003351
2010-04-29 13:14 Footkerchief Category General => Dwarf Mode -- Jobs, Designations
2014-01-22 12:27 Footkerchief Relationship replaced duplicate of 0000140
2014-01-22 12:27 Footkerchief Status new => resolved
2014-01-22 12:27 Footkerchief Resolution open => duplicate
2014-01-22 12:27 Footkerchief Assigned To => Footkerchief


Copyright © 2000 - 2010 MantisBT Group
Powered by Mantis Bugtracker