Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000481Dwarf FortressDwarf Mode -- Combatpublic2010-04-05 09:482015-01-05 00:17
ReporterRhenaya 
Assigned ToToady One 
PrioritynormalSeverityminorReproducibilityalways
StatusacknowledgedResolutionopen 
PlatformOSOS Version
Product Version0.31.01 
Target VersionFixed in Version 
Summary0000481: Kill/attack commands/orders don't work
Descriptionthen setting up a kill command my dwarfs swarm back into the barracks instead of hunting the suspected target. then they will stay there around and do nothing.
Tagsbarracks, behaviour, combat, Fixed in 0.40.01?, training
Attached Files

- Relationships
related to 0008250resolvedToady One Military dwarves won't attack goblins 99% of the time, and when they do they cause a loyalty cascade. 
parent of 0000634new Squad is too busy training, ignores kill order 
parent of 0000929resolvedFootkerchief After Selecting entire squad then setting attack orders on multiple targets some soldiers will stand by 
parent of 0000800acknowledgedFootkerchief Squad attack pathfinding lags behind target movement 
parent of 0000114resolvedToady One Kill orders not cleared after completion 
parent of 0000860new Unable to (s)quad-(k)ill an aggressive-but-tamed named elephant. 
parent of 0001559new Dwarf wrestles foe until he dies from starvation; squad refuses to help out 
has duplicate 0002030closedFootkerchief dwarves not executing kill order 
has duplicate 0002390resolvedFootkerchief Squad not attacking when told to 
related to 0000149resolvedToady One When ordered to attack, squads can get distracted chasing harmless animals 
related to 0001806resolvedToady One Non-cancelled kill orders persist into newly generated world and fortress. 
related to 0001169new Soldiers follow enemies into the water, and then drown 
related to 0003882new Caged creatures are valid targets for kill orders 
related to 0005393new Military Dwarves not obeying kill orders, not following station orders properly, marksdwarves firing wildly into the air, etc. 
related to 0002655new Military dwarfs assigned to kill order never reach combat due to thirst 
related to 0003469acknowledgedFootkerchief Military orders are uninterruptable 
related to 0008367resolvedToady One Soldiers not attack nearby enemy when using kill or station order. 
Not all the children of this issue are yet resolved or closed.

-  Notes
(0001103)
Dwarfu (manager)
2010-04-05 09:54

This isn't always reproducible, I've had [k] attack commands work correctly.
(0001106)
Footkerchief (manager)
2010-04-05 10:06

Are your soldiers assigned to any burrows?
(0001111)
DoctorZuber (reporter)
2010-04-05 10:25

I've seen this once, and no my dwarves were not assigned to a burrow. I switched to issuing a move command which did get them to the intended area, unfortunately by the time I got there, the intended kill target had gone back into hiding. *sigh* However having said that, I might have a clue whats going on.

There is a new skill called observer.
I have "observed" (heh!) that monsters sometimes drop out of sight completely.

Is it possible that a kill order just sort of fails when a creature goes into hiding? Should a kill order at least send them to the last observed location?
(0001156)
Tobias (reporter)
2010-04-05 12:11

I also have a similar Problem. My dwarves won't attack a specific beast. Or rather the squad captain attacks it alone while all his man stand around in the barracks.
When I target something else they go after it just fine.
(0001214)
Rhenaya (reporter)
2010-04-05 14:46

well for me its reproducible as it never works, they just go into the barraks and train ... with the "kill giant rat" task active.

and no the rat was always visible, they even cornered it but instead of attacking they just went back
(0001230)
Nagassh (reporter)
2010-04-05 15:17

I've had this bug occur, I've also had the dwarves swarm around spamming 'pickup equipment' as their task, despite being told to carry their equipment even when inactive, having a look over them, most had their equipment on.

Another problem I've had is ordering a kill command and having 'x cancels pickup equipment, interupted by goblin' then standing on the spot.
(0001232)
king doom (reporter)
2010-04-05 15:20

I've seen mention of kill command only being issued to the first dwarf on the list, and all the solider dwarves assigned to him simply folling the dwarf trying to kill the problem. Give kill commands to each dwarf, that seems to work a bit better, or so I've been told.
(0001247)
DoctorZuber (reporter)
2010-04-05 15:53
edited on: 2010-04-05 15:54

