fix: hopToWorld guard rejects valid hops after interactions#1773
Conversation
Player.isInteracting() stays true for many seconds after benign actions (closing a shop, talking to an NPC, getting aggro'd) because the engine keeps the interaction pointer set until the player moves or combat resets. OSRS does not block hops in that state, but this guard did, causing plugins to spin on "Local player is interacting, cannot hop worlds" forever after Rs2Shop.closeShop() and similar flows. Replace the isInteracting() check with the conditions that actually block a hop: active combat (Rs2Combat.inCombat) and blocking widgets (Rs2Bank/Rs2Shop/Rs2Dialogue). Wilderness PvP timer remains server-enforced via client.hopToWorld(). Closes chsami#1772
|
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 updates Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 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 |
Global.sleep / sleepUntil early-return when invoked on the client thread, so the post-hop wait inside the runOnClientThreadOptional lambda was a no-op: the success check fired microseconds after issuing the request, before the server had processed it. The function returned false on every call, callers retried via sleepUntil polling, and Microbot.java logged "Failed to hop to world N" 3-4 times per actually-successful hop. Move the wait off the client thread. The lambda now only validates and issues the hop request. The script thread then sleeps and sleepUntils for HOPPING / world-change / confirm widget, handles the confirm-dialog fallback, and waits for the hop to fully land (GameState.LOGGED_IN on the target world) before returning. Success is reported as getWorld() == worldNumber, the definitive signal, so callers can trust the return value. Also: the "already on target world" guard now returns true (idempotent success) instead of false, killing the retry loop that triggered the spam on the second and subsequent calls. Closes chsami#1550
Summary
Microbot.hopToWorld(int)usedPlayer.isInteracting()as a safety guard, but that flag staystruefor many seconds after benign actions (closing a shop, talking to an NPC, getting aggro'd) because the engine keeps the interaction pointer set until the player moves / re-engages / combat resets. OSRS does not actually block hops in that state, so plugins were stuck retrying withLocal player is interacting, cannot hop worldsindefinitely afterRs2Shop.closeShop()and similar flows.isInteracting()check with the conditions that actually block a hop: active combat (Rs2Combat.inCombat()) and blocking widgets (Rs2Bank.isOpen(),Rs2Shop.isOpen(),Rs2Dialogue.isInDialogue()).client.hopToWorld()call — no change there. All other guards (isLoggedIn,isHopping,cantHopWorld,quickHopTargetWorld, world equality, world lookup,createWorld) are untouched.Closes #1772
Test plan
./gradlew :client:compileJavasucceeds (only pre-existing deprecation warnings).:client:runboots; client initializes normally.Rs2Shop.closeShop()(e.g. Blast Furnace foreman) — callMicrobot.hopToWorld(...)and confirm the hop proceeds instead of loggingLocal player is interacting.client.hopToWorld()).