View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0010962 | Dwarf Fortress | Dwarf Mode -- Jobs, Designations | public | 2018-12-02 18:39 | 2018-12-23 11:17 |
| Reporter | djthekiller | Assigned To | Loci | ||
| Priority | normal | Severity | major | Reproducibility | have not tried |
| Status | acknowledged | Resolution | open | ||
| Platform | Windows | OS | 10 | ||
| Product Version | 0.44.12 | ||||
| Summary | 0010962: Miners refuse to continue mining and mill about idle outside of meeting zones | ||||
| Description | So i was just starting up a new world, not expecting bugs... and when i began mining my little 3 wide hallway, my dwarfs stopped mining... only after i messed with their labors for hauling... as i did not want them to haul wood the woodcutters were chopping. Then they just went back up and hang around the wagon and outside but near the meeting area. so i check and see their labors are the way they need to be and they are, and they aren't drinking or sleeping, and yet they continue to mill around. the only way i got them to go mine again was to undesignate and redesignate the earth to mine, and then they only mined once and went back to this state. | ||||
| Tags | No tags attached. | ||||
|
|
http://dffd.bay12games.com/file.php?id=14137 here is the save file as well |
|
|
There does seem to be something odd going on. As the OP stated, I was able to get the buggers to remove one row of tiles. I likewise failed to get them to dig into the side to the north of the upper level (they dug two tiles but then stopped). I did find a work around that would allow the OP to continue the game: Channel down the tile just south of the birch at the surface (with priority 1, to override the log hauling), and also designate the tile directly below that one (i.e. 1 Z level down). That causes the buggers to actually mine out the designated area. Obviously, you'd like to plug the hole with a floor at the surface. However, I have no idea what causes the problem. Something with designations in the job structures (I haven't tried to examine those)? |
|
|
perhaps, otherwise i have no way to reproduce exactly what happened |
|
|
Booted up the save, i went to 'Orders' and set dwarves off collecting wood, appearing to be a job pile up, after a few ticks dwarves continued digging. I also removed the workshop from your tunnel, i think the unbuilt solid tiles were blocking your dwarves pathfinding and making them re-prioritise which is very strange but justifiable since @PatrikLundell dug around. Edit, nevermind they cancelled it again. Instead this time i made a seperate access shaft and they resumed as normal, the ramps shouldn't be inaccessible though. |
|
|
The provided save behaved exactly as I would expect on vanilla v0.44.12x32. After I disabled wood hauling on the miners (0009023), they dug all the designated tiles without issue. Are you using DFHack? If so, please try running the save on vanilla to see if the problem persists. |
|
|
this was done on a fresh install, and i did try unsetting orders and all that, but they still refused to continue mining, so i dont know... will try when i get home |
|
|
If you didn't have DFHack installed, you might try loading the save on the 32-bit version instead of the 64-bit version. There were a few reports of pathing problems back when the 64-bit version released, though they were typically written-off as a side-effect of overly large embarks. |
|
|
I tried it without DFHack, but with the 64 bit version. The first time I waited a short while, got impatient, and then increased the dig priority for the dig tiles to 1, and the miners dug it all out. In the second run I just unpaused the save and let it run. The miners eventually made a pause in their wood hauling and dug away the first row, but then went back to hauling wood. I waited until all the wood had been hauled and they were idling, but still no digging. At this time I tried removing and repainting the digging designations, as well as removing them and repainting with a priority of 1, but the miners still don't react. The third time I started with removing the dig designations and then repaint them with the default 4 priority. On this run a miner eventually dug through the first row and continued digging. Thus, my conclusion is that there's something fishy with the designation as they are when the save is loaded. If the save was made with DFHack enabled, it might explain it (as I failed to get them to dig properly when I had DFHack enabled). In general, bug reports should state if DFHack is used, as well as raw changes and other tools used. Regardless, it's interesting that there seems to be a difference between how 32 and 64 bit handles the situation. |
|
|
hrm, that is interesting, i dont use 32 bit b/c its just slower and less supported, which is run this on my ssd as well, so idk |
|
|
I was able to reproduce this bug 6/10 times using v0.44.12x64. I then retested v0.44.12x32 and reproduced the problem 1/10 times. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2018-12-02 18:39 | djthekiller | New Issue | |
| 2018-12-02 18:46 | djthekiller | Note Added: 0038985 | |
| 2018-12-03 01:33 | PatrikLundell | Note Added: 0038986 | |
| 2018-12-03 01:34 | PatrikLundell | Note Edited: 0038986 | |
| 2018-12-03 07:41 | djthekiller | Note Added: 0038989 | |
| 2018-12-03 07:44 | FantasticDorf | Note Added: 0038990 | |
| 2018-12-03 07:46 | FantasticDorf | Note Edited: 0038990 | |
| 2018-12-03 07:49 | FantasticDorf | Note Edited: 0038990 | |
| 2018-12-03 12:19 | Loci | Note Added: 0038994 | |
| 2018-12-03 12:19 | Loci | Assigned To | => Loci |
| 2018-12-03 12:19 | Loci | Status | new => feedback |
| 2018-12-03 13:17 | djthekiller | Note Added: 0038997 | |
| 2018-12-03 13:17 | djthekiller | Status | feedback => assigned |
| 2018-12-03 13:48 | Loci | Note Added: 0038998 | |
| 2018-12-04 00:38 | PatrikLundell | Note Added: 0038999 | |
| 2018-12-04 19:51 | djthekiller | Note Added: 0039005 | |
| 2018-12-23 11:17 | Loci | Note Added: 0039048 | |
| 2018-12-23 11:17 | Loci | Status | assigned => acknowledged |
