0010962: Miners refuse to continue mining and mill about idle outside of meeting zones

Notes
(0038985) djthekiller (reporter) 2018-12-02 18:46	http://dffd.bay12games.com/file.php?id=14137 [^] here is the save file as well

(0038986) PatrikLundell (reporter) 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 (reporter) 2018-12-03 07:41	perhaps, otherwise i have no way to reproduce exactly what happened

(0038990) FantasticDorf (reporter) 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 (manager) 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 (reporter) 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 (manager) 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 (reporter) 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 (reporter) 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 (manager) 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.

Issue History
Date Modified	Username	Field	Change
2018-12-02 18:39	djthekiller	New Issue
2018-12-02 18:46	djthekiller	Issue Monitored: djthekiller
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	View Revisions
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	View Revisions
2018-12-03 07:49	FantasticDorf	Note Edited: 0038990	View Revisions
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 => needs feedback
2018-12-03 13:17	djthekiller	Note Added: 0038997
2018-12-03 13:17	djthekiller	Status	needs 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

Relationships