fix(GotrPlugin): stop idle stalls in Guardians of the Rift (v1.5.6)#484
Open
runsonmypc wants to merge 2 commits into
Open
fix(GotrPlugin): stop idle stalls in Guardians of the Rift (v1.5.6)#484runsonmypc wants to merge 2 commits into
runsonmypc wants to merge 2 commits into
Conversation
The plugin would stand idle mid-game. Three root causes, all addressed:
- Query-API migration dropped auto-walk: `cache.query().interact(id, action)`
clicks at the player's tile and does not walk into range, so any
out-of-range object interaction silently no-ops every tick. Route object
interactions through a walk-first helper that web-walks when >51 tiles
away and hands off to click-to-walk once close (restores legacy behaviour).
- repairCells() locked the loop: it looked up the shield pylons by a name
filter (`contains("cell_tile")`) that never matches a real object name, so
the query was always empty, yet the method returned true unconditionally.
That short-circuited the main loop at `if (repairCells()) return;` on every
tick whenever a powered cell was held, leaving the bot frozen until the next
game start. Match pylons by object id via CellType.GetShieldTier, and only
return true when a cell is actually placed/used.
- Static state leaked across plugin restarts; reset it in run() so a restart
behaves like a first start. Also removed a per-tick blanket
Rs2Walker.setTarget(null) that churned the walker and spammed the log.
Verified live: full mine -> craft -> portal -> craft cycle with no stalls,
including while holding a powered cell. Bump version to 1.5.6.
Runes were only deposited from the !shouldMineGuardianRemains (crafting) branch. When a round ends the chat handler sets shouldMineGuardianRemains = true, so the loop switches to the mining branch and waitingForGameToStart() intercepts the between-rounds lobby tick entirely -- the deposit call was never reached and runes carried into the next round. The !isFull guard also skipped depositing a full inventory of crafted runes (the typical end-of-round state). - depositRunesIntoPool(): drop the !isFull and !optimizedEssenceLoop guards that suppressed depositing, and make it freeze-safe -- return true only when the deposit pool actually exists (walk-first toward it / click it), else return false so the loop never locks up holding runes. - waitingForGameToStart(): deposit any held runes before prepping/mining for the next game, so end-of-round runes are banked reliably. Bump version to 1.5.7.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Fixes the Guardians of the Rift plugin standing idle mid-game. Three root causes, all in the plugin (
GotrScript.java), version bumped to 1.5.6.1. Query-API migration dropped auto-walk
cache.query().interact(id, action)resolvesnearestReachable()and clicks at the player's current tile — it does not walk into range (unlike legacyRs2GameObject.interact, which web-walked when >51 tiles away). After the migration, any out-of-range object interaction silently no-ops every tick and the bot just stands there.Object interactions now go through a walk-first helper that web-walks when far and hands off to click-to-walk once close.
2.
repairCells()locked the whole loopIt looked up the shield pylons with
o.getName().toLowerCase().contains("cell_tile"), but the real pylon objects (GOTR_CELL_TILE_TIER1..4) aren't named that — so the query was always empty — and the method stillreturn trued unconditionally. That short-circuited the main loop atif (repairCells()) return;on every tick whenever a powered cell was held, freezing the bot until the next game start.Now matches pylons by object id via
CellType.GetShieldTier, and returnstrueonly when a cell is actually placed/used (otherwise falls through so the loop can craft).3. Static state leaked across restarts
Reset the static state machine in
run()so a re-enable behaves like a first start. Also removed a per-tick blanketRs2Walker.setTarget(null)that churned the walker and spammed the log.Testing
Ran live against a local 2.6.5 client. Full mine → craft essence → portal → craft → power-up cycle with no stalls, including the previously-fatal case of holding a powered cell while inventory fills with essence. 0 exceptions, no multi-minute silent gaps.
Scope
Plugin-only:
GotrScript.java+GotrPlugin.java(version 1.5.6). No build/infra changes.