0000605: When relieved from a squad, dwarves do not resume civilian jobs, even when squad is deleted entirely

Notes
(0001404) derigo (reporter) 2010-04-06 05:34	This is the most detailed report of this bug so far, (I'd have reported it, but I thought it had been reported on Mantis already). It should be noted that dwarves stuck in this perma-military mode show their job as "no job" yet are not counted as idle dwarves. Sometimes, they'll permanently show a military task as their job, such as 'Individual combat drill', or 'Waiting for demonstration' etc, rather than 'no job', but the effect is the same. It should also be noted that as a halfassed workaround, you can reassign the dwarves to the military and give them orders, and they will follow them. They just can't go back civie properly. other, less detailed reports of this bug: http://bay12games.com/dwarves/mantisbt/view.php?id=181 [^] http://bay12games.com/dwarves/mantisbt/view.php?id=591 [^] possibly: http://bay12games.com/dwarves/mantisbt/view.php?id=499 [^] http://bay12games.com/dwarves/mantisbt/view.php?id=284 [^] thread about it: http://www.bay12games.com/forum/index.php?topic=52245.0 [^]

(0001494) Tallim (reporter) 2010-04-06 09:38	I did some trial runs on this and the dwarfs getting stuck in military mode only occurs if they start training. A squad with the training turned off at the barracks will return to normal work when disbanded. Any dwarf that as begun any form of training stops working outside the military.

(0001841) derigo (reporter) 2010-04-07 13:38	No, I've had lots of dwarves stop training and resume civilian life normally. Though training seems like the trigger, its not 100%.

(0002260) Igfig2 (reporter) 2010-04-08 21:58	While military worked just barely for me in 31.01 (with the caveat that I had to do the barracks shuffle to stop individual combat drills), I find that in 31.02 it's completely broken. My dwarves are all in civilian garb, doing individual combat drills, and nothing I do can compel them to return to proper sparring. This isn't a matter of old bugs; two identical save files, one in .01 and one in .02, exhibit different behaviour.

(0002557) Artfunkel (reporter) 2010-04-10 06:25	Civilians stuck in the "false no job" state can still throw parties and store owned items, oddly.

(0002998) Dewar (reporter) 2010-04-12 00:53	I recently was having a problem getting an undead marmot killed. As it had lost all of its limbs and was effectively unable to fight, I created a squad with all of my normally civilian dwarves in it, and used the immediate attack order to go after the marmot. I didn't ever take the squad off of inactive, assign uniforms, assign them to a barracks, or anything like that. As far as I know none of them ever went into training as I sent them the immediate kill order right after I formed the squad. After a while, it was obvious that even this wasn't going to kill the marmot, so I disbanded the squad. Now all of those civilians appear as civilians with "No Job" and count as idle dwarves, but are all stuck in a circle around the marmot fighting forever. The only reason I know that they're actually fighting is that several have leveled up all the way to legendary wrestlers. This issue has persisted through several save and loads, recreating the original squad, designating a burrow and telling all civilians and guards to go there, and pretty much any other way I could think of to force them to move. I have uploaded my save file at DFFD under the heading "Bugged Save for Issue 0000605. Version 31.02"

(0003018) marcbyrne (reporter) 2010-04-12 03:28	Not much to add except that I'm able to reproduce this bug. Anyone I've put into a squad doesn't seem to ever do civilian work again. This definitely is the case once they've done any kind of training. I'm not sure it that is a requirement for the bug however.

(0003698) neonraven (reporter) 2010-04-15 09:19 edited on: 2010-04-15 09:20	Also experiencing the same bug in .03 although not with all of my military dwarves- first it was just my militia commander, but now 3 of my six military dwarves are stuck in the no job state. I've tried deleting their squad, putting them in new squads, removing any furniture that served as barracks, and they are still stuck although they eat, drink, and store owned items. They also had been on alert with the "Train" order at some point, and I have also cut/pasted orders with various levels of complexity which some people have mentioned as possibly being related.

(0003706) DoctorZuber (reporter) 2010-04-15 10:01	so... he was in the middle of "individual combat training" when his task was interrupted? If so this sounds like the same behavior I am seeing in 0000733. I just hadn't tested this case yet. What I think is happening is the new "dwarven work ethic" (0000008) is preventing the civilian job from interrupting the training job. I was testing some of this behavior using a task I could control reliably with a burrow.

(0006094) Niveras (reporter) 2010-05-04 10:30	I think this (or at least a child of this - 0001731) issue might be a hold over from the previous version, where dwarves legendary in a military skill could no longer be used for civilian tasks. Because of the changes to the military system, any legendary skill on a military dwarf makes them think they are too good for civilian work. Curiously, unlike a comment above, my "No Job" legendary military aren't listed among the idle dwarves - they simply have no job. An alternative possibility is that the Combat Drill job isn't being properly cleared when you turn off training/free the room at their assigned barracks, as I've noticed dwarves with no assigned barracks (but still a barracks defined) continue their drilling. This may explain why the military dwarves with no jobs aren't included in the number of idle dwarves. I tested this with a legendary bonecrafter who I made a captain, assigning him alone in his own squad with his own barracks. He moved to perform a combat drill, continued to drill after I disabled his squad's training at that barracks (but left the barracks defined), and remained with No Job, but not performing civilian tasks, after I freed the Barracks room. This persists even when I delete his squad and replace his captain position with a vacancy. In addition to these observations, my non-legendary military dwarves perform their civilian tasks fine, so I tend to favor the idea that legendary dwarves with military service thinking they are too good for civilian service versus the combat drill not being cleared properly.

(0006110) hyndis (reporter) 2010-05-04 12:59	The issue seems to only occur when they're doing training. It may be that the training task is not cleared properly, and so if you remove the barracks later on, even if they have no job they will not show up as an idler and thus will be ineligible to take any other jobs aside from eating/sleeping/boozing.

(0006189) Adarael (reporter) 2010-05-05 10:27	I had an interesting occurance of this bug. I'd been ordering my military dwarves around willy nilly for about a year, and my game saved based on a change of season - I have auto-save on. I kept playing, ordered my dwarves to do some stupid stuff during a siege a months or two after the autosave - I used the squad menu to give them a kill order on a siege group - and got them all killed. However, on loading my save - the auto-save - the squad was locked in a no-orders training loop, ignoring every order, including kill and move orders.

(0006226) slander (reporter) 2010-05-05 19:16 edited on: 2010-05-05 19:16	The "do nothing" bug seems to have spread throughout my dwarfs. I originally had 20-something dwarfs in various squads until I noticed they got stuck in training, and would not rotate properly according to schedule. I deleted all squads and removed all barracks/training rooms, which led to the ex-soldiers getting stuck in the "No job" role. I am not sure what has happened, but now I have 40+ dwarfs who refuse to take a job, and dwarfs who are actually operational are refusing jobs like hauling refuse or harvesting plants (though woodcutters seem to be working just fine).

(0007062) yarbelk (reporter) 2010-05-20 05:06	So, I have a militia commander, with no squad, and I cannot remove or change his militia post. Other weired behavior related to this I think, when I add/change squads, the Capitan of The Guard position gets vacated. On the Military screen there are still several squads avalible to for (militia commander -> press 'c' to create squads). Most annoying, as the commander keeps trying to hold squad training despite he has no squad, and all my miners refuse to mine as a result.

(0007709) Toady One (administrator) 2010-06-05 01:32	The perpetually "no job" idling state for dwarves that were formerly doing individual drills is handled for 0.31.06. If I'm reading the original issue report correctly, the issues remaining there are: 1) Cancelled organized training -> commander still stuck preparing session 2) Dwarves doing indiv drills, remove from squad -> still drilling 3) Dwarves doing indiv drills, delete squad -> still drilling 2+3 are expected, I think, since they don't link up their personal activities with their squad identification once they are underway. I'll get it fixed up at some point. 1 is something I hope I can reproduce or that I can get a save where it can be reproduced (before the actual cancellation preferably). Saves can be uploaded to http://dffd.wimbli.com. [^] They are very useful for these sorts of bugs, especially with small forts where the offenders are easier to isolate, but anything should work.

(0008322) Redd (reporter) 2010-06-13 13:31	> 2) Dwarves doing indiv drills, remove from squad -> still drilling This is definitely still happening as of 0.31.06. It's not so much "still drilling" which implies they don't stop immediately upon removal, so much as "will perform no other work but drills", i.e. it's still effectively a no job/useless dwarf situation.

