Anonymous | Login | Signup for a new account | 2024-10-15 12:49 PDT |
Main | My View | View Issues | Change Log | Roadmap |
View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | |||||
ID | Project | Category | View Status | Date Submitted | Last Update | |
0000605 | Dwarf Fortress | Dwarf Mode -- Military | public | 2010-04-06 04:54 | 2015-12-11 13:34 | |
Reporter | martinuzz | |||||
Assigned To | Toady One | |||||
Priority | high | Severity | major | Reproducibility | have not tried | |
Status | resolved | Resolution | fixed | |||
Platform | AMD Turion64, RandeonExpress1100 | OS | Windows | OS Version | XP SP3 | |
Product Version | 0.31.01 | |||||
Target Version | Fixed in Version | 0.31.11 | ||||
Summary | 0000605: When relieved from a squad, dwarves do not resume civilian jobs, even when squad is deleted entirely | |||||
Description | Okay.. 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' | |||||
Tags | barracks, idle, Military, squad, training | |||||
Attached Files | ||||||
Relationships | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
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 |
Copyright © 2000 - 2010 MantisBT Group |