11 releases 11 tags

RSS feed

• 0.11 8929961dff

  Compare

  0.11 Stable

  patricus released this 2026-09-28 09:50:10 +02:00 | 0 commits to master since this release

  Auto-walk mostly stops getting stuck. Across one long log, walks spent 25
  minutes not gaining a metre, nearly all of it the walker trying the same bit of
  wall over and over. Now a body that has not moved in four seconds marks that
  patch as blocked and plans round it, breakable rocks are walls on the map until
  someone breaks them, a glide that cannot reach its edge gives up in seconds
  rather than twenty, and a walk cut off by a battle or a cutscene picks itself
  back up once you can move again.

  It also finds people indoors. A quest that sends you to someone inside a
  building only marks the patch of map their door is on, so Hoylake - in the Town
  Hall - was never on offer from outside. The door that leads to the person the
  quest names now stands in for them, and walking to it takes you through it.

  And it tells you about the way off ground that goes nowhere: the lift on the
  lower Outskirts is named wherever you are on that ground, not only when it
  happens to be loaded, and a step onto roomier ground is no longer refused as a
  trap.

  Hoylake had not disappeared - he was indoors

  "On The Hunt" in its return stage marks the whole Harbourtown chunk -
  HoylakeQuest.gd hands the game's map HOYLAKE_CHUNK and nothing finer - and
  Hoylake is not in that chunk. He is in the Town Hall, an interior, which is not
  in the world at all while you are outside. So the list offered "Quest area
  (Harbourtown)", aimed at the middle of the chunk, and never him; and once you
  were inside with him, the quest marker said its area was out on the overworld.

  The quest's own description names who to go to - "Return to Hoylake to show
  him" - and the door that leads to him is in the chunk it marks. So now:

  Outside, a marked chunk with a door whose interior holds the person the
  description names becomes that door, named for them: "Hoylake, in Town Hall -
  On The Hunt". Who is inside is read off the interior's scene state without
  instancing it, and only the recurring NPCs count - they are the characters
  quests are written about; the townsfolk have no name a quest could use. The walk
  is aimed through the door rather than at it, because a door only fires for a
  body moving through it, and the door itself is no longer switched off for the
  walk that is going to it.

  Inside, or anywhere the person is actually present, they get a second entry
  under Markers named for the quest, alongside their usual one under People.

  Names are matched as whole words, longest first, so "Ian" is not found in
  "Ianthe" and "Ranger Wilma" wins over "Wilma".

  Picked a walk back up after a battle

  Overworld monsters chase you, and being caught is a scene transition into a
  battle - which ended the walk for good. 26 quest-area walks in the log were
  killed that way with 100 to 420 metres still to go, and 47 more by a cutscene or
  dialogue taking control; every one left you to find the target and start again.

  A walk interrupted like that now says "Walk paused", and resumes on its own a
  moment and a half after you have control back - "Resuming walk to ...". Not when
  the interruption was the arrival (walking to a door, an encounter, a cutscene
  trigger, or already within a few metres), not if you move or press one of the
  mod's keys first, not in a different level or more than 40 metres from where it
  stopped (a lost battle sends you off to be healed), and not after four minutes.

  Stopped trying the same wall for a minute

  The log's stall hotspots add up to 1,471 seconds of walks that did not gain a
  metre, and nearly all of it is one shape: hop fails, hop assist, reroute, hop
  fails, on one spot. Every recovery the walker has judges itself by its own
  progress toward its own aiming point and hands over to the next with a fresh
  budget, so against something the map cannot see they take turns failing.

  A blunter question now overrules them: has the body stayed within 0.75 metres
  for four seconds while following a route? Then the route runs through
  something. The graph closes the ground between you and the waypoint you could
  not reach - the columns either side as well, since obstacles are rarely one
  tile wide - and the walk plans round it. Up to four times per walk, and the
  closures expire after three minutes.

  A closure can never be the reason for a refusal: your own ground is never
  closed, a closure does not make the ground MEASURE smaller (so no stranded
  warning can start off one), and if the plan round it fails the closure is lifted
  and you are told what is in the way instead - "a breakable rock" when the map
  knows there is one there.

  Breakable rocks are walls until they are broken

  The walk that could not go south from (364, -82) in the Outskirts was up against
  a breakable rock. They are RigidBodies on their own collision layer, held still
  until something hits them hard enough; the player collides with that layer and
  every nav reader ignored it. The map graph routed straight through two of them,
  and every obstruction probe reported "clear" at every height into the rock the
  player was pinned against. Walking eight metres west by hand found the gap
  between them, and the same walk routed first time.

  The map read treats an intact breakable rock as solid now, so routes go round.
  One whose save flag says it is already broken is not read, since the game
  destroys those as the area loads. One broken this session without a flag - they
  come back on the next load - still reads as solid, which costs a detour round a
  hole and is the right way round to be wrong.

  The two live probes that are about the body rather than the terrain - which way
  is clear to steer, and what is in the way - use the body's own collision mask
  now, so the log names what stopped it ("- hit DestructibleRock2") and the local
  detour stops steering back into it.

  A way off the ground, read off the map instead of the scene tree

  The refusal could name the lift only when the lift was streamed in. Remembering
  what had been near the player once helped, but it cannot help somebody who has
  never been near it - loading a save onto the far side of a patch and walking
  until the ground runs out is exactly that case, and the log has it: the refusal
  at 111,523ms had nothing to offer, and the lift first appeared in the registry
  at 115,019ms, three and a half seconds later.

  TileTerrain already reads every chunk's authored scene for its terrain, and
  already collects the doors off that same pass. It collects the lifts now too, so
  a way off is known from the moment the map read lands, whatever is in the tree.
  Three sources, each covering the one before: the live registry, the memory, and
  the map.

  A lift is duck-typed the way the doors are - movement_offset with
  movement_duration and progress is WiredElevator and nothing else in the
  game. Naming its script here would preload it, and whatever its own chain pulls
  in, at parse time; that is the trap every check in tests/ is written around.

  Off-tree, _ready() has never run, so a lift's authored translation is still
  the BOTTOM of its travel - which is exactly the boarding point TargetRegistry
  computes at runtime with _lift_boarding_point. Read live it would be wherever
  the platform happens to be in its cycle.

  Only the raw facts are recorded. What a door or a lift is CALLED stays a naming
  question, and the namer is pure and autoload-free so a check can call it - which
  is why the index lives on TileTerrain rather than on TargetRegistry, which
  hangs the harness outright. A door is named for where it LEADS rather than its
  own node name, since the scenes are authored "WarpRegion", "Cafe Warp",
  "Entrance Warp" - the thing that once listed six of them as "Door (Warp
  Region)".

  Against the real Outskirts chunks with nothing in the tree: 13 ways off, the
  lift found at (177, 5.87791, -69), on the right patch, named "Lift (Elevator)",
  and picked at 64.6m - the live path said 64.9m in the field. 9 of the doors are
  named for their destination.

  Stood still for twenty-seven seconds behind a lamppost

  A glide leg planned as "3.1m out and 0m down, 0.34s aloft" ran from 300,605ms to
  327,634ms. Twenty-seven seconds, never once airborne, the player standing on the
  spot hearing "Quest area (Autumn Hill), 345 meters away" seven times over.

  GLIDE_MAX_SECONDS is 20s and it was the ONLY way out. That is a fair backstop
  for a flight genuinely still in the air, where the physics engine is in charge -
  but the ground phase, walking out to the lip before the jump, had no check on it
  at all. So a pawn pushing into something on the approach held the whole walk for
  the full twenty seconds and then some.

  What was in the way is in the log, a second and a half after the leg was finally
  abandoned and the ordinary machinery got a look at the same spot:

  contacts: on_floor=False ... is_on_wall=True ... slides=1:
    lamppost_world_1 at (53.07, 11.177, -13.72)
  

  A lamppost. The walk has had MAX_NO_PROGRESS for exactly this since the
  reactive-steering days; the glide leg simply never got it.

  It is timed from the last real PROGRESS now, not from the start of the leg,
  which is the property that matters and the one a fixed cap cannot express - a
  long approach has to stay free. Replayed against that leg's real geometry, the
  lamppost gives up in 3.6 seconds, while an uninterrupted 14m approach and a
  27.6-second slow-but-closing one are never abandoned at all.

  Only while grounded and not yet airborne. Once the pawn is in the air
  GLIDE_MAX_SECONDS is still the backstop, and the stamina wait - which stands
  still deliberately, waiting for the bar to refill - returns before any of this
  and is untouched.

  Remembered the lift on the tick, not at the refusal

  The fix above was right about the cause and wrong about where to record it. It
  remembered only what _way_off_this_ground itself found - and that function
  runs ONLY when a refusal or a stranded watch asks it, which is precisely when
  the player is furthest from the way off and it has streamed out. So the memory
  was empty exactly when it was needed.

  The next session showed it plainly. The lift was in the registry and read out
  loud, and the refusal came 84 seconds later with nothing recorded in between:

  97392   "Lift (Elevator), 56 meters away"
  181028  "...no walking route off it"
  

  The sighting is taken on the tick now, walking or idle, from whatever the
  registry happens to hold - and it costs no graph work at all, just the
  positions. It runs before the walking/idle split, because the lift is almost
  always passed DURING a walk and the refusal that needs it comes after that walk
  has run out of ground. The graph question - is it on THIS ground - is still
  asked once, at the refusal, against the flood that is being taken anyway.

  Up to 16 are kept. The nearest one STILL on this ground wins, rather than simply
  the nearest: a door remembered in the town above would otherwise be named to
  somebody standing under it.

  Said the ground went nowhere while standing on the lift out

  "I got as close as the ground I can reach allows, about 181 meters short:
  there's about 129 by 109 meters of ground here and no walking route off it."
  There is a way off it. The tutorial lift is standing on that very patch, and the
  mod had said so itself twenty-three seconds earlier:

  150868  at (131, 8, -37)        "There's a Lift (Elevator) on this ground,
                                   56 meters away"
  173536  at (233.7, 8.1, -38.1)  "...no walking route off it" - nothing
                                   offered at all
  

  Same patch, same lift, same session. What changed in between was a hundred
  metres of walking: _way_off_this_ground looks the lift up in TargetRegistry,
  which holds what is STREAMED IN, so walking away from the lift takes it out of
  the list. The sentence that most needs it is the one said furthest from it,
  after a walk across the patch has run out of ground.

  Neither the lift nor the ground under it can move while the player is standing
  on that ground, so the spot is remembered and re-tested against the current
  flood with the same ground_holds it was found by - which answers "is it still
  on this ground" without the node existing. The memory is dropped as soon as a
  flood no longer holds it.

  Worth writing down, because it looks like a counterexample and is not: the top
  of the sea wall is NOT in this patch's flood, but flooding from up there does
  reach the lift. The graph is directed, the drop is an edge one way, and a player
  on the wall really can get down to that lift - so the memory rightly survives
  there. check_navwayoff.gd pins all of it against the real chunks, including
  that the lift remembered at (131, 8, -37) still reads as on this ground from
  102.7m away.

  Refused to walk onto roomier ground, seven times

  The other half of the same walk, and the reason the player was down there at
  all. Seven refusals in thirty-eight seconds, every one of them this:

  route refused: it ends at (126.4, 8, -50.6) on ground of 2387 nodes (the bar
  is 10118), which does not reach back to (79.2, 10, -27.4) (itself on ground
  of 1442 nodes)
  

  1,442 nodes, refusing a move onto 2,387 - ground 65% bigger, and the piece with
  the lift on it. The guard exists to stop good ground being traded for a trap,
  and it cannot do that job from inside a trap; the mod had already announced that
  pocket as stranding before the first refusal.

  Node count is the mod's own measure of how trapped a piece of ground is -
  _stranded_bar, boxed_in and way_out_of all read it - so more of it is the
  mod's own definition of better. A route onto strictly roomier ground is not
  refused now. STRICTLY, so a sideways move still is: the pinned case is a 49-node
  shelf onto a 49-node pocket, nothing traded for nothing.

  This is deliberately not the bar Control plus End uses. way_out_of PICKS
  somewhere to send you and must only promise real improvement - "four better, out
  of eighty thousand" was that bug. This one FORBIDS a move the player asked for,
  and the honest default when it cannot show the far side is worse is to let them
  go.

  Said it five times because the game was frozen when you asked

  The log has 487 bursts of one sentence requested again and again inside a few
  milliseconds, each read out in full. The worst runs five deep: "Quest area
  (Autumn Hill), 352 meters away" at 53,724ms and again at 53,729, 53,734, 53,739
  and 53,743. Nobody presses a key five times in nineteen milliseconds.

  They came from two unrelated places, which is why the guard is in TTS.speak
  rather than at either source:

  Input that piled up during a freeze. A NavRegion build is synchronous, and
  in this log they run to a median of 960ms and a p90 of 2,956ms - 334 of 683 over
  a second. A player who presses Home again because nothing answered is not asking
  twice. Godot hands the whole backlog over in one frame once it unblocks, so five
  presses become five identical reads, all with the same distance in them because
  the player has not moved between them.

  A signal the game fires more than once. tracked_quest_changed arrives two
  and three times for a single change, and the quest readout went out each time.

  The guard is keyed on the TEXT, and that is the whole safety argument. Cycling
  targets with Page Down, or moving down a menu, produces a different sentence
  every time and is never touched - collapsing those would eat presses and leave
  the selection somewhere the player was not told about. Only a verbatim repeat
  inside 150ms goes, and at 150ms the first sentence has barely started speaking.
  The window is a duration rather than a frame count because the "Teleported to"
  burst spans 49ms, wider than one frame at 60fps.

  _last_at deliberately does not move when a call is collapsed, so suppression
  can never outlast one window however long the backlog is - a held key cannot
  mute a line indefinitely.

  This is the symptom rather than the cause. The builds still freeze the game; see
  check_ttsrepeat.gd for the numbers.

  The refusal did not say how big the ground you were standing on was

  "it ends at (126.4, 8, -50.6) on ground of 2387 nodes (the bar is 10118)" reads
  as a trap either way, and it is only a trap if the ground being LEFT is roomier
  than that. In the same session, six seconds later, the stranded watch put the
  player on 1,442 nodes - so that refusal was turning down a move onto ground half
  again bigger than the ground it was protecting, and nothing in the line said so.
  Both sizes are logged now. The verdict is unchanged; it is the reading of it
  that was impossible.

  Walked down somewhere it could not walk back from

  The refusal that named the lift was the second mistake in that walk. The first
  was fifty seconds earlier and put the player where the refusal happened.

  The walk set off from a 1,332-node pocket and at roughly (126.5, -40) hopped
  down onto a different one - 2,387 nodes, the lower Outskirts - with jump=True
  and no edge in the tile graph coming back. NavRegion planned that descent
  happily, and correctly by its own lights: its region is a corridor drawn round
  the straight line to the goal, the drop is inside MAX_FALL, and nothing in it
  asks whether the ground on the far side goes anywhere. Neither pocket holds
  Autumn Hill. So the walk traded one trap for another and then refused from
  inside the second, having spent the intervening minute making the situation
  worse.

  The graph could have said so before a step was taken. It is directed - a drop
  is an edge one way - so "can I get back" is just "is where I am standing inside
  the ground I would be flooding from down there".

  A route is refused now when its end cannot reach back to where the player is
  standing. Three ways that is fine and must stay fine, which is most of the
  design:

  The far side is well connected. Stepping off a ledge onto the map is not a
  trap, it is how you get down. Judged by the same share of the map that the two
  stranded watches and Control plus End already use, so the four cannot disagree
  about one piece of ground.

  You can walk back. A ramp, a slope, a staircase - the ordinary case, and the
  flood answers it directly.

  The goal is down there. Then going is the whole point, and not being able to
  return is the player's business rather than the mod's.

  It is costed to be free when it does not apply. A route with no real drop in it
  cannot strand anybody and never floods at all. When it does flood, it floods
  once, from the route's END, capped at that bar - so the common case, a drop onto
  the main map, stops at the cap and never pays for the rest. The one flood
  answers all three questions.

  That gate is where the first version of this went wrong, and the field log shows
  it losing the exact walk it was written for. It borrowed the landing watch's
  ONE_WAY_DROP_MIN, on the reasoning that "a drop worth the name" should mean
  one thing in the mod rather than two - but the two watches are not asking the
  same question. The landing watch measures a fall that has already happened, from
  the last floor the player stood on before leaving it, and 2.5m is a sensible
  floor for "a real plummet rather than a kerb". A route is asked something else
  entirely: is any planned step down one the body could not climb back up? In the
  log, waypoint 11 sat at y=8 and waypoint 12 at y=6 - exactly two metres, half a
  metre under the borrowed gate - so the guard returned before it ever looked at
  where the route ended. It ended on the 2,387-node lower Outskirts, which does
  not reach back. The guard was installed, correct, and never ran.

  The route's gate is MAX_STEP_UP now: the most the body can climb is the
  smallest step down that might not be undoable, and "might not" is the right bar
  for something whose only job is deciding whether to ask. Exactly MAX_STEP_UP
  is borderline on height alone and routinely refused for other reasons anyway -
  what the body would land on, what it would have to sweep through - which is this
  walk exactly. Below it a descent is comfortably reversible, so the ramps and
  staircases that make up almost every route still pay nothing.

  Glide legs deliberately do not come this way. A glide is the player asking to
  cross a gap and GlidePlan picks where it lands; refusing one on these grounds
  would be second-guessing an explicit choice.

  The refusal says what it found - "the only way on I can find drops onto ground I
  couldn't walk back off, and X isn't on it" - and, since it is describing ground,
  names a lift or doorway standing on it the same way every other refusal now
  does.

  One caller was reaching past the planner's own reason for a generic height
  diagnosis. _resume_after_glide was the only one of four doing that, and after
  a glide the planner's measurement is almost always the better answer.

  check_navnoreturn.gd pins the rule on plateaus built to be separate components,
  including all three escape valves - the case that must fire, and the three that
  must not - and pins the gate on the waypoint heights out of the log, since every
  one of those cases is dead code behind it. check_navwayoff.gd pins the field
  descent itself on the real chunks: the landing cannot walk back to where the walk
  set off, and Autumn Hill is not on it either, so the drop bought nothing.

  Told there was no way off ground with a lift standing on it

  The map read now lands mid-walk, so the walk that used to stop 231m short of
  Autumn Hill gets 50m further and stops for a better reason. The new one is
  measured correctly and says something false:

  there's about 129 by 109 meters of ground here and no walking route off it.
  Shift plus End teleports you there. Control plus End puts you back on open
  ground.
  

  Rebuilding the graph off the same chunks reproduces that to the node - 2,387 of
  them, 129.1m by 109.1m, and the only thing bounding it is a four-metre rise it
  takes 156 refused adjacencies to describe. There is genuinely no walking route
  off. What is standing on it is the lower Outskirts tutorial elevator, and the
  floor button that drives it twenty-one metres from that. The mod was reading the
  lift out loud in the same breath:

  131534 "Interactable (Lever), 50 meters away"
  131800 "Door to Outskirts Pipe Cave, 50 meters away"
  135900 "Lift (Elevator), 51 meters away"
  132482 "...no walking route off. Control plus End puts you back on..."
  

  The mod had already worked this out once. The note over TargetRegistry's
  _lift_switch_effect names this plate and this lift and says outright that the
  lift "is the only way up out of the lower Outskirts" - it was written to fix
  what stepping on the plate says, and stepping on the plate is not where somebody
  who cannot see the lift start moving asks the question. The refusal is.

  So the graph's silence is not evidence on its own. It has no concept of a lift
  or a doorway, and a patch with either standing on it is not a trap whatever its
  walking edges say. Both the refusal and the stranded watch ask now, and name
  what they find - "There's a Lift (Elevator) on this ground, 51 meters away" -
  in place of a teleport hint the ground did not need.

  Named rather than routed to. Riding a lift is standing on a moving platform and
  waiting, which the walker has no idea how to do; a player told the lift is fifty
  metres away can go and take it, and a player told the ground goes nowhere
  cannot.

  That needed one question the graph could not previously answer. reachable_extent_from
  measures the ground and throws away which nodes it was, which is right for "how
  big is this" and useless for "is that lift over there on it" - one flood with
  several answers. ground_under hands the flood back and ground_holds asks
  about a spot for the price of a cell lookup, at the same reach the endpoint
  linking uses, because a boarding point or a threshold is never a tile centre.

  check_navwayoff.gd pins it on the real chunks: the lift and its plate are on
  the patch, and the top of the sea wall four metres up - the spot Control plus
  End offers, precisely because it is NOT on the patch - is not. That pair has to
  come out differently or the clause would fire on anything at all.

  A walk that starved the map read that would have finished it

  Autumn Hill again, and this time nothing about the marker was wrong - the mod
  simply never got to look at the map. From the field log, the last two lines of
  a sixty-second walk:

  2804906 walk ended: reason="...about 231 meters short..."
  2808435 TileMapper: map read in 72441ms ... 80947 nodes, 295986 edges
  

  Twenty-eight milliseconds between giving up and having the answer. The read had
  been one tick from done for the whole minute.

  The read only ever ran between walks. _process ticked it inside its idle
  branch and returned, so pressing Shift+Home stopped it dead until the walk was
  over - and a walk is exactly when the map is wanted. The player had warped into
  the overworld twelve seconds earlier and ordered a quest area 340m off; the read
  made no progress at all from that moment until the refusal. "72441ms" is
  wall-clock, not work: 12.2 seconds of reading, 60.2 frozen, one tick. It is also
  why the read times across the log run from 8 seconds to 206 for the same 128
  deterministic chunks - they were measuring how long the player stood still.

  Two things were missing for that whole walk, and either alone loses it. The
  quest marker stayed at the flat fallback height - every line reads ground guessed at y=8, and the walk ran at (384, 8, -192) where the ground is really
  y=20, so the goal sat twelve metres inside a hill and no complete route to it
  could exist. And NavGraph had no map at all, so every leg was planned by the
  near-field region alone and every one came back partial - goal was clamped. It
  glided three times, walked to the shoreline, found the ground stops one cell on,
  and refused. The graph that routes there in 161 waypoints, not partial, arrived
  three and a half seconds later.

  So the read runs during a walk now, before the glide and hop-assist branches
  that would otherwise starve it across a three-leg glide just as effectively. It
  still outranks the column-at-a-time warmer for the frame, mid-walk as when idle.
  The cost is seven or eight seconds of low frame rate at the start of the first
  long journey on a map, which is the trade the deadlock was hiding.

  And landing mid-walk is worth acting on rather than waiting out: the walk is
  re-aimed and re-planned on the finished map the moment the controls are its own
  again - not mid-glide, where pulling the route out from under a leg in the air
  is how a glide becomes a swim. Re-aimed as well as re-planned, because a quest
  area and a map-screen mark are both re-grounded on every scan, and until the
  read lands the only answer available for a chunk nobody is near is the guess.

  One diagnostic gap went with it. A marker's aim was logged when the marker was
  created and never again, so the log showed the guess and never the correction -
  which reads exactly like a correction that never happened. It is logged whenever
  the answer changes now.

  A quest area aimed at a height nobody measured

  Autumn Hill, attempted across two sessions and never reached, on foot or by
  teleport. The marker was in the wrong place the whole time:

  quest chunk marker: key=(6, -3) probe=empty (chunk likely not streamed in)
  pos=(384, 8, -192)
  

  That y=8 is a guess, not a measurement. A quest area names a 64m chunk and its
  height has to be asked for, so the mod fires twenty-five ground probes across
  it - and this game loads world geometry by proximity, so a chunk nobody is near
  has no collision in it at all. Every probe comes back empty and the marker gets
  parked at the chunk's centre at a generic overworld height. The note on that
  fallback said it "self-corrects once real terrain streams in as the player gets
  closer", which is true and worth nothing when the reason you want the marker is
  that you cannot get closer.

  The real ground over that spot is y=20. Twelve metres is not a rounding error,
  because of what the planner does with it: a route has to END somewhere the map
  joins up, and the nearest walkable ground to a marker buried twelve metres under
  a hill is too far off to join. So no complete route to Autumn Hill could exist -
  only a partial, which is the weakest answer the planner has. It loses to any
  fresher one, gets thrown away when it cannot close enough ground to be worth
  walking, and turns arriving into "about 215 meters short". Measured over the
  whole map from one of the spots the walk kept turning round at: 173 waypoints to
  the marker, flagged partial; 161 waypoints to the ground the marker names, not
  partial at all. The same journey, one of them unusable.

  The mod already reads all 128 chunks of the overworld straight off the scene
  files, with no physics and no streaming - which is exactly the blind spot the
  probes have. So when the probes find nothing, it asks the map instead, and only
  falls back to the flat guess for a map nothing has read yet. Waypoints marked
  from the map screen are aimed the same way, for the same reason.

  It waits for that read to finish before trusting it, which is not a detail: a
  column's headroom is worked out in the pass that runs once all 128 chunks are
  in, and until then there is nothing there to read. Asking sooner crashed the
  game outright on the next target rescan. The reader now refuses a map that has
  not been finalised, whoever asks it - so the marker is corrected about a minute
  and a half into a session rather than instantly, and the target list picks it up
  on its own the next time it scans.

  Two things that went wrong downstream of it are fixed as well, because both
  outlive this particular marker:

  A walk that went round in a circle. Where a goal genuinely cannot be routed
  to exactly, both planners can only offer partial routes, and the near-field one
  won on nothing but being fresher - even when it was heading back the way the
  player had just come while the map's own graph had a way round. Now the one that
  ends nearer the target wins, and only when it is decisively nearer, so the
  near-field planner still keeps every close call and goes on profiling ground
  nobody has walked yet.

  A teleport that put you back where you started. Shift+End aimed at the
  target's own position. Where that is not somewhere a body can be, the player was
  put down inside the scenery, fell out of the world, and the game returned them to
  the last ground they stood on - the exact spot the key was pressed to leave -
  while the mod announced "Teleported to" each time. The destination's column is
  checked for a floor now, and when there isn't one at that height it aims at the
  nearest surface there is.

  A patch measured with the wrong ruler. "Everything I can walk to from here
  is about 24 by 25 meters" was measured by the near-field planner, whose region
  is a box drawn around the straight line to the target - so the flood stops at
  the box, not at the edge of the ground. The same 24-by-25 turned up at two
  unrelated spots in two sessions, which is the tell: it was reporting the ruler.
  The real patch at one of them is about 130m by 110m. There was already a guard
  against a patch that reads too big; one that reads too small passed every test
  and stated a falsehood confidently.

  It asks the map's own graph now, which has no box around it, and stops counting
  once the ground is plainly not a trap. That opens a third case which had no
  wording: ground too roomy to call a pocket that still goes nowhere - 2,387 nodes
  of an 80,947 node map, with no walking route off it. It says exactly that, in
  the same words the stranded watch already uses for somebody who loads a save on
  such a patch, and it offers Control plus End like the other dead ends rather
  than describing a kerb one step away.

  An escape hatch that moved you thirteen metres onto ground just as stuck.
  Control plus End looks for "somewhere better", and the rule was "more ground
  than here" - which a single node satisfies. Stranded on 2,387 nodes of an 80,947
  node map, it offered a spot 13.8m away that walks out to 2,391. Four better, out
  of eighty thousand, and every refusal in the session recommended that key. It
  now has to clear the same share of the map that the mod uses to decide you are
  stranded in the first place, so the key and the reason for pressing it finally
  agree. On that same patch there is genuinely well-connected ground 16.4m away -
  it reaches 41,586 nodes - which is what the key finds now.

  And when there is nothing better within reach it says so and stops offering the
  key, rather than promising a way out it cannot deliver. Describing the ground
  and knowing what to do about it are two separate questions now, which is why
  one sentence could previously get the first right and the second wrong.

  Being told you are stranded, rather than told about a kerb

  Quest area after quest area refusing to be walked to, and once "no route to
  Harbourtown" - from a spot with plenty of ground in every direction.

  The refusals were right. The player had dropped onto a plateau east of the park
  and could not walk off it: reading the whole map analytically, everything
  reachable from there is 446 nodes across 44 by 52 metres, with no walking route
  to town at all. What was wrong was the sentence. "The ground carries on but
  there is no way onto it from here" describes the first thing in the way, which
  is the right answer at a wall and a hopeless one when the problem is that there
  is nowhere to go - it sounds local, and it sounds like walking a bit further
  round would fix it.

  When the ground you can reach is small, it now says how small: "everything I can
  walk to from here is about 24 by 32 meters - this ground doesn't join the rest
  of the map". Roomier than that and the obstacle really is the story, so the
  older wording stands.

  A party member says which tape they are carrying

  "patricus, Lv 14" and no sign of what he was holding. The two tapes each of you
  actually fights as are drawn inside the party member buttons, and a tape's name
  sits six levels down inside one of those - which is why a reserve slot reads
  fine on its own and these two did not: inside a member button it is seven, one
  past how deep the reader goes. So the two tapes that matter most were the two
  that could not be heard.

  They read as "patricus, Lv 14, Sirenade" now.

  Tapes say who is carrying them

  A tape belongs to a person - you and your partner each hold your own, six
  between the two of you - but the party screen only shows that by position. The
  two buttons along the top are a member and their lead tape; every other tape is
  one flat list with nothing attached saying whose it is. So a reserve read as a
  bare "Dominoth".

  That matters because there is no way to hand a tape over. The only move is a
  swap: two tapes trade places, and each of you keeps the same number. Choosing
  which pair to swap without knowing who holds what was guesswork.

  They read as "Dominoth, Kayleigh's" now. The party member buttons are unchanged,
  having said the name already, and a tape in storage belongs to nobody and says
  nothing.

  Both of those names come out of the game as raw localisation keys - the game
  itself never translates them either, it assigns them to a Label and lets Godot
  do it on the way to the screen - so reading the property straight off announced
  "Kayleigh, Lv 13, SIRENADE_NAME". They go through the translator now, which
  leaves a tape you have renamed yourself alone.

  Downloads

  • Source code (ZIP)
    1 download
  • Source code (TAR.GZ)
    0 downloads

  ---

  • cassette_beasts_access-0.11.zip
    6 downloads · 2026-09-28 09:58:16 +02:00 · 491 KiB