feat: terrain painting, prefab authoring, play-in-editor (PLAN §D/§E) — unpushed work#3
Conversation
## The bug that matters most here
`joinPath('.', 'assets/models')` returned `'./assets/models'`. The project file
lives in the CWD, so rootDir came out as '.', so the asset catalog was keyed
`'./assets/models/prop_tree.glb'` while every world file references
`'assets/models/prop_tree.glb'`.
Every model lookup missed. EVERY entity with a model rendered as a grey placeholder
cube -- all 88 trees, the building, every prop. The models loaded fine. Nothing
errored. The editor just quietly showed you a level made of boxes, which is
indistinguishable from "this level is made of boxes", and is exactly why it survived
this long. The editor was unusable for authoring and it was not obvious that it was.
'.' is not a directory component -- it is "here", and prefixing it produces a path
that is EQUIVALENT to the original but not EQUAL to it. The catalog is a Map; only
equal will do. Self-test pins the identity between catalog key and world modelRef.
## Prefab authoring (PLAN §E)
prefab-tool.ts had existed for weeks with ZERO call sites, because the UI it seemed
to need -- a parallel render path for children, a parallel selection model, parallel
gizmo handling -- was too big a job to start.
It needed none of that. A PrefabChild is an EntityData minus `name` and `userData`,
so while you edit a prefab its children simply ARE state.world.entities: the real
world is parked in a stash and the children are handed to the editor as the world.
Rendering, picking, the move/rotate/scale gizmos, delete, duplicate, snapping,
undo/redo -- all of it was already written against entities, and none of it needs to
know it is looking at a prefab.
- Prefabs tab: name field + "+ New Prefab"; "Edit <name>" for the selected prefab.
No double-click: the UI context has no notion of one, and a hidden gesture is
worse than a visible button.
- Ctrl+S saves the PREFAB, not the world -- saving the world from inside prefab mode
would write the neutral authoring stage over the real level.
- ESC restores the world AND its undo history exactly. Prefab mode gets its own
history; undoing past its start and landing in the world's edits would be
indefensible.
- Cycle rejection is TRANSITIVE (A->B->C->A), enforced at the one place a cycle can
be created, and it now SAYS so -- via a new transient status line. The editor had
no way to tell you it had refused something, and a click that silently does
nothing reads as a broken editor rather than a rule being enforced.
- Entering prefab mode frames the camera on the parts. Without it the camera stays
pointed at a 200 m arena and a three-prop prefab is three pixels of dust.
87 self-tests pass (was 81). Verified in the running editor: the arena now renders
its actual trees, building and river instead of grey boxes; prefab mode shows its
parts in the outliner, saves *.prefab.json, and restores the world on exit.
A Play button in the toolbar (and Ctrl+R). Saves the level currently ON SCREEN -- not the one on disk; making you save first would defeat the point -- to a scratch world, and launches the game on it via `--world <path>`. The fly-cam shows you geometry. It cannot show you whether the spawners spawn, whether the cover works, whether the arena has a shape -- the things a level actually has to do. And if testing a level means "add it to a manifest, restart the game, navigate the menu", it will not get tested often enough to matter. Needed two things that did not exist: engine EN-048 (launchProcess -- Perry's child_process.spawn COMPILES and then does nothing), and a `--world` override in the shooter. `playCommand` in editor.project.json opts a project in; without it there is no button, because a dead button is worse than no button. Verified end to end: editor -> scratch world (204,275 bytes) -> game launched on it, rendering the level the editor had just written. Claude-Session: https://claude.ai/code/session_01V3MihNxaRwMR8GjMPvMkRb
Paint the ground. The layer list is in the brush panel; the layers are the world's own `terrain.layers`, and the swatch beside each is the MASK colour the viewport tints it with — the viewport shows coverage, the game shows the material. - `paint` is a fifth brush kind. LMB paints, Shift+LMB erases. - `+ Add layer` picks a texture from the project's textures dir (new `texturesDir` key, default `assets/textures`). The catalog lists textures without loading them — a splat layer only ever stores a path, and decoding forty 2K PNGs so a panel can print their names would be the most expensive no-op in the program. - A splat is a PARTITION: painting grass in pushes everything else out, or the weights sum past 1 and a cell that is 90% grass AND 90% rock renders as a washed-out average of every texture at once. Erase drives the active layer to zero and does NOT push the others up, so coverage falls and the ground fades back to the game's procedural blend rather than to a bald patch. - Undo snapshots EVERY layer, not just the one you were holding. - Layers are rebuilt explicitly rather than with `.push()`/`.splice()`: they came from JSON.parse and get serialized back to disk (perry-quirks #2). +29 self-test assertions (116 total), covering the partition invariant, undo of a removed-but-painted layer, and the vertex-colour preview — including that adding an unpainted layer changes nothing. Claude-Session: https://claude.ai/code/session_01V3MihNxaRwMR8GjMPvMkRb
|
Warning Review limit reached
Next review available in: 55 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (18)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
These three commits existed only on one machine. They were committed to a
local
mainand never pushed — found while auditing what's outstanding acrossthe repos. The PLAN already marks this work ✅ DONE, which is true locally and
was invisible to everyone else.
90a9736joinPath('.', x)→'./x'made every model a grey box)b5e61898336186No changes of mine — pushing them as-is, via a branch/PR because that's the
convention every repo here uses.
Verified before pushing: the editor compiles clean against current engine
main, including theColortype/value split from Bloom-Engine/engine#102.Why this matters beyond the three commits
The audit rated these features "DONE" from the PLAN. They were done — and one
disk failure from gone. Worth a look at whether anything else is sitting
committed-but-unpushed.
https://claude.ai/code/session_01J1UWgMcrTNvwWeXcJ1T3Fp