Teleport and climb destinations are never validated against collision #19

New issue

Closed

opened 2026-07-27 22:31:38 +00:00 by sickday · 0 comments

sickday commented

2026-07-27 22:31:38 +00:00

Owner

World.jump/2 sets player.position outright. Nothing checks that the tile it
lands on is standable, reachable, or even on a plane that exists as anything but
open air.

That is fine while every destination comes from the transport dump, and it is
not fine for the geometric fallback. World.Climbing.Geometry covers 380 of the
749 {placement, action} pairs the dump never saw, at 96.7% plane-correct and
53.6% exact — so roughly half of those staircases put the player on the wrong
tile, with no check that the tile is one a player could occupy.

The failure is worse than it sounds because of what upper planes look like in
the map data: no plane above 0 carries a single blocked-floor render flag in
the Lumbridge square, and the same holds broadly. Containment above ground is
walls and nothing else. A climb that lands outside a building at plane 1 drops
the player onto ~2,780 connected walkable tiles of open void, from which every
subsequent walk is legal, routes correctly, and looks exactly like the collision
map is broken.

Verified with a flood fill over the decoded flags for square 50,50: at plane 1
the castle rooms form 14 separate components and none of them connects to the
open-world component, so the only way to be out there is to have been put there.

Shape of a fix

travel/3 should validate before committing:

refuse a destination that is solid (Collision.blocked?/1), or
nudge to the nearest standable tile within a tile or two, or
refuse the transport outright and log it, which at least surfaces which
placements the geometry is getting wrong.

Refusing is preferable to landing wrong: a staircase that does nothing is a bug
report, a staircase that puts the player inside the terrain is an afternoon.

`World.jump/2` sets `player.position` outright. Nothing checks that the tile it lands on is standable, reachable, or even on a plane that exists as anything but open air. That is fine while every destination comes from the transport dump, and it is not fine for the geometric fallback. `World.Climbing.Geometry` covers 380 of the 749 `{placement, action}` pairs the dump never saw, at **96.7% plane-correct and 53.6% exact** — so roughly half of those staircases put the player on the wrong tile, with no check that the tile is one a player could occupy. The failure is worse than it sounds because of what upper planes look like in the map data: **no plane above 0 carries a single blocked-floor render flag** in the Lumbridge square, and the same holds broadly. Containment above ground is walls and nothing else. A climb that lands outside a building at plane 1 drops the player onto ~2,780 connected walkable tiles of open void, from which every subsequent walk is legal, routes correctly, and looks exactly like the collision map is broken. Verified with a flood fill over the decoded flags for square 50,50: at plane 1 the castle rooms form 14 separate components and none of them connects to the open-world component, so the only way to be out there is to have been put there. ### Shape of a fix `travel/3` should validate before committing: * refuse a destination that is solid (`Collision.blocked?/1`), or * nudge to the nearest standable tile within a tile or two, or * refuse the transport outright and log it, which at least surfaces which placements the geometry is getting wrong. Refusing is preferable to landing wrong: a staircase that does nothing is a bug report, a staircase that puts the player inside the terrain is an afternoon.

sickday referenced this issue from a commit

2026-07-28 00:31:19 +00:00

fix(world): validate where a jump lands before committing to it

sickday referenced this issue from a pull request that will close it,

2026-07-28 00:32:13 +00:00

fix/reach-and-movement-integrity #28

sickday closed this issue

2026-07-28 00:32:21 +00:00

sickday referenced this issue

2026-07-30 21:01:46 +00:00

Climbing's geometric fallback is 53.6% exact, and plane-1 landings fall into void #54