"Realistic accuracy and cover system" option

[Meridian]

Hello, Jnarical. Some time ago, you came to my stream and discord and claimed that shelters do not work in OXCE.  I checked your statement and made sure you were wrong. I did 4 tests, with my fighter and the enemy without shelter, behind a fence, behind a fence and a window and behind a tree. At the same time, all other shooting conditions were exactly the same. As a result, I found out that the shelter helps, while the larger part of the target area is closed, the fewer hits come to the target. I'm attaching screenshots.

You could have saved testing time and just ask

Of course, cover does work in OG, OXC and OXCE.
As an OXCE dev, I can 100% confirm that cover works as designed and as expected.


The whole misunderstanding is just who considers what being "cover", who considers what being "realistic", and so on...
It's all just definitions and terminology.

[jnarical]

Of course, cover does work in OG, OXC and OXCE.
As an OXCE dev, I can 100% confirm that cover works as designed and as expected.
It's all just definitions and terminology.

There's an old joke

Two Jewish ask Rabbi to resolve their argument.
First guy: "Rabbi, is black a color?"
"Well, sure..." - said the confused Rabbi.
First guy: "See, I told you! Rabbi, is white a color?
Rabbi: "Well, yes, white is a color."
First guy: "See? I told you Moishe, I sold you a Color TV!"

When I show you how accuracy is just the same to half-covered target as like as for fully exposed, you call that "cover works as expected"
When I show how 95% covered target reduces accuracy from 90% to 45%, and missing shots don't hit any cover and just fly by - you call that "cover works as expected"
There's nothing to argue about, other than definitions. Cause right, black and white are still colors ))

[Meridian]

When I show you how accuracy is just the same to half-covered target as like as for fully exposed, you call that "cover works as expected"

Yes, absolutely.

When I show how 95% covered target reduces accuracy from 90% to 45%, and missing shots don't hit any cover and just fly by - you call that "cover works as expected"

Not sure what you mean, cover does not (directly) reduce accuracy in OXCE.
You probably meant "no LOS" check?

There's nothing to argue about, other than definitions.

Exactly, I'm glad we agree.

[jnarical]

You probably meant "no LOS" check?

Nope. I checked that in debugger - there was no penalty.

[Flipbard]

You could have saved testing time and just ask

Of course, cover does work in OG, OXC and OXCE.
As an OXCE dev, I can 100% confirm that cover works as designed and as expected.


The whole misunderstanding is just who considers what being "cover", who considers what being "realistic", and so on...
It's all just definitions and terminology.

Thank you. But it was really interesting for me to check for myself.

jnarical was very persistent and convincing when he came to my Discord server and began to prove that "shelters don't work." He gave formulas, drew diagrams on pieces of paper and sent photos. Although this contradicted my personal experience and the experience of people from the Russian-language chat on the game.  jnarical argued that it only seems to us that shelters work, that this is cognitive bias and self-persuasion. If I had asked you, I would have received two contradictory statements. You would say that they work, jnarical - that they do not work. Both you and he would be referring to the game code. I thought the only sure way to find out the truth was to take the test myself. I conducted it and made sure that the shelters really work. It's harder to hit a fighter behind cover. The fact that not all bullets fly into the shelter itself seems to me quite reasonable. If you aim at an ear sticking out from behind a tree, it is logical that some of the bullets will fly not into the tree, but in the other direction from this ear, i.e. past.

I apologize if I write with mistakes or use the wrong words - English is not my native language.

[jnarical]

I should admit I was wrong. Covers in OG work, seems I got used to OXC and forgot how OG feels... Which is not surprising, considering i haven't played it for decades.
I repeated experiments once again, 100 shots for each, twice for OG.  Well, "works as intended", and seems like the intention was to avoid OG behaviour altogether.

To clarify, this is the percentage of hits, blocked by cover, for similar battlefield state but for different game versions
Original game #1 — 55,6% - I call this "cover works"
Original game #2 — 57,1%
BAI / RA On — 36,8%
OXCE — 11,8% - and this is "doesn't work" to me
BAI / RA Off — 8,8% - ...this is my version in "OXCE mode", which is similar to OXCE at least in theory (doesn't work either)

[Flipbard]

It may be worth testing by disabling this option.

[jnarical]

It may be worth testing by disabling this option.

It does nothing in case there's a line of sight fire

[Flaubert]

Hi! i've heard a lot of good things about your Realistic Accuracy Cover System, (RACS), and wanted to give it a try, but I'm not interested ATM on Brutal AI, Fog of War and other features at BOXCE (no offense, perhaps in the future). So, I'm trying to port just parts related to RACS to the "vanilla" OXCE, identifying and adding just your commits in BOXCE git history. I've some questions related to this, and I'd like to ask you about if you don't mind.

- Are your changes at "AIModule.cpp" (AIModule::BrutalThink and AIModule::BrutalScoreFiringMode) needed for porting RACS? Or are they a "help" to the Brutal AI part of BOXCE?

- Also, changes at TileEngine::calculateUnitsInFOV, related to check visibility of units at your own unit FOV, are a BUG/enhancement of original  calculateUnitsInFOV function? To me, they seem unrelated to RACS feature, but for snipper/spotter feature and Brutal AI (unit->checkForReactivation() and similar)

- Finally: changes at Map::drawTerrain about "// Draw motion scanner arrows" are part of RACS? What does it change about Motion Scanner Arrows on screen? I (think I) recognize elements related to FOW, but others - "offset.y" changed if "myUnit->isKneeled()" - could be related to adjusting arrows position?

To better compare vanilla OXCE and OXCE+RACS, I've chosen to duplicate some functions you heavily modified, so you can call the original one or RACS version depending on Options::battlerealisticaccuracy value. It's the case of TileEngine::canTargetUnit  or Projectile::applyAccuracy, where it was  very difficult for me to "separate/protect" original to changed code using a Options::battlerealisticaccuracy "guard". It's possible some of the changes are related to "bugs" in original code - AIRC I read something in openxcom forum - but as these possible bugs are not identified, I can't know.
I found that original  TileEngine::checkVoxelExposure was not used anywhere in OXCE (??). So it was easy to replace it by yours.

...
Additional details / clarifications:

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.

So, if you don't see any cover number when you press CTRL, and icon is gold, it means the enemy is fully covered and accuracy number is lying (you cannot hit a fully covered enemy)

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

How can you activate this function? Is there any key to save this screenshot?

Thanks a lot for your work. Is a wonderful feature, which IMHO would have been a huge improvement to official OXCE; for me, current OXCE shown accuracy is not very useful beyond knowing that the higher the better accuracy.

[Xilmi]

Considering that all the features you mentioned you are not interested in are optional, I think putting in the effort to try and surgically remove and reimplant this feature in isolation sounds like a bit of a pointless effort.

[jnarical]

Hi! i've heard a lot of good things about your Realistic Accuracy Cover System, (RACS), and wanted to give it a try, but I'm not interested ATM on Brutal AI, Fog of War and other features at BOXCE (no offense, perhaps in the future). So, I'm trying to port just parts related to RACS to the "vanilla" OXCE, identifying and adding just your commits in BOXCE git history. I've some questions related to this, and I'd like to ask you about if you don't mind.

I call it "RA" for short.  If you just want to play with RA without BrutalAI, Fog of War etc. - you could just turn them off, and have (mostly) OXCE experience. It's MUCH easier if all you want is to play with RA, than backporting RA to OXCE... I'd like to do that, but it's not that simple, as accuracy, targeting, los/lof code is tightly coupled. I had to touch different parts of code to make RA work as I wanted too. If you want to implement it on top of OXCE as entirely togglable, you'll get significant overhead and overcomplication... that's why I decided to move away from OXCE - it's too much of a work for me alone. As far as I know, some fixes for RA was commited by Xilmi too, so taking only my commits into consideration isn't enough...

- Are your changes at "AIModule.cpp" (AIModule::BrutalThink and AIModule::BrutalScoreFiringMode) needed for porting RACS? Or are they a "help" to the Brutal AI part of BOXCE?

If you're talking about my commit changing that code, most probably I commited some fix for AI-related code, after discussing it with Xilmi. If something is inside "Brutal"-named code, it's not needed for "vanilla" OXCE. Most probably)

