X-Com reaction fire mechanics

[kevL]

I'm not a dev, just a contributor, & have changed this in my personal build to:

Code: [Select]

https://if (reactor != unit) --> gone. Handled below...

for (std::vector<BattleUnit* >::iterator i = spotters.begin(); i != spotters.end(); ++i)
{
if (reactor == unit) continue;

if (tryReactionSnap(reactor, unit))
{
result = true;
}

reactor = getReactor(spotters, unit);
}
It's been working really good this past month RL (although it's the first bit of c++ i ever did and can now sense problems with it), especially when combined with preventing reactors from taking multiple reaction shots, ie. emptying their TUs all at once but instead waiting till unit makes another move before firing more volleys, in TileEngine::getReactor()

Code: [Select]

if (!(*i)->isOut()
&& canMakeSnap((*i), unit)
&& (*i)->getReactionScore() > bestScore
&& (*i) != bu) https:// kL, stop unit from reacting twice (unless target uses more TU, hopefully)
{
bestScore = (*i)->getReactionScore();
bu = (*i);
}

with those two changes i've been getting firefights very similar to the original.

[djemon_lda]

I would say that this:

Code: [Select]

Troop* bestReactionist = nullptr;
while( ( bestReactionist = GetBestReactionScoreGuy(spotters, walker) != walker)
{
    FireReactionSnap(bestReactionist, walker);
}

is what I'd prefer. Clear, simple and short. just feed it with the right data, removing guys that can't shoot anymore. btw, as far as I remember this was the exact behaviour: as I remember I had situations when some guys with sick reactions ( around 100 ) they did shot twice in a row after a single action of the enemy. The same was done by ethereal when a low reaction soldier has taken a long run, and when making one of his last steps, an ethereal beheld him.

It isn't the most realistic way of course, but as far as I've learnt so far, openXcom aims make the same functionality as the original game.

[kharille]

Can someone put this on nightly builds?  I'm trying to train up reaction fire.  it used to be much easier.  These days the alien just walks out of my view and 10 guys on full time units barely take two shots.

[kevL]

i opened a PR w/ my stuff

Before doing that I did a test on a clean nightly with the supplemental code. 4 soldiers coming up on a UFO door. A muton appears and 3 guys shoot, then the muton takes one more step and we really let 'im have it 


so it should be good, but i'm always uncomfortable until it's vetted,

[kharille]

Heh, something to look forward to.  I remember it used to be so fun when they come out.  Its almost an rts game when they start reaction firing.

[kevL]

yeh RF is (by far) the most exciting part of the game to me,

rule of thumb: reserve 2 snaps + crouch... am now trying to go up & down GravLifts w/out losing "_kneeling" status too.


maybe Sup or one of the Battledevs can check out the new code this weekend

[SupSuper]

i was hoping to leave it to the battledevs, but if they're all on hiatus i'll just have to have a look myself... god help us all.

[redv]

It's been working really good this past month RL (although it's the first bit of c++ i ever did and can now sense problems with it), especially when combined with preventing reactors from taking multiple reaction shots, ie. emptying their TUs all at once but instead waiting till unit makes another move before firing more volleys, in TileEngine::getReactor()

with those two changes i've been getting firefights very similar to the original.

kevL, why do you need prevent units from multiple reaction shots?
In vanilla Xcom, multiple reaction shots was possible.

[kevL]

kevL, why do you need prevent units from multiple reaction shots?
In vanilla Xcom, multiple reaction shots was possible.

hey red, that's what might be still a bit .. wrong w/ my code ( in the context of what's already coded ).

What i didn't like, and the reason for that check, is that it (seems to do) a good job of stopping a unit from *unloading all its TU, all at once* after only 1 initiative check

the downside that you point out, is that /maybe/ a spotted unit would need to expend more of its TU before a spotter can make a second or third attempt to RF -- although I'm not actually sure about that in practice. That is, in the firefights i've been getting I have a 50/50 suspicion that soldiers are in fact taking more than one snap without the spotted unit expending more TU ( when he has the Initiative ). these things happen in pretty fast succession so it's hard to be sure atm...

hence it needs testing IG, by persons well acquainted w/ orig behavior (and ofc who like to reserve TU). ... goal is to preserve/implement strict rules of "initiative", as per ufopedia.org


- will try to set up a test to look more closely & get back....


[ edit ] i think I read that it's actually energy-expenditure that's supposed to trigger RF, but that's not quite right either because kneeling can act as trigger in vanilla. The call(s) to start reaction fire could be scrutinized, as well as this post-call stuff above

[redv]

That is, in the firefights i've been getting I have a 50/50 suspicion that soldiers are in fact taking more than one snap without the spotted unit expending more TU ( when he has the Initiative ). these things happen in pretty fast succession so it's hard to be sure atm...

You can easy check how RF works, if you run OpenXcom under debugger.

[kevL]

im not that clever <g>

But the quick result of a test was that one of my soldiers *did take 2 reaction shots* at a muton without the muton apparently moving between the first and second snap.

[kevL]

i was hoping to leave it to the battledevs, but if they're all on hiatus i'll just have to have a look myself... god help us all.

oh just plug it in, fire it up, and remember to save tu's

[redv]

But the quick result of a test was that one of my soldiers *did take 2 reaction shots* at a muton without the muton apparently moving between the first and second snap.

I did test how works reaction fire (save is attached).
No one soldier didn't shot twice for one step of mutons.

[kevL]

tl;dr : my tests showed the current code getting 10- reaction shots on red's .Sav, mine getting 10+


checkReactionFire(unit)
- getSpottingUnits(vs unit)
- getReactor(spotters vs unit)
   - loop, getReactionScore(spotters)
   - if best score, reactor = spotter *
   - else, initiative returns to unit.


* here is where i put in a check in an attempt to make sure the same spotter is not returned as the reactor twice in a row. But it now seems unnecessary, since iterating over the spotters-vector will never re-iterate over a single unit anyway. Thanks red.


So we get back to checkReactionFire(), passing in the best reactor. Here is the most suspect code:

Code: [Select]

if (reactor != unit) https:// ok, getReactor() returns unit only when no one bests the initiative
{
while (true)
{
if (!tryReactionSnap(reactor, unit)) https:// aggro, targetting, etc.

break; https:// but if that guy can't do it, why break???
https:// Maybe the next guy in the spotters-vector can...
reactor = getReactor(spotters, unit); https:// here.

result = true; https:// yes a reaction was successfully made
if (reactor == unit) https:// ok. if getReactor returns the unit itself, initiative has gone back to unit.
break; https:// -> break
}
}


btw, There seems to be redundancies between canMakeSnap() and tryReactionSnap() -- checking weapon & ammo, eg.

Will amend my code, and try to amend the 'reaction Update' commit.... oh and this is gonna require *playtesting*  :p


ps. I just don't like it. I'd much rather see the spotters-vector getting iterated over in checkReactionFire(). Why? Because i believe checkReactionFire() gets called only once per tile (when unit gets to its next tile during movement) or once when it takes an action like shooting. But checkReactionFire() calls getReactor(), where the spotters-vector *is* iterated over, only if the previously-identified spotter succeeds in making a reaction shot.

it would seem to smooth things out to consolidate (refactor) what's there,


anyway, time to relax on an alienBase mission: 2 xcom down, 10 to go..

Pps. Am i the only guy who doesn't like "while(true)" loops ? <- hint hint

[SupSuper]

Pps. Am i the only guy who doesn't like "while(true)" loops ? <- hint hint

Definitely not.