|Anonymous | Login | Signup for a new account||2023-03-24 08: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|
|0001806||Dwarf Fortress||Dwarf Mode -- Military||public||2010-05-08 22:10||2011-03-14 09:52|
|Assigned To||Toady One|
|Priority||normal||Severity||minor||Reproducibility||have not tried|
|Platform||PC||OS||Windows Vista||OS Version||64-bit|
|Target Version||Fixed in Version||0.31.22|
|Summary||0001806: Non-cancelled kill orders persist into newly generated world and fortress.|
|Description||While defending a fortress, a squad of three soldiers were ordered through the kill list to destroy two alligators. Upon seeing the fun that was bestowed on me, I opted to abandon the fortress and generate a new world (attempting to find ideal evil and savagery settings (namely high)). I did not cancel the order.|
Upon embarking to the new fortress in this new world and setting up a new squad, the squad immediately activated and when looking at the squad menu, they had standing orders to kill alligators.
|Steps To Reproduce||Create squad.|
Order squad to kill creature.
Abandon fortress without canceling orders.
Either create new world and fortress, or possibly even simply a new fortress or even a saved one.
|Additional Information||This is running on the current Mayday version.|
|Tags||No tags attached.|
|God that's appalling.|
edited on: 2010-07-25 18:57
A perhaps slightly more serious consequence is that orders persist between saves. Facing an overwhelming siege I made a backup save to see what would happen if I tried to face it. I then ordered my military out the main gates, and watched them get slaughtered, fort spiral into defeat.
I restored to the backup to try a more conservative/cowardly/survivable tactic. This time I'll just raise the drawbridge, right? My military charged out the main gates, I watched them get slaughtered, fort spiral into defeat.
A quick test confirms that orders persist between saves the same as between fortresses.
Edit: This is less easy to test, but there seem to be other bits of squad information that incorrectly persist between saves. Namely, who's in a particular squad. Following the first massacre, only 3 dwarves from my military lived. Upon the reload, only those were listed as being in their squads, and the ones that were missing couldn't be re-added. I could add more dwarves, though, and any orders given to the squad would then potentially effect more then 10 dwarves. Probably just one bug, which is that with the revamped military, squad information isn't cleared when one saves or abandons.
|Niveras posted this save for duplicate report 0002974: http://dffd.wimbli.com/file.php?id=2909 [^]|
edited on: 2010-11-30 18:21
This bug still exists in .18
I removed a squad member from a squad, then had to load a previous autosave from before that squad member was removed. Upon loading the new save, that squad member was not listed as a member of the squad, nor was that dwarf listed among dwarves eligible to be added to the squad. That dwarf continued to behave as a member of the squad, responding to station orders, carrying equipment, and training. Filling the vacant squad position seemed to have no effect on that dwarf's behavior.
I was able to find a workaround for my particular problem. I made that dwarf my captain of the guard, activated the captain of the guard squad, then fired her, and the dwarf went back to normal behavior.
|Exists in .21, much the same as in piesquared's case. Orders persist, and members who died are no longer in the squad upon reload. Exiting the game and re-loading "solves" the problem.|
|2010-05-08 22:10||Kazlor||New Issue|
|2010-05-09 00:12||Footkerchief||Note Added: 0006441|
|2010-07-17 19:19||Logical2u||Relationship added||has duplicate 0002742|
|2010-07-18 01:52||Footkerchief||Relationship added||related to 0000481|
|2010-07-25 18:41||piesquared||Note Added: 0011040|
|2010-07-25 18:57||piesquared||Note Edited: 0011040||View Revisions|
|2010-08-07 10:08||Footkerchief||Relationship added||has duplicate 0002974|
|2010-08-07 10:08||Footkerchief||Note Added: 0011590|
|2010-08-08 14:47||Footkerchief||Relationship added||has duplicate 0002983|
|2010-08-15 13:08||Dwarfu||Relationship deleted||has duplicate 0002983|
|2010-08-18 05:00||Hieronymous Alloy||Issue Monitored: Hieronymous Alloy|
|2010-11-06 08:43||Logical2u||Relationship added||has duplicate 0002603|
|2010-11-15 13:48||Footkerchief||Relationship added||parent of 0003285|
|2010-11-15 14:01||Footkerchief||Relationship added||related to 0003602|
|2010-11-30 18:15||slothen||Note Added: 0014324|
|2010-11-30 18:21||slothen||Note Edited: 0014324||View Revisions|
|2011-02-28 21:32||Footkerchief||Relationship added||related to 0004099|
|2011-02-28 21:32||Footkerchief||Sticky Issue||No => Yes|
|2011-02-28 21:33||Footkerchief||Relationship replaced||parent of 0004099|
|2011-02-28 21:34||Footkerchief||Relationship added||parent of 0003109|
|2011-02-28 21:34||Footkerchief||Relationship added||related to 0003703|
|2011-02-28 21:35||Footkerchief||Relationship added||parent of 0002852|
|2011-02-28 21:35||Footkerchief||Relationship added||parent of 0001056|
|2011-03-05 00:30||Footkerchief||Relationship added||related to 0000277|
|2011-03-07 10:58||hyperactiveChipmunk||Note Added: 0015903|
|2011-03-09 04:08||Toady One||Relationship replaced||related to 0003109|
|2011-03-09 04:08||Toady One||Relationship replaced||related to 0002852|
|2011-03-09 04:09||Toady One||Status||new => resolved|
|2011-03-09 04:09||Toady One||Fixed in Version||=> 0.31.22|
|2011-03-09 04:09||Toady One||Resolution||open => fixed|
|2011-03-09 04:09||Toady One||Assigned To||=> Toady One|
|2011-03-14 09:49||Footkerchief||Relationship deleted||related to 0003703|
|2011-03-14 09:50||Footkerchief||Relationship added||related to 0003703|
|2011-03-14 09:52||Footkerchief||Sticky Issue||Yes => No|
|2013-03-04 02:46||Dwarfu||Relationship added||has duplicate 0002634|
|Copyright © 2000 - 2010 MantisBT Group|