[http://sourceforge.net/p/ufoai/bugs/3060 Item 3060] imported from sourceforge.net tracker on 2013-01-28 19:58:38

If I understand the specification on the following page correctly, units that are not currently performing an action should not be the targets of reaction fire:

http://ufoai.ninex.info/wiki/index.php/ReactionFireImprovements

See the paragraph that begins "This effect should be in place per soldier per enemy..."

At the moment, if soldier A is in alien B's line of sight, and soldier C moves, it can cause alien B to fire a reaction shot at soldier A. I believe the paragraph in the specification above was explaining that this should not be possible.
===== Comments Ported from Sourceforge =====

====== tlh2000 (2011-10-22 14:48:57) ======

this is in G_ReactionFireCheckExecution
====== tlh2000 (2011-10-22 15:00:56) ======

G_ReactionFireTryToShoot in G_ReactionFireCheckExecution is not checking against the given target edict_t pointer (which is the moving/acting unit) - but against the ent->reactionTarget that is still the old target (that is maybe not the moving unit)
====== aduke1 (2011-11-28 22:43:16) ======

I'm not sure if this is really a bug. At least it was explicitely coded that way.
See g_reaction.c, G_ReactionFireSearchTarget, line 308:

/* not if ent has reaction target already */
if (ent->reactionTarget)
continue;

We can call it a 'design bug'. We might be able to achieve the requested result by removing those lines, but I'm not even sure if that's desired.

@Nate:
Have you found a nice&easy way to reproduce such a situation ?

====== natewr (2011-11-30 13:00:57) ======

Test map for reaction fire
====== natewr (2011-11-30 13:01:23) ======

test map .ufo definition
====== natewr (2011-11-30 13:02:05) ======

I've attached the simple test maps I used before to try and understand the reaction fire. Just a wall to hide behind and an invisible barrier keeping aliens away.
====== aduke1 (2011-11-30 23:10:31) ======

1. Thx Nate, that's helpful :)
2. I can confirm the bug. On that testmap, expose one soldier one step beside the shielding wall. Then move other soldiers away from the wall (out of sight of the aliens). The exposed soldier can be hit several times. That doesn't seem right.
3. Nate, do you also know a way to control the race/equipment of the aliens ? It's pretty hard to test reaction fire if you're confronted with a bunch of bloodspiders :(
4. I also had other 'strange behaviour' (I can not really specify) in my tests.
==> Reaction fire seems to be messed up pretty much.
5. I consider reaction fire a vital feature
6. adjusted priority

====== natewr (2011-12-01 08:45:05) ======

aduke:
3. You can try commenting out the bloodspider races in /ufos/team_aliens.ufo. That may do the trick. It may also break things, who knows. You may also have to comment out the soldier_blood template in /ufos/team_templates.ufo
4. Yes, reaction fire seems to be a bit over-complicated at the moment which makes its behavior appear highly unpredictable. Keep in mind the following: when in skirmish your troops have higher skills, which means they are better at initiating or returning reaction fire. Check it out at start-of-campaign and it appears to behave differently.
------
I agree reaction fire is important, but I think an overhaul at this stage of 2.4 could introduce critical problems. Maybe it can be a priority issue for 2.5?
====== aduke1 (2011-12-19 22:51:58) ======

I'm working on that.
====== aduke1 (2012-02-27 01:07:51) ======

I enabled the new RF code today.
There are still some things to do, but at least the moving/shooting soldier takes the RF now.
Also, RF is *fair* now. That is, it happens after 'TUs for shot in sight'.

Oc RF it particularly hard to test. So I'd like to hear some feedback...
====== aduke1 (2012-03-12 22:08:12) ======

This is definitely fixed.