okay. burrows, are not the problem. I've done a quick test and verified that a squad with orders will ignore burrow restrictions. I tested both for civilian alerts with a very small burrow designation where in all my civilians huddled in the corner, and also for specifically assigning every dwarf in my squad to a burrow. they went there as normal when no orders were given, but the instant a move or kill order was assigned to them they left the burrow to do their job. I would assume that this is "as intended" but I could be wrong.

this doesn't really explain why an entire squad would fail to follow orders. There has to be something else going on here.

My instinct would be that it may be another pathing related issue. Although I am curious about how the mechanics work for "observation" since I think this may also be a likely culprit.

(0001456)
SirPenguin (reporter)
2010-04-06 08:17

I've observed the kill command never being able to work on friendly targets that are not under my fort's control - things like friendly underground critters, Elves, Elven Diplomats, Elven Merchants, the donkeys the elves use, etc. etc.
(0001605)
Rhenaya (reporter)
2010-04-06 15:37

why is it duplicate of 618? i have no problem with friendly goblins, i wanted to attack an giant rat, which is a "wild animal" and sure not friendly (the dwarfs and merchang dwarfs slaughter it then it comes to near)

so it is for sure not about not working on friendlies.

its about i want to kill the freaking giant rat and they just rush into barracks and start training (their skills increase) with the "kill giant rat" taks active
(0001749)
Rhenaya (reporter)
2010-04-07 08:45

ok, it may be is related? the giant rats are inhabitants from a cave (and also a dragon) so they there here on embark (just like the friendly goblins from the other issues)

but the kobold thief i found, was no problem it seemed. (still the merchant escorts charged both, the rats and the kobolds)
(0002592)
DoctorZuber (reporter)
2010-04-10 09:33

I don't like that we're not allowed to "choose" to attack the merchants now. That's just not the dwarf way when you can't randomly attack the merchants and steal their stuff.
(0002594)
DoctorZuber (reporter)
2010-04-10 09:36

the relationship to 0000618 looks like a mistake. It is a very different issue.
(0002600)
HunterZ (reporter)
2010-04-10 10:55
edited on: 2010-04-10 10:55

Are the squad members in the barracks all sleeping? I had that happen when I tried to attack some hostile goblins, but I thought it was because they were tired or wounded (since my barracks was also zoned as a hospital).

I was later able to make a squad attack some macaques that were driving me nuts. They even attacked one that was caught in a cage trap near my main entrance.

(0002628)
DoctorZuber (reporter)
2010-04-10 13:07

when things get "stuck" they tend to just fall asleep, I've noticed this testing other stuck behaviors. With as common as these are they could be confusing this issue.
(0002697)
savanik (reporter)
2010-04-10 20:23

Here's my experience:

I order my guard squad to 'Station' near the front gate, then pull the lever to open the gate. This is while they are 'Active/Training'.

My guards stand around a bit, occasionally sipping from their waterskins, when suddenly... 'Ambush!' They see 12 goblins outside.

I order the squad to kill the goblin! Again through the squad menu.

They immediately turn and run back into the barracks, letting the goblins rush into the fortress unchallenged.

Fortunately my barracks is very close to the entrance, so they don't get real far. BUT STILL! The goblin is in front of you! You see the goblin! You are ordered to kill the goblin! Why are you running that way? The battle is BEHIND us!
(0002711)
Wirrit (reporter)
2010-04-10 21:31

I've had varied success with the kill command. With the same fort, and same squads, no less. There might be misc. issues involved, though.

1) Worked just fine to clear away inconvenient (neutral) goats, marmots, etc.
2) Did not work on irritating (friendly) diplomat.

In another fort, I also had it work quite effectively on (hostile) creatures from the underground.
(0002779)
DoctorZuber (reporter)
2010-04-11 04:15

From my experience kill refuses to work on (friendly) targets not under your control. I have tried on several occasions to try to attack merchants only to have my squad ignore me.

kill will work for killing your own dwarves however, such as berserking dwarves, or even somebody you just don't like very much.
(0002989)
Shadowlord (reporter)
2010-04-11 23:22

I've had the kill command fail to work on two titans, and had to tell them to move past it, which got their attention. (Defending fortress also wasn't working on the titans)

As far as I could tell the kill orders were working on wild animals, insofar as the dwarves would endlessly chase them without ever catching them.

UNTIL NOW. Turns out it doesn't actually work. My Colonel caught a hoary marmot who I had ordered the squad to kill, and beat it senseless with two training swords (which he wasn't supposed to have, the cruel bastard... he should have had an artifact mace, but no, it's sitting in the vault still). Once he beat the marmot to yellow wounds with blue internal organs and it started flitting between unconscious, stunned, faint, and other such states, all the other dwarves in the squad just froze in place and STOOD THERE, even the ones who were only 3 squares away from the marmot.

