You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The set of Vulcanus tiles that block cliff placement - lava and lava-hot -
is written out in four places, with no shared definition and nothing asserting
the four agree.
want_lava, by NAME: name == "lava" || name == "lava-hot"
The last two sit on adjacent lines and say the same thing in two different
vocabularies, which is what makes this worth a ticket rather than a shrug: the
string form and the enum form can drift apart without either file changing.
Why it is not currently wrong
The values agree today; that was checked. The risk is entirely about what
happens when the set changes. vulcanus_fields.rs:195 records that the set was
established by measurement - "Switching lava and lava-hot out of the tile
autoplace category and regenerating is what established the set, not a reading
of tile_collision_masks" - so a future tile that blocks cliffs would be found
the same way, and would then need editing in four places, one of which is a
string literal in a fixture helper.
Shape of a fix
One definition per side, and a test that the two sides agree:
Rust: a const or an is_cliff_blocking(VulcanusTile) -> bool in tiles/vulcanus_catalog.rs, used by vulcanus_fields.rs and by both helpers
in fixtures.rs. The name-based want_lava should go through VulcanusTile's existing name mapping (vulcanus_catalog.rs:95) rather than
matching strings of its own.
The set of Vulcanus tiles that block cliff placement -
lavaandlava-hot-is written out in four places, with no shared definition and nothing asserting
the four agree.
src/noise/cliffs/cliffCatalog.ts:447new Set(["lava", "lava-hot"])crates/fmw-noise/src/cliffs/vulcanus_fields.rs:220matches!(tile, VulcanusTile::Lava | VulcanusTile::LavaHot)crates/fmw-noise/src/fixtures.rs:3632is_lava, the same enum match againcrates/fmw-noise/src/fixtures.rs:3633want_lava, by NAME:name == "lava" || name == "lava-hot"The last two sit on adjacent lines and say the same thing in two different
vocabularies, which is what makes this worth a ticket rather than a shrug: the
string form and the enum form can drift apart without either file changing.
Why it is not currently wrong
The values agree today; that was checked. The risk is entirely about what
happens when the set changes.
vulcanus_fields.rs:195records that the set wasestablished by measurement - "Switching lava and lava-hot out of the tile
autoplace category and regenerating is what established the set, not a reading
of
tile_collision_masks" - so a future tile that blocks cliffs would be foundthe same way, and would then need editing in four places, one of which is a
string literal in a fixture helper.
Shape of a fix
One definition per side, and a test that the two sides agree:
constor anis_cliff_blocking(VulcanusTile) -> boolintiles/vulcanus_catalog.rs, used byvulcanus_fields.rsand by both helpersin
fixtures.rs. The name-basedwant_lavashould go throughVulcanusTile's existing name mapping (vulcanus_catalog.rs:95) rather thanmatching strings of its own.
cliffCatalog.ts, as of Rehome the symbols the dead set still owes surviving code (#227) #361.VULCANUS_CLIFF_BLOCKING_TILESholdthe same names, so a change on one side that misses the other is loud.
Found while auditing #227's phase 7; the TypeScript side moved to
cliffCatalog.tsin #361 and is not affected by the deletion.