[Bug] Damage display when holding alt key

[Meridian]

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

For alt display of arcing weapons, the zig-zag trajectory "issue" is negligible, because the arc itself makes the length much longer than if it was just a straight line.
So the alt display is completely off anyway.

For waypoint weapons, it's even more visible, there you can shoot five times around the whole map and target yourself at the end... distance=zero, length="as long as you want".
The alt display is currently practically useless here if the weapon has range power reduction.

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.

It's really not simple.

At the point of impact, we don't have the "length of the precise trajectory" anymore.
And recalculating it from just the start point and the impact point is not straightforward... for example for arcing trajectories there is an unlimited number of parabolas between point A and B with different heights.
Also, there is RNG involved, we don't try all parabolas (obviously), just a few based on RNG... btw. that's why we can't predict trajectory length before we actually shoot.

And for alt display, there's yet more problems.
Even with having "precise trajectory" and even just considering straight line trajectories... the display just considers zero deviation... and no obstacles.
But the ideal trajectory (zero deviation) and the actual trajectory (with deviation) can easily be different.
Even two hits of the same tile/unit can have quite different results depending on whether you hit a unit at [0,0,0] or [15,15,23]... that's ~1.95 tiles difference! And for a 2x2 unit, the difference can be up to ~4.01 tiles.
And let's not even start with non-square tiles, we don't even have equal "distances" between all neighboring voxels... moving 16 voxels horizontally translates to moving 1 full tile, moving 16  voxels vertically translates to moving only ~0.666 tiles.


Bottomline:
1. in my opinion, the damage calculation is decent enough, serves the intended purpose and doesn't have bugs (i.e. works exactly as designed)
2. we could make a different one, but there's a LOT of things to consider... IMO not worth it
3. the alt display calculation is just a crude approximation given many limitations, some of which *cannot* even be worked around... it is objectively imprecise, but it's the best I can do

[Delian]

Well, let's say that alt-display works well enough. Let's forget about that.

I'm more worried about the distance calculation, since I personally think it's currently not precise enough for the range-reduced damage. But as you say, it would be too much work to make the calculation perfect for every case. Hmm.

Ok, I have two relatively simple propositions.

1. In the Projectile::getDistance() we're returning the calculated approximate trajectory distance used for range-reduced damage.
I propose that we add an if statement there, if it's a non-arcing projectile and without waypoints, then return a distance calculated from the first and the last voxel in the trajectory.

Code: [Select]

if (_action.type != BA_THROW && _action.type != BA_LAUNCH && !_trajectory.empty())
{
    return Position::distance(_trajectory[0], _trajectory[_trajectory.size() - 1]);
}
else
{
    return _distance;
}

2. In the Projectile::move(), we're adding up distance based on the last 1 voxel (either √1, √2 or √3).
I propose to increase accuracy of this by adding up distance based on the last 2 voxels. (half of the distance between the last two voxels)

Code: [Select]

if (_position > 1)
{
    _distance += Position::distance(_trajectory[_position], _trajectory[_position - 2]) / 2;
}
else
{
    _distance += Position::distance(_trajectory[_position], _trajectory[_position - 1]);
}


[Meridian]

For potential changes, Yankes will need to approve. (It's his feature.)

[Yankes]

I could agree to only second change aka, make distance step bit more accurate. First change is nogo as it not handle correctly arcing shots and make big difference between them and linear shots, especially when arcing shoot is very shallow.

[Meridian]

@Delian: Just to maybe clarify on point 1... "_action.type != BA_THROW" doesn't represent arcing shots. You can also have arcing shots for example on BA_SNAPSHOT and other actions.

[Delian]

Oops, sorry, you're right. The first proposition should be:

Code: [Select]

if (_action.type != BA_THROW && _action.type != BA_LAUNCH && !_action.weapon->getArcingShot(_action.type) && !_trajectory.empty())
{
    return Position::distance(_trajectory[0], _trajectory[_trajectory.size() - 1]);
}
else
{
    return _distance;
}


[Yankes]

Yes, but this is only half solution, bigger problem is that you can make very flat arc weapons, in theory they should have path distance close to strength line path distance, when we add this `if` we have two different values.

If we look now on circle and try measure distance from center using current code there are 8 points where `_distance` match 2d distance.
When we add this "avg" operation for each step, number of correct points is 16. And more importantly all other points have error reduced a lot.

I do not know if complicating further code is beneficial, especially if this `if` add more special cases.

[Delian]

bigger problem is that you can make very flat arc weapons, in theory they should have path distance close to strength line path distance, when we add this `if` we have two different values.

There's a hardcoded minimum parabola curvature value of 0.48, so I don't think you can make flat arc weapons. Arcing and non-arcing weapons will always have somewhat different distances, with or without the "if" statement.

Yes, it's only half of the solution, but wouldn't the full solution be difficult to implement?

I do not know if complicating further code is beneficial, especially if this `if` add more special cases.

It's your choice, but in my opinion, I don't think that adding the "if" statement there adds any complexity, because there's already plenty of code that handles arcing and non-arcing weapons in a different manner.

[Yankes]

Adding one `if` is indeed trivial, but you not see long term cost and increasing conceptual complexity.
Current answer for "what voxel distance is" is very very trivial `return _distance;`, no special cases, what value is we return it.
After your change answer will not be that trivial, and when I would like change handling of voxel trajectory I would need check this `if` to see if he
need updates too.
One of my goals in OXCE was remove `if` like this, I would even consider polynomial calculation of `_distance` than adding special cases.

[Yankes]

I pushed in new version update with:

Code: [Select]

_distance += Position::distance(_trajectory[_position], _trajectory[_position - 2]) / 2;
Save test case work fine now, enemy get stunned.

[Delian]

Thanks

Altho it may take a while until the next version of X-Piratez before I'm able to test it.

[Yankes]

You could replace exe, we recently did not do any big breaking changes and XPZ should work with new exe.

[Delian]

Where do I get the new exe?

[Yankes]

https://lxnt.wtf/oxem/#/Extended

[Delian]

k, works

thread can be closed