0009629: Fatal digging priority inversion - Dwarf Fortress Bug Tracker

Notes
(0034862) PatrikLundell (reporter) 2016-03-17 04:33	I've just encountered a related issue that might explain the priority inversion: I'd accidentally stranded a miner and had it prune away some excess adamantine ledges while waiting for a rescue floor to be built. I had the miner run back and forth between two ends, but eventually I ran out of ledge I wanted to prune, so I designated the one the miner was standing on. The miner did nothing, i.e. just stood there, rather than move to the free tile beside or stupidly mine straight down. I then removed the designation and designated a tile I didn't really want to remove (as it would cause a cave-in), and the miner ran away to mine that one away. The incident indicates to me that DF somehow excludes the tile stood on at designation time for mining and only considers it after dealing with some other tile (at which time the danger consideration is probably not invoked for a follow on tile), presumably because DF recognizes the danger of mining out the tile below, but failing to realize it can move a tile to the side to both be in range and be out of danger. The issue might even have a common pathing route problem with the one where a building destroyer happens to get too close to the target (i.e. one tile away from it, rather than the required 2 tiles), e.g. due to a diagonal movement, and then remaining trapped, unable to move out to the required destruction distance (until distracted by a juicy live target, where returning to the destruction target might follow a luckier path).

(0034866) Button (reporter) 2016-03-17 15:08	I think your second issue (the one in the comment) is unrelated. I've noticed that pathing logic seems to be all-or-nothing for digging designations now - i.e. the highest-priority tile which any miner can reach is selected for mining, but the job's not necessarily given to the miner that can reach it. You can recreate this easily by mining out a room with walls at least 2 tiles thick, and trapping a miner inside it. You'll need at least one miner outside the room - but preferably a lot, so they've got a better chance of picking up the jobs before the inside guy can get to them. Now designate mining jobs on the inside walls of the room - tiles that only your trapped miner can reach - with priority 1 and watch the cancellation spam. May or may not require there to be designations of a lower priority elsewhere.

(0034868) PatrikLundell (reporter) 2016-03-17 15:48	I haven't encountered the mining cancellation spam situation, but I'm trying not to get my miners get trapped (The comment situation isn't a very common one). I'm quite sure neither the original report nor the comment situation was caused by "designation theft", as I both stared quite intently at the proceedings when it happened, and am rather sure there was no cancellation message. In the comment case, the digging designations were standard prio 4 ones (the stranded miner didn't exactly need to worry about distracting dig sites elsewhere). Also, the bug report situation allowed any miner to steal the priority 1 tile, but nobody did, in that the tile didn't flash until the miner finished with the prio 2 one. The other miners are usually busy trekking to other dig sites from the latest harvesting job, or trekking back to harvest another pig tail, so the competition for dig jobs isn't intense.

(0037969) PatrikLundell (reporter) 2018-03-19 06:44	I've now got a save clearly illustrating the priority inversion issue: http://dffd.bay12games.com/file.php?id=13588. [^] It took a couple of years to get a repeat of the issue in a situation where I was able to understand what was going on, why, and be able to repeat it. In this save the miner is in the process of channeling out a priority 2 tile, and there is a priority 3 tile a short distance away. While paused, immediately before saving, I designated two additional priority 2 channel tiles, one of which is directly underneath the miner., and the other is to the side. As soon as the save is unpaused, the miner finishes channeling out the tile worked on, channels out the one to the side, but then, instead of moving one tile to the side and dig out the tile stood upon, the miner addresses the priority 3 tile and then returns to the priority two one. While it is a good thing the miner doesn't cause a fall by digging out the tile underneath the feet (as opposed to workers removing stairs with nothing underneath, when a safe place to stand beside it exists [a different bug report]), it isn't a good thing to address the wrong tile first, as that may well cause a cave-in (it doesn't in this setup, but it shouldn't be hard to generate).

Issue History
Date Modified	Username	Field	Change
2016-03-15 04:18	PatrikLundell	New Issue
2016-03-17 04:33	PatrikLundell	Note Added: 0034862
2016-03-17 15:08	Button	Note Added: 0034866
2016-03-17 15:48	PatrikLundell	Note Added: 0034868
2018-03-19 06:44	PatrikLundell	Note Added: 0037969

Relationships