root
d7c8d3e579
An instance edit was dropped as soon as its value matched the template object. With nested containers the template is not what the value falls back to: the outer container holds an edit for the object below it, and that one wins. If the inner template happened to carry the same value the user typed, the edit was thrown away and the value jumped to whatever the container in between says. Reported against the Jump-and-Run project: a coin narrowed to 8 inside "level", then set back to the sprite's own 24 in the scene, snapped back to 8. Reproduced through the inspector before touching anything. InstanceTarget now offers `base`: the template with the edits of every container in between woven in. Everything that judges deviation uses it - setOverride/setName/setPosition, both Revert commands, and the gold marks in the inspector. Writing still goes into the real template, which is where "apply to container" belongs. `base` is built on every read. Apply writes into the template and then asks whether the edit still deviates, so a base captured beforehand would answer for the template as it was - the e2e suite caught exactly that. Also in here, because it corrects the commit before it: placing an asset by double-clicking its row is gone, as asked for in asset-doppelklick.md. Dragging is the only way to place now. That took AssetPanel.place, the PlacementTarget interface, Editor.placementTarget and the two worldCenter() methods that existed only to feed it. A double-click on a scene asset still makes it the active scene.
2.1 KiB
folgende fehlverhalten, beispiel jump and run projekt:
- wenn ich IM container asset "level" von einem einzigen coin sprite die breite ändere von 24 => 8
- wenn ich dann in der level scene bin und auf das geänderte coin sprite gehe und von 8 => 10 ändere funktioniert es noch
- sobald ich aber auf den original standard wert 24 ändere (oder auf den reset button klicke) dann springt es zurück auf 8 (ist korrekt bei reset, aber wenn ich explizit die ursprünglichen 24 haben will, geht das nicht, weil dieser wert nicht mehr als overwrite gilt)
Umgesetzt (2026-09-09). Reproduziert im Browser am echten Jump-and-Run-Stand: nach dem Tippen
von 24 stand {"ov":8} da, genau wie gemeldet. Deine Deutung war richtig — der Wert galt nicht
mehr als Override und wurde weggeworfen.
Ursache. Ein Instanz-Edit wurde geloescht, sobald der Wert dem Template-Objekt gleicht
(instanceRef.setOverride). Bei verschachtelten Containern ist das Template aber nicht die
Basis: level haelt auf seinem c1-Objekt einen Edit fuer das darunterliegende coin-body
(die 8), und der gewinnt gegen das Template im coin-Asset. Traegt dieses Template zufaellig
schon die 24 — was jede Ruecknahme auf den Asset-Wert in einem Container-Editor hinterlaesst,
weil ein gespeicherter Override nie geloescht wird — dann galten 24 als "gleich dem Template",
der Edit fiel weg und der Wert landete auf der Zwischenebene: 8.
Fix. InstanceTarget hat jetzt base: das Template mit den Edits jedes Containers
dazwischen eingewoben. Nur das ist ein Wert, auf den etwas zurueckfallen kann. Alles, was eine
Abweichung beurteilt, benutzt es: setOverride/setName/setPosition, die beiden
Revert…ToTemplate-Kommandos und die Gold-Markierung im Inspector. Das Schreiben von
"Apply to container" geht weiterhin ins echte Template — dort gehoert der Wert hin.
Bei einer einzigen Ebene sind base und template identisch, das Verhalten aendert sich dort
nicht. Reset landet weiterhin auf 8 (deine Erwartung), 24 bleibt jetzt als Override stehen.
Drei Unit-Tests in tests/core/apply.test.ts halten es fest; zwei davon schlagen ohne den Fix
fehl (gegengeprueft).