- Also, changes at TileEngine::calculateUnitsInFOV, related to check visibility of units at your own unit FOV, are a BUG/enhancement of original  calculateUnitsInFOV function? To me, they seem unrelated to RACS feature, but for snipper/spotter feature and Brutal AI (unit->checkForReactivation() and similar)

It seems to me atm, that function was checking all four tiles for big units even after discovering it's in FOV, which is unnecessary. But I could be wrong (And could've been wrong understanding that code right). As I remember, that change is related to something else, for example new version of canTargetUnit. Need to double-check.

- Finally: changes at Map::drawTerrain about "// Draw motion scanner arrows" are part of RACS? What does it change about Motion Scanner Arrows on screen? I (think I) recognize elements related to FOW, but others - "offset.y" changed if "myUnit->isKneeled()" - could be related to adjusting arrows position?

I don't get anything from me in that part of code, checked with "git blame", found nothing. Please elaborate which line numbers we're talking here.

To better compare vanilla OXCE and OXCE+RACS, I've chosen to duplicate some functions you heavily modified, so you can call the original one or RACS version depending on Options::battlerealisticaccuracy value. It's the case of TileEngine::canTargetUnit  or Projectile::applyAccuracy, where it was  very difficult for me to "separate/protect" original to changed code using a Options::battlerealisticaccuracy "guard". It's possible some of the changes are related to "bugs" in original code - AIRC I read something in openxcom forum - but as these possible bugs are not identified, I can't know.

The most difficult part is separating it in all other places, like Map.cpp and ProjectileFlyBState.cpp. For me it took months of sitting and looking at code, to get an idea how all that works, at least to some extent. But I'm not the "real" programmer, after all ))

I found that original  TileEngine::checkVoxelExposure was not used anywhere in OXCE (??). So it was easy to replace it by yours.

That's right. It's just unused (and bugged to the core if someone decided to use it) piece of code, at least in OXC. For OXCE, maybe something changed in that regard, didn't look at)

So, if you don't see any cover number when you press CTRL, and icon is gold, it means the enemy is fully covered and accuracy number is lying (you cannot hit a fully covered enemy)

It's always a challenge to add some new mechanics to the game and don't have players (too) confused. "Extender accuracy" (or relatively "new" separate option to display accuracy numbers at cursor) shows numbers without considering LoF, except no-LoS penalty of course. So, cursor on enemy behind dozen of walls still displays non-zero numbers with Extender accuracy "On" - and players are used to it. So, it's not "lying" in RA - it gives some useful info instead of just plain "you couldn't hit target behind a wall so your accuracy is zero". It's not, and you could force-fire to that target with more or less success.

How can you activate this function? Is there any key to save this screenshot?

F10 in Battlescape
https://www.ufopaedia.org/index.php/Controls_(OpenXcom)
https://www.ufopaedia.org/index.php/Hidden_Features_(OpenXcom)

Thanks a lot for your work. Is a wonderful feature, which IMHO would have been a huge improvement to official OXCE; for me, current OXCE shown accuracy is not very useful beyond knowing that the higher the better accuracy.

