Dwarf Fortress Bug Tracker - Dwarf Fortress
View Issue Details
0000018Dwarf FortressPathfindingpublic2010-04-01 14:422010-06-09 06:45
Toady One 
PCWindows Vista
0000018: Pathfinding fails to update after map changes
Had several problems already with dwarves unable to path to areas that should be pathable, or unable to place structures because it was unable to find path to the needed resources. More information needed.
related to 0000820closed Footkerchief Arriving caravan that has no access to depot totally grinds the game to dust. 
related to 0000140resolved Toady One Miner cancels mine, and the designation. 
parent of 0000070closed Toady One Negative distance for building materials 
parent of 0000176closed Toady One Pathfinding not working properly with grates and ramps 
parent of 0000225closed Toady One Cannot find path to build bug 
parent of 0000317closed Toady One Constructing staircases causes pathing problems. 
parent of 0000346closed Toady One Recently cut wood logs not usable 
parent of 0000529closed Toady One Yet another way to break pathfinding, this time with a rock. 
parent of 0000635closed Toady One Removing a construction and replacing it with a different one sometimes fails to list the closest stone 
parent of 0000623closed Toady One Cannot build constructions over empty spaces (INCLUDES SAVE) 
parent of 0000559closed Toady One Miners won't mine some squares (at first) 
parent of 0000769closed Toady One Dwarves cannot dump items through doors. 
parent of 0000776closed Toady One Butcher cancels Butcher an Animal: Could not find path. 
parent of 0000901closed Toady One Cutting off access to outside areas causes lag and buggy pathfinding. 
parent of 0000984closed Toady One Dwarves path to suspended constructions, get stuck 
parent of 0000990closed Toady One I tracked down the source of the pathfinding/job item misplaced bug 
parent of 0001005closed Toady One Bridge over a pit by only entrance to fort breaks pathfinding 
parent of 0000103closed Toady One Dwarfs get stuck in buildings 
has duplicate 0000062closed Footkerchief Cannot make wooden crossbows 
has duplicate 0000164closed Footkerchief Pathfinding issues 
has duplicate 0000104closed Footkerchief No access to building material issue 
has duplicate 0000128closed Footkerchief Dwarves sometimes do not start new jobs anymore 
has duplicate 0000137closed Footkerchief Path finding seems to break completely 
has duplicate 0000198closed Footkerchief Trader runs around in circles, never reaches depot 
has duplicate 0000341closed Footkerchief Miners descending z-levels by using ramps are unable to path back up. 
has duplicate 0000345closed Footkerchief Pathfinding updates too slowly 
has duplicate 0000320closed Footkerchief Dwarves complain about pathing through stairs 
has duplicate 0000554closed Footkerchief Mining designations ignored 
has duplicate 0000602closed Footkerchief Pathfinding fail, sometimes dwarfs cant find a "way out" 
has duplicate 0000677closed Footkerchief miner stops following job orders. 
has duplicate 0000690resolved Footkerchief Stuck Miner: magma channel 
has duplicate 0000997closed Footkerchief Miner decides to be stuck, problem with stairs 
has duplicate 0001095closed Footkerchief Sporadic lack of access near constructions 
has duplicate 0000816closed Footkerchief Smelter will not allow smelting jobs to be queued: Needs ore and/or fuel. 
has duplicate 0001217closed Footkerchief Dwarves refuse to dig. 
has duplicate 0001152closed Footkerchief Placing door freezes dwarf in place 
has duplicate 0001019closed Footkerchief Dwarves also get stuck on stairs 
has duplicate 0001651closed Logical2u Building Constructions, Other Labors Will Result In Idling When Finished - Ocean Biome? 
has duplicate 0001858resolved Footkerchief Dwarves cant seem to find path right 
has duplicate 0000662resolved Footkerchief Cancels cut gem: needs rough gem (gem exists) 
Issue History
2010-04-01 14:42DoctorZuberNew Issue
2010-04-01 15:22warmistNote Added: 0000021
2010-04-01 15:52muckypupIssue Monitored: muckypup
2010-04-01 17:37ercdvsNote Added: 0000042
2010-04-02 01:42st0rmforceNote Added: 0000146
2010-04-02 01:43immibisNote Added: 0000147
2010-04-02 05:52TodestoolTag Attached: pathfinding
2010-04-02 11:02Retro42Note Added: 0000235
2010-04-02 13:54axusNote Added: 0000283
2010-04-02 15:15axusNote Edited: 0000283bug_revision_view_page.php?bugnote_id=0000283#r76
2010-04-02 15:26exottoyuhrNote Added: 0000305
2010-04-02 15:32warmistNote Added: 0000307
2010-04-02 15:33exottoyuhrNote Edited: 0000305bug_revision_view_page.php?bugnote_id=0000305#r78
2010-04-02 15:44axusNote Edited: 0000283bug_revision_view_page.php?bugnote_id=0000283#r79
2010-04-03 05:28warmistIssue Monitored: warmist
2010-04-03 07:21KaguyaIssue Monitored: Kaguya
2010-04-03 07:21KaguyaIssue End Monitor: Kaguya
2010-04-03 07:31KaguyaNote Added: 0000502
2010-04-03 07:32KaguyaNote Edited: 0000502bug_revision_view_page.php?bugnote_id=0000502#r130
2010-04-03 07:39alphafalconNote Added: 0000504
2010-04-03 07:46FootkerchiefCategoryGeneral => Pathfinding
2010-04-03 08:43FootkerchiefRelationship addedhas duplicate 0000062
2010-04-03 08:49FootkerchiefRelationship addedparent of 0000070
2010-04-03 09:04FootkerchiefRelationship addedhas duplicate 0000164
2010-04-03 09:15FootkerchiefRelationship addedhas duplicate 0000104
2010-04-03 09:30FootkerchiefRelationship addedhas duplicate 0000128
2010-04-03 09:31FootkerchiefRelationship addedparent of 0000166
2010-04-03 09:46FootkerchiefRelationship addedhas duplicate 0000137
2010-04-03 09:48FootkerchiefRelationship addedparent of 0000140
2010-04-03 11:05FootkerchiefRelationship addedparent of 0000176
2010-04-03 11:07burneddiNote Added: 0000588
2010-04-03 11:11DoctorZuberNote Added: 0000590
2010-04-03 11:12FootkerchiefRelationship addedparent of 0000198
2010-04-03 11:14DoctorZuberNote Added: 0000592
2010-04-03 11:23FootkerchiefRelationship addedparent of 0000225
2010-04-03 11:29FootkerchiefRelationship addedrelated to 0000235
2010-04-03 15:23ZeroGravitasNote Added: 0000684
2010-04-03 15:29savanikNote Added: 0000686
2010-04-03 15:29savanikNote Edited: 0000686bug_revision_view_page.php?bugnote_id=0000686#r177
2010-04-03 15:43FootkerchiefRelationship addedparent of 0000317
2010-04-03 15:55DoctorZuberNote Added: 0000696
2010-04-03 16:03king doomNote Added: 0000698
2010-04-03 18:36chuzzumIssue Monitored: chuzzum
2010-04-03 18:45petitsouriceNote Added: 0000740
2010-04-03 19:38FootkerchiefRelationship addedhas duplicate 0000341
2010-04-03 20:01FootkerchiefRelationship addedhas duplicate 0000345
2010-04-03 20:04FootkerchiefRelationship addedhas duplicate 0000320
2010-04-03 20:37FootkerchiefRelationship addedparent of 0000346
2010-04-04 08:39king doomNote Edited: 0000698bug_revision_view_page.php?bugnote_id=0000698#r268
2010-04-04 08:39king doomNote Edited: 0000698bug_revision_view_page.php?bugnote_id=0000698#r269
2010-04-04 08:40king doomNote Edited: 0000698bug_revision_view_page.php?bugnote_id=0000698#r270
2010-04-04 13:44FootkerchiefRelationship addedparent of 0000372
2010-04-04 13:44FootkerchiefRelationship addedparent of 0000262
2010-04-04 21:18jeebussezNote Added: 0000997
2010-04-04 21:50WirritNote Added: 0000998
2010-04-05 03:42oliverNote Added: 0001044
2010-04-05 07:14terrenbladeIssue Monitored: terrenblade
2010-04-05 13:15FootkerchiefRelationship deletedparent of 0000262
2010-04-05 20:04FootkerchiefRelationship addedhas duplicate 0000554
2010-04-05 20:23InsanityPreludeNote Added: 0001323
2010-04-05 22:20FootkerchiefRelationship addedparent of 0000529
2010-04-05 23:02FootkerchiefRelationship deletedparent of 0000372
2010-04-06 06:14ZegNote Added: 0001410
2010-04-06 06:15ZegNote Edited: 0001410bug_revision_view_page.php?bugnote_id=0001410#r429
2010-04-06 06:16ZegIssue Monitored: Zeg
2010-04-06 09:04FootkerchiefRelationship addedhas duplicate 0000602
2010-04-06 10:19FootkerchiefRelationship addedparent of 0000635
2010-04-06 10:50FootkerchiefRelationship addedparent of 0000623
2010-04-06 12:46FootkerchiefSticky IssueNo => Yes
2010-04-06 12:49FootkerchiefSummaryPathing issues? => Pathfinding fails to update after map changes
2010-04-06 14:27CaptainFailmoreNote Added: 0001582
2010-04-06 14:29CaptainFailmoreNote Edited: 0001582bug_revision_view_page.php?bugnote_id=0001582#r469
2010-04-06 14:59SymmetryNote Added: 0001595
2010-04-06 15:14KaelGotRiceNote Added: 0001600
2010-04-06 17:34felzixIssue Monitored: felzix
2010-04-06 17:37felzixNote Added: 0001621
2010-04-06 18:30FootkerchiefRelationship addedhas duplicate 0000677
2010-04-06 22:41FootkerchiefRelationship addedparent of 0000690
2010-04-06 22:47FootkerchiefSeverityminor => major
2010-04-06 22:48FootkerchiefNote Added: 0001683
2010-04-07 09:25WirritNote Added: 0001758
2010-04-07 10:44FootkerchiefRelationship addedparent of 0000559
2010-04-07 13:24DoctorZuberNote Added: 0001833
2010-04-08 00:00SymmetryIssue Monitored: Symmetry
2010-04-08 00:19FootkerchiefRelationship addedparent of 0000769
2010-04-08 00:21FootkerchiefRelationship addedparent of 0000776
2010-04-08 14:16FootkerchiefRelationship addedparent of 0000820
2010-04-08 21:11savanikNote Added: 0002251
2010-04-09 03:39Khym ChanurIssue Monitored: Khym Chanur
2010-04-09 08:57jarvollIssue Monitored: jarvoll
2010-04-09 11:39martinNote Added: 0002368
2010-04-09 11:46darkfredIssue Monitored: darkfred
2010-04-09 13:50darkfredNote Added: 0002419
2010-04-09 17:39FootkerchiefRelationship addedparent of 0000901
2010-04-10 12:08mrdudeguyIssue Monitored: mrdudeguy
2010-04-10 17:49teetheringNote Added: 0002681
2010-04-10 17:53teetheringIssue Monitored: teethering
2010-04-11 00:48FootkerchiefRelationship addedparent of 0000984
2010-04-11 02:24FootkerchiefRelationship addedparent of 0000990
2010-04-11 03:17Toady OneNote Added: 0002767
2010-04-11 03:17Toady OneAssigned To => Toady One
2010-04-11 03:17Toady OneStatusnew => acknowledged
2010-04-11 03:17Toady OneNote Edited: 0002767bug_revision_view_page.php?bugnote_id=0002767#r895
2010-04-11 04:05DoctorZuberNote Added: 0002776
2010-04-11 04:06DoctorZuberNote Edited: 0002776bug_revision_view_page.php?bugnote_id=0002776#r903
2010-04-11 07:19bloodystumpIssue Monitored: bloodystump
2010-04-11 07:24SirPenguinNote Added: 0002795
2010-04-11 07:43user891Note Added: 0002798
2010-04-11 08:24user891Note Edited: 0002798bug_revision_view_page.php?bugnote_id=0002798#r907
2010-04-11 10:09FootkerchiefRelationship addedparent of 0000997
2010-04-11 10:19FootkerchiefRelationship addedparent of 0001005
2010-04-11 10:37darkfredNote Added: 0002832
2010-04-11 13:48DoctorZuberNote Edited: 0002776bug_revision_view_page.php?bugnote_id=0002776#r930
2010-04-11 15:56FootkerchiefRelationship deletedparent of 0000166
2010-04-11 17:11Toady OneNote Added: 0002907
2010-04-11 17:22Rafal99Note Added: 0002909
2010-04-11 17:27MarkhamNote Added: 0002911
2010-04-11 17:46Rafal99Note Added: 0002921
2010-04-11 18:04ItchyBeardNote Added: 0002922
2010-04-11 18:07ToasterNote Added: 0002924
2010-04-11 18:21Toady OneNote Added: 0002929
2010-04-11 18:21Toady OneStatusacknowledged => resolved
2010-04-11 18:21Toady OneFixed in Version => 0.31.03
2010-04-11 18:21Toady OneResolutionopen => fixed
2010-04-11 21:55bloodystumpIssue End Monitor: bloodystump
2010-04-11 22:20Khym ChanurIssue End Monitor: Khym Chanur
2010-04-12 12:26FootkerchiefRelationship replacedrelated to 0000140
2010-04-12 12:27FootkerchiefRelationship deletedrelated to 0000235
2010-04-12 12:43FootkerchiefRelationship addedparent of 0000103
2010-04-12 12:49FootkerchiefRelationship replacedrelated to 0000198
2010-04-12 12:49FootkerchiefRelationship replacedrelated to 0000690
2010-04-12 12:49FootkerchiefRelationship replacedrelated to 0000820
2010-04-12 12:49FootkerchiefRelationship replacedrelated to 0000997
2010-04-12 12:50FootkerchiefRelationship deletedrelated to 0000140
2010-04-12 12:50FootkerchiefRelationship addedrelated to 0000140
2010-04-13 09:01FootkerchiefRelationship replacedhas duplicate 0000198
2010-04-13 12:28FootkerchiefRelationship addedhas duplicate 0001095
2010-04-14 20:31FootkerchiefRelationship addedhas duplicate 0000816
2010-04-16 09:08FootkerchiefRelationship addedhas duplicate 0001217
2010-04-16 09:08FootkerchiefIssue Monitored: Footkerchief
2010-04-16 13:57warmistIssue End Monitor: warmist
2010-04-18 19:09FootkerchiefRelationship addedhas duplicate 0001152
2010-04-20 19:34FootkerchiefRelationship addedhas duplicate 0001019
2010-04-26 17:27FootkerchiefRelationship replacedhas duplicate 0000997
2010-04-30 06:16Logical2uRelationship addedrelated to 0001651
2010-04-30 14:36Logical2uRelationship replacedhas duplicate 0001651
2010-04-30 14:36Logical2uIssue Monitored: Griggs
2010-06-02 13:07FootkerchiefSticky IssueYes => No
2010-06-09 06:45Toady OneStatusresolved => closed
2010-07-16 09:06FootkerchiefRelationship addedhas duplicate 0001858
2010-07-20 09:09FootkerchiefRelationship addedhas duplicate 0000662
2012-05-20 14:55FootkerchiefRelationship replacedhas duplicate 0000690

