OpenXcom Forum
OpenXcom Forks => More Forks => Brutal AI => Topic started by: jnarical on April 11, 2024, 10:37:28 pm
-
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 (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)
Old video but still...
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.
- 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
- Sniping bonus mitigates target's cover. Bonus is equal to final accuracy minus unit's own accuracy, then divided by 2. New accuracy can't exceed previous "final" accuracy. Example: Target covered by 95% (extremely high), cover efficiency is 100% (which is kinda extreme too), unit's ACC stat is 85, weapon multiplier for aiming shot is 130%, and shot is performed from kneeled position.
Final accuracy without cover effect and without sniping bonus: 85*1,3*1,2 = 132,6
Final accuracy with cover effect, without bonus: 132,6 * 0,05 = 6,63%
Sniping bonus: (132,6 - 85)/2 = 23,8
Total accuracy: 6,63 + 23,8 = 30%
Now, the same example with cover efficiency = 70%
Final accuracy with cover effect, without bonus: 132,6 * 0,7 * 0,05 + 132,6 * 0,3 = 4,64 + 39,8 = 44,4%
Total with bonus: 44,4 + 23,8 = 68%
Seems legit for sniper shot to 95% covered target, isn't it?
- Min/max accuracy used to be capped at 5%/95% respectively. Now it's basically umcapped 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.
- 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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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? :o
-
@jnarical: Why is this not gated behind your option? :o
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.
-
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.
-
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.
-
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?
-
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.
-
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.
(https://i.imgur.com/Nn6feS2.png)
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.
-
'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?
-
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
(https://i.imgur.com/ToBiEpm.png)
-
So, I'm not only planning to "put that behind RA", but hope to fix it to reasonable state first.
Fair enogh. I quite liked the ability to see the 'hit roll' when I last tried. Perhaps too much PF WotR. :-[
In other words, 100% hit with good enough explosive, or 83,5% (good) hit with weak grenades
Yep, one of my problems with grenades in general. I seem to be somewhat in a minority, though.
-
I seem to be somewhat in a minority, though.
I've heard a significant number of complaints about this issue from different people, throwable explosives are just much more efficient overall. I'm not sure for 100% but I think mods' developers (I recall XCF in particular) try to mitigate that advantage somehow.
UPD:
Tried original DOS version... What should I say? OXCE perfectly represents old algorithm :)
-
Latest changes in RA part (not that much)
(https://media.discordapp.net/attachments/1138951748124409956/1232593827219378237/image.png?ex=6637ddb4&is=66368c34&hm=5fc3da9a1f9cf8d216687793a934ce492ec3d0db683455cfe2f0d87d5a8c9504&=&format=webp&quality=lossless)
1) There's a kind of old bug where unit is elevated, target point belongs to the upper tile, and my code wasn't detecting that unit in one function, but detected in another, so there was discrepancy (50% no-LoS penalty was incorrectly applying in applyAccuracy, but not in drawTerrain). Yes, that's a part of that known bug with tank in XPZ, seems like its fix wasn't complete
2) All arcing shots now work with classic accuracy code, so no "precise" chance to hit or checking % target visibility. It immediately fixed related bugs (I've closed two issues in github). It is temporary solution ofc, I just want to narrow down all other bugs before starting to write "arcing RA" part. This could be confusing so I'll repeat)) RA is disabled for all arcing shots!
3) Two bugs - one in RA part in applyAccuracy, setting target voxel for missing trajectory outside of the map. I didn't think that would be a bug, as any voxel outside of the map still could be used as a valid target for a shot... but the issue comes when this voxel is used to get a tile from it, somewhere in code, and gives invalid tile. So I've restricted search for missing trajectroies only inside map boundaries. Second one - there's 100-times cycle which don't do anything useful, if target voxel belongs to invalid tile. I've added early break from the cycle in that regard.
4) Rollback that unlucky grenades accuracy commit that Meridian told about
My real life takes over one more time, so I cannot have as much time dedicated to OXC development as I want, but hope it'll change.
-
brown accuracy digits are a cheat
it will show you exactly where the alien is, even if you can't see it, just move the crosshair from your ship over the UFO
-
brown accuracy digits are a cheat
it will show you exactly where the alien is, even if you can't see it, just move the crosshair from your ship over the UFO
Thanks, I’ll look what could be done here.
-
brown accuracy digits are a cheat
it will show you exactly where the alien is, even if you can't see it, just move the crosshair from your ship over the UFO
Fixed, It was trivial.
-
Fix is available in 8.5.0.
-
After I've got a couple of positive opinions about my version of throwing accuracy code, I've decided to return it back to game, under new option (independent from RA) - "Alternative throwing mechanics".
Here's the reasoning behind it.
There is applyAccuracy function, which applies unit's accuracy, adding deviation to target voxel, and there're several issues here.
1) Resulting deviation for successful rolls is not enough to make grenade fall to tiles, adjanced to target. It always falls to target tile in that regard.
That feels unnatural.
2) Resulting deviation for unsuccessful rolls feels unnatural too - grenade could fall too far away from target
3) Accuracy for direct shots counted the same way as for throwable explosives. Throwing accuracy of 70% means that roughtly 70% of the time that highly explosive thing will hit the ground right under the target unit, demolishing both the target and surroundings. This is the main issue - although there's a distance modifier, it doesn't affect "successful" rolls. So, no matter how low your accuracy is, if you get a succesful roll - your grenades turn to a "sniper" ones. There's no significant difference between high and low throwing accuracy.
For successful hit with explosives - you doesn't need a precise hit to a voxel inside target's body, hitting any tile around it can be considered as success, to a different degree depending on a distance from target to explosion.
As a quick and dirty solution, for "Alternative throwing" option
1) I've added additional deviation so grenades could fall around the a target more naturally
2) Decreased deviation for "missed" rolls (again, to make them look more natural)
3) I've changed the formula, introducing accuracy additional penalty based on accuracy and distance. Distance without penalty is equal to square root from unit's accuracy multiplied by 3. All numbers are arbitrary and are subject to change of course, now I consider them as pretty conservative.
That way, a unit with T.Accuracy=36 could throw to 6 * 3 = 18 tiles without a penalty, and then it gets additional 16 voxels of deviation for every additional tile of distance.
T.Acc=49 gives 21 tile of "aimed" throwing
T.Acc=64 gives 24 tiles
T.Acc=81 gives 27 tiles
T.Acc=100 gives 30 tiles
With these changes, grenades are much less precise and powerful, you couldn't throw them across the whole map straight to target's feet anymore. But they are still powerful enough in hands of people with good throwing accuracy. Different accuracy and strength now matters more - there could be situation, when you got a soldier with good strength but poor accuracy.. so he could throw anything across the map, but without any precision, On the other hand, another soldier with poor strength never gets a penalty, as he just couldn't throw far enough, so he always hit target OR one ot its nearest tiles.
-
1) I've added additional deviation so grenades could fall around the a target more naturally
2) Decreased deviation for "missed" rolls (again, to make them look more natural)
3) I've changed the formula, introducing accuracy additional penalty based on accuracy and distance. Distance without penalty is equal to square root from unit's accuracy multiplied by 3.
Hey Mister) thank you for the new tossing mechanics. Could be a gamechanger.
- Can you share the exact formula? Is it bell engine or flat random around the target?
- What's the penalty per tile past optimal distance?
- I would like you to consider adding critical success toss too (i will share insights below in text, FYI)
For discussion:
1) Considering major mods, ordinary throwing skill is 40-50 for majority of troops in the beginning. THR skill cap is usually 80-90 (w/o commendations, which give additional +5 after many battles)
According to lore, throwing 35 is somewhere ordinary man skill, while 50 is beyond that. 85 THR should be human olympic champion
2) Besides, there's one more sufficient parameter: STR. In OXCE, STR is the limiter of THR distance (and it should be), but what I feel is: to a lower degree, it can influence THR preciseness as well. Say, THR skill should have weight of 75% and STR should have weight of 25%. Some armors effectively reduces weight (like, weight= -40) and will not provide any bonuses, while armors, that boosts soldiers' strength (like, +50 STR) will have additional 12,5% hitchance.
3) The critical THR success possibility should be incrementally higher to apply on closer targets. For example, the low-skill trooper (40 THR skill) throws grenade:
- 2 tiles away should have at least 90% underfeet chance,
- 5 tiles away should have, like, 65%
- 10 tiles away - your penalties and deviations come into full power
For example, high-skiller trooper (80 THR) should be able to toss grenade well across the map. It is rather rare to find out such units in your rooster, but some mods present you units better (and stronger), than humans.
For these units, critical THR success chance should proliferate to a longer distances.
-
Added some fixes, including important one. Changes involve "missing shots" mostly, improving how they work.
1. When targeting a unit with autoshot, and that unit is killed before all the projectiles are launched - remaining projectiles no more target the floor, they still aim to that target voxel which was part of that unit's body.
That's normal targeting behaviour for OG and always was that way, and I considered it a bug in RA. Now it's gone, and heavy multiple projectile autofire weapons, like chainguns - work correctly. That was a small code change, but it'a big deal, really.
.
2. Now when shooting empty tile, roll-based hit/miss mechanics considers "virtual" medium-sized unit as target for calculating missing shots. So, if your accuracy roll gets a miss - shot will fly outside that "invisible" unit (but it surely could fly through the target tile at the same time)
3. Since the OG, when targeting empty tile, target voxel is fixed depending on tile type - 2 types of walls, floor, ceiling, object, or void. For example, for "void" tiles target is (8,8,12) inside that tile, its center. For RA, when targeting such tiles and rolling a hit - projectile now gets light deviation around that point. And when rolling a miss - yes, it'll fly outside invisible unit))
I've tested that code a little, in classic, XCF and 40k. All seems fine.
My next goal will be adding two things simultaniously:
1) "weightened" effect of target's exposure.
Possible options would be: 0% (off), 30% (light), 50% (medium), 70% (high), 100% (full)
In current version, it's 100%/full.
For example, you got 100% accuracy shot to 30% exposed target.
With different settings, final accuracy will be:
0%/off: 100%
30%/light: 70% + 30%*0.3 = 79%
50%/medium: 50% + 50%*0.3 = 65%
70%/high: 30% + 70%*0.3 = 51%
100%/full: 100% * 0.3 = 30% (current RA version)
2) "Sniper accuracy mechanics" - portion of accuracy, exceeding 100% initially, added after calculating exposure effect. And that could be weighted based on shot type, if needed. Time will tell.
For example, you get very high accuracy shot to a highly covered target. Initial accuracy 180%, target exposure is 5% (basically, some sectoid looking from a small window, with only its head exposed). Even with 100% exposure weight from the previous option, you get 180*0.05 (9%) + 180-100 (80%) = 89% chance to hit, where 80% part is for "sniping".
-
2) "Sniper accuracy mechanics" - portion of accuracy, exceeding 100% initially, added after calculating exposure effect. And that could be weighted based on shot type, if needed. Time will tell.
For example, you get very high accuracy shot to a highly covered target. Initial accuracy 180%, target exposure is 5% (basically, some sectoid looking from a small window, with only its head exposed). Even with 100% exposure weight from the previous option, you get 180*0.05 (9%) + 180-100 (80%) = 89% chance to hit, where 80% part is for "sniping".
Hey Joy, all changes are very nice and appreciated. Few things I would like to put your attention into:
- sniper shots exceeding 100% may be worth reconsidering formula, because weapon accuracies had been balanced around different shooting mechanics. Plain over-100% growth of hitchance is something that will make it surreal that 130% accuracy-guy will have 80% of actual chance to hit 50%-covered unit, while 100%-guy will have plain 50%. May it be 1/3 penalty for everything beyond 100% too, be worth considering.
- empty-tile shooting is somehow broken in OG:
* when you have a wall adjacent to a tile you shoot: sometimes unit shots into wall, instead of a tile.
* when tile is empty or beyond visibility range, (or enemy that stands on it is undiscovered yet) - shooting goes into the ground tile. That is part of mechanics and is purposeful for number of things: killing downed enemies, lighting ground with plasma etc. But sometimes it is worth to shoot through this particular tile so bullet can fly past it and hit everything beyond.
Moreover, when player targets tile that is located above, fly-through shots are hard to make. E.g. unit stands on ground, supposed enemy is located on 4th floor 30 tiles away, unseen, then default firing results in shooting into the ceiling of 3rd floor, not window/wall of 4th floor.
I suggest making one more shooting option: shooting into tile's center 1/3 height. This could be, possibly, tied to ALT button, instead of default shooting, which clearly should keep it's designation of ground aiming, if no enemy or object is located on the target tile.
To remind, CTRL is engaged for "shoot no matter what action", so CTRL+ALT+click must result in shoot no matter what, but into the 1/3 height of the tile.
- as we go through hit/miss rolls, there is one more thing I would like to suggest, regarding the visible targets shooting:
BASIC
* roll for hit means bullet flies into the target voxel
* roll for cover means bullet hits target OR cover, but within target voxel cone
* roll for miss DOESN'T mean necessary miss, but instead gives random shot within cone, where shot can go everywhere. (even, into the target, randomly)
DIFFERENCES for abovementioned ALT-method
*ALT+ roll for hit means bullet flies into target's voxel center's 1/3 height, even if there is cover (contrary to the specific case when unit shoots precisely into the finger, which sticks out from the window. Prove me incorrect, if CTRL+shooting already goes into center, not open-part of the body)
* NO COVER is considered when calculating ALT-shots. If there's cover, indeed, it is up to player to consider this method. This method is specifically good for destruction covers with heavy weapons.
* roll for miss works as default (goes everywhere, even into the target, randomly)
Wish you best!
-
- sniper shots exceeding 100% may be worth reconsidering formula, because weapon accuracies had been balanced around different shooting mechanics. Plain over-100% growth of hitchance is something that will make it surreal that 130% accuracy-guy will have 80% of actual chance to hit 50%-covered unit, while 100%-guy will have plain 50%. May it be 1/3 penalty for everything beyond 100% too, be worth considering.
1) About the formula - all numbers are just arbitrary... Maybe a threshold for sniping should be equal to unit's own accuracy? I don't know, but the core idea of sniping is just like that) Your example has a mistake... 130% accuracy to 50% covered target will be 130%*0.5 + 30% = 95%... and this mechanics should be used with "partial"effect from cover. It'll make 130% accuracy even more powerful and 100% accuracy to half-covered target - less penalized.
- empty-tile shooting is somehow broken in OG:
* when you have a wall adjacent to a tile you shoot: sometimes unit shots into wall, instead of a tile.
* when tile is empty or beyond visibility range, (or enemy that stands on it is undiscovered yet) - shooting goes into the ground tile.
It's not broken. It chooses target voxel based on tile type, and it's different one for different kinds of walls. About a tile with undiscovered unit - it's also makes kind of sense. And what about shooting in desired direction - as far as know, CTRL works just like that. To me at least, it works as "target the center of a tile, regardless of its type". So, if you'll shoot a tile with an undiscovered enemy with a CTRL, you'll get precisely what you want. I was experimenting with it lately, without CTRL a bullet goes to a floor (for a "floor" tile without a wall), with CTRL flies "horizontally" (considering the fact that gun's barrel is higher than tile center, it goes downwards slightly)
- as we go through hit/miss rolls, there is one more thing I would like to suggest, regarding the visible targets shooting:
BASIC
* roll for hit means bullet flies into the target voxel
* roll for cover means bullet hits target OR cover, but within target voxel cone
* roll for miss DOESN'T mean necessary miss, but instead gives random shot within cone, where shot can go everywhere. (even, into the target, randomly)
DIFFERENCES for abovementioned ALT-method
*ALT+ roll for hit means bullet flies into target's voxel center's 1/3 height, even if there is cover (contrary to the specific case when unit shoots precisely into the finger, which sticks out from the window. Prove me incorrect, if CTRL+shooting already goes into center, not open-part of the body)
* NO COVER is considered when calculating ALT-shots. If there's cover, indeed, it is up to player to consider this method. This method is specifically good for destruction covers with heavy weapons.
* roll for miss works as default (goes everywhere, even into the target, randomly)
I didn't get much tbh but I'll look again outside my working hours))
For now, I can tell that destroying covers already works well with CTRL. I'm not sure where target voxel precisely is when you aim a unit with CTRL... Both ways are possible, I should check. For now, I don't get why you're asking for another firing mode, my guess is that you want to have a way to shoot slightly down... for destroying obstacles with HE shots, for example. So those HE shots could explode more often and not fly away to the sky ))
UPD:
For HE ammo, I've already adjusted target point to a lower one
-
Thanks for clarification, CTRL+shooting indeed goes to the waist-level of the target empty tile. Shame on me for not knowing it for 7 years.
-
New update to Realistic Accuracy. Internally I consider it as "RA v1.0" and it's a huge milestone.
What's added / changed:
- I've changed, almost removed accuracy caps. Now it's 1% / 300% for minimum/maximum respectively. Was 5%/95%. It was a quick and dirty fix, in the nearest future I'll change that to 1/1000 :) I plan to remove upper cap entirely by default, and to add "98% upper cap" as menu option. Reason: as I found out, in mods like XCF one could possibly get up to 600 final accuracy... So who am I to disallow that? :)
- Now short-ranged aimed shots have 100% cap instead of 95%. After some distance, you could be sure that you won't miss.
- New option: cover efficiency! It means - how much of your accuracy is affected by targe'st cover. Possible values are 0, 30, 50, 70 and 100%. 0% effectively disables all cover-based accuracy penalties - so you get vanilla-like hit chances. 100% means all your accuracy is multiplied by target exposure percent - that's how RA used to be earlier. Default value will be 50%, with 70% as a more hard/tactical option. Calculation example: you're targeting enemy with 10% exposure, your accuracy with bonuses like kneeling is 120%, and cover efficiency is set to 70%. That means, we take 100-70=30% of your accuracy as unaffected, that would be 120%*0.3=36%. Then, we take the remaining 70% of your accuracy (120%*0.7=84%) and apply target exposure to it: 84%*0.1=8,4% - and then we add the numbers together: 36+8,4=44.4% - and that would be your final accuracy, except for the case with aimed shot - 'cause there's another option!
- New option: sniping mechanics. Here's how it works. Imagine you got a unit with 83 own accuracy stat. That unit is performing an aimed shot while kneeled, gets 120% weapon bonus for aimed and 1.2 multiplier for kneeling, which gives us 83*1,2*1,2=119,52 (120 like in the previous example, if rounded). We get sniping bonus as (total accuracy - unit's accuracy)/2, which is (119,52-83)/2=18,26. Adding that to the result of previous example, we get 44,4+18,26=63% chance to hit - that's almost 2 of 3 shots. That way, aimed shots now have significant tactical advantage against heavy covered targets, negating their protection from cover. Sniping bonus couldn't make your accuracy higher than you "initial final" accuracy, and is capped at that value. For shots which were improved to their maximum value by sniping bonus - crosshair cursor becomes white, which means "Look! You'he got a good sniper shot here, congrats!" Another small detail about this mechanics - accuracy size multiplier for targeting big units doesn't counts in sniping bonus, but... it's still used for accuracy calculation before applying bonus.
But don't forget, that even if auto-shot has a much smaller initial chance, it has a good chance to destroy the cover so remaining shots wil have much better chances against the target, opened to fire.
- And the last one... I've updated russian translation.
Feel free to test and give feedback, positive or negative! And don't forget to submit bugs, too.
-
New option: sniping mechanics.
Realistic accuracy improved aimed shots
New option: cover efficiency! Default value will be 50%
Realistic accuracy cover efficiency
is default value 50% ? or 70% ? now it seems to be 70% default value (image below)
which value will be the best and most brutal?
-
Realistic accuracy improved aimed shots
Realistic accuracy cover efficiency
is default value 50% ? or 70% ? now it seems to be 70% default value (image below)
which value will be the best and most brutal?
This is bug, it seems ( the intention was to make 50% default
-
and which value of "Realistic accuracy cover efficiency" will be the most brutal? what is your opinion?
as Xilmi mentioned before (https://openxcom.org/forum/index.php?topic=11663.msg163823#msg163823) - 0% is the most brutal by his opinion?
if "Realistic accuracy and cover system" = NO (default) then "Realistic accuracy cover efficiency" will be 0% too (regardless of the set value) ?
-
and which value of "Realistic accuracy cover efficiency" will be the most brutal? what is your opinion?
as Xilmi mentioned before (https://openxcom.org/forum/index.php?topic=11663.msg163823#msg163823) - 0% is the most brutal by his opinion?
if "Realistic accuracy and cover system" = NO (default) then "Realistic accuracy cover efficiency" will be 0% too (regardless of the set value) ?
I’m not sure about “most brutal”, cause all mechanics works the same way for both player and AI. So it’s not about difficulty, more about how tedious will your battles be. Less cover efficiency - more successful shots for both sides.
Yes, the topmost RA option enables all set of RA options. Without it, shooting mechanics should be vanilla. If you like tight spread of RA but don’t like cover mechanics - you could disable covers by setting “cover efficiency” to 0%.
-
OXCEB 8.6.0
a bug - accuracy calculation when shooting alien through walls does not work correctly
if you know (or don't know) that there is an enemy behind the wall and you aim at him and shoot - then although it says 64% hit, in fact it is about 15%, so it is always better to aim behind the enemy, where there will be a real 56% and not fake 64%
previously, when there was a brown crossfire, it quickly became clear that shooting through walls on a brown crossfire was super inaccurate. now the brown crossfire is gone, but the super inaccuracy at this point remains
to reproduce:
1. load this save + options (https://openxcom.org/forum/index.php?action=dlattach;topic=11928.0;attach=63755)
2. do "auto shot" to the corner, 2 times. and count how many bullets of 6 pcs will hit the corner wall (zero)
use ctrl+click to shoot through the walls
-
a bug - accuracy calculation when shooting alien through walls does not work correctly
I'll check that after finishing to fix the crash.
-
a bug - accuracy calculation when shooting alien through walls does not work correctly
fixed. fix will be added in next bai release.
-
Just two things I would like to be added:
- Would it be possible to set a maximun hit chance, like 95% of the new games even with kneeling and other acc bonus?
- Can the target size be consider for hit chances?
-
- Would it be possible to set a maximun hit chance, like 95% of the new games even with kneeling and other acc bonus?
It used to be that way, but I changed it and removed upper cap after numerous requests. The thing is, most players who play mega-mods got accustomed to 100+ accuracy numbers, and even more - mods themselves are made with that in mind. Why do you want such limit btw?
- Can the target size be consider for hit chances?
It does. Big units have something like x1.35 accuracy multiplier as far as I remember,
============
There's a known bug in current version, off-center shooting isn't working as intended for reaction fire and most probably for AI units. Fix isn't trivial and heavily depends on technical debt, which should be fixed first.
-
It used to be that way, but I changed it and removed upper cap after numerous requests. The thing is, most players who play mega-mods got accustomed to 100+ accuracy numbers, and even more - mods themselves are made with that in mind. Why do you want such limit btw?
It does. Big units have something like x1.35 accuracy multiplier as far as I remember,
Well could it be added back as a toggable option? I much prefer having the Rng be on the hit chances than for it to be on the damage (yes I'm like one of the five people that prefer 50-150).
Regarding the size the question was more in line of smaller targets like the rats some mods add, althougth thinking about it sectoids would also have a smaller profile than normal humans.
-
smaller targets like the rats
RA scans target's hitbox, which differs for enemies. For example, there could be situation where you could see muton behind a stone wall but couldn't see sectoid which stands next to it. Their width differs too. But the issue with small creatures is their hitboxes could be much larger then sprite image. I couldn't help with this, it's up to mod makers.
Well could it be added back as a toggable option?
I could return it back relatively easily, but I'd rather fix huge technical debt which prevents further development. And that's much easier said than done.
-
RA scans target's hitbox, which differs for enemies. For example, there could be situation where you could see muton behind a stone wall but couldn't see sectoid which stands next to it. Their width differs too. But the issue with small creatures is their hitboxes could be much larger then sprite image. I couldn't help with this, it's up to mod makers.
But would it matter in the open without cover? For instance a 1M target and a 0'5M target being shot, the latter would be presenting a lesser are to be impacted upon. Or is just like normal OXCE where the shot will always lead towards the target heavily.
And understandable about tech debt, I would like maximun accuracy but there are ways for myself to get it by limiting possible accuaracy on itself.
-
But would it matter in the open without cover?
No and yes. At the early stage of development I've made a decision not to take unit size into account (excluding 2x2 units), for a couple reasons. First one is their size differs A LOT, for example muton is x1.5 or even x2 larger than sectoid. This could've changed accuracy numbers a lot too, and I've considered that was too big of a change, especially for old xcom playerbase.
But. Cover is much more beneficial for smaller units, cause of its relative size. Even small grass counts as cover, and for muton it could reduce its visibility to 97%, but for something as small as rats, it could be 80-85% And grass is everywhere, you could even consider it as "totally open field")) Small sectoids could hide behind small covers more effective than mutons, too.
-
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.
-
And another OXCE test. A well-aimed shot from a distance of 27 cells. The declared accuracy of the game is 86%
Your claim that the shelter is only 5% effective is not true. If only 5% of bullets hit an obstacle, it does not mean that the chance of hitting the target is reduced by 5%.
It can be seen from the test that it becomes about 2 times more difficult to hit the target.
-
All tests were made in standart OXCE (not BAI/RA).Visibility/Cover percentages were measured in BAI/RA afterwards.
One could think that cover works at least sometimes, at least to some extent. Actually, it doesn't. Cover works, when shot hits it instead of target, in front of it. That's when cover works as, well, COVER. That wasn't true for almost 80% misses - most of them flew by. Unfortunately, i haven't count them, but they are way more than half of all the misses.
There is a correlation between cover percentage and missed shots, sure, especially for high objects density. But those shots not only don't hit any cover, they are incredibly insufficient to use them to a tactical advantage. Even extremely 95% covered unit will be hit with every seconds aimed shot.
UPD:
Flipbard, I'm not interested to continue this discussion. I jsut don't care.
-
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.
-
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 ))
-
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.
-
You probably meant "no LOS" check?
Nope. I checked that in debugger - there was no penalty.
-
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.
-
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)
-
It may be worth testing by disabling this option.
-
It may be worth testing by disabling this option.
It does nothing in case there's a line of sight fire
-
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.
-
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.
-
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)