fix(fishing): a spot stands on water, and blocked was never that #232
Loading…
Reference in a new issue
No description provided.
Delete branch "fix/fishing-spots-on-land"
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?
An operator screenshot from Barbarian Village: a fishing splash on the grass
above the river. Relocation had been moving spots there for a release with a
green suite behind it.
World.FishSpots.valid_tile?/2askedCollision.blocked?/2and then for awalkable neighbour, on the reading that a river is solid and the shore beside
it is not. Half of that is true, and the wrong half decides: a river IS solid,
and so is the mud bank it runs between, and so is a cliff, a fence and a tree.
Every one of them is "solid with a walkable neighbour", so every one of them
was a legal fishing spot.
The distinguishing fact was in the cache all along and
Cache.MapSquarewasthrowing it away: the terrain overlay. The decoder now keeps it as one bit
(0x80) beside
drawn,World.Collision.Flagscarries it as 0x800000 andWorld.Collision.water?/2reads it. Which overlay is water is measured, notassumed -- the dump stands 147 of its own 153 fishing rows on overlay 6,
texture: 25in config group 2 file 4, and the next most common tile under aspot is no overlay at all, of which there are three.
valid_tile?/2is now water first, then the shore; reversed it is thereachability test under a new name. Four of the five fly areas are re-derived
against it and Shilo Village was already right, so all 29 rows pass in both
fishing.exsandnpc_spawns.exs.refusedbecomes a tombstone list a testholds to being genuinely unfishable.
Five of the dump's clusters have no tile this decoder can prove is water --
three 3419 rows at y 6018-6038 whose map square carries no overlay at all, and
three singletons -- so
unprovable/1names them and they are pinned ratherthan dropped. A pinned cluster's tiles are exactly the rows the dump states, so
the pin can only decline to improve on the operator's data, never invent a
tile. Our own derived tiles get no such exemption.
Measured on a live world: 92 spots over 57 clusters, 87 on water and the five
pinned ones named in the boot log. The collision flag map grows 1.1%
(6,069,237 to 6,136,942 tiles), all of it water the map author left unmarked.
Two traps worth the next reader's time. Config group 2's file list is SPARSE --
137 files over ids 0..173 -- so zipping against 0..136 renames every definition
above 91, where group 6 is dense and the same code is right. And water under a
bridge reads as water from the raw terrain file but not through the collision
map, which is the correct answer:
2387,3427at Tree Gnome was one.The generator's own
water?/1wants the same change;Tools/dumpsis aseparate tree and is not carried here.
Not verified in play.
::tele 3106 3432stands on the west bank with three ofBarbarian Village's five candidates in view.
An operator screenshot from Barbarian Village: a fishing splash on the grass above the river. Relocation had been moving spots there for a release with a green suite behind it. `World.FishSpots.valid_tile?/2` asked `Collision.blocked?/2` and then for a walkable neighbour, on the reading that a river is solid and the shore beside it is not. Half of that is true, and the wrong half decides: a river IS solid, and so is the mud bank it runs between, and so is a cliff, a fence and a tree. Every one of them is "solid with a walkable neighbour", so every one of them was a legal fishing spot. Barbarian Village 6 of 7 candidates on land 5 mud bank + 1 bare grass Barbarian Outpost 3 of 4 the cliff at x 2498 Lumbridge 2 of 8 bare grass Tree Gnome 1 of 5 bare grass 12 of 30 The distinguishing fact was in the cache all along and `Cache.MapSquare` was throwing it away: the terrain overlay. The decoder now keeps it as one bit (0x80) beside `drawn`, `World.Collision.Flags` carries it as 0x800000 and `World.Collision.water?/2` reads it. Which overlay is water is measured, not assumed -- the dump stands 147 of its own 153 fishing rows on overlay 6, `texture: 25` in config group 2 file 4, and the next most common tile under a spot is no overlay at all, of which there are three. `valid_tile?/2` is now water first, then the shore; reversed it is the reachability test under a new name. Four of the five fly areas are re-derived against it and Shilo Village was already right, so all 29 rows pass in both `fishing.exs` and `npc_spawns.exs`. `refused` becomes a tombstone list a test holds to being genuinely unfishable. Five of the dump's clusters have no tile this decoder can prove is water -- three 3419 rows at y 6018-6038 whose map square carries no overlay at all, and three singletons -- so `unprovable/1` names them and they are pinned rather than dropped. A pinned cluster's tiles are exactly the rows the dump states, so the pin can only decline to improve on the operator's data, never invent a tile. Our own derived tiles get no such exemption. Measured on a live world: 92 spots over 57 clusters, 87 on water and the five pinned ones named in the boot log. The collision flag map grows 1.1% (6,069,237 to 6,136,942 tiles), all of it water the map author left unmarked. Two traps worth the next reader's time. Config group 2's file list is SPARSE -- 137 files over ids 0..173 -- so zipping against 0..136 renames every definition above 91, where group 6 is dense and the same code is right. And water under a bridge reads as water from the raw terrain file but not through the collision map, which is the correct answer: `2387,3427` at Tree Gnome was one. The generator's own `water?/1` wants the same change; `Tools/dumps` is a separate tree and is not carried here. Not verified in play. `::tele 3106 3432` stands on the west bank with three of Barbarian Village's five candidates in view.