Two findings from #269. A reference from a container into a placement
nested in it was dead from the start, and deleting an asset left
references to the objects it took along showing "(missing)".
- A reference is stored the way its holder shows the object. In a
container tab that is q~x for content of a nested placement q.
- referenceCandidates translates it when the container is placed: in
placement r, q~x becomes r~q/x. pathOfId and idOfPath in instance.ts
do the mapping, objectChoices offers the same spelling the other way.
The rule holds at any depth.
- Storing q/x as proposed in #285 was dropped. The container tab would
then have had to translate its own ids.
- No migration. All projects and snapshots hold three references, none
of them with ~ or /.
- Create container lets a reference to content of a member placement
follow it. It was left dead before.
- Paste lets such a reference point into the copy. It kept pointing at
the original before. Both go through the new renamedReference.
- Delete asset records what every holder shows before the cascade and
clears every reference to an object that is gone afterwards, with
dropReferencesToGone from #269. The row shows None, undo restores
the references (#286).
Tests:
- Gate: 198 files, 2882 tests (2873 + 9), exit 0
- Unit object-references: 26 passed (17 + 9)
- e2e 1-17,57: 566 checks passed, 57 has +57i and +57j
- Six unit counter-probes fail between 1 and 3 tests each
- The browser counter-probe fails 57i and 57j as described in the
issues
- e2e total 1609 is computed, not measured in a full run
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Deleting an object in a container tab only cleared references inside
the template. Placements in scenes and other containers kept their
instance edit and showed "(missing)" in the inspector.
- shownObjectIds records which objects every holder shows before the
delete. dropReferencesToGone compares that with the state after it
and clears each reference that no longer resolves.
- A reference is resolved from its own place with referenceCandidates,
the same way the runtime does. One rule covers instance edits,
nested placements and full ids like p~crate.
- A cleared instance edit is dropped when it now says the same as the
template's own value. Without such a value a marked None stays, as
if picked by hand, and Reset hands the row back to the template.
- All cleared references come back with a single undo.
- References that were already dead in saved projects stay untouched.
Findings, not fixed here:
- A reference from container D into a nested placement q is stored as
q~<id>, but the copy is named r~q/<id> in every placement of D. The
runtime finds nothing, so that reference is dead from the start.
- Delete asset removes placed objects by cascade but does not clear
references to them.
Tests:
- Unit object-references: 17 passed (13 + 4)
- Gate: 198 files, 2873 tests, exit 0
- e2e 1-17,57: 564 checks passed, 57 has 13 (+1 for 57h)
- Five unit counter-probes and one browser counter-probe fail as
expected
- e2e total 1607 is computed, not measured in a full run
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The CI run for ded71a9 failed three checks in e2e 58 clipAreas. The
cause was the new step 57g, not the editor. It ends in the Variables
tab on purpose, and the clean-up of 57 then deletes the object whose
list that tab shows. The tab closes itself, and the editor falls back
to the last open document instead of the scene view. In the full run
earlier modules had left document tabs open, so 58 measured and
clicked in the wrong tab. Run on its own, 57 had no other document
open, which is why the module run before the push was green.
- 57 switches back to the scene view before its clean-up, with a
comment that says why.
- 58 sets the scene view itself at the start, as 44 and 51 already do.
It no longer depends on what the modules before it left open.
Tests:
- e2e 57,58 with the fix: ALL PASSED, 17 checks.
- Counter-check 57,58 and 54,57,58 without the fix: green, because no
other document was open.
- Counter-check with a graph tab left open before 57, without the fix:
3 FAILED with the same values as in CI. Same setup with the fix:
ALL PASSED, 17 checks.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Choosing the target of an object variable meant finding its name in
a dropdown. With many objects, or several with the same sprite, the
name alone does not say which one it is. The eyedropper lets you
click the object where you see it instead.
- Every object dropdown gets an eyedropper button next to it. This
covers variables, struct fields and list entries, in the Inspector
and in the Variables tab.
- The button opens the Scene View or the container tab the object
lives in. A strip above the view names the field and the current
candidate and offers Take and Cancel. The cursor is a crosshair.
- A click picks a candidate and writes nothing yet. The candidate
gets its own cyan frame, the selection stays on the object with
the variable.
- Clicking follows the selection rule. `pickOn` in
`src/viewport/pick.ts` uses `pressOn` and only counts objects the
dropdown offers. A click on empty space keeps the candidate.
- Enter or Take writes through the same handlers as the dropdown.
That is one undo step, or none if nothing changes.
- Esc, Cancel, a right click in the view or a second click on the
button cancel without writing. So do a tab switch, another
selection, undo, redo, play and loading a project.
- After Take or Cancel the editor goes back to the tab the pick came
from.
- While the eyedropper runs, the view does not drag, marquee, paint,
show handles or open its context menu. Panning and zooming stay.
Found on the way:
- Started from the Variables tab, the click missed the object. The
Scene View is hidden while that tab is open, and the layout skips
hidden children. The strip appeared then, the view moved down by
32 px but kept its old height. `Editor.display()` now lays the row
out again after showing it.
Tests (on melektaus-atx):
- unit pick and object-pick: 27 passed, 13 new
- gate: 196 files, 2844 tests, CHECK EXIT 0. Two more come from
svg-icons, which checks every icon twice.
- e2e 57: ALL PASSED, 12 checks, 5 new (57e to 57g)
- Counter-checks work. Without the layout fix 57g fails. Picking
objects the dropdown does not offer fails 2 tests. Writing on
cancel fails 2 more.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
CI has been red since f84defb. In the full run the scene holds more
than 40 filler objects from module 11. The object menu is height
limited and scrolls, and overlayTexts() only returns the visible rows.
Aim 57 and Crate 57 sit at the end of the scene and were never visible.
- Check None right after opening the menu, it is always the top row.
- Type 57 into the search field before looking for Aim 57 and
Crate 57 and before clicking Crate 57, like module 7 does with the
parent picker.
- No product code changes.
Tests:
- Reproduced with modules 1-11 and 57: the old test fails with the
same cut-off list and "nothing to click: Crate 57" as CI.
- New test: ALL PASSED - 405 checks, all 5 checks of 57 green.
- The full run could not be verified locally. Module 12 fails here
because the local server holds leftover uploaded images. It is
green in CI.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
An Object variable could only be set by a graph while the game runs.
A placed object always showed "(null)", although the other objects of
its scene are there to choose from and the runtime can already find
any object by its id. Now the placed object stores a reference to one
of them, and the running game turns it into the real object.
- Stored as {"$object": "<id>"}. The empty placeholder stays as it
was, so old projects load unchanged and empty still means "(null)".
- The row of an Object variable on a placed object is a dropdown with
None and every object of the scene, indented like the Hierarchy.
The same goes for Object fields in structs and Object items in
lists, also in the Variables and List tabs.
- The behavior asset keeps "(null)". An asset has no scene, so "Apply
to asset" is gone from Object rows.
- The runtime resolves the reference when the Variables or Properties
node reads it. A destroyed target reads as null, a missing one shows
"(missing)" in the row.
- Inside a container only objects of the same container are offered.
The reference keeps the template id, so every placement finds its
own copy.
- Deleting the target clears the reference in the same undo step.
Paste points references inside the pasted group at the copies and
leaves outside references alone. Create container and Unpack carry
references along with the new ids.
- A value a graph writes while running stays in the run. The scene
keeps the picked object, also in "Run in editor".
Found on the way:
- Setting an override coerced every object slot to empty, in plain
values, struct fields and list items. The shared objectPlace() now
keeps the reference.
Not done:
- No eyedropper to pick in the scene, the dropdown is enough for now.
- Deleting a template object in the container editor does not clean up
references in other scenes. They read as null there.
Tests:
- ./check.sh: 187 files, 2724 tests, CHECK EXIT 0
- e2e 1-9, 51, 57: ALL PASSED, 389 checks
- e2e 1, 57 on the final bundle: ALL PASSED, 17 checks
- 13 unit tests in object-references.test.ts, 5 checks in e2e 57
- Counter-checks: 8 unit breaks fail their tests, the browser break
without a pick list fails 57b-57d
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
adminandClaude Opus 5.5