fabi/Syplheed-Reborn
Archived
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

re: sites are entities 1:1 — withdraw "n is craft-per-member"

Browse Source 
The suspected confound turned out not to exist. Gaps between consecutive
same-unit definition-pointer sites are all >= 0x1000, with 274 of them exactly
0x1000, so entities are page-spaced and there are no near-adjacent pairs to
merge. Clustering at any threshold below 0x1000 gives ratio 1.00 for every unit
type, and hull is plausible on 298 of 298 clustered bases at delta 0x130. The
player shows two objects because there are two, not because one holds two
pointers.

That removes the excuse the previous iteration had used to keep the reading
alive, and the reading does not survive: sum(n) fits the turret row well (216
against 214, with kills already recorded), but DeltaSaber_T, Player and
Acropolis all come out at exactly twice their sum(n). An undershoot can be
blamed on phases 2-3 not having started; an overshoot cannot. n goes back to ❔
and the previous 🟡 is withdrawn. All the turret row establishes is that a
roster member expands into many craft, not that n is the factor.

Formation slot count was tested as the alternative and rejected outright: 630
turret slots against 214 live.

Side result worth keeping: a FormationSet record's FrameCount is its slot count,
and the name suffix usually agrees -- Turret07_30 -> 30, ArrowHead03_64 -> 64,
4_Bird -> 4 -- with one exception, AttackerS03_12 having 14 slots, so the suffix
is a label and not a guarantee.

Also recorded: the 298 live entities are not the 116 roster records. Both
structures exist at once, and the rule mapping one onto the other is the real
open question.

Probe caveat noted in the doc: entities2.moving() found no movers this run, so
the delta spectrum was empty and the clustering threshold was a fallback rather
than a measurement. It does not change the conclusion, since every gap exceeds
any threshold below 0x1000.
This commit is contained in:
Sylpheed RE agent
2026-08-24 13:13:43 +00:00
parent 356c4e70f8
commit a7cc4d6408
4 changed files with 192 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
docs/re/BACKLOG.md
View File

@@ -326,10 +326,14 @@ search cannot find a *schedule*.
(monotone 298→280). The hunting pilot **does** kill (hull crossing at t=57s).
🔴 "No births in 164 s" does NOT separate the wave models — everything is
pre-allocated, so an arrival must be a STATE CHANGE, not an allocation.
🟡 Turret `sum(n)`=216 vs 214 sites found (vs `Count`=21) suggests the mystery
member field `n` is the craft count per member — NOT promoted: the probe counts
definition-pointer *sites*, and the player (1 member → 2 sites) proves some
entities hold several. **Next: collapse sites into entities, then re-test.**
🔴 **`n` = craft-per-member is WITHDRAWN** (re-tested 2026-08-24): sites really
are entities 1:1 (all same-unit gaps ≥0x1000, hull plausible 298/298), so the
confound was not the explanation — and with it gone, `DeltaSaber_T`, `Player`
and `Acropolis` all come out at exactly **2×** `sum(n)`. An undershoot is
explainable by phases; an overshoot is not. `n` back to ❔. Formation slot count
also rejected (630 turret slots vs 214 live). ✅ Side result: `FormationSet`
`FrameCount` = slot count. ❔ **Open: the 116 roster records and the 298 live
entities are different structures; the expansion rule between them is unknown.**
* 🟡 **COMPETING MODEL (user, 2026-08-24): waves are event-gated, not
clock-driven** — released by kills/objectives rather than at a fixed time, with
the route's start time being a post-trigger delay. Fits the evidence better: