Keeping a dungeon's list of missing pieces true

Every dungeon I draw on the phone designer page has a manifest, a list of what the dungeon needs and whether the game already has it. It had gone stale, so I made the game answer it. Each row now names what in the game satisfies it, and a script recomputes the answers. On the four Breakout Site sheets that’s 51 rows, 25 of them had (14 before), 26 still to build, and 2 the script can’t check yet.

Why did the manifest go stale?

After the starting dungeon was joined to the game, floor 1’s manifest still said the game lacked the ruled starting chest and Subject 29’s ends, and its draft note still asked which door Carl’s key opens. All three were built. The page’s copy of floor 1 also still had two security doors, at (31,33) and (31,34). I’d said “just one door. I accidentally put two there”, and the dungeon’s file had already lost one, but importing the page’s copy again would have brought it back. Both were fixed in the same pass, and the plain door’s removal took floor 1 from 59 things to 58.

Giving each row a ref

A row is free text, so the script needs to be told what “the game has it” means. Each row gets a ref, one string or a list of them. A list is had only when every entry is.

• <kind>:<id>, like npc:helena or item:juice_injector, is had when that id is under that kind in content/registry.json.
• model:<stem> is had when <stem>.glb is installed anywhere under assets/models.
• class:<Name> is had when a script declares class_name <Name>.
• in:<path>#<text> is had when that file contains the text. This is for a person who is seated by the dungeon’s own file, as against one who is only on the workbench: in:content/dungeons/breakout_site.json#"helena" is had only once the file names her.
• A work-list id like S465 is had when that item is ticked in WORKLIST.md.

A ref the script can’t read, such as an unknown kind, counts as not had, and it says so. A row with no ref is reported and its have is left exactly as it was. The script never guesses.

Writing the answer back to the page

tools/dungeon_manifest.py reads the sheets I save from the page into a folder, and for each one whose manifest changed it writes a file holding only three fields: the new manifest, a draftNote with a dated line added, and a rev one higher than the sheet’s, so that the phone’s copy takes the update and doesn’t overwrite it. A second run replaces the dated line instead of stacking another. It prints what changed, row by row, with what answered it. The updates go to the page’s database in one batch, each carrying the version the listing showed, so a sheet that was edited in the meantime is refused instead of overwritten.

--check writes nothing and exits 1 if any sheet on the page is stale. --repo answers from another checkout, which mattered because the worker’s checkout was cut before the join landed.

Running it on the Breakout Site

The first pass turned 8 rows to had: the floors, the lifts on three floors, the start in the vat, the juice, the ruled starting chest and a note read. Carl, Subject 29 and Helena stayed to build until the join had landed. Run again on the main checkout, their rows turned to had because the dungeon’s file now names them. Two rows were added to floor 1 along the way, the people’s models and the site in the game’s own world.

What’s left

Two rows have no ref: a dead creature lying as scenery, and a readable log. Of the 26 rows still to build, 22 point at a work-list item that several rows share, so ticking the item marks all of them had. When a branch builds one of them, its row’s ref has to be changed to the thing itself, and nothing checks that yet. The game’s own copy of the manifest in the dungeon file isn’t refreshed, only the page’s, and the page doesn’t show a row’s ref.

The test, tools/dungeon_manifest_test.py, has 33 checks and they all pass.