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.
931 B
931 B
Der E2E-Check pixel-art filtering keeps the border between two quadrants hard faellt
sporadisch um — heute (2026-09-09) zweimal in vier Laeufen, jeweils ohne dass eine Aenderung
Texturen beruehrt haette.
- gruen:
["#e63c3c","#e63c3c","#3cc85a","#3cc85a","#3cc85a"]— harte Kante,nearestgreift - rot:
["#c65641","#a67047","#868a4c","#66a552","#3cc85a"]— weicher Verlauf, alsolinear
Der Folge-Check (switching the filter back to smooth …) meldet im Fehlerfall fuer beide
Filter denselben Verlauf, ist aber trotzdem gruen — er vergleicht nicht gegen den Erwartungswert.
Das heisst: wenn der Filterwechsel haengt, faellt genau ein Check, und der zweite deckt es zu.
Zu klaeren: laedt der Test die Textur zu frueh aus (Timing), oder wird scaleMode beim ersten
Setzen manchmal nicht auf die schon hochgeladene GPU-Textur durchgereicht (dann ist es ein echter
Produktfehler und kein Testproblem)?