Standing still and not moving from the spot was exactly what they were doing when I had ordered the squad to kill the titans earlier, and even better, the titans also had yellow and some red wounds (which tended to heal back to yellow) with blue internal organs (due to fighting dogs and wrestling with civilians) when I issued their kill orders.

So I would not be surprised if the kill order breaks whenever the target sustains either substantial injuries, or perhaps blue internal injuries, although precisely which is shutting it down, or whether it's something else related to combat, I don't know for sure. I don't think it's unconsciousness, since the squad (except for the Colonel) remained frozen while the marmot was only faint, and the titans never went unconscious.

Further: They all unfroze when I switched the kill order to a move order. The marmot proceeded to retreat onto a cage trap. I have a ton of caged critters, so I think I'll reproduce this in an arena with a wolf or the like, and make a video of it.
(0002995)
Shadowlord (reporter)
2010-04-12 00:21

Well! There goes that theory (or maybe there's something wrong with titans too).

I just had another titan invade, and immediately ordered the same squad to kill it, and they just froze in place, even though the titan was unharmed. Now, this titan only had three body parts, though, two of which were wings, so... It was a giant slug with leathery skin (not that that stopped it from flying over the city walls and toppling several buildings).
(0004277)
Leperous (reporter)
2010-04-19 16:11

I'm finding my bugged kill order has led to a bunch of slackers standing around in the dining hall, and a few others who are effectively invincible: one is single handedly lopping off the feet of a forgotten spider beast, one has been webbed by a giant spider for about 2 months, and another has had major heart and lung injuries for the same amount of time while in combat with (another) invincible ant man.

Oddly if I cancel the kill order, which should revert to a station order, all the dwarves go off duty and the ones under attack all instantly die.

I'd attach the save file, but I can't be bothered, it's obvious to everyone that kill orders don't work 100%.
(0004524)
RusAnon (reporter)
2010-04-21 17:06

I had this issue several times.
According to other tests, i guess it is related to some bizarre pathing issues.
When they cannot path to target, they will abort the order and go to barracks.

This is reproduceable if you put something in walled off area, for example (which is probably intended).

From what i've seen, pathing errors like this occur if distance is large enough, so i have to move them around with [m] manually.
(0004526)
skeggox (reporter)
2010-04-21 17:54

I'll second RusAnon.

I ordered a squad to kill an underground Forgotten Beast that had just popped up, but no path existed to it (I had detected the cavern it is in 'in passing' from another tunnel). The squad went to the meeting zone and hung around with the Kill order active (in the job list). One went to switch equipment, etc.

Then I had a miner create a path, re-issued the kill order, but nothing happened. I manually stationed them very close to the beast (about 8 squares) and reissued the Kill order. They immediately turned around and headed back.

Finally, I stationed them within sight of the beast, and two promptly turned around for sleep and booze. The other two were attacked and took down the beast.
(0004945)
se5a (reporter)
2010-04-24 20:59

I've found that even the move too doesn't always work correctly if it's too far away from where the dwarfs are. I suspect that the kill order doesn't work if the squad can't see the critter they're ordered to kill too though.
(0006529)
Rhenaya (reporter)
2010-05-10 19:01

today i hade something similar:

the squad was doing individual combat training.
i ordered them to kill a skeletall hoary marmot
they then run out of the barracks like 20 tiles
then they turned around and run back into the barracks
got the little blue question mark for a second and run out again
repeat ad nauseum...

the only way to actually get them killing the skelett was to station them near it
(0007211)
Cardinal (reporter)
2010-05-22 20:00
edited on: 2010-05-22 20:02

This seemed to show up after .01 In the first version of the new release, the (k)ill command seemed to work all the time (I never tested it, but I used it a lot, with my squad murdering the local wildlife in various forts). Now, it never seems to work, and I resort to the station command to get soldiers to attack.

And it's unrelated to visibility of the target. My squad acts goes back to normal routine even if the target is nearby and out in the open.

(0008406)
Kyle_Solo (reporter)
2010-06-14 07:01
edited on: 2010-06-14 07:01

Is this still a problem? I've never had any problems with it in 0.31.06, though I did in 0.31.03.

(0008411)
Kumquat (reporter)
2010-06-14 08:57

Yes.

My current fort is semi-randomly experiencing all the problems described in the comments. So far move orders have almost always worked, kill orders usually work but sometimes they don't.

Ordering civilians to burrows seems to be part of it but even that isn't consistent. I guess that is something to experiment on. That may be the situation I had with an unkillable glass titan, but I reloaded over that.
(0008575)
Kanddak (reporter)
2010-06-16 13:51

I have some modded [SPEED:0] dwarves with attack order problems. When a squad is ordered to attack creatures, only one dwarf will engage a given target at a time, while his squadmates stand around and watch. Sometimes the dwarf fighting will become overexerted and stop doing much damage to the target, which has been wounded enough that it does nothing except repeatedly pass out, so things can drag on for a very long time. If the order is cancelled, the dwarf will become a civilian and leave, but if the order is then given again, the same dwarf will pick up right where he left off.
(0008704)
Leperous (reporter)
2010-06-19 13:47
edited on: 2010-06-19 15:28

This is still an issue in 31.06/07 (import) and it's a BIG pain, especially when you have a Forgotten Beast running amok.

The only workaround I know of is to build doors/hatches and lock them when the military are on the same side of them as the enemy. It's as if they are conflicted with something going on in the barracks.

http://dffd.wimbli.com/file.php?id=2546 [^]

(As an aside, this old save also has a Mason who is never getting any medical attention in 31.07.)

(0008705)
RusAnon (reporter)
2010-06-19 14:09

I just had this happen in 31.07, so its definitely not fixed.
Invading goblins started to flee, and I ordered to kill one of squad leaders. And axedorfs, being 4 tiles away from the goblin, just went back to fort instead of killing him.
(0009722)
Footkerchief (manager)
2010-07-07 08:04

Reminder sent to: Toady One

Today's devlog: "I made the kill order work a bit better, so that non-targeted benign wilderness animals wouldn't gum it up and it'll force targeting of targets that aren't normally allowed (it was a bit confused about those)."

That probably means that this report and/or some of its child reports can get checked off.
(0009763)
Toady One (administrator)
2010-07-07 20:10

I'll probably want to check some of the saves first. It seems like a good candidate for a bug with lots of ways to go wrong. It should be a bit better now though.
(0010103)
Murphy (reporter)
2010-07-13 00:12

This bug is still present in .10 version.
When my dwarves are inactive, instead of complying with the order they will stay in barracks, or sometimes run outside for 20-30 tiles, then back to the barracks. Making them active at this point didn't seem to help.
I undesignated the barracks, canceled the order and set them on defend burrows and they eventually killed the invader.
(0010770)
Rhenaya (reporter)
2010-07-20 23:10

yeah i think the problem here is that kill commands dont override over tasks, they run a few tiles and then turn back to do more "invidiual combat training" (just with "kill command" still in job list) maybe they see the command again and run out, just to turn around after a few tiles again.

also they stop if you use multiple kill orders on the corpse of the first one they killed (unless the others are still in sight)
(0010772)
prios (reporter)
2010-07-21 00:30

"also they stop if you use multiple kill orders on the corpse of the first one they killed (unless the others are still in sight)"

Yeah, just had this happen to me, I think. The squad somehow gets "stuck" on the last kill order, and stands stock-still around the corpse, unresponsive to further kill orders.
(0010949)
XenonMB (reporter)
2010-07-25 04:20

yes i just had that happen with .11 on a titan, very annoying
(0011030)
benco (reporter)
2010-07-25 16:32

Had this in .11 on a dragon. He was in my stockpile, which is by all means completely accessible, no burrows, and my military, when given the task to attack, would stand around, and on the (v -> g) page where it says what job they are doing, it was saying their job was Soldier (cannot follow order) or something to that extent. Moving them worked fine, but attacking didn't.
(0011032)
Footkerchief (manager)
2010-07-25 16:51
edited on: 2010-07-25 16:52

benco, it would be helpful to upload a save demonstrating the problem you described to http://dffd.wimbli.com/ [^]

(0011107)
Drone (reporter)
2010-07-26 15:32

I've had this only on flying creatures. Could it be that if the creature has a chance of ever possibly flying, they'll think that it is unreachable, even if it's sitting in a 1 zlevel high corridoor?
(0011119)
benco (reporter)
2010-07-26 17:00

I can upload my save if you like, but my fortress now only has 11 dwarves, the dragon was pumelled to death by my civilians.
(0011699)
kwieland (reporter)
2010-08-10 13:29
edited on: 2010-08-12 16:16

I recently noticed this. I have a save with the "Soldier (cannot follow order)" bug. I wasn't issuing a kill order, though. I was simply trying to get them to train. I had 7 dwarfs and 5/7 where in the barracks training. The schedule had all 7 to train. No burrows at all. After a while, I was curious where the other two were. They where in the meeting hall with the "Soldier (cannot follow order)" job. Few game days later and there they were, up in the barracks. So, strange, I thought and carried on. In this case it seems to be a pathing issue/bug. I use a lot of ramps inside.

Edit: I think this might have to do with armor and weapon allocation. I was experimenting with barracks/archery targets to see if I could get marksdwarfs training. Then I built 7 archery targets and assigned the squad to train at each of the archery targets.

All of the soldiers got the unable to perform job. I finally figured out that they were incorrectly assigned weapons. Since the weapons assigned them were "melee" type. I changed it to changed it to ranged weapon and they still all sat around. Then I remembered to assign bolts. It took a few game days, but then they all finally went and practiced at the archery range! Progress! Then they ran out of food and it death spiraled. Oh well!

(0011919)
Rhenaya (reporter)
2010-08-19 05:02

i even get that line sometimes on melees fully and properly equiped and only train in the schedule, however it only stay for a few frames. this maybe a new line for "no job" on active soldiers, as most dwarf stay for a few frames on no job while looking for a new one.

this seems to be mostly fixed and was maybe related to the eternal invidual combat drill bug (because that showed quite similar behaviour).

now it only wont work on (un)friendly targets like 0000860, some pre inhabitant creatures (like rats, cyclops or dragons in a nearby cave, see examples in first notes, not sure of natural animals already on the map at embark) or if you give a multiple kills order they will stay at the first kill instead of following the next one (except the other ones is in regular "i see you i kill you" range, but then the subject would kill it without the order anyway) but this is already related with 0000114
(0012421)
tatterdemalian (reporter)
2010-09-04 21:54

Same thing just happened to me with a giant. I issued a kill order, and the entire squad is now in "Soldier (cannot follow order)" mode. What's funny is one of my soldiers is actually chasing the giant around, following it everywhere, but won't attack it even when it's cornered right next to her. She just stands there while the giant moves back and forth, eventually moving past her again and walking away, with the soldier still following it. The giant doesn't have any wings or other unusual features in its description, it's just apparently untouchable as long as it's running away (which it started to do almost immediately after taking a fullisade of crossbow bolts to the face).
(0012440)
kuketski (reporter)
2010-09-06 00:01

I ordered my whole army(30 dwarves) to exterminate citten-slayering goblin ambush.

militia commander was the first one to arrive. And since she is legendary shield user, she pwned 5 of 6 goblins without any ingures.

the last one got away only because she was idling after every kill for several frames and that time was enough for poor archer to run.

she was standing over corpse of the last goblin, while the last one was getting away right under her nose. literally.

Yeah, it must be looking VERY cool - to wipe entire squad alone, while dodging or blocking all of 10~25 arrows and standing over the corpse of every victim for a moment and just staring at enemies to instill fear in their hearts.

But she hasnt such a job, she was flashing "?" for such moments.
(0012554)
tatterdemalian (reporter)
2010-09-09 15:42

After some experimenting with a goblin ambush whose last goblin apparently triggered the bug, it seems that, if the target of a kill order switches from "attack" mode to "flee" mode, no military dwarves will ever attack it again under any circumstances. If they're over 10 tiles from the creature, they will return to whatever standing orders they had before the squad kill order, while if they're under 10 tiles from the creature they will simply follow it around until it goes back into attack mode, and kills them (the goblin was so crowded in by the dwarves it kept running in circles until it apparently healed up well enough to start attacking again). Even while under attack they won't attack the creature, instead remaining with the "Soldier (cannot follow order)" job, and the other soldiers will remain in whatever order mode they were in as well.

Finally, I tried putting the soldiers on standing orders to defend the burrow, just to see if they would fight then. They actually did attack and kill a kobold thief that was uncovered, but the goblin that was rampaging through the fort was ignored completely, even by new militias I created to replace the old ones that the goblin cut to shreds. I also tried "Patrol Route," but the soldiers neither attacked nor patrolled, but that could be because I screwed it up somehow (I have no idea how it works).
(0013404)
Boldwyn (reporter)
2010-10-18 04:04
edited on: 2010-10-18 16:00

It still is present in .16 version. My small unit just stands there with "cannot follow order" while the giantess is running around the fort. I'll upload the save later when I have access to it.

Save: the dwarves are in "cannot follow order" mode. They stayed some time like this doing nothing, no training, just stayed in their bedrooms near the invading giant and slowly move towards their target.

http://dffd.wimbli.com/file.php?id=3295 [^]

(0015959)
tatterdemalian (reporter)
2011-03-08 09:08

Tested in version 31.20. Still getting occasional "cannot follow order" messages, but there seems to be a greatly improved frequency of target evaluation, so these messages are usually transient unless the target actually is completely out of reach. Targets on different Z-levels seem to confuse soldiers a lot more often now, though.

Thankfully, the improved evaluation rate seems to have fixed the problem with soldiers standing around over the bodies of dead enemies instead of moving on to fight other enemies.
(0016358)
Doradan (reporter)
2011-03-18 15:03

I was making a pretty good living making platinum crap that the traders loved when a giant showed up. I ordered my militia to gear up and go after him. They succeeded, then stood there, with the command still active despite them standing on his corpse. Later, a snatcher was spotted by one of my wardogs, and I ordered a kill command on her. Turns out, one of my rangers further up on the mountain sniped her immediatly, killing her on the spot. My militia then started wandering around, and near died of thirst when I realized the problem. FURTHER later on, I got ambushed (Curse them!) twice at once. I put kill commands to both militia squads to handle the seperate groups of goblins. The dwarves (including the marksdwarves) ran right up to the hostiles and got slaughtered, because it had under activity *soldier cannot complete command*, despite the goblins being right there. My (non militia) rangers and wardogs put up a valiant fight, but the fort still Had Fun.
(0016361)
kwieland (reporter)
2011-03-18 19:06

I agree with tatterdemalian. Much improved, but I still see it occasionally and also observe the z-level problems.

Also, "equipment mismatch" error could be more informative (equipped with bow, needs bolts;equipped with pick, can't use axe; equipped with sword, can't train at archery target, etc..)
(0023681)
JonTheRed (reporter)
2012-10-26 06:53

I haven't been able to reproduce this, but I have run into a different-looking issue with kill commands (which may or may not be related, or perhaps it's even a feature). My dwarves always scramble to the target's location at the time of selecting the target, and then go to the target itself. For example, if there are goblins in the upper-left corner of the map, and my dwarves reach the surface from the lower-right, they'll go all the way to the corner before going after the goblins, even if the goblins they've been ordered to kill are in the middle of the map; they'll go around the goblins to reach the corner where the goblins were when I gave the kill order, then double back to the middle of the map to fight.
(0025870)
thvaz (reporter)
2014-07-11 16:06