(0008323) Footkerchief (manager) 2010-06-13 13:34 edited on: 2010-06-13 13:35	Redd, not sure if you saw the next sentence of Toady's post: 2+3 are expected, I think, since they don't link up their personal activities with their squad identification once they are underway. I'll get it fixed up at some point.

(0008324) Redd (reporter) 2010-06-13 13:54	I did see the next sentence, and I also saw the previous sentence "If I'm reading the original issue report correctly" and was posting to both confirm the 'reading' of case 2, and to clarify it's interpretation. If this was redundant then I apologise.

(0008325) Footkerchief (manager) 2010-06-13 14:04	Gotcha, it's no problem.

(0009172) LoSboccacc (reporter) 2010-06-27 14:41	save with stuck dwarves, 0.31.08: http://dffd.wimbli.com/file.php?id=2589 [^]

(0010953) Toady One (administrator) 2010-07-25 06:33	I fixed the remaining issues I mentioned in my last note for 0.31.11, but the two child issues 0000499 and 0001174 aren't handled/tested yet.

(0010968) Footkerchief (manager) 2010-07-25 09:42 edited on: 2010-07-25 09:42	Reminder sent to: Toady One I moved 0000499 over to 0000428 (the other training catchall), and I switched 0001174 from "child" to "related" (since it's weird and we don't have a save for it). The upshot: this can be marked resolved now, if you want.

