Bot.Travel wedges any leg whose straight line crosses water, mountain or building #123
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
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?
Bot.Travel.hop/2picks its waypoint by straight-line interpolation, so any legwhose direct line crosses water, a mountain or a building wedges the bot
permanently.
hop/2is the whole of long-leg travel: for a destination further than@hop(80) tiles it returns
which is a point 80 tiles along the straight line to the destination.
Nothing asks whether that point is standable, or whether a route to it exists.
When it lands inside terrain the planner cannot reach, the bot issues a walk,
does not move,
stuckclimbs,reroutesreaches@max_reroutes(3), and theleg ends
:stuck. The goal fails, loops, re-chooses, and — because thegeography has not changed — usually picks a destination on the same side of the
same obstacle and wedges again.
Observed
Three times in one sitting, with fishing bots but nothing fishing-specific
about it:
3091,3240) routing to the Al Kharid ground (3267,3149), 176tiles east across the River Lum. Leg state
%{steps: 6, stuck: 4, reroutes: 4, walked?: true}.2598,3420) to Catherby (2835,3432), into the mountains —two bots, both parked at
2697,3409.The log signature is a line repeated forever at one tile:
0 step(s)is the tell: a walk was issued and the planner produced no path.Why it matters beyond bots
This is the leash on where a bot can be usefully spawned — anywhere whose
bank or resource lies across water is unreachable in practice — and it is the
same fact that keeps a pker rising at Edgeville rather than walking in from
further out. Any future goal that travels between regions inherits it.
Shape of a fix
The waypoint is the wrong thing to guess. Options, cheapest first:
planner for a route toward it and walk as far as it actually reached, then
hop again from there. This is close to what a person does and needs no map
knowledge.
waypoints off the straight line before giving up.
durable answer and the most work.
Worth reading #23 first — closed, and about
Movement.routetruncating at 128steps. Different mechanism, adjacent symptom: both are a bound that produces a
bot standing still with nothing said about why.
A second mechanism reaching the same wedge, measured 2026-08-19 on a 75-bot
fishing fleet:
Movement's@max_path(128) truncates the route, and atruncated route is indistinguishable from the hop's for the bot walking it.
Twelve of those in one sixteen-minute sitting, all from bots on the Falador
coast (
{0, 2874, 3341}and{0, 2875, 3332}) whose banks are 70 and 71tiles away. The path is found and then cut short, so the bot walks to a tile
that is not where it asked to go and re-issues from there — which is the same
observable as the hop landing somewhere unroutable, and would be read as the
hop unless the warning is in the log.
Worth separating when this is fixed, because the two want different answers: a
straight-line hop that lands in terrain wants a reachable waypoint, whereas a
path capped at 128 steps is already a good path and wants either a larger cap
or a caller that walks it in stages and re-plans.
@max_path's own docs say itdrops work; nothing downstream treats a capped route as different from a
complete one.
Related, and what a partial fix showed
Bot.Goals.FishandBot.Goals.GatherAndBanknow spurn a ground whose legfails and choose another, so a failed leg is no longer a permanent loop. That
is a mitigation and it is measurably not a fix:
spurned three grounds, settled at Draynor and banked 108 fish each;
fourteen grounds and roam without banking anything, because every ground in
reach of them is on the far side of this.
So the spurn buys a bot an escape wherever a reachable alternative exists, and
nothing at all where the whole neighbourhood is beyond the planner. That makes
this issue the one that decides whether large fishing fleets work.
Superseded:
Bot.Travelno longer uses the straight-linehop/2. A leg now asksBot.Routefor the whole path and walks it in forty-step waypoints, which also covers the 128-step route cap from the comment. Remaining travel problems are tracked on forge.home.arpa (#45, #49).