It worked everytime I tested it in 40.02, and when it didn't, gave the correct cause.
(0030939)
vomov (reporter)
2014-11-10 03:25

I'm seeing quite a bit of 'no reachable valid target'-errors in three separate forts now, which seem to pop up after targets climb trees or faint (not sure). Also, soldiers stationed near a valid target (in my opinion a minotaur killing everything that moves is a valid target) show 'stationed' as their action, and do not attack.

I feel the severity of this issue increased after the recent updates, can anyone confirm?
(0030941)
Larix2 (reporter)
2014-11-10 04:13

It seems to be especially problematic with birds, since those pretty much by definition change z-level. I've seen very few cases of dwarfs actually loosing a shot at a bird, normally they get reams of "vengeful after joining conflict" thoughts without ever acting on them. Melee soldiers sent after grounded birds killed one and stood around the others like dopes while getting pecked constantly. I've also had soldiers get stuck with "no job" after demobilisation although there were plenty of things to do.

This makes keas and other airborne thieves a massive problem currently - if you don't abandon the surface altogether, everyone will go stir-crazy but no-one will lift a finger to shoo off the birds they're so pissed-off about.

- Issue History
Date Modified Username Field Change
2010-04-05 09:48 Rhenaya New Issue
2010-04-05 09:54 Dwarfu Note Added: 0001103
2010-04-05 10:06 Footkerchief Note Added: 0001106
2010-04-05 10:25 DoctorZuber Note Added: 0001111
2010-04-05 12:11 Tobias Note Added: 0001156
2010-04-05 14:46 Rhenaya Note Added: 0001214
2010-04-05 15:17 Nagassh Note Added: 0001230
2010-04-05 15:20 king doom Note Added: 0001232
2010-04-05 15:53 DoctorZuber Note Added: 0001247
2010-04-05 15:54 DoctorZuber Note Edited: 0001247 View Revisions
2010-04-05 15:54 DoctorZuber Note Edited: 0001247 View Revisions
2010-04-06 08:17 SirPenguin Note Added: 0001456
2010-04-06 09:27 Footkerchief Relationship added has duplicate 0000618
2010-04-06 09:58 Footkerchief Relationship added parent of 0000634
2010-04-06 15:37 Rhenaya Note Added: 0001605
2010-04-07 08:45 Rhenaya Note Added: 0001749
2010-04-10 09:33 DoctorZuber Note Added: 0002592
2010-04-10 09:36 DoctorZuber Note Added: 0002594
2010-04-10 10:55 HunterZ Note Added: 0002600
2010-04-10 10:55 HunterZ Note Edited: 0002600 View Revisions
2010-04-10 11:51 Footkerchief Relationship added parent of 0000929
2010-04-10 11:51 Footkerchief Relationship added parent of 0000800
2010-04-10 11:52 Footkerchief Relationship replaced parent of 0000618
2010-04-10 11:52 Footkerchief Summary Kill Command does not work => Kill/attack command/order doesn't work
2010-04-10 13:07 DoctorZuber Note Added: 0002628
2010-04-10 20:23 savanik Note Added: 0002697
2010-04-10 21:31 Wirrit Note Added: 0002711
2010-04-11 04:15 DoctorZuber Note Added: 0002779
2010-04-11 23:22 Shadowlord Note Added: 0002989
2010-04-11 23:50 Shadowlord Issue Monitored: Shadowlord
2010-04-12 00:21 Shadowlord Note Added: 0002995
2010-04-19 16:11 Leperous Note Added: 0004277
2010-04-21 12:25 Footkerchief Relationship added parent of 0000114
2010-04-21 17:06 RusAnon Note Added: 0004524
2010-04-21 17:06 RusAnon Issue Monitored: RusAnon
2010-04-21 17:54 skeggox Note Added: 0004526
2010-04-22 11:35 Footkerchief Relationship added related to 0000149
2010-04-22 18:47 Khym Chanur Issue Monitored: Khym Chanur
2010-04-23 10:31 larz334 Issue Monitored: larz334
2010-04-24 20:59 se5a Note Added: 0004945
2010-04-26 10:50 Footkerchief Relationship added parent of 0000860
2010-04-26 15:34 Footkerchief Relationship added parent of 0001559
2010-05-10 19:01 Rhenaya Note Added: 0006529
2010-05-10 19:02 Rhenaya Tag Attached: barracks
2010-05-10 19:02 Rhenaya Tag Attached: behaviour
2010-05-10 19:02 Rhenaya Tag Attached: combat
2010-05-10 19:02 Rhenaya Tag Attached: training
2010-05-22 09:21 Footkerchief Relationship added has duplicate 0002030
2010-05-22 20:00 Cardinal Note Added: 0007211
2010-05-22 20:01 Cardinal Note Edited: 0007211 View Revisions
2010-05-22 20:02 Cardinal Note Edited: 0007211 View Revisions
2010-06-06 01:05 Cel Issue Monitored: Cel
2010-06-10 17:02 Footkerchief Sticky Issue No => Yes
2010-06-14 07:01 Kyle_Solo Note Added: 0008406
2010-06-14 07:01 Kyle_Solo Note Edited: 0008406 View Revisions
2010-06-14 08:57 Kumquat Note Added: 0008411
2010-06-14 10:08 Conti Issue Monitored: Conti
2010-06-16 13:51 Kanddak Note Added: 0008575
2010-06-19 13:47 Leperous Note Added: 0008704
2010-06-19 14:09 RusAnon Note Added: 0008705
2010-06-19 15:27 Leperous Note Edited: 0008704 View Revisions
2010-06-19 15:28 Leperous Note Edited: 0008704 View Revisions
2010-06-20 01:02 Footkerchief Relationship added has duplicate 0002390
2010-06-20 09:39 Felblood Issue Monitored: Felblood
2010-07-04 10:34 Footkerchief Relationship deleted parent of 0000618
2010-07-07 08:04 Footkerchief Issue Monitored: Toady One
2010-07-07 08:04 Footkerchief Note Added: 0009722
2010-07-07 20:10 Toady One Note Added: 0009763
2010-07-07 20:10 Toady One Assigned To => Toady One
2010-07-07 20:10 Toady One Status new => acknowledged
2010-07-11 10:00 Profligate Issue Monitored: Profligate
2010-07-13 00:12 Murphy Note Added: 0010103
2010-07-18 01:52 Footkerchief Relationship added related to 0001806
2010-07-20 20:49 prios Issue Monitored: prios
2010-07-20 23:10 Rhenaya Note Added: 0010770
2010-07-21 00:30 prios Note Added: 0010772
2010-07-25 04:20 XenonMB Note Added: 0010949
2010-07-25 14:17 Footkerchief Relationship added related to 0001169
2010-07-25 16:32 benco Note Added: 0011030
2010-07-25 16:32 benco Issue Monitored: benco
2010-07-25 16:51 Footkerchief Note Added: 0011032
2010-07-25 16:52 Footkerchief Note Edited: 0011032 View Revisions
2010-07-26 15:32 Drone Note Added: 0011107
2010-07-26 17:00 benco Note Added: 0011119
2010-08-10 09:55 theqmann Issue Monitored: theqmann
2010-08-10 13:29 kwieland Note Added: 0011699
2010-08-10 13:29 kwieland Issue Monitored: kwieland
2010-08-12 14:43 JimboOmega Issue Monitored: JimboOmega
2010-08-12 16:16 kwieland Note Edited: 0011699 View Revisions
2010-08-17 01:16 kuketski Issue Monitored: kuketski
2010-08-19 05:02 Rhenaya Note Added: 0011919
2010-09-04 21:54 tatterdemalian Note Added: 0012421
2010-09-05 07:40 Dame de la Licorne Issue Monitored: Dame de la Licorne
2010-09-05 08:23 Hieronymous Alloy Issue Monitored: Hieronymous Alloy
2010-09-06 00:01 kuketski Note Added: 0012440
2010-09-09 15:42 tatterdemalian Note Added: 0012554
2010-09-28 08:47 schm0 Issue Monitored: schm0
2010-10-18 04:04 Boldwyn Note Added: 0013404
2010-10-18 08:11 Boldwyn Issue Monitored: Boldwyn
2010-10-18 15:59 Boldwyn Note Edited: 0013404 View Revisions
2010-10-18 16:00 Boldwyn Note Edited: 0013404 View Revisions
2010-11-05 13:34 Another Issue Monitored: Another
2011-01-13 08:06 Footkerchief Relationship added related to 0003882
2011-03-08 09:08 tatterdemalian Note Added: 0015959
2011-03-18 15:03 Doradan Note Added: 0016358
2011-03-18 19:06 kwieland Note Added: 0016361
2011-03-21 01:49 Another Issue End Monitor: Another
2012-02-22 07:22 Footkerchief Summary Kill/attack command/order doesn't work => Kill/attack commands/orders doesn't work
2012-02-22 07:22 Footkerchief Summary Kill/attack commands/orders doesn't work => Kill/attack commands/orders don't work
2012-02-22 08:04 Footkerchief Relationship added parent of 0005393
2012-02-26 07:24 Footkerchief Relationship replaced related to 0005393
2012-03-16 05:03 kento Issue Monitored: kento
2012-10-26 06:53 JonTheRed Note Added: 0023681
2014-01-25 08:50 Footkerchief Tag Attached: Fixed in 0.34.12?
2014-01-27 20:33 Footkerchief Relationship added related to 0002655
2014-07-06 20:59 Footkerchief Relationship added related to 0003469
2014-07-07 22:23 Footkerchief Tag Renamed Fixed in 0.34.12? => Fixed in 0.40.01?
2014-07-11 16:06 thvaz Note Added: 0025870
2014-07-14 13:45 Footkerchief Relationship added related to 0007288
2014-07-30 13:40 Dwarfu Relationship deleted related to 0007288
2014-09-23 12:15 Footkerchief Relationship added related to 0008250
2014-11-05 08:02 vomov Note Added: 0030876
2014-11-05 08:02 vomov Note Deleted: 0030876
2014-11-10 03:25 vomov Note Added: 0030939
2014-11-10 04:13 Larix2 Note Added: 0030941
2014-11-13 06:25 Footkerchief Relationship added related to 0008367
2014-12-16 15:01 BenLubar Issue Monitored: BenLubar
2015-01-05 00:17 vomov Issue Monitored: vomov


Copyright © 2000 - 2010 MantisBT Group
Powered by Mantis Bugtracker