"Realistic accuracy and cover system" option

[jnarical]

Hi. Here's the dedicated topic for questions, bugreports and suggestions about RA in BrutalAI.
Bugreports could be also placed here: https://github.com/narical/openxcom-accuracy/issues
For now, I'll take the description from github (it could be inaccurate, but will be fixed... eventually)

Features:

• Precise probabilities distrubution. Accuracy number represents real chance to hit, which wasn't the case with "classic" x-com accuracy. New accuracy works just like dice rolling in D&D - for 40% accuracy shot, the game rolls random number in 1-100 range, where 1-40 counts as hit, and 41-100 as miss.
  
• Less shooting spread. Cone of fire is more tight, making it possible to use it tactically. You can intentionally aim to a target, trying to get other targets in fire range - to a greater efficiency than in "classic". Bear in mind, that units aim to the middle of the exposed part of target, so shots spread around that point.
  
• Type of shot (aimed/snap/auto) affects spread. For the same final accuracy, aimed shot will miss closer to a target, snap/auto will be less accurate, and auto with one-handed weapon will be even worse. Combined with reduced spread, it provides a variety of options, for example with high exposive type of ammo, which is much more potent now, especially at long ranges.
  
• Soldiers raise weapon to aim. For an aimed shot or while kneeling, soldiers will raise their weapons to eye level. That means, if they see an enemy - they can shoot it. For example, now it's possible to fire a shot targeting sectoid (16 voxels high unit) while kneeling behind a stone wall.
  
• Cover matters! For every shot, accuracy is multiplied by percent of targets surface, visible to attacker. taking into consideration how accuracy rolls, every bit of cover can determine the difference between life and death. A piece of wooden fence, landing gear of Skyranger or its ramp, high crops or even that lone head of cabbage. Everything.
  
• Off-center shooting works in a different way. If enabled, it allows units to check chance to hit (not just LoF as before!) from shifted positions, and select the best one - which allows shooting from behind a cover with a much better effectiveness. X-Com operative can hide behind Skyranger's wheel and aim from around the corner without penalty to enemy visibility.
  
• Accidental suicide / frienly fire protection. After rolling a miss, game looks for some "missing" trajectory. If target is far enough, that trajectory will never be selected if it ends on nearest two tiles from the attacker. That means, you can shoot with rockets or high explosive ammunition through windows, from Skyranger ramp, throught narrow gaps, near your nearest teammates without a fear of accidently blowing yourself up. Not applies to guided-type weapons, like blaster launcher - they still use classic accuracy. Beware of force-fire with CTRL - it overrides suicide protection!
  
• Less confusing close-range accuracy numbers. In "classic" x-com, dispayed accuracy doesn't match with real, especially in close range shooting, where the real one is much higher. In this mod, there are two formulas for close range. First one gives accuracy multiplier. For aimed shots, last 10 tiles to target give you additional +0.1 to accuracy multiplier, up to x2 for point-blank shot. For snap/auto, it's +0.2 multiplier for last 5 tiles. If your accuracy is not enough to get upper cap with x2 multiplier, another formula applies, where delta between that cap and your accuracy is divided by number of tiles to target evenly. You'll gain maximum possible accuracy for point-blank either way, but first formula makes it possible to get that number even from a distance, if soldier is good at shooting.
  
• Min/max accuracy caps at 5%/95% respectively. For 5% or less - kneeling grants additional 2%, and aiming another 3%
  

Planned / possible features:

• Accuracy threshold for reaction fire. New menu option, which prevents reaction fire until chance to hit reaches the threshold. It would prevent units from wasting their TUs at low-accuracy shooting.   
  
• Customizable effect of target exposure to accuracy. New menu option:
  "no effect" - % of target exposure doesn't affect final accuracy
  "low effect" - 40% fraction of accuracy is multiplied by visibility %
  "medium effect" - 60% fraction of accuracy is multiplied by visibility %
  "full effect" - final accuracy is multiplied by visibility
  
• Added accuracy bonus to overcome target's cover. Now, 150% accuracy against 90% covered target results to 150*0.1=15% accuracy. There are numerous ways to improve that. For example, apply "overshoot" (over-100% portion) of accuracy after applying visibility, so last example turns to: 150*0.1+50=65% - which makes snipers great again
  
• Unlucky RNG protection. New menu option. If on, the game prevents several unlucky RNG rolls in a row, by forced use of mathematical expectation value.
  