(0010972) Toady One (administrator) 2010-07-25 09:59	Okay, I'll mark it off then, since 0000428 is still stickied and can kind of reflect the overall status of training.

Issue History
Date Modified	Username	Field	Change
2010-04-06 04:54	martinuzz	New Issue
2010-04-06 05:34	derigo	Note Added: 0001404
2010-04-06 09:20	Footkerchief	Relationship added	parent of 0000181
2010-04-06 09:20	Footkerchief	Relationship added	parent of 0000591
2010-04-06 09:20	Footkerchief	Relationship added	parent of 0000499
2010-04-06 09:20	Footkerchief	Relationship added	parent of 0000284
2010-04-06 09:38	Tallim	Note Added: 0001494
2010-04-06 09:55	Justice	Issue Monitored: Justice
2010-04-07 10:07	RusAnon	Issue Monitored: RusAnon
2010-04-07 13:38	derigo	Note Added: 0001841
2010-04-08 21:58	Igfig2	Note Added: 0002260
2010-04-08 23:18	Footkerchief	Relationship added	parent of 0000853
2010-04-08 23:19	Footkerchief	Relationship replaced	has duplicate 0000853
2010-04-08 23:20	Footkerchief	Relationship replaced	has duplicate 0000591
2010-04-09 03:39	Khym Chanur	Issue Monitored: Khym Chanur
2010-04-09 15:15	Footkerchief	Relationship added	child of 0000428
2010-04-10 05:21	Artfunkel	Issue Monitored: Artfunkel
2010-04-10 06:25	Artfunkel	Note Added: 0002557
2010-04-10 06:29	Jiri Petru	Issue Monitored: Jiri Petru
2010-04-11 10:57	Fleischwolff	Issue Monitored: Fleischwolff
2010-04-12 00:53	Dewar	Note Added: 0002998
2010-04-12 00:54	Dewar	Issue Monitored: Dewar
2010-04-12 03:13	marcbyrne	Issue Monitored: marcbyrne
2010-04-12 03:25	marcbyrne	Tag Attached: Military
2010-04-12 03:25	marcbyrne	Tag Attached: idle
2010-04-12 03:26	marcbyrne	Tag Attached: training
2010-04-12 03:28	marcbyrne	Note Added: 0003018
2010-04-12 04:40	Dwarfu	Issue Monitored: Dwarfu
2010-04-15 09:19	neonraven	Note Added: 0003698
2010-04-15 09:20	neonraven	Note Edited: 0003698	View Revisions
2010-04-15 10:01	DoctorZuber	Note Added: 0003706
2010-04-15 12:07	Footkerchief	Relationship added	parent of 0001174
2010-04-15 16:43	RaptorJedi	Issue Monitored: RaptorJedi
2010-04-22 00:40	Cameo	Issue Monitored: Cameo
2010-04-22 09:19	Footkerchief	Relationship added	parent of 0001426
2010-04-23 23:32	Footkerchief	Relationship added	parent of 0001450
2010-04-27 13:02	Footkerchief	Relationship added	parent of 0001574
2010-05-01 09:59	yeesh	Issue Monitored: yeesh
2010-05-03 21:30	Footkerchief	Relationship added	parent of 0001731
2010-05-04 03:37	Logical2u	Relationship added	parent of 0001413
2010-05-04 10:30	Niveras	Note Added: 0006094
2010-05-04 12:59	hyndis	Note Added: 0006110
2010-05-05 10:27	Adarael	Note Added: 0006189
2010-05-05 19:16	slander	Note Added: 0006226
2010-05-05 19:16	slander	Note Edited: 0006226	View Revisions
2010-05-20 05:06	yarbelk	Note Added: 0007062
2010-05-24 10:48	Footkerchief	Relationship added	has duplicate 0002061
2010-05-26 13:40	Footkerchief	Relationship added	has duplicate 0002062
2010-06-04 13:25	Hieronymous Alloy	Issue Monitored: Hieronymous Alloy
2010-06-04 13:44	Footkerchief	Sticky Issue	No => Yes
2010-06-04 17:24	Footkerchief	Relationship replaced	related to 0000428
2010-06-04 18:55	BlackRogueDreams	Issue Monitored: BlackRogueDreams
2010-06-04 21:00	Cardinal	Issue Monitored: Cardinal
2010-06-05 00:37	Cel	Issue Monitored: Cel
2010-06-05 01:04	kaustic	Issue Monitored: kaustic
2010-06-05 01:32	Toady One	Note Added: 0007709
2010-06-05 01:32	Toady One	Assigned To	=> Toady One
2010-06-05 01:32	Toady One	Status	new => acknowledged
2010-06-06 11:01	snelg	Issue Monitored: snelg
2010-06-07 02:25	lucasup	Issue Monitored: lucasup
2010-06-07 05:40	EvilGrin	Issue Monitored: EvilGrin
2010-06-11 05:53	Kyle_Solo	Issue Monitored: Kyle_Solo
2010-06-13 13:18	Footkerchief	Relationship added	has duplicate 0002307
2010-06-13 13:27	Redd	Issue Monitored: Redd
2010-06-13 13:31	Redd	Note Added: 0008322
2010-06-13 13:34	Footkerchief	Note Added: 0008323
2010-06-13 13:35	Footkerchief	Note Edited: 0008323	View Revisions
2010-06-13 13:54	Redd	Note Added: 0008324
2010-06-13 14:04	Footkerchief	Note Added: 0008325
2010-06-22 09:18	Footkerchief	Relationship added	related to 0001774
2010-06-22 18:26	Footkerchief	Relationship added	related to 0001443
2010-06-25 08:26	Threlicus	Issue Monitored: Threlicus
2010-06-27 14:41	LoSboccacc	Note Added: 0009172
2010-06-27 15:32	LoSboccacc	Issue Monitored: LoSboccacc
2010-06-30 13:48	Footkerchief	Relationship added	has duplicate 0000574
2010-07-02 15:32	Footkerchief	Relationship added	has duplicate 0002546
2010-07-02 15:32	Footkerchief	Issue Monitored: dorfyone
2010-07-03 20:09	Blebleman	Issue Monitored: Blebleman
2010-07-05 09:29	Footkerchief	Relationship added	has duplicate 0002551
2010-07-07 00:17	Footkerchief	Relationship added	has duplicate 0000534
2010-07-07 00:17	Footkerchief	Issue Monitored: codeManJones
2010-07-07 00:17	Footkerchief	Issue Monitored: Roadkiller
2010-07-07 01:04	Lester	Issue Monitored: Lester
2010-07-07 02:10	alexleon	Issue Monitored: alexleon
2010-07-09 21:27	TomiTapio	Tag Attached: squad
2010-07-11 09:56	Profligate	Issue Monitored: Profligate
2010-07-13 15:49	Footkerchief	Relationship added	has duplicate 0002680
2010-07-15 05:09	eXperion	Issue Monitored: eXperion
2010-07-15 05:09	eXperion	Issue End Monitor: eXperion
2010-07-15 09:33	TomiTapio	Tag Attached: barracks
2010-07-15 11:01	Calite	Issue Monitored: Calite
2010-07-15 18:56	RossM	Issue Monitored: RossM
2010-07-19 20:29	eatatree	Issue Monitored: eatatree
2010-07-25 06:33	Toady One	Note Added: 0010953
2010-07-25 09:37	Footkerchief	Relationship replaced	related to 0001174
2010-07-25 09:38	Footkerchief	Relationship deleted	parent of 0000499
2010-07-25 09:42	Footkerchief	Note Added: 0010968
2010-07-25 09:42	Footkerchief	Note Edited: 0010968	View Revisions
2010-07-25 09:59	Toady One	Note Added: 0010972
2010-07-25 09:59	Toady One	Status	acknowledged => resolved
2010-07-25 09:59	Toady One	Fixed in Version	=> 0.31.11
2010-07-25 09:59	Toady One	Resolution	open => fixed
2010-07-25 12:27	Dwarfu	Issue End Monitor: Dwarfu
2010-07-25 19:05	alexleon	Issue End Monitor: alexleon
2010-07-26 05:40	Threlicus	Issue End Monitor: Threlicus
2010-08-02 21:18	Blebleman	Issue End Monitor: Blebleman
2010-08-08 06:32	Ancelyn	Issue Monitored: Ancelyn
2010-08-14 02:51	Khym Chanur	Issue End Monitor: Khym Chanur
2010-08-19 17:55	Logical2u	Relationship added	parent of 0003068
2010-09-06 08:21	Dwarfu	Sticky Issue	Yes => No
2010-09-07 04:51	Hieronymous Alloy	Issue End Monitor: Hieronymous Alloy
2010-09-11 13:18	lucasup	Issue End Monitor: lucasup
2010-12-23 10:15	Footkerchief	Relationship added	has duplicate 0000388
2011-03-21 17:10	RossM	Issue End Monitor: RossM
2011-03-27 15:44	LoSboccacc	Issue End Monitor: LoSboccacc
2012-06-04 14:51	eatatree	Issue End Monitor: eatatree
2014-07-18 00:22	Cel	Issue End Monitor: Cel
2015-04-06 18:33	lethosor	Relationship replaced	related to 0000388
2015-12-11 13:34	Calite	Issue End Monitor: Calite