re: a unit field left unset on disc is not a global constant — Size_Y inherits Size_X
Attacks the 21/110 unit-coverage limit from the cheap side: if a defaulted field always took one runtime value, the captured units would pin it for all 110. Only 6 of 24 confirmed defaulted fields behave that way. The other 18 vary per unit, so the default is computed. Asking which OTHER field of the same unit holds that value — counting only non-zero cases, and checking the two fields sit at different offsets so the layout solver cannot be aliasing them — gives four rules. Size_Y <- Size_X is solid: seven unrelated ships (e105 600, e106 300, e108 80, e201 300, f101 400, f105 700, f106 200) each omit it on disc and each shows its own Size_X live, while the two fields differ freely when both are on disc. Size_Radius fits both min(X,Z) and the median of the three axes and cannot yet be separated; e010_ADAN_Attacker_S is what rules out the simpler Size_X rule. FCSRange and DefencePoint rest on two independent units each and ship as HYPOTHESIS. Applied across the disc the rules recover 65 (unit, field) values in units that have never been visited. Falsification test recorded: load any uncaptured stage and compare one predicted value. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -272,3 +272,55 @@ take-off, ~12 minutes in mid-combat, and after GAME OVER. 14 objects, the same
|
||||
is no need to play it, and no need to survive it.
|
||||
|
||||
Stages captured so far: `Ttrl` (BASIC CONTROLS), Stage 02.
|
||||
|
||||
## A defaulted unit field is not a global constant — some inherit from a sibling
|
||||
|
||||
**Confidence: 🟡 for `Size_Y`, ❔ for the rest. Analysis 2026-08-10, offline, from
|
||||
[`captures/unit-runtime-fields.csv`](../captures/unit-runtime-fields.csv).**
|
||||
|
||||
The coverage limit above (21 of 110 units, growing only with story progress) is
|
||||
worth attacking from the other side first: *if* a field the disc leaves unset
|
||||
always took the same runtime value, the 21 captured units would pin that default
|
||||
for all 110 and no further missions would be needed.
|
||||
|
||||
**It does not.** Restricting to the 150 values that are both ✅ CONFIRMED and
|
||||
come from a field the disc leaves defaulted, only 6 of 24 fields have a single
|
||||
value across every unit that defaults them (`HP`→10, `MassScore`→0,
|
||||
`MaximumVelocity`→0, `RadarRange`→0, `DestroyMotionTime`→0, `Size_Z`→0.1). The
|
||||
other 18 take several distinct values — so the default is computed per unit.
|
||||
|
||||
Where from? For each defaulted value, ask which *other* field of the same unit
|
||||
holds exactly that value. Counting only cases where the value is **non-zero**
|
||||
(otherwise `0 == 0` inflates every pair) and checking that the two fields are at
|
||||
**different offsets** (so the match is not the layout solver aliasing them):
|
||||
|
||||
| defaulted field | takes the value of | support | independent units |
|
||||
|---|---|---|---|
|
||||
| `Size_Y` (`0x034`) | `Size_X` (`0x030`) | 9/9 | **7**, 6 distinct values |
|
||||
| `Size_Radius` (`0x050`) | `min(Size_X, Size_Z)` | 4/4 | 4, 3 distinct values |
|
||||
| `FCSRange` (`0x2a4`) | `RadarRange` (`0x2a0`) | 4/4 | 2 |
|
||||
| `DefencePoint` (`0x2bc`) | `AttackVesselPoint` (`0x2b4`) | 6/6 | 2 |
|
||||
|
||||
`Size_Y ← Size_X` is the one to trust: seven unrelated ships (`e105` 600,
|
||||
`e106` 300, `e108` 80, `e201` 300, `f101` 400, `f105` 700, `f106` 200) each omit
|
||||
`Size_Y` on disc and each shows its own `Size_X` at runtime. When both fields
|
||||
*are* on disc they differ freely (14 distinct `Size_Y` values against 13 of
|
||||
`Size_X`), so this is a default rule, not one value stored twice.
|
||||
|
||||
`Size_Radius`'s formula is **not yet separable**: `min(Size_X, Size_Z)` and "the
|
||||
median of the three axes" fit all four units identically. `UN_e010_ADAN_Attacker_S`
|
||||
is what rules out the simpler `Size_Radius ← Size_X` (X=100, Y=40, Z=50, radius
|
||||
**50**). The last two rules rest on two independent units each and are ❔ —
|
||||
recorded so they can be falsified, not relied on.
|
||||
|
||||
**Why it matters for the reimplementation:** filling a missing `Size_Y` with `0`
|
||||
or with a global constant gives the game's largest hulls a wrong lateral extent
|
||||
(`f105` 700, `e105` 600, `f101` 400 — all defaulted on disc). Applied across the
|
||||
disc, the rules recover **65 (unit, field) values in units that have never been
|
||||
visited**: `Size_Y` in 21 of the 21 units that omit it, `Size_Radius` in 22 of 26,
|
||||
`FCSRange` in 14 of 56, `DefencePoint` in 8 of 60.
|
||||
|
||||
**How to falsify:** the rules predict a specific number for units in stages not
|
||||
yet captured. Load any new stage, snapshot, and compare — one disagreement kills
|
||||
the rule. That test is also the cheapest use of the next mission that gets
|
||||
loaded, whatever it is loaded for.
|
||||
|
||||
Reference in New Issue
Block a user