There are numerous bugreports, now I'm working on glaring issues with arcing shots (in base xcom game there's only one unit who uses it - Celatid, and it's deadly effective with it damage and accuracy, but in XCF / 40k / Piratez... oh boy!) Accuracy in conjuction with arcing shots, where target could be totally hidden and still in your firing range - takes a while to wrap my head around...

Additional details / clarifications:

• All RA additional options work only when the main RA option is on.
  
• When RA option is off - the game should works the same as OXCE... but it doesn't. To make RA possible, I've done many changes to the code, which affects "vanilla" accuracy, including fixes and improvements, but also new bugs.
  
• Forced shot with CTRL (with RA on) has additional feature and works slightly different - shows the percent of target's exposure (in other words, how much cover it has). When displaying % exposition, it has two little arrows from sides. Now, the differences. If target is partially visible, pressing CTRL will give exposition number. If target doesn't have line of sight - it will show "classic" Extender accuracy number in gold color.
  
• For RA, LoS/LoF origin point calculation is changed, big units (like hovertank and cyberdisk) are more cumbersome in terms of finding LoF, they don't have off-center aiming ability, and can't shoot "from around the corner" as small live creatures, which gives some advantage against them to small units.
  
• There's First-Person View screenshot function. It makes a picture from unit's eyes perspective. At the moment, it doesn't take into account off-center shooting option, so if you get blocked view in picture but unit still sees and shoots enemy in game - it's ok. You just can't get two additional pictures with shifted line of sight
  
• Initially, this mod was intended to use with classic UFO1/2 games, without megamods/total conversions in mind. But as BrutalAI is widely used to play mods, I was forced to make RA work with them to - with mixed results. There are plenty new mechanics, extensive use of weapons which had never been used in vanilla games, extensive use of arcing-type  weapons... But the most obvious issue is game balance. Sometimes it's weird behind any sense, and I honestly cannot balance my RA to please everyone. I still do my best, but balancing RA around XCF to make all those 100500 weapons good and realistic is far beyond my goals.
  

[Juku121]

it could be inaccurate, but will be fixed... eventually
...
Min/max accuracy caps at 5%/95% respectively. For 5% or less - kneeling grants additional 2%, and aiming another 3%

Didn't we discuss this, and it turned out that the cap wasn't really as hard as this line says it is? I recall testing it in... December? ...and getting something like 99% accuracy at non-point-blank distances.

When RA option is off - the game should works the same as OXCE... but it doesn't.

This sounds like a big problem for BOXCE in general.

...balancing RA around XCF to make all those 100500 weapons good and realistic is far beyond my goals.

XCF weapons aren't meticulously balanced or even close to 'realistic', nor were really intended to be, though. Same for Piratez.

[0xEBJC]

When RA option is off - the game should works the same as OXCE... but it doesn't. To make RA possible, I've done many changes to the code, which affects "vanilla" accuracy, including fixes and improvements, but also new bugs.

This sounds like a big problem for BOXCE in general.

Not sure if this is what you are referring to:
I checked the code too, and found that RA is 'ON' when the value is '0' zero, and 'OFF' when the value is '1' one. for "realistic = 0 and Normal = 1"

There were a number of places where this value was checked and so I thought it best to not suggest changing the value to reverse 1 and 0 for the logic.

[Juku121]

No, the problem isn't the values of the flags for RA, but rather the fact that RA can't really be 'turned off' without reverting to OXCE.

[Xilmi]

There were certain things in OXCE that I considered outright bugs and that I've changed because I thought it would be silly to leave them in.

For example when throwing grenades you sometimes got an error message but could continue trying to throw and then it would eventually work. That was because it simulated the flight path and whenever it would hit a wall in the simulation, even though in other simulated throws the throw worked fine, it would say "nope".
So you could try until it wouldn't hit a wall in the simulation.

This also fucked the AI over because the AI had already determined that a throw is possible but then had it's simulation fail and just end up doing nothing when the intention was to throw a grenade.

Units like Celatids and Deep-Ones also severely suffered from issues regarding their arcing-projectiles.

[Meridian]

He's not talking about things, which happen once in a century and need an army of debuggers to be found.

There are dozens and dozens of changes in BAI, which change the core mechanics of the game and there's no way to turn them off.
That's what the discussion is about.

But to stay ontopic:
I spent a minute reading some recent commit names, and easily found a concrete example for you related to this thread: https://github.com/Xilmi/OpenXcom/commit/7d92ed64eaaf16f8738f5ec2ce932c962913e686

Huge change, no option to turn it off. One of many.

[Xilmi]

I spent a minute reading some recent commit names, and easily found a concrete example for you related to this thread: https://github.com/Xilmi/OpenXcom/commit/7d92ed64eaaf16f8738f5ec2ce932c962913e686

