1280df7ce0
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.
134 lines
6.2 KiB
Markdown
134 lines
6.2 KiB
Markdown
# 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](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 → n` should 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, which `pilot.py`'s own notes say has happened before.
|
||
|
||
## What is needed next
|
||
|
||
1. **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.
|
||
2. **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.
|