Skip to content

fix(walker): stop opening shop doors beside the path#1811

Open
bgatfa wants to merge 1 commit into
chsami:developmentfrom
bgatfa:fix/walker-opens-nonblocking-doors
Open

fix(walker): stop opening shop doors beside the path#1811
bgatfa wants to merge 1 commit into
chsami:developmentfrom
bgatfa:fix/walker-opens-nonblocking-doors

Conversation

@bgatfa

@bgatfa bgatfa commented Jun 27, 2026

Copy link
Copy Markdown

What

The webwalker no longer opens closed doors that sit beside its path but don't
block it (e.g. shop doors on the Lumbridge net-fishing -> courtyard route).

Why

Users reported the walker opening shop doors -- like Bob's Brilliant Axes --
that are near the path but not blocking it, intermittently. handleDoors'
WallObject branch found a door via a 1-tile probe-adjacency fallback, then
validated it against the probe tile (not the door's real location) and, failing
that, accepted it via a pathTouchesBothEnds catch-all that ignored orientation.
So a door one tile off the route -- whose blocked edge the path never crosses --
was opened anyway.

How it works

  • The WallObject branch now calls isDoorOnSegment(object, fromWp, toWp), which
    walks the segment against the wall's actual blocked edge -- the same validator
    the GameObject branch and findDoorNearSegment already use. The probe-orientation
    check and the pathTouchesBothEnds shortcut are gone.
  • wallDoorTouchesSegment now derives the blocked neighbour from both orientationA
    and orientationB, so a legitimately on-path door advertising its edge on either
    orientation is still opened.

Testing

Reproduced live on the reported route (Lumbridge net-fishing 3241,3154 ->
courtyard 3222,3218, shop doors confirmed closed) with a diagnostic build logging
isDoorOnSegment ground truth.

  • Baseline (buggy): walker opened door (3234,3207) with onSegment=false, accepted
    purely by the catch-all -- a west-facing door while the path stepped north past it.
  • After the fix, 8-run diagnostic batch: 0 off-segment opens; the fix actively
    rejected the bug geometry 14 times; 8/8 walks arrived.
  • Collision-verified batch: door (3234,3207) stayed CLOSED before and after every
    walk; 0 wall-door opens logged; 4/4 arrived.
  • Regression guard (sole-passage door, Bob's): walker still opens an on-path door
    and crosses through, 5/5.
  • Rs2WalkerUnitTest passes, including wallDoorTouchesSegment_startingBesideDoorAnd
    MovingAway_returnsFalse and ..._crossingDoorEdge_returnsTrue.

handleDoors' WallObject branch validated a found door against the probe tile
instead of the wall's real location, then accepted any door through a
pathTouchesBothEnds catch-all. Since the probe-adjacency fallback can land a
tile off the wall, a closed shop door one tile beside the route -- e.g. doors
by Bob's Brilliant Axes on the Lumbridge net-fishing -> courtyard walk -- got
an Open interaction even though the path never crossed it. Intermittent, since
it depends on the smoothed segment geometry.

- Validate the wall's actual blocked edge against the segment via
  isDoorOnSegment, matching the GameObject branch and findDoorNearSegment;
  drop the probe-orientation check and the pathTouchesBothEnds shortcut.
- wallDoorTouchesSegment now derives the blocked neighbour from both
  orientationA and orientationB so an on-path door is never missed.
@coderabbitai

coderabbitai Bot commented Jun 27, 2026

Copy link
Copy Markdown
Contributor

Review Change Stack

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: 832977ae-e05b-48ee-8f03-9df8ea9d5e0a

📥 Commits

Reviewing files that changed from the base of the PR and between fd57cc1 and 13bed1c.

📒 Files selected for processing (1)
  • runelite-client/src/main/java/net/runelite/client/plugins/microbot/util/walker/Rs2Walker.java

Walkthrough

In handleDoors, the WallObject branch drops the prior orientation probe validation (orientationA/B, searchNeighborPoint, pathTouchesBothEnds) and instead calls isDoorOnSegment(object, fromWp, toWp) directly, matching the GameObject branch behavior. In wallDoorTouchesSegment, blocked-edge neighbor computation is extended from a single orientation-A neighbor to two neighbors (blockedNeighborA, blockedNeighborB), returning early only when both are null, and the stepping loop returns true if either neighbor matches the door-edge transition.

Possibly related PRs

  • chsami/Microbot#1775: Also modifies Rs2Walker door/wall handling, specifically changing how door probing is conditionally skipped during transport-related path edge resolution.
🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (4 passed)
Check name Status Explanation
Title check ✅ Passed The title clearly describes the main fix: preventing the walker from opening nearby shop doors that are beside, not on, the path.
Description check ✅ Passed The description accurately matches the code changes and explains the bug, fix, and testing in a way that is clearly related.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.

Warning

There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure.

🔧 ast-grep (0.44.0)
runelite-client/src/main/java/net/runelite/client/plugins/microbot/util/walker/Rs2Walker.java

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant