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).
Übernommen aus todo-notes/done/overwrite-reset-nested.md beim Umzug auf das Issue-System (2026-09-12).
Angelegt: 2026-09-09 · 633f01c — Add five notes raised while the override work was running
Abgeschlossen: 2026-09-09 · d7c8d3e — Measure a deviation against the base, not the innermost template
Gemeldet von: admin
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).
---
*Übernommen aus `todo-notes/done/overwrite-reset-nested.md` beim Umzug auf das Issue-System (2026-09-12).*
- **Angelegt:** 2026-09-09 · `633f01c` — Add five notes raised while the override work was running
- **Abgeschlossen:** 2026-09-09 · `d7c8d3e` — Measure a deviation against the base, not the innermost template
- **Gemeldet von:** admin
admin
added the todo-note label 2026-09-12 15:03:50 +02:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
folgende fehlverhalten, beispiel jump and run projekt:
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 nichtmehr 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 dieBasis:
levelhaelt auf seinemc1-Objekt einen Edit fuer das darunterliegendecoin-body(die 8), und der gewinnt gegen das Template im
coin-Asset. Traegt dieses Template zufaelligschon 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.
InstanceTargethat jetztbase: das Template mit den Edits jedes Containersdazwischen eingewoben. Nur das ist ein Wert, auf den etwas zurueckfallen kann. Alles, was eine
Abweichung beurteilt, benutzt es:
setOverride/setName/setPosition, die beidenRevert…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
baseundtemplateidentisch, das Verhalten aendert sich dortnicht. Reset landet weiterhin auf 8 (deine Erwartung), 24 bleibt jetzt als Override stehen.
Drei Unit-Tests in
tests/core/apply.test.tshalten es fest; zwei davon schlagen ohne den Fixfehl (gegengeprueft).
Übernommen aus
todo-notes/done/overwrite-reset-nested.mdbeim Umzug auf das Issue-System (2026-09-12).633f01c— Add five notes raised while the override work was runningd7c8d3e— Measure a deviation against the base, not the innermost template