Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000605Dwarf FortressDwarf Mode -- Militarypublic2010-04-06 04:542015-12-11 13:34
Assigned ToToady One 
PriorityhighSeveritymajorReproducibilityhave not tried
PlatformAMD Turion64, RandeonExpress1100OSWindowsOS VersionXP SP3
Product Version0.31.01 
Target VersionFixed in Version0.31.11 
Summary0000605: When relieved from a squad, dwarves do not resume civilian jobs, even when squad is deleted entirely
DescriptionOkay.. I assigned a military commander..
Made a squad, assigned my 3 miners under him.
Set my miners, all 3 of them, to 'pick (exotic)' as weapon choice.
Designated a barracks.
Squad went to spar on 'individual combat drill)

I then tried the training alert. Military commander started preparing training session. However, I read that it was bugged, and turned it off, back to inactive.
The 3 miners reverted to doing individual combat drill immediatly.
The military commander is stuck at preparing training session.

Now, I needed my miners again.
First, in the military screen, I manually removed them from squad.
They kept drilling.

Then, I deleted the entire squad.
They kept drilling.

Then I removed the barracks designation.
2 stopped sparring, one was out getting a drink. I rebuilt the barracks. The dwarf out getting a drink got back to it, and resumed individual combat drill again. The military commander got back to preparing combat training.

Now, the other 2 miners, who stopped drilling, are idling around. They did get the 'pickup equipment' job, and are holding a pick in their left hand.
However, they are not mining. I tried redesignating an area for mining. No effect.

So, In practice, they are no longer in the military. Heck, their squad does not even exist anymore. I made a new squad, with the military commander only.
But, they are not going back to their civilian job, and one even thinks he still is a soldier, since he did not even get the 'pickup equipment' job, but is still on 'individual combat drill'

Tagsbarracks, idle, Military, squad, training
Attached Files

- Relationships
related to 0000428acknowledgedToady One Dwarves refuse to train, and other training weirdness 
parent of 0000181resolvedToady One Soldier gets stuck waiting for a demonstration. 
parent of 0000284resolvedToady One Military Training: Odd Behavior 
parent of 0001426resolvedToady One freshly created squads train in 'civilian mode' 
parent of 0001450resolvedToady One Dwarves will not harvest bushes or cut trees after a period of time. 
parent of 0001574resolvedToady One Militia commander stuck in Go to training 
parent of 0001731resolvedToady One Military dwarf successfully completes mood; won't perform civilian tasks when unassigned from military 
parent of 0001413resolvedToady One Post - Artifact Ex Soldier Dwarf Does Nothing 
parent of 0003068resolvedLogical2u dwarves quit working 
has duplicate 0000591closedFootkerchief Dwarves will remain in "no job" state 
has duplicate 0000853closedFootkerchief "No job" dwarf not counted as idle 
has duplicate 0002061closedFootkerchief Military dwarves get stuck with job "Go to Individual Combat Drill" 
has duplicate 0002062closedFootkerchief Miner listed as "No Job" while mining job available 
has duplicate 0002307resolvedFootkerchief Ex-military still training 
has duplicate 0000574resolvedFootkerchief Dwarfs do not change back from military icon to civilain 
has duplicate 0002546resolvedFootkerchief Dwarfs that have been removed from all squads continue to train 
has duplicate 0002551resolvedFootkerchief Elvens cancel trade after being offered food in a barrel and broker will not go back to work 
has duplicate 0000534resolvedFootkerchief After deleting a squad, dwarf still goes to combat drills, won't perform civilian tasks 
has duplicate 0002680resolvedFootkerchief Squad continues to train after being told to stop 
related to 0001174resolvedFootkerchief Dwarf is stuck doing non-cancelable tasks 
related to 0001774new Ex-military Dwarf hunted vermin and starved himself to death despite having access to food and drink 
related to 0001443confirmedFootkerchief Former guards continue to beat criminals 
related to 0000388acknowledgedlethosor Military units give incorrect task information 

-  Notes
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: [^] [^]

possibly: [^] [^]

thread about it: [^]
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.
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%.
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.
Artfunkel (reporter)
2010-04-10 06:25

Civilians stuck in the "false no job" state can still throw parties and store owned items, oddly.
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"
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.
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.

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.
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.
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.
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.
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).

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.
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 [^] They are very useful for these sorts of bugs, especially with small forts where the offenders are easier to isolate, but anything should work.
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.
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.

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.
Footkerchief (manager)
2010-06-13 14:04

Gotcha, it's no problem.
LoSboccacc (reporter)
2010-06-27 14:41

save with stuck dwarves, 0.31.08: [^]
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.
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.

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

Copyright © 2000 - 2010 MantisBT Group
Powered by Mantis Bugtracker