2010-04-01 15:22   
Repricated with setting:
w w

(w- wall, r-ramp)
Well basicaly a walled in depot and ramp to go up. Up there when trying to build anything it shows that there is no access but only to east,west and south walls. North builds ok.
2010-04-01 17:37   
Adding to this, i created a down stairway on z level 1, and a proper connecting up stairway on zlevel -1. The dwarves build it going down, and i eventually sealed the area with a floodgate. dwarves were unable to use the existing stairway to get out or in to mine further.

Creating a new path, then walling it back up seemed to fix the problem.
2010-04-02 01:42   
I had a similar problem
Kitting out a floor for bedrooms, A load of dwarfs were putting in doors.
They then couldn't find a way back up the staircase, even though there was nothing between it and them. There were about 5 dwarfs on that floor and they all got "lost" at the same time.
Tunnelling out a square fixed it.
2010-04-02 01:43   
I had a similar problem when building a water tower above ground.
2010-04-02 11:02   
Easily replicated. Built a fort, dug a straight 10z stairway down and started fleshing out my outpost. No issues until now.

As soon as I start building a wall(just one side to start, not enclosed) around my entrance pathing goes nuts and most dwarves go to No Job and all progress slows down considerably.

Note: Easy to spot with Fisherdwarves. They went from "Fishing" to "No Job" almost at the same time.
2010-04-02 13:54   
(edited on: 2010-04-02 15:44)
I had a problem with a miner that would hang out not mining a place very close by. He was one tile northwest of a ramp. I set the ramps to be removed, and being adjacent to them, he did that, once all the ramps were gone he went back to normal.

