# UnitMotion - account for target's movement in ComputeTargetPositionClosedPublicActions

Authored by wraitii on Jun 16 2019, 10:17 AM.

# Details

Reviewers
None
Group Reviewers
 Restricted Owners Package (Owns No Changed Paths)
Commits
rP22431: UnitMotion - account for target's movement in ComputeTargetPosition (improve…
Summary

With the UM changes, units sometimes chase/flee forever.
The reason for this is that the chasing unit tries to move in-range to the entity correctly, but the entity is also moving on the same turn. So this might never get us in-range. To fix it, we need to account for possible movement of the target. The trick is that we need to account for twice the unit's movement - see below for an explanation of this.

This, combined with other revisions, returns Chasing/fleeing to an A23-like state.

With A Chasing B, it goes:

Turn N-1:
B moves to its position at N-1
A checks if it's in range to B. If yes - hit. If no, carry on.
A moves along its waypoint.
A checks if it will be in range to B at the end of its path. If not, it computes a path to B's position at N-1.
Turn N:
B Moves to its position at N.
A receives the path to B position's at turn N-1. It updates its waypoints.
A check if it's in range.
A moves to B's position at turn N-1.
A notices again that it won't be in range and computes a path to B at position N.
Turn N+1:
B Moves to its position at N+1.
A receives the path to B position's at turn N. It updates its waypoints.
A check if it's in range. [ it is currently at B's position at N-1, so no]
A moves to B's position at turn N.
A notices again that it won't be in range and computes a path to B at position N.
[goes on forever]

This is recursive, so actually describing turn N+1 is enough.
As you can see, if we try to add the current movement of B, we get (changes from above between italic brackets)
Turn N+1:
B Moves to its position at N+1.
A receives the path to B position's at turn [N+1]. It updates its waypoints.
A check if it's in range. [it is currently at B's position at [N], so no]
A moves to B's position at turn [N+1]
A notices again that it won't be in range and computes a path to B at position [N+2]

So we need to add the movement speed twice to make sure we actually move in position. This wouldn't happen if we computed a path synchronously before moving, but we don't want to do that.

Test Plan

Check out fleeing/chasins behaviour (NB: only works correctly if you also add D1983 in the mix)

# Diff Detail

Repository
rP 0 A.D. Public Repository
Lint
 Automatic diff as part of commit; lint not applicable.
Unit
 Automatic diff as part of commit; unit tests not applicable.

### Event Timeline

wraitii created this revision.Jun 16 2019, 10:17 AM

Successful build - Chance fights ever on the side of the prudent.

BTW, this could be changed if Move() was split in a pre-move, move, and post-move phase that all units went through sequentially.
It would then look like:
Turn N:
Pre-move:
A receives the path to B position's at turn N. It updates its waypoints.
A check if it's in range. [it is currently at B's position at [N-1] — which is now also what B is at, that's the difference with above — so yes]

Move:
B Moves to its position at N
A moves to B's position at N

Post-Move:
A notice it isn't in range. It computes a path to B's position + movement speed, aka B's position at N+1.

This would remove the need to multiply the movement speed by two.

wraitii updated this revision to Diff 8706.Jul 3 2019, 6:31 PM