View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000733 | Dwarf Fortress | Pathfinding | public | 2010-04-07 13:05 | 2014-09-12 09:55 |
| Reporter | DoctorZuber | Assigned To | Toady One | ||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Platform | PC | OS | Windows Vista | OS Version | meh |
| Product Version | 0.31.01 | ||||
| Summary | 0000733: A digging dwarf who is assigned to a burrow mid task becomes stuck | ||||
| Description | The stuck dwarf will finish the tile he is currently digging and then stop at or near his current tile. He fails to actually go to the burrow. | ||||
| Steps To Reproduce | 1. remove the mining labor from all but one dwarf 2. Designate an area for digging 3. wait for a tile to blink yellow indicating that the task is assigned 4. pause and create a small burrow 5. assign this dwarf to that burrow 5a. Alternatively declare an alert state assigning all dwarves to a burrow. | ||||
| Additional Information | Releasing the stuck dwarf from the burrow returns him to normal motion. | ||||
| Tags | burrow, designation, pathfinding, stuck | ||||
| parent of | 0004851 | resolved | Toady One | Dwarves assigned to newly created burrows just stand still with "No job" |
| has duplicate | 0001640 | closed | Dwarfs just assigned to a burrow will stop and stand still | |
| related to | 0000597 | confirmed | Civilians assigned to burrows while hauling something spam "dropoff inaccessible" |
|
|
more testing... works on dig, ramp, down ramp, up stair, channel... without bothering to systematically test the rest I'm going to say it works on all designations unless proven otherwise. repeating these steps several times in a row results in the dwarf returning to the same exact tile every time. This will be the tile he was at when this was first attempted. deleting the burrow releases the dwarf as well. |
|
|
I'm also suffering from organization problems with miners and burrows. If I declare a burrow and put mining designations on its edges, the first tiles are dug correctly by the dwarf assigned to this burrow. Then he/she continues digging outside the burrow edges, and as soon as he manages to dig a tunnel out of the previously designated burrow, the rest of the miners see the designated digging area as free-for-all. All the solutions that fix this involve continuous micromanaging of the miners. I propose that any new tiles dug by a dwarf assigned and located in their burrow are appended to the aforementioned burrow. Not quite the same problem, but relates to it. |
|
|
I'm getting a funny feeling this odd little behavior is responsible for a good percentage of the pathfinding issues we are seeing. While this is easily illustrated with a burrow assignment I don't think this bug has anything to do with burrows at all. I think it is actually a flaw in the new dwarven work ethic (0000008) which is preventing dwarves from being reassigned to other tasks. If that is the case, this little behavior could easily be responsible for a lot of our pathfinding problems. |
|
|
a few updates, checked this on other behaviors and found that most tasks will insist on being completed BEFORE the burrow assignment tries to take over. When a dwarf finishes the task first he invariably becomes stuck as described. I also noticed that if you wait long enough, several minutes maybe, the dwarf will eventually 'try again' to path back to the burrow and this time he succeeds. so this isn't permanently stuck, just for a good long time potentially in the middle of a crisis. Another oddity, interrupting a hauling job with a burrow assignment results in dwarf being stuck as described again, only this time with the difference that the dwarf will sit there repeatedly spamming "cancels store item in stockpile: Drop off Inaccessible" For a feature that's supposed to be your panic tool for getting all dwarves someplace safe in a crisis, it doesn't work very good. ;P |
|
|
I did a few experiments in 0.34.11 and could not get the bug to repeat though I admittedly have little experience with burrows. I request someone else have a look at this, but I believe the bug to be fixed. |
|
|
I just tested it. I'm fairly sure you're right, and that it's resolved. |
|
|
I've done more testing of this ( 0.40.09 ) having my miners dig one tile wide tunnels and have a better understanding of dwarf behaviour. Dwarf Miners can hang for a few moments in indecision, but don't get stuck permanently. Set up: I designated a one tile wide tunnel to be dug so that only one miner could work at a time. I also set up a burrow far away from the mining set. Execution: Once Urist McMiner is almost done mining his block, I pause and increment time one unit at a time. Once his block is gone, I immediately assign him to the burrow. Results: Urist mines the next block before heading to the burrow, however, he can get stuck for a short while as he decides what to do. It doesn't always happen and time lengths can vary from maybe half a second to 5. ( Note, I didn't time it, just a guess ) |
|
|
Thanks for testing. Please PM a manager on the forums if this bug is still present. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2010-04-07 13:05 | DoctorZuber | New Issue | |
| 2010-04-07 13:16 | DoctorZuber | Note Added: 0001831 | |
| 2010-04-07 13:18 | DoctorZuber | Note Edited: 0001831 | |
| 2010-04-07 19:40 | DoctorZuber | Tag Attached: stuck | |
| 2010-04-07 19:40 | DoctorZuber | Tag Attached: burrow | |
| 2010-04-07 19:40 | DoctorZuber | Tag Attached: designation | |
| 2010-04-08 01:05 | babbalo | Note Added: 0001976 | |
| 2010-04-08 01:08 | babbalo | Note Edited: 0001976 | |
| 2010-04-11 03:38 | DoctorZuber | Tag Attached: pathfinding | |
| 2010-04-11 03:45 | DoctorZuber | Note Added: 0002774 | |
| 2010-04-11 03:52 | DoctorZuber | Note Edited: 0002774 | |
| 2010-04-11 14:14 | DoctorZuber | Note Added: 0002878 | |
| 2010-04-15 10:04 | DoctorZuber | Note Edited: 0002774 | |
| 2010-04-20 01:06 |
|
Relationship added | child of 0000597 |
| 2010-04-29 12:42 |
|
Relationship added | has duplicate 0001640 |
| 2011-08-27 08:47 | Logical2u | Relationship added | parent of 0004851 |
| 2012-02-19 08:23 |
|
Relationship replaced | related to 0000597 |
| 2014-08-18 14:42 | JayJayForce | Note Added: 0029259 | |
| 2014-08-18 14:46 | Talvieno | Note Added: 0029260 | |
| 2014-08-18 14:59 |
|
Assigned To | => user6 |
| 2014-08-18 14:59 |
|
Status | new => feedback |
| 2014-08-20 10:22 | JayJayForce | Note Added: 0029364 | |
| 2014-08-20 11:24 | Talvieno | Note Edited: 0029260 | |
| 2014-09-12 09:55 |
|
Note Added: 0030139 | |
| 2014-09-12 09:55 |
|
Status | feedback => resolved |
| 2014-09-12 09:55 |
|
Resolution | open => fixed |
| 2014-09-12 09:55 |
|
Assigned To | user6 => Toady One |