Also, guys tend to get stuck next to constructed walls.

Hmm, also happens with statues! weird...

2010-04-02 15:26   
(edited on: 2010-04-02 15:33)
Dig a tunnel one Z-level down from the ground, then dig a channel above it, thus:



and the dwarves will not go past the open space on any Z-level. I noticed this when digging skylights for a fort.

Update: I can confirm that saving and loading solves the problem.

2010-04-02 15:32   
Saving and loading seems to help sometimes
2010-04-03 07:31   
(edited on: 2010-04-03 07:32)
http://i39.tinypic.com/2vvkrhz.png [^]

The marked tiles could not be dug at all (Could not find path), nor could any of the walls in the screenshot that would've breached into the cavern itself, while all other interior walls could be dug out.

The only other entrance to the cavern would've been the scout tunnel I dug earlier, but it's atleast 10 z-levels from the bottom, thus not a valid route either.

Saving and loading didn't help, but I managed to detour this with two ways:
1) Digging one z-level below, then digging a ramp up into the cavern (even then there was few cancellations due to no path). Digging stairs up to the cavern didn't work.

2) Simply digging right, to the exact same cavern. The wall could be breached from there. And once there was a hole there, the miners could dig out the marked tiles, by walking around in the cavern.

Didn't try removing ramps and replacing them with stairs, however. The save is now long gone so I can't test it out. What I did try, was to dig the scout tunnel down to the cavern, but it failed too once I was placing the last part of stairs to the cavern floor (Could not find path)

