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

re: find the roster-to-craft link — a pointer at roster_base + 0x08

Browse Source 
The previous iteration was right that neither structure points at the other's
base, and wrong to stop there. Craft point eight bytes into a roster record.

Resolving the 5101 "pointers into the roster range" by distance to the nearest
roster base gives a distribution that is neither flat nor diffuse: +0x08 appears
exactly 300 times, matching the 300 live craft, while every other delta appears
at most twice and 4780 of 5104 land more than 0x4000 from any base.

A count matching a count is the coincidence that has already misled this corpus
three times, so the link was tested on something a coincidence cannot survive.
Each side's unit type is resolved by a different chain -- the craft's from its
definition pointer at +0x130, the record's from its +0x04 name chain -- and they
must agree. They do, on all 300, with zero disagreements, and the fan-out
histogram is [(1, 300)]: every craft has exactly one such pointer, none has zero
or two.

The fan-in is the useful half. Only 41 of the 116 roster records are referenced
at all; the other 75 have no craft. Craft per referenced record is discrete:
24 records with 2, one with 4, four with 8, and twelve with 18 -- summing to
exactly 300. The twelve holding 18 are all e007 Turret.

This is the observable four iterations have been hunting. A member with zero
craft is not deployed; a member's craft count is its live strength; so an
arrival is craft appearing for a record that had none and a kill is that count
falling. Both are attributable to a named squadron, because the record is a
UnitGroup member and UnitGroup names the squadron that Route_S02.tbl ties to a
phase and an arrival time. The chain from a memory observation to a static route
entry is complete.

Not claimed: that the 75 undeployed members are waiting on phases 2 and 3. That
is a plausible reading, but the run only shows they have no craft.
This commit is contained in:
Sylpheed RE agent
2026-08-24 13:48:39 +00:00
parent ad18465519
commit 46e511e791
5 changed files with 234 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

13
docs/re/BACKLOG.md
View File

@@ -339,9 +339,16 @@ search cannot find a *schedule*.
`0xbdb2fd80`–`0xbdcd1d80`). Craft count varies run to run (296/298/300), so it
must only be compared WITHIN a run. ❔ **Still open: the expansion rule.** Four
candidates now dead — `Count`, `n`, formation slots, head pointers.
**Next test:** for the 5101 craft words pointing into the roster VA *range*,
plot the distance to the nearest roster-record base; a spike at one delta means
a link at `base+X`, a flat distribution kills the thread.
✅✅ **SOLVED (2026-08-24): the link is a pointer at `roster_base + 0x08`.**
The delta histogram spiked at `+0x08` with exactly 300 hits for 300 craft.
Verified on something a coincidence cannot survive — each side's unit type
resolved by a *different* chain (craft via def pointer `+0x130`, record via
`+0x04` name chain) — **agreeing 300/300, 0 disagreements**, fan-out `[(1,300)]`.
Fan-in: only **41 of 116** records have craft (2×24, 4×1, 8×4, 18×12 = 300).
⇒ **an arrival is craft appearing for a record that had none; a kill is that
count decreasing — both attributable to a named squadron**, hence to a route.
**Next:** watch PER-RECORD craft counts over a mission (not the global total);
that is the kill-vs-no-kill test with squadron resolution.
* 🟡 **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:

89
docs/re/roster-to-craft-link.md
View File

@@ -62,3 +62,92 @@ names directly. Since an arrival is already known to be a *state change* rather
than an allocation ([mission-liveness-probe.md](mission-liveness-probe.md)),
finding the mediating structure matters more than finding a flag: it is what
would let a change be attributed to a named squadron and therefore to a route.
---
# ✅ FOUND: the link is a pointer at `roster_base + 0x08` (2026-08-24)
The refutation above was right that neither object points at the other's **base**
— and wrong to stop there. Craft point *8 bytes into* a roster record.
## How it was found
The 5101 "pointers into the roster range" were resolved by distance to the
nearest roster-record base below. The distribution is not flat and not diffuse:
```
+0x00008 x300 5.9% <- exactly the number of live craft
+0x034b2 x2
+0x02d97 x2
... every other delta appears at most twice
(4780 of 5104 land >0x4000 from any base -- unrelated heap traffic)
```
One delta, hit exactly as many times as there are craft.
## ✅ Verified by an independent cross-check, 300/300
A count matching a count is the sort of coincidence that has already misled this
corpus three times, so the link was tested on something a coincidence cannot
survive: **each side's unit type is resolved by a completely different chain**,
and they must agree.
* the craft's type comes from its definition pointer at `+0x130`;
* the roster record's type comes from its `+0x04` name chain
([mission-wave-arrivals.md](mission-wave-arrivals.md)).
Result:
| check | result |
|---|---|
| craft fan-out at `base+0x08` | **`[(1, 300)]`** — every craft has exactly one |
| craft with no link | **0** |
| craft with more than one | **0** |
| **unit type agrees** | **300** |
| unit type disagrees | **0** |
Two independently-derived labels agreeing on all 300 objects settles it.
## ✅ What the fan-in shows: 41 of 116 members have craft
Only **41 of the 116** roster records are referenced by any craft. The rest have
none at all. The distribution of craft per referenced record is strikingly
discrete:
| craft per record | records |
|---|---|
| 2 | 24 |
| 4 | 1 |
| 8 | 4 |
| **18** | **12** |
24·2 + 1·4 + 4·8 + 12·18 = **300**, exactly.
The twelve records holding 18 craft each are all `UN_e007_ADAN_Turret`, giving
216 turret craft — which is also what `sum(n)` predicted for turrets, though
that agreement is not being promoted again on its own after the last withdrawal.
## Why this matters for the wave question
This is the observable that four iterations have been looking for:
* a roster member with **zero** craft has not been deployed;
* a member's **craft count is its live strength**;
* therefore an **arrival is craft appearing for a record that had none**, and a
**kill is that count decreasing** —
and, crucially, both are **attributable to a named squadron**, because the roster
record is one `UnitGroup` member and `UnitGroup` names the squadron, which
`Route_S02.tbl` ties to a phase and an arrival time. The chain from a memory
observation to a static route entry is now complete.
75 of 116 members being undeployed at this point in Stage 02 is consistent with
phases 2 and 3 not having started, but that is an interpretation, not a
measurement — the run only shows they have no craft.
## Next
Watch the per-record craft counts over a mission, not the global total. A record
going 0 → n is an arrival; n → n−1 is a kill. That is the kill-versus-no-kill
experiment the event-gated model needs, and it now has a signal with squadron
resolution.