Shooting accuracy (again)

[jnarical]

Previous topic is here:
https://openxcom.org/forum/index.php?topic=7699

Hi. Last week I was working on alternative Projectile::applyAccuracy() implementation, and I'm pretty happy with the result.

Here's a video comparison:

Spoiler:

I've made a accuracy simulation program (with the help of Gemini 2.5 Pro) which I used for tuning new code to match with vanilla in terms of hit chances. The result which I get with this program - match with numbers I found here:
https://www.ufopaedia.org/index.php/Firing_Accuracy_Testing

Here's an example of using accuracy simulation tool:

Spoiler:

I'll attach last version of this script here under terms of WTFPL license, in case someone wants to tinker with it.

Vanilla accuracy rolls X/Y deviation independently, this gives square dispersion shape, which leads to inconsistency between shooting angles depending on shooting direction, and sometimes gives really wierd shooting angles. And dispersion itself feels unnatural. In a few words, with my algorithm, I turned dispersion square into a circle, moving "corners" to inner circle with lesser diameter, and modified dispersion to preserve vanilla hit-chances. Size of spread circles (outer and inner) is configurable, I set it to 0.8 from vanilla "square size" but it's my personal taste.

I've played like 9-10 games with and without new option and it seems all good. The difference isn't obvious immediately, but in the long run it's better, heavy cannons and autocannons start to be more useful. And I suppose it should be better with occassional suicides, due to extremely wierd shot angle when launching rocket from a window in vanilla accuracy.

I'd like to add this code to base OXC, but didn't make a PR as I'm not sure where to put this alternative option.
I've left the function at pastebin: https://pastebin.ubuntu.com/p/dSyhz7m9zD/

UPD: yellow dots mean Z-misses, when shot trajectory is below or above the target

[Yankes]

Right now I see that target unit and "aim points" are in same place, could you split this and see how accuracy will behave when you move "aim point" outside of unit?

[jnarical]

Right now I see that target unit and "aim points" are in same place, could you split this and see how accuracy will behave when you move "aim point" outside of unit?

If I get you right, it will behave the same way, the algorithm is "target-agnostic" as vanilla one. I use virtual "target" with diameter=7 and height=20 to measure % of hits, both for vanilla and new algorithm. No target data is used by algorithm itself.

Uploaded the commit: https://github.com/OpenXcom/OpenXcom/compare/master...narical:OpenXcom:alternative_accuracy

UPD: or do you want to know % of hits (to target) when targeting some other tile? Just wild guess...

[Yankes]

Yes, this is question I ask you previously, if you change "aim point" do it affect hit chance at given unit?

[ps]

For code `double realDistance = sqrt((double)(xdiff*xdiff)+(double)(ydiff*ydiff));`? Why could you not use 3d distance here?
Some mods have lot of vertical levels and if you shoot alien on top of skyscraper you probably have lot of spread even if on xy plane unit is 2 tiles away.

[Meridian]

I'd like to add this code to base OXC, but didn't make a PR as I'm not sure where to put this alternative option.

As far as I know, OXC doesn't accept any changes anymore.
It's in just-necessary-maintenance mode.

For OXCE, I'll check this when I'm back at home (in 2 weeks).

[jnarical]

Yes, this is question I ask you previously, if you change "aim point" do it affect hit chance at given unit?

Change to where, exactly? To another voxel of the same unit, or to a different tile? In a former case, maybe you're right and chance to hit will change, due to "artificial" shape of dispersion cloud. There are two groups of additional dispersion, placed at both sides of a target. If you move target point to side voxel of a unit - one of those groups will overlap with it, slightly increasing chances to hit. I didn't think about it, but it's trivial to fix, just by moving additional dispersion slightly away from target point. Now it's 4 voxels away, and targeting rightmost side of a unit will make left additional dispersion overlap unit by 3/7 of its width (if if has 7 voxel diameter). That's not a big deal to me, I doubt it'll increease chance to hit even by 1%. And if we move those side dispersion clouds away by 7 voxels, this won't be the issue at all.

On the other hand, if we're talking about changing target to another tile - of course chance to hit previous one will change. I don't get the question, honestly. By how much chances will change? I mean, just look at dispersion shape. Compared to vanilla, overall area is smaller, the density of points is higher, and chances to hit something in the general direction of fire is higher, compared to vanilla. But that's the whole point right? To change most wierd and unnatural "corner" shots to a more natural?

UPD: new algorithm will increase chances against big units. To me, that's desireable outcome, cause it feels fair compared with "why you're shooting in 45 degree direction of that cyberdisk you idiot ?!" feeling from vanilla

For code `double realDistance = sqrt((double)(xdiff*xdiff)+(double)(ydiff*ydiff));`? Why could you not use 3d distance here?

