epic/OpenRA
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Introduce MoveCooldownHelper to prevent lag spikes from failed pathfinding

Browse Source 
Several activities that queue child Move activities can get into a bad scenario where the actor is pathfinding and then gets stuck because the destination is unreachable. When the Move activity then completes, then parent activity sees it has yet to reach the destination and tries to move again. However, the actor is still blocked in the same spot as before and thus the movment finishes immediately. This causes a performance death spiral where the actor attempts to pathfind every tick. The pathfinding attempt can also be very expensive if it must exhaustively check the whole map to determine no route is possible.

In order to prevent blocked actors from running into this scenario, we introduce MoveCooldownHelper. In its default setup it allows the parent activity to bail out if the actor was blocked during a pathfinding attempt. This means the activity will be dropped rather than trying to move endlessly. It also has an option to allow retrying if pathfinding was blocked, but applies a cooldown to avoid the performance penalty. For activities such as Enter, this means the actors will still try and enter their target if it is unreachable, but will only attempt once a second now rather than every tick.

MoveAdjacentTo will now cancel if it fails to reach the destination. This fixes MoveOntoAndTurn to skip the Turn if the move didn't reach the intended destination. Any other derived classes will similarly benefit from skipping follow-up actions.
This commit is contained in:
RoosterDragon
2024-04-07 15:02:53 +01:00
committed by Gustas
parent fe35c42ead
commit 2ed0656d1b
16 changed files with 239 additions and 47 deletions
Download Patch File Download Diff File Expand all files Collapse all files

14
OpenRA.Mods.Common/Activities/Move/Follow.cs
View File

@@ -23,10 +23,10 @@ namespace OpenRA.Mods.Common.Activities
readonly WDist maxRange;
readonly IMove move;
readonly Color? targetLineColor;
readonly MoveCooldownHelper moveCooldownHelper;
Target target;
Target lastVisibleTarget;
bool useLastVisibleTarget;
bool wasMovingWithinRange;
public Follow(Actor self, in Target target, WDist minRange, WDist maxRange,
WPos? initialTargetPosition, Color? targetLineColor = null)
@@ -36,6 +36,7 @@ namespace OpenRA.Mods.Common.Activities
this.maxRange = maxRange;
this.targetLineColor = targetLineColor;
move = self.Trait<IMove>();
moveCooldownHelper = new MoveCooldownHelper(self.World, move as Mobile) { RetryIfDestinationBlocked = true };
// The target may become hidden between the initial order request and the first tick (e.g. if queued)
// Moving to any position (even if quite stale) is still better than immediately giving up
@@ -57,12 +58,9 @@ namespace OpenRA.Mods.Common.Activities
useLastVisibleTarget = targetIsHiddenActor || !target.IsValidFor(self);
// If we are ticking again after previously sequencing a MoveWithRange then that move must have completed
// Either we are in range and can see the target, or we've lost track of it and should give up
if (wasMovingWithinRange && targetIsHiddenActor)
return true;
wasMovingWithinRange = false;
var result = moveCooldownHelper.Tick(targetIsHiddenActor);
if (result != null)
return result.Value;
// Target is hidden or dead, and we don't have a fallback position to move towards
if (useLastVisibleTarget && !lastVisibleTarget.IsValidFor(self))
@@ -77,7 +75,7 @@ namespace OpenRA.Mods.Common.Activities
return useLastVisibleTarget;
// Move into range
wasMovingWithinRange = true;
moveCooldownHelper.NotifyMoveQueued();
QueueChild(move.MoveWithinRange(target, minRange, maxRange, checkTarget.CenterPosition, targetLineColor));
return false;
}