Rs2Walker: partial-path retry loop spins for ~1min when plane changes mid-walk (Integer.MAX_VALUE finalDist)

[runsonmypc]

Summary

When a walk crosses between planes (via fairy ring, ladder, teleport, etc.), the partial-path retry logic in Rs2Walker.processWalk gets stuck in a retry loop for ~60 seconds before giving up, because WorldPoint.distanceTo returns Integer.MAX_VALUE (2147483647) across planes and the retry-vs-arrive check treats that as "still far from target."

Location

runelite-client/src/main/java/net/runelite/client/plugins/microbot/util/walker/Rs2Walker.java, lines 461–477:

int finalDist = Rs2Player.getWorldLocation().distanceTo(target);
if (finalDist < distance) {
    setTarget(null);
    return WalkerState.ARRIVED;
} else if (partialPath) {
    if (partialRetries < 3) {
        log.info("[Walker] Walked partial path ({} tiles remaining), retrying from current position (attempt {}/3)",
                finalDist, partialRetries + 1);
        recalculatePath();
        return processWalk(target, distance, partialRetries + 1);
    }
    log.info("[Walker] Walked partial path, exhausted retries. final distance to target: {}", finalDist);
    setTarget(null);
    return WalkerState.UNREACHABLE;
}

WorldPoint.distanceTo(other) returns Integer.MAX_VALUE when this.getPlane() != other.getPlane(). After a fairy ring (or any transport) that changes the player's plane, finalDist == 2147483647, so finalDist < distance is always false, so it falls into else if (partialPath) and recurses up to 3 times.

Repro in live log

20:40:09 walkWithStateInternal: distToTarget=9817, target=(11303,9117,plane=1)
20:40:10 Path endpoint (3892,9702,plane=1) is 7411 tiles from target, walking partial path (557 tiles)
20:40:14 No longer near path
20:40:14 Walked partial path (2147483647 tiles remaining), retrying from current position (attempt 1/3)
20:40:15 processWalk: target=(11303,9117,plane=1)
20:40:34 Interacting with Fairy Ring @ (2658,3230,plane=0)   ← player now on plane 0
20:41:02 Walked partial path (2147483647 tiles remaining), retrying from current position (attempt 2/3)
20:41:05 walkWithStateInternal: distToTarget=96, target=(1587,3126,plane=0)   ← finally moves on, ~1 min later

2147483647 in the log is the Integer.MAX_VALUE tell. Partial paths legitimately can cross planes via transports, so the retry logic's plane-sensitivity is a bug, not a feature.

Expected

Either the retry recognizes the plane-change case as "player is somewhere different than expected — re-plan without spinning," or it uses a plane-agnostic distance metric to decide whether retry is worth it.

Actual

Retry fires 3×, each iteration doing a fresh recalculatePath() + full processWalk attempt. Walker appears frozen in-game for ~60 seconds.

Suggested fix

Smallest change: switch to distanceTo2D(target) at line 461 — plane-agnostic and semantically correct here since partial-path retries should care about "how far am I, as the crow flies, from the target" not "am I on the exact same floor."

int finalDist = Rs2Player.getWorldLocation().distanceTo2D(target);

Alternative (more defensive): handle Integer.MAX_VALUE explicitly:

int finalDist = Rs2Player.getWorldLocation().distanceTo(target);
if (finalDist == Integer.MAX_VALUE) {
    // plane differs; use 2D metric to decide
    finalDist = Rs2Player.getWorldLocation().distanceTo2D(target);
}

Related

• Bug Rs2Walker: partial-path logic has no upper bound — accepts 7000+ tile gaps as 'partial' #2 (partial-path accepts absurdly-far targets) is what triggers entering this retry loop in the first place; together they turn bad targets into 60s freezes.