fix/alkharid-gate-wedge-and-death-skull #222

Merged
sickday merged 4 commits from fix/alkharid-gate-wedge-and-death-skull into main 2026-07-24 12:10:18 +00:00
Owner
No description provided.
Post-deploy, the fleet piled in the mountains behind the Al Kharid bank.
Log-verified: destination-anchored recovery resolved 'nearest hub' by raw
chebyshev, and for every Lumbridge-area destination that IS the Al Kharid
bank across the river (Lumbridge has no bank; its oaks are 80 tiles from
Al Kharid vs 98 from Draynor, and A* cannot complete oaks->Al Kharid within
even 300 steps). Recovered bots re-planned west legs from inside Al Kharid,
marched into the border range, timed out, and recovered right back.

- TollGate: new river band (y 3233..3334, split on x=3252). East-west
  there is connected only by ~200-step winding routes the bounded router
  cannot walk (probe: scripts/probe_alkharid_north_extent.exs); genuinely
  open country starts ~y 3335.
- Navigation.home_bank/home_anchor: goals carry their task's :relocate
  bank and prefer it for banking legs and recovery anchors; nearest-bank
  and recovery-hub lookups reject candidates across the toll gate.
- recover_to_hub also banks the recovered bot's pack (it lands at a bank,
  mirroring the task-transition deposit). Without this, sixteen swamp-task
  fishers sat permanently on the Al Kharid bank tile: full pack -> cannot
  hold the toll -> :gate_cannot_pay cascade -> recovered to the same bank
  with the same full pack, forever. The only other deposit site is the
  goal's :banking phase, which a failing travel leg never reaches.

Live-verified via hot-load on the test world: the 16 parked fishers
dropped to 0 within 4 minutes, with 17 bots actively fishing at the swamp
shore; the border basin settled at ~25 — the legitimate gate-commuting
population.
The 468 cache ships it — Bank booth 18491 at (3208,3221,2) and Bank
Deposit Box 9398 at (3210,3217,2) on the castle top floor — but the bot
bank list carried a stale 377-era 'absent in this revision' note, so every
nearest-bank pick for the whole Lumbridge area (oaks, swamp, hops) crossed
the river to Al Kharid. Bots bank positionlessly and the coarse router is
same-plane, so the entry anchors at the ground-floor courtyard tile
(3210,3218,0) beneath the booths rather than the z=2 tile.

Gives Lumbridge-area recoveries and fallback banking a same-side hub;
rotation tasks keep their own pinned :relocate banks (the swamp fishers'
Al Kharid toll commute is unchanged).
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).
fix: bank-access reliability — stand-tile clicks, A*-first routing, recovery re-arrival
All checks were successful
ci / test (pull_request) Successful in 2m36s
d66878d30d
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.
Sign in to join this conversation.
No description provided.