fix(walker): stop opening shop doors beside the path#1811
Conversation
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.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
WalkthroughIn Possibly related PRs
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
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.javaThanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
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
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.
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.
purely by the catch-all -- a west-facing door while the path stepped north past it.
rejected the bug geometry 14 times; 8/8 walks arrived.
walk; 0 wall-door opens logged; 4/4 arrived.
and crosses through, 5/5.
MovingAway_returnsFalse and ..._crossingDoorEdge_returnsTrue.