OpenXcom Forum
OpenXcom => Open Feedback => Topic started by: wsmithjr on August 08, 2013, 03:58:21 am
-
So, a recent mission using .9 stable version of OpenXcom has got me wondering about how exactly it is determined if X-Com units can reaction fire at the aliens.
The situation is that a group of rookies assaulted a Muton Supply Ship. The Skyranger landed right next to the Supply Ship and only found 1 Muton immediately outside. So, I figured I'd head on into the ship and let the Mutons come to me. I stationed 2 rookies at one door, and 3 at the other. They sat inside the ship watching the doors and did nothing else. Eventually, the Mutons started entering the ship from outside. One would enter in, shoot one of my rookies and then leave. I lost 6 rookies in this manner and at no point did any of the Rookies react and fire back. I don't have a save game and can't say what kind of reaction stats the rookies had, so the stats may not have been particularly notable, but the fact that they sat there turn after turn and had full TUs but never fired makes me wonder how it all works.
Ufopaedia talks about a concept of "mutual surprise" https://www.ufopaedia.org/index.php?title=Reaction_fire_triggers (https://www.ufopaedia.org/index.php?title=Reaction_fire_triggers) that indicates for the original that Xcom would be unable to fire after the alien first stumbles into their LOS. This makes sense, but why would the remained rookies not fire once the Muton guns down one of their buddies as now we have a case of an action that can trigger reaction fire?
I remember in the "good old days" having my guys circling a UFO and having tons of reaction fire each time an alien would attempt to walk out the door. So, I'm wondering if things work differently in OXC and how to best handle situations such as this. Is there a better way to guard doorways which would enable your soldiers to fire if this behavior is intentional? Or has this all changed with the Nightly builds. I'll try to replicate this scenario using a more recent version and see what happens.
Thanks for any comments.
-
Agreed. There is something seriously wrong with reaction fire in 0.9.
I've mind controlled the last alien and stuffed it in the corner and lined up my troops in a V formation trapping the alien. on the next turn, the alien walks around and expends all his TUs and not a single one of my soldiers reaction fires. It seems like only soldiers with 70+ reaction stat perform actual reaction fire, and sometimes even they don't fire.
-
So, a recent mission using .9 stable version of OpenXcom
There's your problem. Use the nightly.
-
Yeah, yesterday I had 11 guys with assault rifles pinning down 4 mutons, with pistols. Only 1 or 2 guys reaction fired at reactions 70 and 52. One of the mutons fired about 5 rounds and then started to wander in the enclosed box.
I can't train my guys properly!
-
Reaction-chance is proportional to your TUs as well as your Reactions. If you don't move a guy on a turn he's way more likely to get a reaction shot in, unless his Reactions is exceptionally low.
-
Nah. I remember the old days, queuing up my guys outside a ufo. It was a fun action scene with laser blasts flying everywhere. Now nothing happens.
Maybe I'll try laser pistols next time....
-
I haven't been able to set up the original scenario, but I did start a new game with the latest build and in the first terror mission, I did get reaction shots on Reapers trying to approach me and the like armed with Laser Pistols. So, it's not like I don't see any reaction fire; I'm just wondering if it's something peculiar to the type of situation indicated above. I'm wondering if it's pointless to guard doorways like that and need to come up with some different tactics. Or, maybe things have significantly changed since 0.9 and now it is more effective.
Thanks.
-
I think reaction fire got rewritten since 0.9, but don't know if the triggering in itself was affected.
It's definitely possible to set up a bunch of guys to guard a door and have them shoot whatever comes out before it can move, just did it myself twice in a row on the same turn with a pair of Reactions 40-50 rookies.
However, keep in mind that if the alien that pops out has high Reactions and/or most of its TUs left, it'll STILL get the jump on your guys, so reaction fire becomes more unlikely as the aliens become better.
-
I think reaction fire got rewritten since 0.9, but don't know if the triggering in itself was affected.
It's definitely possible to set up a bunch of guys to guard a door and have them shoot whatever comes out before it can move, just did it myself twice in a row on the same turn with a pair of Reactions 40-50 rookies.
However, keep in mind that if the alien that pops out has high Reactions and/or most of its TUs left, it'll STILL get the jump on your guys, so reaction fire becomes more unlikely as the aliens become better.
Good to hear. It makes sense that the stronger aliens would get the drop on us. I can understand the Muton going in and gunning down a soldier, but if you have several soldiers guarding the door, my question is why the surviving soldiers didn't return fire. Maybe that could be explained if the other rookies had too low of a Reaction stat even though they had full TUs available.
Thanks.
-
There's your problem. Use the nightly.
Break save game. There's your problem.
-
Reaction-chance is proportional to your TUs as well as your Reactions. If you don't move a guy on a turn he's way more likely to get a reaction shot in, unless his Reactions is exceptionally low.
You didn't read my post. All my guys were at full TU because the previous turn i had MC the alien to trap it in a corner (not literally a corner, but a section of the ship where all he can do is walk around back and forth in front of my troops). None of my guys had moved for 2 straight turns.
I just would like to request it to behave similar to vanilla. One of the most fun parts of vanilla was watching the hail of laser + plasma fire when an unsuspecting alien would walk out of the door. Those fun "moments" don't happen anymore.
-
Yeah... Loved it. 10 guys with laser rifles. Alien walks out and its like Butch Cassidy and the Sundance kid....
Beautiful....
-
Morbo, the reaction fire code is wrong in the 0.9 game version.
As Hythlodaeus said, use a nightly version. Check the log to see what breaks your saved games and update your savegame to make it work. Better yet, ask Warboy on IRC for help on this.
Keep in mind that this is still a "work-in-progress" software. Some things are broken. Some thinks don't work at all. Some may work as intended.
Help the developers finish the game by using the nightlies and reporting any bug you find. The "stable" versions are beta, and are tested only to insure that you can run the game. They are not a "complete product" and also they are not bug free. Neither are the nightlies, mind you, but by using the them you won't have to deal with bugs that got fixed sometime after the last "stable" release.
-
sorry to reiterate, but yes, the reaction fire code has been completely re-written to be completely in-line with the original game.
it's fairly easy to update a saved game from 0.9 to the nightly, and it's a LOT easier to do if it's a geoscape save.
-
@Warboy, or any other openXcom dev:
I've seen the code for the reaction fire (code dwonloaded not longer than 3 days ago), and I think, that this isn't exactly what it was like in the original, and perhaps what is written here isn't what the author had in mind.
while (true)
{
if (!tryReactionSnap(reactor, unit))
break;
reactor = getReactor(spotters, unit);
result = true;
if (reactor == unit)
break;
}
The reaciton fire routines finish in two cases:
1) the best "reactor" was unable to fire.
2) all reactors have worse reflexes than the spotted unit.
Only The second case is corresponding to the original implementation. The whole round of checking reaction fire is finished if and only if the spotted unit has the greatest reaction score.
In your algorithm it's either this, or a situation where the shooter fails to shoot the reaction snap, which is fully dependant on what this condition gets evaluated to ( true or false )
if (action.weapon && action.weapon->getAmmoItem() && action.weapon->getAmmoItem()->getAmmoQuantity() && unit->getTimeUnits() >= action.TU)
(the first check btw isn't necessarry and just creates noise - you are using the action.weapon pointer 4 statemnes earlier)
Not knowing your internal architecture with details I cannot say when would the getAmmoItem() return a null pointer, but the rest of the condition tells us, that this returns false when a unit has not enough time units for its action OR the currently considered reactionist is out of ammo.
This in turn means, that if I have sick reactions ( like for example Point Man from FEAR series ), and have exactly one time unit less than I need to fire a time consuming fire action, then none of my buddies will fire.
This makes many situations where good reacionists are stomped by that break invoked because a better reaction guy was unable to perform a shot for whatever reason ( other than problems with line of fire, because this is not checked in the tryReactionSnap as far as I've seen ).
I hope this will help you improve the code and functionality of the product.
Regards,
djemon_lda
-
I'm not a dev, just a contributor, & have changed this in my personal build to:
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()
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.
-
I would say that this:
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.
-
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.
-
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,
-
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.
-
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
-
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. :P
-
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, 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
-
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.
-
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.
-
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. :P
oh just plug it in, fire it up, and remember to save tu's
;)
-
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.
-
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:
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
-
Pps. Am i the only guy who doesn't like "while(true)" loops ? <- hint hint
Definitely not. :)
-
tryReactionSnap() breaks the loop (through potential shooters) when it returns false. It returns true
if (action.weapon
&& action.weapon->getAmmoItem()
&& action.weapon->getAmmoItem()->getAmmoQuantity()
&& unit->getTimeUnits() >= action.TU)
hence, if any of those are false, the loop exits prematurely, possibly leaving some reactors that are eligible to fire unable to fire.
I've sparsed down my commit ( and at present still stand by it ) It looks like this:
for (std::vector<BattleUnit*>::iterator i = spotters.begin(); i != spotters.end(); ++i)
{
if (tryReactionSnap(reactor, unit))
{
result = true;
}
reactor = getReactor(spotters, unit);
if (reactor == unit)
{
break;
}
}
Note that getReactor() returns whoever has initiative.
& here's how the base mission went:
-
Does it still don't work?
-
the way i understand it now, when deciding who gets initiative, a so-called vector is made up of all units that spot the victim. There will be an order or sequence of those units: check #1 to see if he can react, check #2 etc etc.
If and when a unit in that vector fails to meet the reaction requirements (a loaded gun + able to make a snapshot) then the loop or sequence-checking stops short.
On redv's save above, the current code and my change give the same results (because all the soldiers are topped up on ammo + tu)
I think Sup is waiting for someone with more knowledge of the craziness that is xCom combat to have a looksee...
-
so you are saying that if you have ten soldiers lined up and the first one (in the "vector") doesn't have a gun, nobody will reaction-fire?
-
i think so -- it's what to watch for
I'll try some more tests w/ output to Log later, see what shows up
( my real debugger is hanging on an unhandled exception..:\ )
-
current code works.
units won't get added to the vector unless they are capable of making a snaphot!
- will withdraw my PR
(now, if you want to talk messy, convoluted and redundant ( welcome to c++ ) that's a different cake)
ps. sry khar my bad..
-
Only snapshots? Does that mean no more reaction-fired blasterbombs? Because those were funny but annoying.
-
(now, if you want to talk messy, convoluted and redundant ( welcome to c++ ) that's a different cake)
this isn't a thing of c++, it is a thing of bad coders. I have seen better written and more readable assembly code, than java. it is not a problem of any language - it is always a problem of how the programmer is able to express their thoughts and the process of coding. there is no (and will never be any ) language on earth for example that will make a thought process put into file look good when it is by the algorithm : "ok, so I will change/add this fully or semi random thing, and will check if it works..."
-
How can I fix it?
-
What's the status on this? I'm using the latest nightly to date, and reactions don't seem to work very well for my guys.
I can get reaction-fired upon by a Sectoid for so much as kneeling (on Veteran), but it's really hard for my men to surprise an alien with any kind of reliability.
Reaction fire was crucial in the original game, and not only for door camping. A good portion of my kills in it was due to it given how I advanced across the field carefully, using scouts and HWPs as spotters and keeping many shooters with TUs so to deal with enemies that would come into range. Active, manual, spotter-aided firing was only half of that strategy.
-
On Veteran difficulty aliens have higher stats, sectoids will have around 60 TU's and 70 reaction which will be more then any rookie. Just keeping a unit on reserve to fire a snap-shot doesn't mean they will fire a snap-shot if they don't have a lot of TU's as their initiative will be lower
Initiative = Reaction * (CurrentTU/MaxTU)
You want the people who take/avoid reaction shots to have high TU's and high reactions so any movement will lower their Iniative less, and generally try to keep them moving a little.
Leap-frogging can work in XCOM but you need to take the leaps over two turns instead of doing it in one turn for reaction fire to take place, but even then it can be hard to make it work well. I normally use reserve fire for units to move around to make sure they can shoot an alien if they spot one but I will move them into good positions before the turn ends instead of hoping to get a reaction shot.
-
I've had more success against Floaters just now. Maybe they're slower on the trigger, but I managed to get a satisfying number of reaction-fired laser shots off in my last terror mission.
A bunch of those were good hits, to boot. There's nothing quite like a good reaction-fire kill. 8)
-
Sharp. Don't forget about Stamina. Good tactic is to exhaust aliens during their turn. Good idea to use smoke grenades, especially near UFO gates. Aliens will spend all their TU and possibly stamina when they show themselves from smoke. They won't be able to shoot and our troops will reaction fire on them.
Isn't it working in OpenXCom?
-
This wasn't really my playthrough, so I can't verify this (and thus can't place this in the bug tracker), but was the issue of the game not checking your stats correctly when you were fired at during your turn fixed in any of the nightly builds?
To better understand what I am talking about, see this:
https://www.dailymotion.com/video/x16qvdp_o-alienbase-01_music?start=75
At around 01:21, the soldier gets reaction fired at with a Stun Launcher. He does not lose consciousness until another soldier takes a shot during the same turn at 02:24.
-
Does the mutual surprise rule still counts in OpenXcom?
-
This wasn't really my playthrough, so I can't verify this (and thus can't place this in the bug tracker), but was the issue of the game not checking your stats correctly when you were fired at during your turn fixed in any of the nightly builds?
To better understand what I am talking about, see this:
https://www.dailymotion.com/video/x16qvdp_o-alienbase-01_music?start=75
At around 01:21, the soldier gets reaction fired at with a Stun Launcher. He does not lose consciousness until another soldier takes a shot during the same turn at 02:24.
Also posted here - https://openxcom.org/forum/index.php/topic,1706.0.html
-
Does the mutual surprise rule still counts in OpenXcom?
I would really like to know... :\
-
Does the mutual surprise rule still counts in OpenXcom?
yes.