"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)