Change Details

I think at some point in the rewrite the code that "handled" the target moving out of world got squished, so this kept units in moving state forever (see [[ https://wildfiregames.com/forum/index.php?/topic/25155-testing-pathfinder-update/page/4/&tab=comments#comment-378018 | here ]]). This fixes it. If ComputeTargetPosition become computationally expensive, it might be worth doing another check.

Previously, unitMotion had no code that checked particularly if the target was still in the world. When the target moved out of the world, unitMotion would follow the path to its last known position, then send a "MoveSucceeded" message because the "at destination" check would do that in the situation where the target was out of the world (because MoveToTargetRange fails). rP22364 moved code around and, in particular, no longer called "MovementSucceeded" when `PossiblyAtDestination` returned true (that must have been a mistake from a poor rebase). - this was a bug - rP22365 immediately fixed that state of affair by calling MovementSucceeded() when calling `PossiblyAtDestination`. This returned unitAI to its A23 state. rP22366 subsequently changed "PossiblyAtDestination" logic, in such a way that when the target of unit motion is moved out of the world, instead of returning true, it returns false (which is internally logical, but with consequences): This means that unitMotion will no longer send messages if the target is moved out of the world. Thus unit will follow its path to its last waypoint and stay there in its current state, unable to carry on. This was missed in rP22366, and thus requires fixing. This fixes that problem by explicitly checking . If ComputeTargetPosition become computationally expensive, it might be worth doing another check. Furthermore, this still changes behaviour from A23 (the entity will stop right where it is) - requiring D1992 to re-introduce A23 behaviour.

I think at some point in the rewrite the code that "handled" the target moving out of world got squishedPreviously, so this kept units in moving state forever (see [[ https://wildfiregames.com/forum/index.php?/topic/25155-testing-pathfinder-update/page/4/&tab=comments#comment-378018 | here ]]unitMotion had no code that checked particularly if the target was still in the world. When the target moved out of the world, unitMotion would follow the path to its last known position, then send a "MoveSucceeded" message because the "at destination" check would do that in the situation where the target was out of the world (because MoveToTargetRange fails). This fixes itrP22364 moved code around and, in particular, no longer called "MovementSucceeded" when `PossiblyAtDestination` returned true (that must have been a mistake from a poor rebase). - this was a bug - rP22365 immediately fixed that state of affair by calling MovementSucceeded() when calling `PossiblyAtDestination`. This returned unitAI to its A23 state. rP22366 subsequently changed "PossiblyAtDestination" logic, in such a way that when the target of unit motion is moved out of the world, instead of returning true, it returns false (which is internally logical, but with consequences): This means that unitMotion will no longer send messages if the target is moved out of the world. Thus unit will follow its path to its last waypoint and stay there in its current state, unable to carry on. This was missed in rP22366, and thus requires fixing. This fixes that problem by explicitly checking . If ComputeTargetPosition become computationally expensive, it might be worth doing another check. Furthermore, it might be worth doing another checkthis still changes behaviour from A23 (the entity will stop right where it is) - requiring D1992 to re-introduce A23 behaviour.