[Bug] Damage display when holding alt key

[Delian]

When you're aiming at an enemy and have a crosshair shown, you can hold the alt key to display the possible damage range. It's possible that the displayed damage is incorrect if the weapon has a "Power reduction/tile" rule. This probably happens because the calculated distance is rounded precisely, instead of rounded up, like the game normally does with distances.

For instance, let's say a weapon has a powerRangeThreshold of 10 tiles and you're x=10 and y=1 distance away from the target. Normally, the game would consider this as a distance of 11m (10.05m rounded up). If you hold the alt key, the displayed damage will be reduced by 1x powerRangeReduction. However, according to my tests, the actual damage is not reduced.

I'm assuming that the distance is rounded correctly so that melee weapons with 1 range can function correctly on targets vertically (x=1,y=1) 1 tile away. That's fine, but then, the displayed crosshair damage should take this correct rounding into account, which it currently does not.

[Meridian]

When you're aiming at an enemy and have a crosshair shown, you can hold the alt key to display the possible damage range. It's possible that the displayed damage is incorrect if the weapon has a "Power reduction/tile" rule. This probably happens because the calculated distance is rounded precisely, instead of rounded up, like the game normally does with distances.

Wrong. The calculated distance (for the alt display) is rounded up:

Code: [Select]

int distanceSq = action->actor->distance3dToPositionSq(Position(itX, itY,itZ));
int distance = (int)std::ceil(sqrt(float(distanceSq)));


For instance, let's say a weapon has a powerRangeThreshold of 10 tiles and you're x=10 and y=1 distance away from the target. Normally, the game would consider this as a distance of 11m (10.05m rounded up). If you hold the alt key, the displayed damage will be reduced by 1x powerRangeReduction. However, according to my tests, the actual damage is not reduced.

Ruleset is in tiles.
Alt display calculates in tiles.
Actual power reduction calculation is in voxels (exact projectile trajectory length).

Since display is rounded up to whole tiles, there can be a difference at the end.

I'm assuming that the distance is rounded correctly so that melee weapons with 1 range can function correctly on targets vertically (x=1,y=1) 1 tile away. That's fine, but then, the displayed crosshair damage should take this correct rounding into account, which it currently does not.

Melee weapons don't use power reduction at all.
"Projectile trajectory length" is zero both in straight and diagonal direction.

If you meant ranged weapons with range 1, it works the same way as for any other range, there is no special case handling.

[Delian]

Wrong. The calculated distance (for the alt display) is rounded up:

Ah, sorry, yes, that's what I meant. When holding the alt key, it uses a rounded-up distance. (I never liked this rounding up heh)

Still, the problem remains. The alt-displayed damage isn't correct. Something must be terribly wrong if the amount of voxels travelled (optimal path) produces a distance that is less than the one used for alt-display. Because that would imply that the visible distance can be greater than the actual distance, which logically doesn't make sense since the visible distance should be the shortest distance to the enemy. But even if we ignore this logical conundrum, the alt-displayed damage should still do a better job trying to estimate the damage. It should try to use the voxel distance instead of the visible distance then.

If you meant ranged weapons with range 1, it works the same way as for any other range, there is no special case handling.

What's that stuff in the Mod/RuleItem::isOutOfRange() then?

Yeah, some melee weapons are disguised ranged weapons.

[Meridian]

Ah, sorry, yes, that's what I meant. When holding the alt key, it uses a rounded-up distance. (I never liked this rounding up heh)

Still, the problem remains. The alt-displayed damage isn't correct. Something must be terribly wrong if the amount of voxels travelled (optimal path) produces a distance that is less than the one used for alt-display. Because that would imply that the visible distance can be greater than the actual distance, which logically doesn't make sense since the visible distance should be the shortest distance to the enemy. But even if we ignore this logical conundrum, the alt-displayed damage should still do a better job trying to estimate the damage. It should try to use the voxel distance instead of the visible distance then.

In worst case, the difference can be almost 2 whole tiles.
On the attached picture, the trajectory is ~10.1 tiles long (real length), and 12 tiles long (in tile math).

Anyway, everything is as designed, there is no bug.
If the display approximation bothers you, feel free to implement a crosshair that targets voxels instead of tiles; or just go vanilla and don't use it

What's that stuff in the Mod/RuleItem::isOutOfRange() then?

It's used for something else.

If you found the method, I'm sure you can find where it's used too

[Delian]

Meh, I don't have C++ dev environment installed.

Ok. Hmm, is there a case where you actually need the voxel distance? Like, you said that the actual distance is the voxel distance. But would it cause any problems if this was changed into a simple tile distance? Tile distance between the attacker and the tile in which the projectile landed? Or, if the tile distance was used only for the purpose of calculating the range-reduced damage? It's not a vanilla feature anyway.

[Meridian]

Meh, I don't have C++ dev environment installed.

Ok. Hmm, is there a case where you actually need the voxel distance? Like, you said that the actual distance is the voxel distance. But would it cause any problems if this was changed into a simple tile distance? Tile distance between the attacker and the tile in which the projectile landed?

Depends on person's definition/meaning of the word "problem".