Huge change, no option to turn it off. One of many.

@jnarical: Why is this not gated behind your option?

[jnarical]

@jnarical: Why is this not gated behind your option?

Short answer is:

There were certain things in OXCE that I considered outright bugs and that I've changed because I thought it would be silly to leave them in.

That was (partly) a joke. Long answer / my reasoning:

function applyAccuracy() is used for shooting with direct fire, for arcing shots, for waypoint-guided weapons and for throwing as well. For all above its voxel-based nature works well, every voxel matters... but not for throwing - 'cause at the end it's tile-based. Due to "classic" accuracy formula, it's either (voxel-based) hit or miss with a high degree of dispersion in case of missing. There's a portion of that dispersion where grenade falls mathematically at the edge of tile, but teleports immediately to its center.

From gameplay-wise perspective, that looks like grenade flies either straight to the target tile, or falls somewhere at distance. I tried to experiment with it and really liked when it falls to adjanced tiles more often, and that overall spread of throwing feels more natural. My real mistake here is that I didn't bother to wrap that change under "RA option enabled" condition, which should be done in a nearest future...

TBH I wrote that piece of code in a moment when I (unsuccessfully) was trying to troubleshoot accuracy issues with arcing shots, and I still haven't managed to figure that out. For that, I added a ton of debug/additional code, including separation for arcing shots in "classic" calculation to experiment with different dispersion. The idea was - in case I can't manage to make arcing shots work with "full" RA algorithm, at least add a small RA block inside classic algorithm for them specifically, using basic algorithm with tweaks. As side effect, I added "tweaked" throwing block, and it went to commit to unclutter my diff.

[jnarical]

There are dozens and dozens of changes in BAI, which change the core mechanics of the game and there's no way to turn them off.

For your example, rather obvious, there is a way - to fix my code and make that change optional. And I'll do that in nearest time.

There are really dozens of changes which can't be made optional, or can but with too much overhead (like making second versions for several big complex functions). I'm totally agree with that. Those changes include fixes which you personally rejected and called those "feature not a bug". Apart from them, there are changes which are needed for RA to work, and that classic code was changed.

To me, it's much more important those "changes of core mechanics" should be little to no observable from player's perspective, and when I get complains that game plays differently from OXCE I personally consider that as bug. And yes, there are unfixed bugs now. The main issue is my real life drive my attention from OXC development for quite a long time.

[Meridian]

For your example, rather obvious, there is a way - to fix my code and make that change optional. And I'll do that in nearest time.

There are really dozens of changes which can't be made optional, or can but with too much overhead (like making second versions for several big complex functions). I'm totally agree with that. Those changes include fixes which you personally rejected and called those "feature not a bug". Apart from them, there are changes which are needed for RA to work, and that classic code was changed.

To me, it's much more important those "changes of core mechanics" should be little or no observable from player's perspective, and when I get complains that game plays differently from OXCE I personally consider that as bug. And yes, there are unfixed bugs now. The main issue is my real life drive my attention from OXC development for quite a long time.

I agree with everything you said.

I'm not trying to go on a witch hunt here or anything like that.
You (and everybody else) are free to make any modifications you like.
What's a feature to me is a bug to you and vice versa... that's absolutely normal.

All I want is that people stop calling BAI 100% compatible with OXCE... that is really making me depressed and frustrated... because no matter how I look at it, it is NOT compatible with OXCE, not by any measure I can think of.

[jnarical]

not by any measure I can think of.

If it works with all the mods and players see no difference (for example) - that's a clear measure of compatiility to me. And if there are differences - it's not all black and white.

Didn't we discuss this, and it turned out that the cap wasn't really as hard as this line says it is? I recall testing it in... December? ...and getting something like 99% accuracy at non-point-blank distances.

I've just copy-pasted the text, I know it's out-of-date but I don't remember actual numbers. That's why I ever left a small disclaimer about it)

This sounds like a big problem for BOXCE in general.

I'd like to know more, do you mean accuracy-related issues/differences by that? By any chance, could you give detailed examples of said problems, which bothers you the most?

[Juku121]

I'd like to know more, do you mean accuracy-related issues/differences by that?

For starters, it's the general problem that BOXCE is no longer an addition to OXCE, but a different fork, as Meridian said. This means not all knowledge transfers over, OXCE devs and informed players can't always provide support, there are undocumented things that may or may not be bugs and only one person in the world can tell the difference without code diving. Stuff like that.

