Rs2Walker: partial-path logic has no upper bound — accepts 7000+ tile gaps as 'partial'

[runsonmypc]

Summary

Rs2Walker.processWalk accepts any pathfinder result as a "partial path" regardless of how far the path's endpoint is from the requested target. This makes clearly-unreachable targets waste ~60 seconds in retry loops (see #1) instead of failing fast.

Location

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

boolean partialPath = false;
if (dst == null || dst.distanceTo(target) > distance) {
    if (path != null && path.size() > 1) {
        log.info("[Walker] Path endpoint {} is {} tiles from target {}, walking partial path ({} tiles)",
                dst, dst.distanceTo(target), target, path.size());
        partialPath = true;
    } else {
        setTarget(null);
        return WalkerState.UNREACHABLE;
    }
}

The only guard is path.size() > 1. A pathfinder endpoint 7000 tiles from target is still treated as "partial."

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 (11303,9117,plane=1), walking partial path (557 tiles)

Target (11303, 9117, plane=1) has coords outside normal OSRS ranges (x should be roughly 1200–3800). Endpoint is 7411 tiles away. The walker still accepts it as partial, commits to walking, then gets stuck in the plane-change retry loop (#1).

Expected

If the pathfinder's best reachable tile is clearly not close to the requested target (e.g. thousands of tiles away), fail fast with UNREACHABLE rather than attempt the walk. The current "always try" policy makes bad callers expensive.

Suggested fix

Add an upper-bound sanity check on the endpoint gap:

static final int MAX_PARTIAL_PATH_GAP = 2000;  // tuning knob

boolean partialPath = false;
if (dst == null || dst.distanceTo(target) > distance) {
    int gap = dst == null ? Integer.MAX_VALUE : dst.distanceTo2D(target);
    if (path != null && path.size() > 1 && gap <= MAX_PARTIAL_PATH_GAP) {
        log.info("[Walker] Path endpoint {} is {} tiles from target {}, walking partial path ({} tiles)",
                dst, gap, target, path.size());
        partialPath = true;
    } else {
        log.warn("[Walker] Target {} is unreachable (endpoint={} gap={}); giving up", target, dst, gap);
        setTarget(null);
        return WalkerState.UNREACHABLE;
    }
}

MAX_PARTIAL_PATH_GAP = 2000 is conservative — the longest legitimate run across the overworld is maybe 1000 tiles; a 2000-tile gap is almost certainly a bad target (instance-template coords, malformed WorldPoint, etc.).

Use distanceTo2D so plane mismatches don't trigger Integer.MAX_VALUE here either.

Related

• Rs2Walker: partial-path retry loop spins for ~1min when plane changes mid-walk (Integer.MAX_VALUE finalDist) #1 (plane-change retry spin) — this issue is the trigger; Rs2Walker: partial-path retry loop spins for ~1min when plane changes mid-walk (Integer.MAX_VALUE finalDist) #1 is the amplifier.
• QuestScript: multiple unchecked getDefinedPoint().getWorldPoint() calls throw NPE through EventBus #3 (QuestHelper hands the walker instance-template coords (11303,9117,plane=1)) — the source of the bad targets we observed.