Using tile distance instead of voxel distance would produce different results.
I personally don't care much in this case, but I guess nitpickers would call it a huge problem.

If I had to change it, I would add a config setting anyway... changing behavior without backwards-compatibility would just make modders go after me with torches and pitchforks.

[Delian]

I've done a few more tests and I've come to a conclusion that... using voxel distance is bugged.

For instance, my distance from the enemy is x=10, y=26. So tile distance is 27.86. But the voxel distance? 30. So first the distance was smaller, but in this case it's larger?

would just make modders go after me with torches and pitchforks.

I'm pretty sure no one actually tested this and they just assumed that tile distance was used.

[Meridian]

I've done a few more tests and I've come to a conclusion that... using voxel distance is bugged.

For instance, my distance from the enemy is x=10, y=26. So tile distance is 27.86. But the voxel distance? 30. So first the distance was smaller, but in this case it's larger?

How did you test voxel distance?
Using c++ dev environment? (I can't think of any other way to test it atm)

If you give me a save and exact instructions how and what to reproduce, I can debug and explain what's going on in detail for that particular scenario.

However, I have to say that I am 99.9% sure it works correctly, and I am not looking forward to (likely) waste my time.

I'm pretty sure no one actually tested this and they just assumed that tile distance was used.

It was extensively tested by Yankes; and it was tested also by modders, for example in Piratez.

[Delian]

I tested it in game. I attached the savegame (piratez ver: v.M4.1.2 OXCE 7.4 10-Jan-2022) demonstrating the bug.

Use the soldier to attack the enemy (Megapol Wolfman hp=48 stun=47) with the Wand of Peace.
Expected result: enemy should be knocked unconscious
Actual result: no damage (enemy gets hit but the hit log registers it as a miss due to damage being less than 0)

The friendly unit has psiStrength: 73. Wand of Peace does 0.01 x psiStrength² damage. 0.01x73x73=53.29 (rounded to 53). So average damage is 53.
Tile distance to the enemy is 27.86->28 tiles. Wand of Peace has damage reduction of 3 per tile after 12. So at 28 tiles, the damage should be reduced by 16x3=48. After hit, the actual damage should be 2.5 - 7.5 (rounded to 2-7, as shown on the alt-key display; Wolfman has 175% CHARM res, so the actual final damage range should be 3.5-12.5 (rounded to 3-12)).

However, due to the "voxel distance" being 30, the actual damage is reduced by 18x3=54.

[Meridian]

I'll check tomorrow.

[Meridian]

Tile distance is ~27.86, rounded up to 28.

Projectile trajectory length is ~474 voxels (~29.625 tiles).
The attached text file contains all 409 voxels in the trajectory, with the contribution of each step and the subtotals.

[Delian]

So, it looks like the produced trajectory length is incorrect.

[Meridian]

So, it looks like the produced trajectory length is incorrect.

Dude, what's wrong with you?

The trajectory length is absolutely 100% correct, I gave you even the entire derivation of it... if you want, calculate and check it by hand.

[Meridian]

Here's a few examples to illustrate the difference between "distance between two points" and "trajectory length".

Hopefully it helps.

[Delian]

Thank you for the examples. I think the example of non-arcing weapons correctly shows the issue, but the arcing weapons and the waypoints weapons do not. I've attached an example for an arcing weapon (side view).

As you explained, there's a difference between a "distance between two points" and "trajectory length", I agree with this.
But what I'd like to point out is the difference between "precise trajectory" and "approximate trajectory". The approximate trajectory is trajectory that is approximated to voxels, but otherwise tries to follow the line/curve of the precise trajectory. You've already snown this on your non-arcing example, but just for the sake of clarity, I've attached an edit where I've rearranged the black lines so that we can easily see why the voxel-approximated trajectory length is longer than the simple distance between two points.
Anyway, what I'm trying to argue here is that, a projectile that follows a trajectory, the total distance that it travelled should come from the "precise trajectory" and not from the "approximate trajectory", even though the projectile was drawn following the approximate trajectory.
In case of an arcing trajectory, the distance should be the length of the precise trajectory curve (not the shortest distance). In case of waypoints, the distance should be the sum of line lengths between waypoint voxels.

If we return to the savegame I provided, the starting voxel is 200,207,18 and ending voxel is 359,614,15, right? In this case, the precise trajectory length would be the distance between these two voxels.
sqrt ( (359-200)² + (614-207)² + (15-18)² ) = 436.9657 -> 27.3104 tiles. But if we add up the lengths between voxels in the approximate trajectory, then we get a distance of 29.625 tiles.

Which distance is the correct one?
27.31 tiles of the precise trajectory?
27.86 tiles of the visible distance?
29.62 tiles of the approximate trajectory?

You've convinced me that the trajectory length should be used instead of the visible distance. But then, I think it should be the precise trajectory.
But why? Why should we use the length of the precise trajectory instead of the approximate trajectory? Well, that's because, to begin with, I think the main purpose of the "approximate trajectory" is for graphical drawing and for hit tests. It was never supposed to have been used to measure any distance, because, as an approximation, it can produce weird results.