Conversation
|
Important Review skippedAuto incremental reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
WalkthroughThis PR bumps the version to 2.5.6 and refactors two key gameplay systems. VirtualMouse extracts natural mouse movement eligibility into a reusable Possibly related PRs
🚥 Pre-merge checks | ✅ 3 | ❌ 2❌ Failed checks (2 warnings)
✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. 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. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
runelite-client/src/main/java/net/runelite/client/plugins/microbot/util/walker/Rs2Walker.java (1)
1423-1429:⚠️ Potential issue | 🟠 Major | ⚡ Quick winNormalize blacklisted door coordinates before lookup.
sessionBlacklistedDoorsis populated withprobe, which is already instance-normalized, but the guard at Line 1425 still checks the raw path tiles. In instanced areas that means the blacklist never matches and the same quest-locked door can be retried indefinitely.Possible fix
- // Skip any door whose tile was blacklisted after a prior quest-lock detection — - // avoid re-triggering the same failed interact loop this session. - WorldPoint skipFrom = path.get(index); - WorldPoint skipTo = index + 1 < path.size() ? path.get(index + 1) : null; + boolean isInstance = Microbot.getClient() + .getTopLevelWorldView() + .getScene() + .isInstance(); + + // Skip any door whose tile was blacklisted after a prior quest-lock detection — + // avoid re-triggering the same failed interact loop this session. + WorldPoint skipFrom = isInstance + ? Rs2WorldPoint.convertInstancedWorldPoint(path.get(index)) + : path.get(index); + WorldPoint skipTo = index + 1 < path.size() + ? (isInstance + ? Rs2WorldPoint.convertInstancedWorldPoint(path.get(index + 1)) + : path.get(index + 1)) + : null; if (sessionBlacklistedDoors.contains(skipFrom) || (skipTo != null && sessionBlacklistedDoors.contains(skipTo))) { return false; } List<String> doorActions = List.of("pay-toll", "pick-lock", "walk-through", "go-through", "open"); - boolean isInstance = Microbot.getClient() - .getTopLevelWorldView() - .getScene() - .isInstance();Also applies to: 1438-1445, 1565-1569
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In
`@runelite-client/src/main/java/net/runelite/client/plugins/microbot/util/walker/Rs2Walker.java`:
- Around line 2262-2265: The current logic in handleTransports exits immediately
when handleObject(transport, object) returns false, so the logged "retrying"
path never actually retries; change the control flow so that transient/miss
results from handleObject do not cause an immediate return from
handleTransports. Concretely, update handleObject (or its callers) to
distinguish fatal failures vs transient "retry" outcomes (e.g., boolean -> enum
or set a transport.retry flag) and in handleTransports, when a transient/retry
result is detected after prepareTransportObjectForInteraction(object), do not
return false—instead continue to the retry/fallback logic (allow the second
attempt or trigger candidate rescanning for stairs/ladder/trapdoor) so the retry
path logged around the transport handling is actually executed. Ensure the same
change is applied to the analogous branch around the code that logs "retrying"
(the 2325–2328 area) so both retry paths behave consistently.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: 90cc6789-6c6c-4737-8371-d3ce6e239145
📒 Files selected for processing (3)
gradle.propertiesrunelite-client/src/main/java/net/runelite/client/plugins/microbot/util/mouse/VirtualMouse.javarunelite-client/src/main/java/net/runelite/client/plugins/microbot/util/walker/Rs2Walker.java
| prepareTransportObjectForInteraction(object); | ||
| if (!handleObject(transport, object)) { | ||
| return false; | ||
| } |
There was a problem hiding this comment.
The new transport “retry” path never retries.
At Line 2326 the code logs retrying, but handleObject() returns false immediately, and Line 2263 then exits handleTransports() on the first miss. That means no second attempt and no fallback candidate scan for a required stair/ladder/trapdoor interaction.
Possible fix
- if (!started) {
- log.debug("[Walker] {} transport click on {} produced no movement/animation; retrying",
- transport.getAction(), tileObject.getId());
- return false;
- }
+ if (!started) {
+ log.debug("[Walker] {} transport click on {} produced no movement/animation; retrying",
+ transport.getAction(), tileObject.getId());
+ Rs2GameObject.interact(tileObject, transport.getAction());
+ started = sleepUntil(() -> Rs2Player.getWorldLocation().getPlane() != z
+ || Rs2Player.isMoving()
+ || Rs2Player.isAnimating(), 1800);
+ if (!started) {
+ return false;
+ }
+ }Also applies to: 2325-2328
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In
`@runelite-client/src/main/java/net/runelite/client/plugins/microbot/util/walker/Rs2Walker.java`
around lines 2262 - 2265, The current logic in handleTransports exits
immediately when handleObject(transport, object) returns false, so the logged
"retrying" path never actually retries; change the control flow so that
transient/miss results from handleObject do not cause an immediate return from
handleTransports. Concretely, update handleObject (or its callers) to
distinguish fatal failures vs transient "retry" outcomes (e.g., boolean -> enum
or set a transport.retry flag) and in handleTransports, when a transient/retry
result is detected after prepareTransportObjectForInteraction(object), do not
return false—instead continue to the retry/fallback logic (allow the second
attempt or trigger candidate rescanning for stairs/ladder/trapdoor) so the retry
path logged around the transport handling is actually executed. Ensure the same
change is applied to the analogous branch around the code that logs "retrying"
(the 2325–2328 area) so both retry paths behave consistently.
2 participants
webwalker fixes