View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0009629 | Dwarf Fortress | Dwarf Mode -- Jobs, Assignment of Jobs | public | 2016-03-15 04:18 | 2018-03-19 06:44 |
| Reporter | PatrikLundell | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | have not tried |
| Status | new | Resolution | open | ||
| Platform | PC | OS | Windows | OS Version | 10 |
| Product Version | 0.42.05 | ||||
| Summary | 0009629: Fatal digging priority inversion | ||||
| Description | Getting dorfs to dig tiles in the correct order is a pain when trying to e.g. channel away a single tile corridor into a chasm. I've designated the digging of the furthermost tile with a priority 1 digging task. When a miner finally approaches the tile (most of the time they're called away to harvest while en route; apparently digging is interruptible regardless of priority, while "store own item" jobs are set in stone once the dorf has started to move towards the x¤pig tail sock¤x), I then designate the digging of tile 2, 3, and 4 with the corresponding priorities, which usually works (other miners rarely manage to get in to "steal" the digging job in between if this designation is done late enough). When the priority 4 tile starts flashing I pause and set up the next set of tiles with priority 1 - 4 and unpause. However, I've seen multiple times that the miner finishes digging out the prio 4 tile, but then remains standing on the prio 1 tile and instead starts to dig out the prio 2 one inside of himself instead, finishing the move with digging out the 0000001 tile underneath and the predictable plummeting to death. | ||||
| Steps To Reproduce | See description | ||||
| Additional Information | Often the setup fails completely: the miner ignores the digging designation set up while the current tile is being dug, and instead treks to a far off prio 4 tile instead, presumably the next tile to dig has been selected BEFORE the current one is done, possibly as early as when the digging starts, so you have to be lucky with the timing to set up the error condition. Using LNP with Dwarf Therapist, the Phoebus tile set, and DFHack with Performance Tweaks enabled. | ||||
| Tags | No tags attached. | ||||
|
|
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). |
|
|
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. |
|
|
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. |
|
|
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). |
| 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 |