2010-04-03 07:39   
http://www.bay12games.com/dwarves/mantisbt/view.php?id=166 [^] seems to be at least related if not the same problem. Apologies for duplicating (searched for the wrong keywords it seems)
2010-04-03 11:07   
I think I know what causes this:

There seems to be a system that caches paths to save processor power. This is hinted by the following experiment:

Dig a long, narrow hallway, with only one exit. Build a wall somewhere in the center, and make sure the dwarf builds it so that he gets stuck behind the wall. Then remove the wall. He will still think that the wall is there (although it is not), and thus refuse to move out of the hallway, and will stay there until he starves to death.

Now that the dwarf is stuck there, save your game, and then load it back up. He will happily move out of the aisle. I bet this is because saving and loading resets this "path caching".
2010-04-03 11:11   
I think there's more than one pathing issue going on, although your case for caching does sound plausible seeing as some of the issues can be resolved by a save/load.
2010-04-03 11:14   
0000222 is the only one I've been able to partially confirm, pathing through mechanisms does have problems.
2010-04-03 15:23   
Actually, I think this should be kicked up to major importance. Routine breaks in pathing ruin Fortress mode entirely, and it seems to come up quite a lot.
2010-04-03 15:29   
Ran into an oddity this morning. Don't know how reproduceable it is, so will document fully here.

