46e511e791
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.
6.2 KiB
The 116 roster records and the ~300 live craft are not directly linked
Status: 🔴 a direct pointer link is refuted in both directions; ✅ the two structures are in distinct heap regions; ❔ how a roster member expands into craft is still unknown.
Four attempts have now failed to explain how 116 roster members become ~300
live craft — Count (116), the member field n (387), formation slot count
(630, rejected), and now a pointer link. This records the fourth so it is not
retried.
The two structures
| vtable / locator | count | VA range (measured) | |
|---|---|---|---|
| roster records | 0x820AF030 |
116 | 0xbc372c00 … 0xbc9bc720 |
| live craft | def-pointer site − 0x130 |
296–300 | 0xbdb2fd80 … 0xbdcd1d80 |
| unit definitions | 0x820AF844 |
14 | — |
They are in different regions, ~19 MB apart, and neither range overlaps the other. The 14 definitions match Stage 02's 14 distinct unit types exactly.
The craft count is not fixed: three runs at comparable mission times gave 296, 298 and 300. That is expected now that kills are confirmed, but it means the craft population must be compared within a run, never across runs.
🔴 Refuted: neither structure points at the other
tools/re-capture/link_probe.py scans the first 0x400 bytes of every object
for a word equal to a known address of the other kind.
- roster record → craft base: 0 of 116 records hold one.
- craft → roster record base: 0 of 300 craft hold one.
Both directions are empty, so whatever associates a member with its craft is not a pointer at the head of either object.
❔ The one loose thread, and why it is not evidence yet
The same scan counted pointers into the ranges rather than at exact bases:
- roster words pointing anywhere into the entity heap: 181, of which only
2 land within
0x400of a known craft base; - craft words pointing anywhere into the roster VA range: 5101.
5101 looks like a lot, but the roster range spans 6.5 MB and certainly holds many allocations besides the 116 records, so pointers "into the range" may have nothing to do with roster records at all. This is deliberately not being read as a link.
The test that would make it evidence: for each of those 5101 pointers, compute
the distance to the nearest roster-record base below it. If the association is
"craft points at roster_base + X" for some fixed X, that distribution spikes
at a single delta. If it is flat, the pointers are unrelated allocations and the
thread is dead.
What this means for the wave question
The association may not be a pointer at all — it could be an index, a hash, or mediated by a third object (a squadron or formation instance) that neither side names directly. Since an arrival is already known to be a state change rather than an allocation (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
+0x04name chain (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.