Melee attack on a running target

[CoolleR]

Any attack on a running target in melee does not pass - the animation goes, but the damage is not applied. As a result, the rider can not kill him by running footman

[wraitii]

There is the same problem in some other cases, such as when a javeliner is attacked by a lion. It flees to some minimal distance, starts to shoot its javelin, and the lion catches up before the shot so the javeliner gets hit and inflicts no damage as it tries to regain some distance. It's sort of linked to the problem of two units with the same walking speed chasing each other possibly indefinitely.

The melee problem is at line 842 of UnitAI.js, it checks after the "Timer" if the attacker is still in range. Only the attacker stopped moving and the target not, so the attacker is out of range. Rinse, repeat. To fix this problem, we could either make the attacked unit stop, or allow a unit to attack while walking.

The javeliner problem is caused by the minimal range of the attack. The lion has gotten too close, so the javelineer moves away. Only the javeliner forgot to take into account that the lion moved too and that it should retreat way more. So he gets stuck in an infinite loop of dying. Fix for that would be to make the javeliner move farther away (javeliner aka any ranged unit, I mean). I might throw a patch for this, seems simple enough, while the melee one is trickier.

The infinite chase problem is because the units don't check they can outrun their target. "ShouldAbandonChase?" (line 2613) doesn't check for unit speed, when it really should. I'll try fixing that one as well.

[wraitii]

The attached patch should improve/fix the behavior of ranged units (aka the javelineer case above). I'm showing this more as a proof of concept/matter of discussion though, it may introduce weird behaviors I haven't thought of.

[historic_bruno]

I was looking at this problem a few weeks ago. I think it's more complicated than using speed difference alone, because we have to consider attack timings (how long does it take to prepare an attack?) There is a preparation speed for melee and ranged units, some of them like siege are very slow - up to 5 seconds! A low level component like CmpUnitMotion probably shouldn't know about attack speeds, but it should obviously be a part of determining point of attack. I was thinking maybe altering the min and max attack range to account for this but couldn't get a satisfactory solution.

It leads to another problem in the pathfinder, I don't think a unit can continuously pursue a target? There is a fixed target which is where the target was, and every time the pursuer reaches that target, it stops and if possible calculates a path to where the target is now. During the time the unit is stopped, the target gets farther ahead, which is ridiculous and would never happen in the real world. When units have similar speeds it's especially noticeable. We need to eliminate that delay.

One issue to think about for the future is different movement speeds like running and charging, and how these will impact the calculation. For now I guess it would be OK to work with the assumption of walking.

[historic_bruno]

Although thinking about it, the siege unit in pursuit is not a big deal because I think many or all siege units will not be mobile once we have packing and unpacking, and also their targets will often be static (structures). So that's an extreme case, but the timing concern still applies to other units.

I don't like the idea of making the target unit stop, but maybe temporarily slowing it down if the attack range check has succeeded wouldn't be a bad idea. It should likely be done not to an absolute speed but proportionally, so that an attacked and wounded cavalry unit would still have a chance to "outrun" a slow infantry unit.

[wraitii]

We discussed it with Deiz on IRC, and came up with this for the "estimation of by how much you should walk farther away": (anim time + aim time) * speed diff + (some small arbitrary number)

The problem is actually two-fold: fleeing enough to fire a shot while not being hit, and when chasing, chasing enough to have time to fire before the units goes away again (which might mean being ahead of the chased unit in some cases). Thisis valid for both melee and ranged units, but ranged units anims usually take longer.

The problem with chasing is that the units assume the enemy is not moving. I'm trying to fix by having the unit go to the "estimated interceptory point", but my fix will be pretty basic.

[FeXoR]

I don't think this will always help since the (ranged) unit to attack can (will if trying to get the min dist to the attacking melee unit) move the other direction if the melee unit gets to the "estimated" position on the other side of the ranged unit. I said this quite often a long time ago but I will say it again once in a while. And now it's time, sorry!

No non-siege unit should have a min range > 0. This is more realistic AND avoids such problems. If you feel it's really needed you could use another animation in this case (as if archers would use a dagger or Javelins don't throw their weapon) but the damage does not need to wary for this (indeed other problems/strangenesses arise when the melee damage can be smaller than the ranged attack).

Melee units attacks should deal the damage VERY EARLY during the attack animation (despite the actual time the hit takes place visually) OR melee units range should only be checked when starting the attack, not when they are actually dealing the damage. Both solution solve the problem by "unlinking" visual and actual damage dealing.

Unit AI should not try to do the job of the player. So ranged units should not flee and melee units should not focus ranged units/siege engines far behind other enemy units that might be considered less optimal targets, because: That "try to be efficient" approach in a global scale is very inefficient! They simply deal less damage in both cases.

Similar problems will arise when attack priority is added so please think this through before applying it...

This issue is somehow connected to #1010.

[k776]

Backlogged until a decision is reached about how best to fix this.