Loaded game. In the freshly-loaded game, I have a corridor and room that looks like this:

[Editor's note: I hate proportional fonts! paste in notepad to see properly - VERY simple design]

In the room there was a bunch of waste stone that I designated to be dumped. As there was no stone in the doorway, I designated a door to be built immediately.

1. A swarm of dwarves departs for the dump jobs.
2. A long dwarf grab a door and slaps it in the open space.
3. IMMEDIATELY all the dwarves who had just picked up stones 'cancels Dump: Drop-off Inaccessible'
4. Followed by 'cancels Drink: Could not find path.'
5. The pathing issues continued until I designated the door to be deconstructed. Immediately after being *designated* everyone resumed normal pathing. *The door had not been removed yet.*
6. The door was then deconstructed as normal and stored in the stockpile.
7. Was able to reliably reproduce this issue by fully deconstructing the door and building a new one there.
8. Was able to eliminate the pathing issue by designating for deconstructing, letting a single tick elapse, then stopping the removal.
9. Was *still* able to reliably reproduce this issue by fully deconstructing the door and building a new one there.

2010-04-03 15:55   
I think I agree with this caching theory. Changing the path by digging a new path and walling off the old path seems to create problems consistently. I am fairly certain it is not the only pathing problem however.
king doom   
2010-04-03 16:03   
(edited on: 2010-04-04 08:40)
dig a five by five room, build a wall across half of it, making sure the dwarves have access to the bottom half of the room (closest to the bottom of the screen)


* = empty stone floor.
x = up/down stair.
l and _ are the walls.

Tell the dwarves to remove the constructed wall, and they will cancel the task because they cannot get to the top of the room and remove it from there, even though they can directly acces the wall from the bottom of the room.

2010-04-03 18:45   
I have had numerous path issues as well:

* = hallway
_ = open pit (dig a channel, then go underneath and get rid of the up ramp)
X = desired location of a floodgate to cable up a Mechanism to a lever
D = dwarf

   * ******
   * ******

In this case the job to attach the floodgate to a lever fails and is canceled because the dwarf cant find a path to the gate. I experimented and added a floor over the pit and then of course the dwarf went 'behind' the gate and installed the mechanism.

In another case I have had dwarves fail to find a path to build a workshop.
2010-04-04 21:18   
My dorfs don't want to cross the river to start mining or chopping trees, despite a large bridge and many floors covering the gap.
2010-04-04 21:50   
How I ran across the problem :
(1) Take large, flat area. Designate a large, solid rectangle to be Channeled by your miners. One or more of them will probably get stuck on a ramp.

(2) Dug an up-down stairway. On the levels above it (above ground), I -constructed- up-down stairways. Dwarves treated the path as partially invalid -- leading to a situation where dwarves could get into my tower with ease, but could not thenceforth escape. Might be hard to reproduce.

As reported by others, however; I find the problem fixes itself when I save/load the game. ... However, as my population rises, I need to do this more and more frequently. Large-population forts become problematic.
2010-04-05 03:42   
Here's how I reproduced pathing problems where valid paths get lost until reload:

1. Embark on a flat site with lots of picks
2. Set everyone to mining
3. Designating the border of a large square to be channelled (i.e. you're digging a moat)

Watch as idlers drops to 0, then gradually comes back up to 7 as dwarfs get stuck. I usually only get about 1/3 of a 50x50 moat done before everyone has stopped.

Then save/reload and watch them all wake up again.
2010-04-05 20:23   
I was trying to dig down to a cluster of gems in the caverns via staircases in a pillar of rock. At the bottom, the miners would consistently cancel it with a message of "Could not find path" even though there was nothing there that should have been blocking them from carving the staircase.
2010-04-06 06:14   
(edited on: 2010-04-06 06:15)
If this is going to be the bug repot that all the duplicates get refered too, should it really not be a major, not a minor?

As I mentioned in the forum post, easy enough to get reproducable pathing errors. I found I imediatly started getting problems as soon as I tried to seal off part of the map. Originally, I had a locked door at my fort entrance and noticed the problem seemed to go away when it was unlocked. So I replaced it by just a plain wall, thinking it was a problem with trying to path through locked doors, but the problem persisted. Also confirmed that channels have the same effect.

The actual effect is that the tiles around any construction site or dig site act like a sealed space when the construction is completed or the square dug out. This includes workshops. Dwarves will still try and path through this 'zone' but will cancel their job with the inaccessable message. Dwarves in the 'zone' can only access materials within it (if you try and build a wall, you can see the available materials change as you move the cursor over the zone), but will still send job cancelation messages as they try to path to items outside it.

2010-04-06 14:27   
(edited on: 2010-04-06 14:29)
Seconding the 'cache' observation, with some added notes:

This problem will, after a time, resolve itself. Dwarfs will eventually find new paths to use and relearn the map, but a considerable span of seconds to minutes might pass before this happens. The heuristic map used by the game to build pathways is apparently updated in real time (as per the door experiment) at least part of the time, but other times paths are built and rebuilt very slowly, such as with the wall experiments above. The dwarfs won't even consider other paths to be available, almost as though the whole map is set to restricted-level traffic by default.

Assuming that this theory is correct, it brings to light three problems that the people in this thread (and myself) have observed. One, doors shouldn't appear to be impassible. In fact, unless they're locked, they shouldn't have any impact on an existing path at all. Two, the game builds new paths far too slowly now. The gap between 'thinking' and dwarfs actually using pathways was noticeable in the old release but usually quite brief; but now the wait is problematic, and sometimes indefinite. Finally, some events apparently don't update the heuristic map in real time, if they update it at all. Wall removal and other deconstruction events should immediately open up paths that were previously obstructed - something that happens when the game is restarted (thus rebuilding the working heuristic map) or after an often lengthy wait time of path rebuilding.

With the total overhaul path-finding got in this release, issues like this can be expected.

2010-04-06 14:59   
I've seen this using the "pillar of up/down staircases then channel" technique to hollow out large areas. In my experience this is trivial to reproduce with multiple miners working at once in this way.

I'd also echo the request by Zeg that this be major, it's actually a game breaking bug even if it does have the lengthy workaround of restarting.
2010-04-06 15:14   
Just wanted to add too that I get pathfinding bugs a lot near stockpiles, a dwarf having just grabbed or dropped something at stockpiles will "dance" back and forth with no job until they finally break out of it for some reason.

Don't know if there's anything else I can do to test further to help out.
2010-04-06 17:37   
Just wanted to say that I'm seeing this issue, too. Severity should definitely be higher since this has broken fortress mode for me and apparently lots of others.

I'm running dwarf fortress with wine on Linux.
2010-04-06 22:48   
I updated the severity field, but people shouldn't put too much stock in that anyway -- I don't know how much attention Toady will pay to it unless it says "crash."
2010-04-07 09:25   
For what it's worth, here's a corresponding thread in the bug forum -- http://www.bay12games.com/forum/index.php?topic=52003.0 [^]

Interestingly, one of the people in the thread suggests locking and unlocking a door -- and says that kick-starts pathing, just as effectively as a save/load does. And, several others piped up saying that method worked.

Temporary workarounds for the win!
2010-04-07 13:24   
I seem to have found one reliable way to get a dwarf stuck using a burrow I listed it out as a new topic in 0000733 to describe it fully.
2010-04-08 21:11   

I can verify that the locking/unlocking door works. Actually, I can verify that /locking/, specifically, works. Unlocking does not appear to do anything.

Second: I have a reliable reproduction with very interesting behavior!
1. Dig your first burrow downwards, quarters, etc.
2. Dig a channel filled with water, so it is impassable.
3. Build a drawbridge across it and hook it up to a lever.
4. Attempt to build a wall next to the moat. Wall production proceeds fine.
5. Pull the lever and raise the drawbridge. PATHING ISSUES!
6. Pull the lever and lower the drawbridge. No pathing issues.
7. Repeat 5-6 indefinitely.

It seems to have something to do with a path *existing* that can reach the outside of the map.
2010-04-09 11:39   
I can also confirm that locking a door resolves the issue, so hopefully that will lead to an easy fix.
2010-04-09 13:50   
Door trick works for me. BUT....

...the trick does not make the game actually playable. On all 3 of my fortresses this only fixes the problem for around 40 seconds. I don't know what I am doing differently than those who seem to be able to play, but mining is impossible for me.

When mining inside the fortress dwarves can only do 4 blocks or so apiece before stopping again. OTOH they can mine large areas outside with no ill effect for perhaps 5 minutes.
2010-04-10 17:49   
This is a very severe problem on my map. But I found that saving and then continuing the save gets the dwarves going, so if you're having severe issues like I am this might help you. But you will need to do this quite often unfortunately.
Toady One   
2010-04-11 03:17   
I tried the channel/wall reproducibility methods from this thread and from 0000070 as well, using the released 0.31.02 zip, and I can't get anything bad to happen. Obviously something is going on, but I'm having trouble getting it to show up.

2010-04-11 04:05   
(edited on: 2010-04-11 13:48)
I have a crazy theory. I'm beginning to think that some of our pathfinding bugs may not actually be pathfinding bugs at all. in 0000733 I found a reliable way to get dwarves "stuck" by assigning them to a burrow mid-task.

I however, don't think this is actually a bug in burrows so much as a flaw in the new dwarven work ethic (0000008) which many of us have been complaining about. This new behavior is not allowing the burrow to interrupt an assigned task which results in the dwarf finishing his task and then sitting down to take a nap wherever he happens to be. While the burrow is an easy way to illustrate this, it's quite possible this occurs when other jobs try to interrupt a task as well. if that is the case, it could explain a lot of our problems.

2010-04-11 07:24   
This sounds like an impossible bug to really get to you, Toady, because it seems that saving and loading fixes it. As such, uploading a save doesn't have much of a use.

Please see my report here - 0000891 for a save with a similar yet probably slightly different problem. It has to do with new HFS becoming eternally stuck in a 1 tile hallway. I imagine it's related to all the pathing bug woes.
2010-04-11 07:43   
(edited on: 2010-04-11 08:24)
Toady, whatever pathfinding code is being called the instant a door becomes locked is the code we want to run whenever the rest of the map changes, especially regarding constructions and digging. It should not run 30 seconds later, like it seems to be doing now.

Also, has anyone noticed if the Alt key is bound to something? I switch from the game often but am hoping I'm not making things worse somehow with my alt-tab combination.

2010-04-11 10:37   
I think one of the key components for reproducibility is that you do the digging near the dwarven idle traffic areas. It seems to be worst when you are doing a complex pattern of mining right near the meeting area. Only takes seconds to re-break each time. I have a fortress based on a pattern of interconnecting X's with diagonal shafts, the dining room in the center. It rebreaks after 4 tiles are mined from the ends of any spoke.

also, perhaps it is a timing problem with scheduling the updates to pathfinding. Many of the posters have mentioned that they had very fast machines. I for one have about the fastest i7 based machine available.
Toady One   
2010-04-11 17:11   
Psithief, I can't run that code at every change or the game would grind to a halt. There are other functions that handle situations like digging that run faster, and they are working here in the situations I've tried. There's obviously some situation or configuration that is messing things up, but I haven't seen it yet.
2010-04-11 17:22   
Try building a long (like 20 tiles or so) wall. Every time a dwarf finishes one tile of it, it gets stuck next to it. There seem to be some updates every few moments that unstuck all dwarves. But they only happen every 5 minutes or so (at least in my 20-30 FPS game), while my dwarves are idle during that time. This makes every above-ground construction a real pain to build.
2010-04-11 17:27   
I didn't have this problem until I designated a multiple-level burrow. Removing the burrow fixed the pathing problems some dwarves were having.
2010-04-11 17:46   
It doesn't seem to be related. I tried deleting all burrows. Then observed a few dwarves building a wall. They have like 50% chance of getting stuck next to the wall every time they build it.
2010-04-11 18:04   
I've witnessed a variety of pathfinding bugs over the course of maybe 20 forts, but also can't pin down a specific cause. The following should be considered somewhat anecdotal until I can pin down a way to replicate the problem (I've been trying to avoid it, not replicate it).

The big problem I've had (which this comment relates to) manifests as a dwarf constructing one piece of a construction and then getting 'confused'. The same thing Rafal is talking about I think. The dwarf will sit still until pathing updates, apparently not being able to path _anywhere_ at all (he will even go to sleep on the spot even if a bed is 10 squares away). He will be listed as No Job. He will cancel constructing other bits of construction because he can't reach them. You sometimes get job cancellation spam when the problem starts to occur (cannot reach site).

I tend to play on completely flat embarks (usually 3x3 or 4x4), often making only minimal forays into the caverns below. On some of these embarks, the pathing problems manifest. On some of them, they don't. This is with pretty much the same castle design (an above ground fort - big square of walls) every time. The problems seem to manifest more frequently on larger embarks. The problems seem to manifest more if you start doing things underground. The problems seem to manifest more if you construct updown stairs or ramps, especially if you're building them downwards. Again, all very anecdotal - but I've made a lot of forts.

Could it somehow be related to some underground features (even if the caverns have not been breached?). That might explain why it occurs immediately on some maps but not on others.

Once the problem starts occurring on a map, that game is basically a write-off from that point on. It doesn't 'fix' itself later - you can only mitigate the problem using door locking/unlocking or save/reload.
2010-04-11 18:07   
I have seen pathing bugs (Once when I got miners stuck, another when I built a workshop in a frequently used hallway) and I have yet to designate a burrow in my fort. I don't think it's burrow related.
Toady One   
2010-04-11 18:21   
I've addressed what should be the main cause of these problems (see comments in 0000070), but I doubt I've handled every single pathing issue that's been reported. It's difficult to say what I should do with those reports now.