86c918f399
Two further runs sampled the counts from the instant flight is detected. Both give 116 roster records in the very first sample, flat thereafter, with 14 unit definitions throughout. That is not a load race: a race would climb toward 116 from below, and it never does. The leading explanation was arithmetic rather than behavioural -- census_probe counts raw aligned vtable hits while wave5_probe counted distinct primary_va values, which are different quantities if an offset can alias to a VA another offset also claims. Measuring both in the same run refutes it: 116 raw hits and 116 distinct VAs in every sample. So the outlier stands unexplained. Four runs now read 116/300, 116/300, 116/296 and one 42/170, with save drift, freezing, load race and VA aliasing each individually refuted. Recorded rather than dropped, because a one-in-four anomaly in the measurement apparatus is what later turns into a wrong conclusion. Practical rule adopted: discard a run that disagrees with 116 rather than interpreting it, and reproduce any finding in at least two runs. Useful new fact: craft declines steadily and monotonically in both runs, 300 to 288 and 296 to 280, roughly 16-20 losses over 168 s under the hunting pilot. Whether the player or NPC crossfire is responsible is not determined here, but destruction is visible in this signal, which is half of what the kill-versus- no-kill experiment needs. Still not observed in any run: an arrival.
6.2 KiB
Per-record craft strength — the measurement works, the run does not reproduce
Status: ✅ the per-record measurement is internally consistent; 🔴 it does not reproduce across runs, and that is now the blocker; 🔴 zero arrivals and zero losses in 190 s of hunting, which does not test the event-gated model.
Follows roster-to-craft-link.md: craft point at
roster_base + 0x08, so a member's live strength is how many craft point at it,
and an arrival should be a 0 → n transition on one record.
✅ The measurement itself is sound
tools/re-capture/wave5_probe.py counted craft per roster record every ~20 s.
The first sample:
craft=170 deployed records=24/42 strength histogram [(2, 11), (8, 2), (12, 11)]
11·2 + 2·8 + 11·12 = 170, exactly the craft total. The per-record decomposition is internally consistent, and 24 of 42 records deployed with 18 holding nothing is the same shape as the previous run's 41 of 116.
🔴 But the numbers do not reproduce across runs
| run | roster records | craft | deployed | strengths |
|---|---|---|---|---|
| link2 (earlier) | 116 | 300 | 41 | 2, 4, 8, 18 |
| wave5 (this one) | 42 | 170 | 24 | 2, 8, 12 |
Same disc, same save slot, same launch script, same stage.
The save has not drifted — that was the first suspicion and it is refuted:
content/.../game01/savedata is unmodified since 2026-08-23 16:37; only the
profile .gpd files were written today.
The guest was not frozen — the pilot's telemetry over the same 190 s shows
speed varying across dozens of values and a live engagement (tgt=e007_ADAN_Turret
at 259–680 m), so the game was advancing normally.
So the discrepancy is real and unexplained. Candidates, none tested:
- the probe samples at a different point in the mission's deployment and the roster-record set is still being built (argued against by the counts being completely static for 190 s afterwards — if it were still loading, it should have grown toward 116);
gmem.extents()races the emulator's allocation, so the vtable scan sees a different set of extents between runs;- deployment strength genuinely varies per run (turret squadrons at 18 vs 12).
Until this is understood, per-record counts cannot be used as a time series, and no cross-run comparison of them means anything. This is the same discipline already recorded for the global craft count, now needed one level down.
🔴 Zero arrivals, zero losses in 190 s
Every sample was identical: 170 craft, 24 deployed, no 0 → n, no n → n−1.
- Against the clock model, weakly: if phase-1 arrivals were at t = 90/120/170
seconds, a
0 → nshould have appeared, and none did. - It does not test the event-gated model at all, because nothing was killed.
The pilot engaged continuously — closing to 259 m on turrets — but
fc=0, no record lost strength, and the player's own hull never moved off 1500. It shot and missed, whichpilot.py's own notes say has happened before.
What is needed next
- Explain the 42-vs-116 discrepancy before trusting any per-record series. Cheapest test: sample the roster-record count repeatedly within one run, starting the instant flight is detected. If it climbs, it is a load race; if it is flat at a run-specific value, it is not.
- Get a confirmed kill. Without one, the kill-versus-no-kill experiment cannot run. The pilot reaches firing range and does not destroy anything, so the gap is accuracy, not engagement.
The 42-vs-116 outlier does not reproduce (2026-08-24)
Status: ✅ the baseline is stable and it is not a load race; 🔴 the VA-aliasing explanation is refuted; 🟡 the outlier itself stays unexplained; ✅ losses are observable.
tools/re-capture/census_probe.py samples the raw counts every 12–20 s from the
instant flight is detected, and also reports what the scan is looking at.
✅ Two further runs, both stable at 116
t roster distVA craft defs extents MB
0 116 116 300 14 272 342.2
60 116 116 294 14 262 342.3
120 116 116 292 14 258 342.4
168 116 116 288 14 258 342.4
and a second run, 116 throughout, craft 296 → 280.
Not a load race. The roster count is 116 in the very first sample and never moves — it does not climb toward 116 from below, which is what a race would look like. Definitions are 14 throughout, matching Stage 02's 14 unit types.
🔴 Refuted: VA aliasing was not the cause
The leading hypothesis was arithmetic rather than behavioural: census_probe
counts raw aligned vtable hits, while wave5_probe counted distinct
primary_va values, and if one offset can alias to a VA another offset also
claims, those are simply different numbers. Measuring both in the same run
settles it: 116 raw hits, 116 distinct VAs, in every sample. They are the
same number here, so the difference in what was counted cannot explain 42.
🟡 The outlier stands, unexplained
Four runs now: 116/300, 116/300, 116/296 — and one 42/170. Same disc, save, script and stage; save drift, freezing, load race and VA aliasing are all individually refuted. I do not know what produced it.
What that changes in practice: the baseline is trustworthy enough to build on, but any single run that disagrees with 116 should be discarded rather than interpreted, and a result must be reproduced in at least two runs before it is written down as a finding. Recorded rather than quietly dropped, because a one-in-four anomaly in the measurement apparatus is exactly the kind of thing that later turns into a wrong conclusion.
✅ Losses are observable; arrivals still are not
Craft declines steadily and monotonically in both runs — 300 → 288 and 296 → 280, roughly 16–20 losses over 168 s under the hunting pilot. Whether the player or the NPC crossfire is responsible is not determined here; what matters is that destruction is visible in this signal.
No arrival has yet been seen in any run. The per-record 0 → n watch is still
the right instrument, and it can now be run against a known-good baseline.