Aus #269 (dort gefunden, nicht behoben). Der Fehler stammt aus #258.
Befund
Ein Objekt in Container D kann auf Inhalt einer verschachtelten Platzierung q in D zeigen. Die Wahl im Inspector bietet dafür q~<id> an, und so wird der Verweis auch gespeichert.
In jeder Platzierung r von D heißt die Kopie aber r~q/<id>, nicht r~q~<id>. Der gespeicherte Verweis passt also in keiner Platzierung.
Mit einer Wegwerf-Sonde nachgewiesen: Die Laufzeit findet für den Verweis nichts, und in der Szene bietet der Inspector q/<id> an. Der Verweis ist damit von Anfang an tot, nicht erst nach einem Löschen.
dropReferencesToGone aus #269 fasst solche Verweise nicht an: Sie haben schon vorher nichts gezeigt, also verschwindet auch nichts.
Zu klären, bevor gebaut wird
Welche Form ist die richtige? Entweder speichert der Container die Form, die in seinen Platzierungen gilt (q/<id>), oder die Auflösung (referenceCandidates und die Laufzeit) übersetzt q~<id> beim Platzieren. Vorschlag: Die Wahl in D speichert gleich die Form, die in den Platzierungen gilt, damit es nur eine Schreibweise gibt.
Bestehende tote Verweise dieser Art? Vorschlag wie in #269: keine Migration, sie verschwinden beim nächsten Setzen.
Tests (Vorschlag)
Unit: Container D mit verschachtelter Platzierung q, ein Objekt in D zeigt auf ein Objekt in q. D ist in einer Szene platziert. Die Laufzeit findet dort das richtige Objekt, und der Inspector zeigt seinen Namen statt (missing).
e2e 57 um einen Block erweitern, der den Verweis im Container-Tab mit echter Maus setzt und in der Szene prüft.
Aus #269 (dort gefunden, nicht behoben). Der Fehler stammt aus #258.
## Befund
- Ein Objekt in Container D kann auf Inhalt einer verschachtelten Platzierung q in D zeigen. Die Wahl im Inspector bietet dafür `q~<id>` an, und so wird der Verweis auch gespeichert.
- In jeder Platzierung r von D heißt die Kopie aber `r~q/<id>`, nicht `r~q~<id>`. Der gespeicherte Verweis passt also in keiner Platzierung.
- Mit einer Wegwerf-Sonde nachgewiesen: Die Laufzeit findet für den Verweis **nichts**, und in der Szene bietet der Inspector `q/<id>` an. Der Verweis ist damit von Anfang an tot, nicht erst nach einem Löschen.
- `dropReferencesToGone` aus #269 fasst solche Verweise nicht an: Sie haben schon vorher nichts gezeigt, also verschwindet auch nichts.
## Zu klären, bevor gebaut wird
1. **Welche Form ist die richtige?** Entweder speichert der Container die Form, die in seinen Platzierungen gilt (`q/<id>`), oder die Auflösung (`referenceCandidates` und die Laufzeit) übersetzt `q~<id>` beim Platzieren. Vorschlag: Die Wahl in D speichert gleich die Form, die in den Platzierungen gilt, damit es nur eine Schreibweise gibt.
2. **Bestehende tote Verweise dieser Art?** Vorschlag wie in #269: keine Migration, sie verschwinden beim nächsten Setzen.
## Tests (Vorschlag)
- Unit: Container D mit verschachtelter Platzierung q, ein Objekt in D zeigt auf ein Objekt in q. D ist in einer Szene platziert. Die Laufzeit findet dort das richtige Objekt, und der Inspector zeigt seinen Namen statt `(missing)`.
- e2e 57 um einen Block erweitern, der den Verweis im Container-Tab mit echter Maus setzt und in der Szene prüft.
Done in 5e21d47 (together with #286), wiki 12a2b16 (Behaviors, Containers, Development).
Question 1: which spelling
The stored spelling stays the one the container tab shows: q~x for content x of a placement q nested in the container. The lookup translates it instead.
The proposal here (store q/x) is dropped. With it the container tab itself would have had to translate, because there the object is called q~x. Now one rule holds for every holder: a reference is written the way its holder shows the object.
What changes
In a container tab an object can pick content of a container placed inside it, and the reference works in every placement, in the inspector and in the running game.
In a placement r of the container, q~x resolves to r~q/x. pathOfId and idOfPath in src/core/model/instance.ts do the mapping, used by referenceCandidates and objectChoices in objectRefs.ts. The rule holds at any depth.
Question 2: no migration, as proposed. None would have been needed either: all projects and snapshots hold three references, none of them with ~ or /.
Taken along, the same mistake in two more places
A reference to content of a placement (q~x) used to get lost:
Create container left it dead. Now it points at q'~x inside the new template and at c~q'/x from outside.
Pasting a copy left it pointing at the original. Now it points into the copy.
57i picks "Nest 57" from the nested placement in the container tab with the real mouse. The reference is then stored as or57-o-inner~or57-i-nest, the row in the scene shows the name, and a Play run logs "Nest 57".
Six unit counter-checks work, each bent on its own in a container copy. Each one fails between 1 and 3 tests, and the clean state is back at 26 of 26.
The browser counter-check works too, with a build that compiles: 57i then fails with exactly the picture from this issue, the runtime reads "".
Screenshot checked: target shows "Nest 57".
The e2e total of 1609 is computed (1607 + 2). CI is still switched off, so there is no run for 5e21d47.
Done in `5e21d47` (together with #286), wiki `12a2b16` (*Behaviors*, *Containers*, *Development*).
**Question 1: which spelling**
- The stored spelling stays the one the container tab shows: `q~x` for content x of a placement q nested in the container. The lookup translates it instead.
- The proposal here (store `q/x`) is dropped. With it the container tab itself would have had to translate, because there the object is called `q~x`. Now one rule holds for every holder: a reference is written the way its holder shows the object.
**What changes**
- In a container tab an object can pick content of a container placed inside it, and the reference works in every placement, in the inspector and in the running game.
- In a placement r of the container, `q~x` resolves to `r~q/x`. `pathOfId` and `idOfPath` in `src/core/model/instance.ts` do the mapping, used by `referenceCandidates` and `objectChoices` in `objectRefs.ts`. The rule holds at any depth.
- **Question 2:** no migration, as proposed. None would have been needed either: all projects and snapshots hold three references, none of them with `~` or `/`.
**Taken along, the same mistake in two more places**
A reference to content of a placement (`q~x`) used to get lost:
- *Create container* left it dead. Now it points at `q'~x` inside the new template and at `c~q'/x` from outside.
- Pasting a copy left it pointing at the original. Now it points into the copy.
Both go through the new helper `renamedReference`.
**Tests** (on `melektaus-atx`)
```
gate 198 files, 2882 tests, CHECK EXIT 0 (2873 + 9)
unit object-references 26 passed (17 + 9)
e2e 1-17,57 ALL PASSED - 566 checks (57: +57i, +57j)
```
- **57i** picks "Nest 57" from the nested placement in the container tab with the real mouse. The reference is then stored as `or57-o-inner~or57-i-nest`, the row in the scene shows the name, and a Play run logs "Nest 57".
- Six unit counter-checks work, each bent on its own in a container copy. Each one fails between 1 and 3 tests, and the clean state is back at 26 of 26.
- The browser counter-check works too, with a build that compiles: 57i then fails with exactly the picture from this issue, the runtime reads `""`.
- Screenshot checked: *target* shows "Nest 57".
- The e2e total of 1609 is computed (1607 + 2). CI is still switched off, so there is no run for `5e21d47`.
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.
Aus #269 (dort gefunden, nicht behoben). Der Fehler stammt aus #258.
Befund
q~<id>an, und so wird der Verweis auch gespeichert.r~q/<id>, nichtr~q~<id>. Der gespeicherte Verweis passt also in keiner Platzierung.q/<id>an. Der Verweis ist damit von Anfang an tot, nicht erst nach einem Löschen.dropReferencesToGoneaus #269 fasst solche Verweise nicht an: Sie haben schon vorher nichts gezeigt, also verschwindet auch nichts.Zu klären, bevor gebaut wird
q/<id>), oder die Auflösung (referenceCandidatesund die Laufzeit) übersetztq~<id>beim Platzieren. Vorschlag: Die Wahl in D speichert gleich die Form, die in den Platzierungen gilt, damit es nur eine Schreibweise gibt.Tests (Vorschlag)
(missing).Done in
5e21d47(together with #286), wiki12a2b16(Behaviors, Containers, Development).Question 1: which spelling
q~xfor content x of a placement q nested in the container. The lookup translates it instead.q/x) is dropped. With it the container tab itself would have had to translate, because there the object is calledq~x. Now one rule holds for every holder: a reference is written the way its holder shows the object.What changes
q~xresolves tor~q/x.pathOfIdandidOfPathinsrc/core/model/instance.tsdo the mapping, used byreferenceCandidatesandobjectChoicesinobjectRefs.ts. The rule holds at any depth.~or/.Taken along, the same mistake in two more places
A reference to content of a placement (
q~x) used to get lost:q'~xinside the new template and atc~q'/xfrom outside.Both go through the new helper
renamedReference.Tests (on
melektaus-atx)or57-o-inner~or57-i-nest, the row in the scene shows the name, and a Play run logs "Nest 57"."".5e21d47.