re: value classes resolve by KIND; the 344-name residual drops from 31 to 4

Generalised the "does the referent exist?" sweep that cracked S14. The value
classes resolve as three different kinds:

  AIID                   31 values   31 records    0 files    0 unresolved
  FormationID           126 values  126 records    0 files    0 unresolved
  CollisionMeshes        18 values    0 records   18 files    0 unresolved
  EnumerateSubobjective  17 values    0 records   17 files    0 unresolved
  NamePlate              52 values   27 records   24 files    1 (empty string)
  BackGroundID           10 values    0 records    0 files   10 unresolved

FormationID 126/126 re-derives unit-group-table's own "every FormationID
resolves" from a different direction, as the control.

The 27 NamePlate values that stage-definition-table called "non-file plate ids"
are record names - ACROPOLIS x114, NP_ArrowHead x84, NP_ASFrigate x78 - and the
split 24 files + 27 records + 1 empty = 52 matches the two-vocabularies count
already recorded there. So the census residual shrinks: 313 resolve as files
plus 27 as records = 340 of 344, leaving the 4 never-shipped _Test tables as the
entire residual. The old reading was a KIND error, not a missing-file error.

BackGroundID is a genuinely unresolved third kind: the ten sky names, used 6-36
times each, are neither record names nor pak keys under 10 prefixes x 9 suffix
forms.

Recorded as powerless so it is not re-run: the image holds 0 exact strings for
all ten backgrounds, but also 0 for Formation_4_Bird, AI_Structure,
NP_ArrowHead, ACROPOLIS and CollisionSet_S03.bin, every one of which does
resolve in data. The executable names no data value at all, so the negative
discriminates nothing.

All fifteen artefacts byte-identical.
This commit is contained in:
Sylpheed RE agent
2026-08-28 05:55:52 +00:00
parent 0502c736cf
commit 07aecb3d04
2 changed files with 74 additions and 0 deletions

View File

@@ -6352,3 +6352,31 @@ whether the large asteroids collide distinguishes the two; no static route can.
`UN_<stage>_Asteroid_cmesh_*` squadron entities. S28.Phase_1 borrows
`S14_p2_asteroid.tbl` but deploys no cmesh of its own, so the borrow does not
carry the dangling references.
---
## ✅🟡 2026-08-28 — value classes resolve by KIND; the 344-name residual drops to 4
Item (b): generalise the "does the referent exist?" sweep.
**Three kinds, not one.** `AIID` 31/31 and `FormationID` 126/126 resolve as
**record names**; `CollisionMeshes` 18/18 and `EnumerateSubobjective` 17/17 as
**pak files**; `NamePlate` splits **27 records + 24 files + 1 empty = 52**;
`BackGroundID` **0 of 10** as either. (`FormationID` re-derives
`unit-group-table`'s own "every `FormationID` resolves" as the control.)
🔑 **The 27 `NamePlate` "non-file plate ids" are record names**`ACROPOLIS`
×114, `NP_ArrowHead` ×84, `NP_ASFrigate` ×78. So `stage-definition-table`'s
census improves: 313 resolve as files **+ 27 as records = 340 of 344**, leaving
the **4 never-shipped `_Test` tables** as the entire residual. The old reading was
a *kind* error, not a missing file.
🟡 **`BackGroundID` is a genuinely unresolved third kind** — the ten sky names,
used 636 times each, are neither records nor pak keys under 10 prefixes × 9
suffix forms.
⚠️ **Powerless route, recorded so it is not re-run:** the image holds 0 exact
strings for all ten backgrounds — and also 0 for `Formation_4_Bird`,
`AI_Structure`, `NP_ArrowHead`, `ACROPOLIS`, `CollisionSet_S03.bin`, all of which
*do* resolve in data. The executable names no data value, so the negative
discriminates nothing.