That's the code written 10-12 years ago, based on code written 30+ years ago. My goal wasn't to rewrite it entirely (you guys aren't particulary fond of approving massive changes as I learned). The goal was to add this option: change the 2D shape from square to circle, and change dispersion inside that circle to a one that "feels" more natural. Keeping real odds of hitting a target as close to old algorithm as possible. This approach won't fix other flaws of old code.

It could be improved tho, taking into account Z distance compared to distance on XY plane. I could see easy bandaid solutions rigth away.

For OXCE, I'll check this when I'm back at home (in 2 weeks).

Ok, thanks! I'll include this "fix" into BOXCE and ask people to test it.

[Yankes]

I more curious how it will behave if target other tiles behind. Reason I as this because if we had "super super duper realistic" accuracy this should not affect final number of trajectories that could hit given target. When I looked on original code I had some doubts if its behave this way. And your version if is approximate bell curve correctly it should behave same independently how far you set targeting tile relative to target unit.

I tried run your python script but its seems its not compatible with cygwin I use (probably its package system fault as some qt packages did not want to work correctly).
Because of this I can't check this myself (and I not curious that much to install full windows python ).

btw could you show graph of density on orthogonal plane to main trajectory? Like you shoot from voxel (0,0) to voxel (0, 100) and you check how many trajectories hit voxel (X, 100) where X is from -100 to 100, this will be bit better to analysis as is bit hard to see density by number of lines or dots

[jnarical]

Script is using some libraries of course (listed in first lines of it), like PyQt6, numpy etc. It's pretty easy to make it work under linux. Didn't try with Windows (doesn't have any) so couldn't help with that.

I think I got what you're trying to say. Dispersion in its current form isn't uniform, for a reason. Imagine circle inscribed into square. Difference between their areas is ~21.5%, and hitting those corner areas (in vanilla) is most probably a miss. I move those "corners" inside the smaller inner circle, and if I don't care about their uniform round dispersion - I turn a good share of those 21.5% dispersion area from misses to hits, and that increases hit-chances against the vanilla. That's where those two side dispersion blobs came from.

But this could lead to scenario, where shooting a tile near a target could give better chances to hit it, which I (of course) don't like.
I could make a uniform arc from those corners, but the price is increased hit-chances compared to vanilla for close-range (1-5 tiles) scenarios. That could be countered by other means.

That way, it would be honest uniform (in terms of relative distribution density at different angles) simulation. Or, in another words - overall dispersion angle is constant for set accuracy, for any range. I've just checked that, it's the same for distances from 3 to 50 tiles, almost the same for 2 tiles, more for 1 tile. Attached 5 vs 25 tiles distance comparison (for same 20% accuracy). Points have different scale (and there's different number of them), and additional "arc" has fixed width in voxels (~4) but other than that, the dispersion looks absolutely the same.

UPD: of course, there are much more Z-misses for longer distance

[Yankes]

Ok, its look good for me.

> I could make a uniform arc from those corners, but the price is increased hit-chances compared to vanilla for close-range (1-5 tiles) scenarios

I would go with this, but probably behind mod options (not "user option" as it affect balance).

[jnarical]

I would go with this, but probably behind mod options (not "user option" as it affect balance).

That's why I made a dedicated tool and spent several days making new code matching with the old one. For this new option to be included and available to players, with "chances to hit are unaffected" in the description.

To be honest, it'll change balance even with hit chances perfectly matched. Most of those rockets and HE ammo which flew away at 45 degrees - now will go in the target's direction. But that feels great and not unfair/unrealistic how it used to be... Idea of making this code into the game without user option to enable it makes me extremely sad.

As long as I started to make my own Realistic Accuracy mod more then a year ago, and got first working prototypes - I played OXC only with "fixed" accuracy. Of course there were bugs, balance changes, the whole thing was changed several times... but I totally forgot how base OXC/E feels. And when I tested my new algorithm we're talking about, and played several games with vanilla accuracy (to compare how it feels) - well, memories returned. I couldn't bear "classic" algorithm anymore, the amount of frustration it gives just kills all the positive feelings from other aspects. You take 2 big rockets on mission, and they both fly 45 degrees off-target and off-screen, without any splash damage - "hold your empty rocket launcher, hope you like it" ) This part of the game makes memes, people write emotional posts here on forum.

I made several charts to show the difference of two algorithms without corrections:
https://imgur.com/a/openxcom-vanilla-vs-new-accuracy-algorithm-JG3LQDR
I already changed algorithm, making that additional dispersion "arc" continuous!

UPD: btw this new algorithm doesn't have a single line in common with Realistic Accuracy mod. This is just modified vanilla code.

UPD: seems I found decent enough settings. The core issue was reduced outer diameter, that gives increased chances. Now chances match, more or less.