0008846: Miners only dig exposed tiles, then become idle.

Notes
(0032338) Detros (manager) 2015-03-07 08:12	Are you sure - those tiles are truly designated and not just markers? - those tiles have some higher (1,2) priority assigned? - those tiles are accessible (designated but not exposed tiles can't be dug)? - those dwarves have mining labor enabled? - those dwarves have mining equipment equipped or accessible? - those dwarves are not confined in a burrow without those tiles? - civilian alert confining civilian dwarves to some area is inactive? If any of these make it please upload your zipped save folder to http://dffd.bay12games.com/ [^] and post a link to it here so we can have a look.

(0032339) Merelorn (reporter) 2015-03-07 10:24	Thank you for the suggestions. I have checked them all but none seem to be the cause: - the tiles are designated (You have just taught me about the existence of markers!) - even with increased priority the problem persists - they are accessible (the miner just decided to stop mining halfway through mining a corridor) - no burrows or alerts used - miners have been mining until this very moment, stopping without me interacting with them (mining labor enabled, equipment equipped) - miners are not involved in military I have uploaded the save here: http://dffd.bay12games.com/file.php?id=10651 [^]

(0032341) Merelorn (reporter) 2015-03-07 12:31 edited on: 2015-03-07 13:52	I might add that I have saved and reloaded the game several times prior to this issue popping up without problems. Then this happened. I have reloaded from a backup and have played for some time. Then it occurred again. One of the reloads resulted in another bug - dwarf getting stuck while building a door, making the tile impassable to everyone. I suspect this might be a memory leak. The embark site is large (12x12), memory usage shows 2.09 GB. Loading the save in Windows Vista crashes the game straight away upon approaching 2GB. However, the fact that it produces bugs instead of a crash perhaps suggests that some part of the code does not do as it should.

(0032345) Detros (manager) 2015-03-07 19:49	I have downloaded your save, it loads slow and when it finally does the game is unplayable: loading designation screen takes like 30 seconds so I have closed its console after "resume game" didn't do anything even three minutes after hitting spacebar. In recent versions can dwarves need like even over 10 secs to pick next job sometimes. Though mining usually seems resilient against that to me, taking jobs in nearby tiles. Your area is huge and it is quite forested. These new multilevel trees can be quite power hungry so my guess game is so busy with them it doesn't have time for your miners :D . Was this fort/world also generated in 40.24 or is it from older versions? There used to be 0008649, "Unreachable high-priority mining jobs prevent lower-priority jobs from being taken"

(0032346) Merelorn (reporter) 2015-03-08 00:27 edited on: 2015-03-08 00:30	Yes, generated in 40.24. I have looked at 8649, but that is not my case. I have actually only learnt about priority designations from your first suggestion (thanks). I have tried increasing the priority but to no avail (or surprise). Delayed picking of jobs is not the case either. After loading, miners pick up the job immediately, only to become idle after digging a single tile - and remain idle indefinitely. I can run the game, although it is significantly slower than I'm used to. I do share your dwarven sentiment of blaming the trees, but even if that is not the case I find the 2GB RAM usage highly untrustworthy. I leave that as a suggestion and the most likely source of the problem. Other than that I'm out of ideas.

(0032347) Detros (manager) 2015-03-08 04:12	Few more ideas: So you can get each miner to dig one tile once per each loading? Or only one after loading of this save? Seeing how slow it was for me I haven't even tried if re-saving does anything with this issue. You may additionally try designating other areas for digging, using other types of designations or forbidding, dumping, reclaiming and giving of those picks to other dwarves. And also check your errorlog.txt located in the main DF folder. Maybe they have some pathing issues. You haven't mentioned it, so to clarify: are you using any mods, graphic tilesets? Have you done any changes of raw files? Or are you using vanilla 40.24? And for that Windows version, is it SDL or Legacy one?

(0032384) Merelorn (reporter) 2015-03-18 08:44	Apologies for disappearing, I was kinda busy. I am using vanilla version in both cases, SDL for Win. It is one tile per loading. Designating new areas allows mining of one tile in that area. Passing the picks to other dwarves makes no difference, nor does resaving. I have checked the errorlogs: Connected Component Overflow Connected Component Overflow path fail: pond grabber,76,114,33 -> 76,113,33: Id 0001074:Path Goal Seek Station Flood:Station Owner at 76,113,33 Connected Component Overflow The 'path fails' do occur, but these seem to be random and sometimes do not appear at all. What does appear regularly is the connected component overflow - once upon loading once, once upon unpausing the first time, then occsaionally accompanied by a short freeze.

Issue History
Date Modified	Username	Field	Change
2015-03-07 07:28	Merelorn	New Issue
2015-03-07 08:12	Detros	Note Added: 0032338
2015-03-07 09:42	Merelorn	Issue Monitored: Merelorn
2015-03-07 10:24	Merelorn	Note Added: 0032339
2015-03-07 12:25	Merelorn	Tag Attached: 0.40.24
2015-03-07 12:25	Merelorn	Tag Attached: designation
2015-03-07 12:25	Merelorn	Tag Attached: mining
2015-03-07 12:31	Merelorn	Note Added: 0032341
2015-03-07 13:52	Merelorn	Note Edited: 0032341	View Revisions
2015-03-07 19:49	Detros	Note Added: 0032345
2015-03-08 00:27	Merelorn	Note Added: 0032346
2015-03-08 00:30	Merelorn	Note Edited: 0032346	View Revisions
2015-03-08 04:12	Detros	Note Added: 0032347
2015-03-18 08:44	Merelorn	Note Added: 0032384

Relationships