Matching a secret wall to its repainted walls in Godot
The illusion wall stuck out after the walls were repainted. It now wears the same material, and notes written on a dungeon sheet can be read.
The secret wall in the Breakout Site’s juice vat room stuck out after I repainted the dungeon walls. It wears exactly what the walls beside it wear now, so from the corner of the room it’s one wall with three panels. I also made the notes written on a dungeon sheet readable, and fixed a test that only failed when the whole suite ran.
Why did the secret wall stand out?
After I redid the walls, the secret door in the starter dungeon no longer matched them. The panel at tile (13,3) wore its piece’s baked material, while the walls around it had moved to the painted set from the repaint.
The fix was to put the choice in one place. DungeonInterior.material_shown() returns what a laid piece wears on a given floor, painted where the floor is painted, and both build() and the illusion call it:
static func material_shown(member: String, of_theme: String, state: String,
on: DungeonPlan, origin := Vector3.ZERO) -> Material:
var material := material_of(member, of_theme, state, origin)
if PaintedSurface.paints(on):
material = PaintedSurface.material_for(member, origin, material,
PaintedSurface.theme_of(on))
return material
A later repaint reaches the illusion without touching it. On a floor of flat faces, the cover is a plate over the mouth and takes PaintedSurface.face(plan, "wall", ...) the same way.
That broke the fade. The illusion used to thin out by duplicating the wall’s material and animating its alpha, and a painted wall is a shader, so there was nothing to duplicate. It now fades with the instance’s transparency, and a faint violet overlay comes up and goes again by the end of the fade.
How can a note on a dungeon sheet be read?
The dungeon generator stocks notes the party should read, like a line sheet or a code on a tag, as item things whose item is a description in words. The importer built nothing for those, so the hub-code floor’s code wasn’t in the game.
DungeonNotes reads the dungeon files and treats any item that isn’t a valid id (a capital or a space gives it away) and has no refinement as a note. An id-shaped word that isn’t an item is still an error, so a typo gets caught. Each note becomes a generated item with the thing’s id, registered next to the dungeon keys. A small table picks its name and look from the words: a tag or card lies as a tag, anything else as a sheet of paper. The look is built in code, flat on the floor under a small light, and when it’s picked up it opens on the note screen.
The test loads the generated hub-code floor, reads the code off the note, types it on the door’s keypad, and checks the door opens. The film does the same thing: the note says 9583 and the door opens.
Contact sheet of the film, with the wall before and after, the note, the keypad and the opened corridor.
Why did monster_profiles fail only in the crowd?
The test said an idle warden takes half of the first hit on an ally 10 m away. In the full suite the ally took all of it. The warden was asleep. An idle warden far from the party sleeps and only thinks once a second of physics, on a step set by its instance id, and puts its guard up for half a game second. The test struck a fixed 0.5 s after the spawn, which landed inside or outside the guard depending on the instance id and how many physics steps a second took on a loaded machine. The test now waits until the ally is guarded. I ran the monster and dungeon tests twice, 24 each time, and none failed.
There’s a real fault under it that I filed separately. An ally hurt by a trap or another monster’s blast is unguarded about half the time while its warden sleeps, but the rule I decided on is half of all damage to allies within 15 m. I can either make a sleeper’s guard last at least a full nap, or ask the warden for its guard when the hit lands. I haven’t picked yet.