Second, Meridian's example is a very good highlight of something I have a lot of problems with (engine-level tightened throwing dispersion when I think said dispersion is ridiculously low to begin with, and modding tools provide limited means to address that), one which is quite difficult to notice in-game without playing a lot, getting a sense that something's is off, and then either code diving or getting someone else knowledgeable (and right now, that was like two people on the planet!) to point out this got changed.

And ATM it looks like BOXCE is a minefield of such potential subtly but meaningfully different aspects, and that makes me not want to play it at all. Because testing and documenting such things is usually assumed to be the responsibility of those who make the changes, and 'play to find out' is rightfully lambasted as lazy dev behaviour.


Bottom line, I can no longer trust BOXCE to behave like OXCE, with AI-oriented changes and some option-gated additional stuff. And I have little desire to learn two subtly different sets of game rules/behaviours. I can get changing some things because vanilla behaviour wasn't working for AI, or it was somewhat disputably a bug, one OXC(E) didn't care about but didn't really change the game much. The above example is neither, and a significant change at that. And I don't want to walk on a minefield of finding out what exactly does or does not work as it used to, without a clear heads-up.

[jnarical]

engine-level tightened throwing dispersion when I think said dispersion is ridiculously low to begin with, and modding tools provide limited means to address that

Ok, I've just made an experiment - 4 guys throw 8 grenades each at a reasonably long distance.
BOXCE, RA on - 90% of grenades go straight to the target tile
BOXCE, RA off - 100$ similar
OXCE - 100% similar

I have to admit, throwing is kinda broken (and was initially) and my edits made dispersion tighter (and worse). I didn't want to deal with original accuracy code, but it seems that I have to. At least, now I know another issue and working on it.

upd:
What do I mean by "broken"? Here's a test in "vanilla" OXCE, which I use to look for differences with BOXCE, with or without RA.
24 flares thrown from a tile, where selected unit is. Throwing accuracy of units: 55, 73, 75, 77.
16/24 = 67% went straight to the target tile.
7/24 = 29% went to adjanced tile
1/24 = 4% went 2 tiles away from target
I've that test several times, and to me the issue is obvious.


The reason of this - that accuracy applied voxel-based, and when bullet with enough deviation (usually 10+ for small target is enough) just misses entirely, throwables drop near a target, not flying away.

[Juku121]

'OXCE' can cover a lot of things. I've not played the vanilla UFO/TFTD in... decades?

My point was rather that it looks like the limited tools available outside the engine ('accuracyAimed' and 'throwMultiplier') only effect the accuracy part, and maximum dispersion is dictated by the engine (and changes to the engine).

Some mods halve throwing accuracy via 'throwMultiplier' to address the vanilla precision somewhat.

One time when I was trying to see how well that actually works, I set both really low and people were still lobbing grenades two screens away with passable accuracy. The four tiles or so are generally still within explosion radius, although the damage can be quite small.




Current BOXCE means that knowledge is now outdated, and once I discover that (if I do) there's really no way to address it short of petitioning Xilmi or making another fork.



I do hope you either put this behind RA, or introduce some more variety. But the general problem of there being undocumented changes to the base game that are hard to spot and impossible to turn off remains.



Edit: Was there a difference in your tests when using a lower-accuracy soldier?

[jnarical]

I do hope you either put this behind RA, or introduce some more variety.

The main goal of making RA initially was and still remains to make accuracy generally better... So, I'm not only planning to "put that behind RA", but hope to fix it to reasonable state first. Now I'm sure that using same accuracy function to calculate both direct-hit weapons and tile-based throwables is a bad idea. And I plan to test that in original old UFO for comparison. And of course "vanilla" OXCE algorithm will be available in untouched state. As I've said earier, I consider every observable difference between OXCE and BOXCE w.o. RA as a bug.

Was there a difference in your tests when using a lower-accuracy soldier?

Ok, I selected 4 soldiers with minimum throwing accuracy available. Results:
T.Accuracy 55: 4/6 target tile, 1/6 adjanced tile, 1/6 - distance 2 tiles to target
T.Accuracy 59: 5/6 target tile, 1/6 - distance 3 tiles to target
T.Accuracy 63: 5/6 target tile, 1/6 adjanced tile
T.Accuracy 54: 3/6 target tile, 1/6 adjanced tile, 1/6 - distance 2 tiles to target, 1/6 - distance 3 tiles to target
Overall: 71% asbsolute hit, 12,5% adjanced tile, 8,3% 2-tile distance, 8,3% 3-tile-distance...

In other words, 100% hit with good enough explosive, or 83,5% (good) hit with weak grenades