I'd like to see RA in "generic" OXCE but that doesn't seem to happen. I posted a PR to OXC more than a year ago, with targeting-related fixes - haven't got any luck still. No chances to something more serious, sadly. The best I could do (in theory) is to make RA-fork based on OXCE rather than BrutalOXCE, but that won't be necessary until Xilmi drops the development.
(the PR in question: https://github.com/OpenXcom/OpenXcom/pull/1431)

[jnarical]

Fixed long-standing bug. Found time and energy to deep dive into this code again, and after two sleepless nights I present a fix. This is huge, I really sorry it wasn't fixed months ago. I was basically a fun-killing bug. In a nutshell - spread was bugged when force-shooting to covered targets, making you unable to use force-shooting.

Spoiler:

Now waiting for Xilmi to update BOXCE

[Xilmi]

Now waiting for Xilmi to update BOXCE

I released a new version with your fixes.

[xenoroyal]

Jnarc, sir.  From your mods description

Cover efficiency. How much cover affects chances to hit a target:
"no effect" 0% - target exposure doesn't affect final accuracy
"medium effect" - 50% fraction of accuracy is multiplied by visibility
"high effect" - 70% fraction of accuracy is multiplied by visibility
"full effect" - 100% final accuracy is multiplied by visibility

What setting should I play on?  Im playing brutal AI, going for a challenge, but dont want to make cover either too weak or too strong.  Could you please provide insight on what you think the ideal setting is?


based on your recent post, which i dont fully understand

To clarify, this is the percentage of hits, blocked by cover, for similar battlefield state but for different game versions
Original game #1 — 55,6% - I call this "cover works"
Original game #2 — 57,1%
BAI / RA On — 36,8%
OXCE — 11,8% - and this is "doesn't work" to me
BAI / RA Off — 8,8% - ...this is my version in "OXCE mode", which is similar to OXCE at least in theory (doesn't work either)

What cover efficency setting should I be using?

[jnarical]

based on your recent post, which i dont fully understand

First, how to read those numbers.
I'll be using BAI-RA for OXCE with Brutal AI and Realistic Accuracy disabled, and BAI+RA for enabled.



In original (DOS) game, just like in OpenXCom Extended (or BAI-RA) - shooting is "simulated" by deviation, based on accuracy and distance.

Lets take a look at original game first. The number of shots which hit the target, combined with the shots which hit the cover: 48,5% and 54% for two tests (fraction numbers because I measured more than 100 shots in first case, by mistake). These two numbers heavily correspond with 48% accuracy, considering that I counted hits and misses "by hand" and some hits to cover I should possibly count as "misses"... So, we can see that overall "accuracy" displayed by the game really represents the chance to hit the target, in case when it's fully exposed. And we could calculate "cover efficiency": cover hits / (target hits + cover hits), and that gives us 57% and 56% (rounded) for both cases. This is REAL cover efficiency in original DOS game, mind you - measured for a single game scenario.

Using this approach for OXCE or BAI-RA, for 55% accuracy we get this:
 60 hits to target and 8 to cover - for OXCE, which corresponds to 12% cover efficiency
 52 hits to target and 5 to cover - for BAI, which corresponds to 9% cover efficiency
As 100 test samples isn't too much for relialiable statistics, we could say that ROUGHTLY accuracy for both games represents overall chance to hit (55% compared with factual 68% in OXCE, 57% in BAI-RA)

In general, it means in OXCE cover has much less effect than in original DOS game (10% vs 60% for this particular game scenario)

For BAI+RA the algorithm is "inversed" - it's not a honest simulation, it's roll-based, and that allows me to "set" cover efficiency and decouple shot deviation entirely. In this example, cover efficiency was set to 70% in menu - and that lowers overall accuracy from 55% to 32%, considering other effects from distance, target cover percentage etc. for this particular game scenario. And for 32% accuracy I got 36 factual hits, which is again roughtly corresponds. I don't count cover hits in this case, cause there's no simulation and they depend on shot spread which I set by myself, and cover effect is alredy included to accuracy.

That was an explanation, I'll leave it as a separate comment