fix/alkharid-gate-wedge-and-death-skull #222
No reviewers
Labels
No labels
bug
ci-cd
client
epic:security-hardening
feature
optimization
priority:high
priority:low
priority:medium
server
No milestone
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
BlackLobster/Server!222
Loading…
Reference in a new issue
No description provided.
Delete branch "fix/alkharid-gate-wedge-and-death-skull"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Game.Bot.BankAccess (the staircase counterpart of GatePassage): a bank entry may carry ascent/descent staircase scripts ({loc_id, x, y, action, to_z}) and a floor_tile; the gatherer goals run an :bank_ascend pass before :banking and ALWAYS descend afterwards — including before a goal-completing deposit — because a bot left upstairs can never path a ground destination on its own (the coarse router is same-plane). Recovery deposits stay positionless by design. Lumbridge Castle's access script is cache-verified: 1738 ground Climb-up, 1739 middle (Climb-up 2 / Climb-down 3), 1740 top Climb-down; counter beside booth 18491 at (3208,3220,2). Two load-bearing fixes shaken out by the live run: - bot_interact_object is now a movement takeover: it cancels the streamed-path goal AND queued waypoints before queueing the click. A banker arriving off a streamed travel leg camped its staircase clicking forever — the queued object action waits for an empty walk queue that maybe_prefetch never allows, while the stream tug-of-wars the bot back toward its stale target. Also explains intermittent gate pay-click failures for bots arriving at the toll gate mid-stream. - @route_max_distance 64 -> 128: a partial route out of a walled compound (the castle courtyard) ends pressed against the interior wall nearest the goal instead of at the exit gate, and the bot paces there; the radius must cover compound-exit legs end to end (courtyard -> swamp completes at 102 steps).Four fixes shaken out by live long-leg testing of the Lumbridge climb, each caught by tracing a wedged bot on the test world: - BankAccess walks to a ground-truthed stand tile beside each staircase (steps now {id, x, y, action, to_z, stand_x, stand_y}) and only clicks once adjacent. A click cast from afar dispatches :too_far into the short-radius object approach, which silently pops the action beyond ~8 tiles (path_to_object -> []) while any still-live travel stream drags the bot away; adjacent clicks dispatch inline, deterministically. - maybe_build_route prefers a COMPLETE A* route (endpoint-verified) over the canned-route table; canned routes and partial chaining are fallbacks. Consulting the table first let the 50-tile tolerance hijack perfectly routable legs - a swamp-bound fisher matched a passing long-haul route and circuited past its own bank until stuck recovery fired. The canned routes exist for A*-defeating legs only. - Bank-leg stuck/timeout recovery returns to :travel_to_bank instead of jumping straight to :banking - the recovered bot re-arrives at its hub and banks authentically (climbing where the bank demands it) instead of depositing through the floor. - bot_interact_object's movement takeover also bumps path_seq: a long leg almost always has an async path chunk in flight at arrival, and a stale reply landing after the field clears repopulated the waypoints toward the old target, clobbering the click's approach. Plus: @travel_tick_limit 150 -> 250 (a 100-tile leg walks in ~110-180 goal ticks; at 150 it timed out at the buzzer every trip and emergency recovery beat the authentic walk), GoalRunner failure logs carry the bot index, BankAccess and the object-action dispatcher gained debug logging.