Dwarf Fortress Bug Tracker - Dwarf Fortress
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0010962Dwarf FortressDwarf Mode -- Jobs, Designationspublic2018-12-02 18:392018-12-23 11:17
Reporterdjthekiller 
Assigned ToLoci 
PrioritynormalSeveritymajorReproducibilityhave not tried
StatusacknowledgedResolutionopen 
PlatformWindowsOS10OS Version
Product Version0.44.12 
Target VersionFixed in Version 
Summary0010962: Miners refuse to continue mining and mill about idle outside of meeting zones
DescriptionSo 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.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2018-12-02 18:39djthekillerNew Issue
2018-12-02 18:46djthekillerIssue Monitored: djthekiller
2018-12-02 18:46djthekillerNote Added: 0038985
2018-12-03 01:33PatrikLundellNote Added: 0038986
2018-12-03 01:34PatrikLundellNote Edited: 0038986bug_revision_view_page.php?bugnote_id=0038986#r15848
2018-12-03 07:41djthekillerNote Added: 0038989
2018-12-03 07:44FantasticDorfNote Added: 0038990
2018-12-03 07:46FantasticDorfNote Edited: 0038990bug_revision_view_page.php?bugnote_id=0038990#r15850
2018-12-03 07:49FantasticDorfNote Edited: 0038990bug_revision_view_page.php?bugnote_id=0038990#r15851
2018-12-03 12:19LociNote Added: 0038994
2018-12-03 12:19LociAssigned To => Loci
2018-12-03 12:19LociStatusnew => needs feedback
2018-12-03 13:17djthekillerNote Added: 0038997
2018-12-03 13:17djthekillerStatusneeds feedback => assigned
2018-12-03 13:48LociNote Added: 0038998
2018-12-04 00:38PatrikLundellNote Added: 0038999
2018-12-04 19:51djthekillerNote Added: 0039005
2018-12-23 11:17LociNote Added: 0039048
2018-12-23 11:17LociStatusassigned => acknowledged

Notes
(0038985)
djthekiller   
2018-12-02 18:46   
http://dffd.bay12games.com/file.php?id=14137 [^]
here is the save file as well
(0038986)
PatrikLundell   
2018-12-03 01:33   
(edited on: 2018-12-03 01:34)
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)?
(0038989)
djthekiller   
2018-12-03 07:41   
perhaps, otherwise i have no way to reproduce exactly what happened
(0038990)
FantasticDorf   
2018-12-03 07:44   
(edited on: 2018-12-03 07:49)
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.
(0038994)
Loci   
2018-12-03 12:19   
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.
(0038997)
djthekiller   
2018-12-03 13:17   
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
(0038998)
Loci   
2018-12-03 13:48   
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.
(0038999)
PatrikLundell   
2018-12-04 00:38   
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.
(0039005)
djthekiller   
2018-12-04 19:51   
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
(0039048)
Loci   
2018-12-23 11:17   
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.