re: all 24 settings objects named -- stage\StageParameter_S<NN>.tbl

The queued item (the 29-object resource manifest) turned out to be already
settled by challenge-mission-gate.md and stage-mission-tables.md, so the
iteration moved to the open question those docs make answerable.

Hashing EVERY string that appears in any IDXD object on the disc resolves all
24: StageParameter_S01..S16 (story), S24..S29 (challenge), StageParameter_
Tutorial shared by all six tutorials, and StageParameter_Test.  16+6+1+1 = 24,
which is exactly why the settings family is 24 against 29 stage records.

IsBoss16Enable confirmed independently: that object is StageParameter_S16.
GravityFactor is non-zero in S10 (700), S11 (400), S03 (250), S27 (250); the
three unscored objects are S24, S27, S28; the one without SplinterCell is _Test.

Refuted on the way: TOC order is not stage order (the TOC is hash-sorted and the
Boss16 object is 17th, not 16th), and neither the StageResource template nor a
real 19-field record names the settings table.  The AUTO_SETTINGS filenames are
a different scheme -- none of the 28 hashes to any of these 24.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PMRJjbxLqZtsb5Vb7KunPE
This commit is contained in:
Claude (auto)
2026-08-27 19:05:28 +00:00
parent 54e36349a4
commit 19b6eb3ee6
6 changed files with 141 additions and 17 deletions

View File

@@ -4670,3 +4670,48 @@ the settings family is 24 objects, the resource family 29.
🟡 Still open: which settings object is which stage beyond `IsBoss16Enable`;
`SplinterCell Count 5`; what `SpaceSize`, `GlareType` and `Nebura_*` mean
numerically.
---
## ✅✅ 2026-08-27 — all 24 settings objects named: `stage\StageParameter_S<NN>.tbl`
**The grep-first rule paid for the whole iteration.** The queued item was the
29-object resource manifest — and reading the owning docs first showed it is
**already settled**: `challenge-mission-gate.md` counts exactly 29 stage records
(16 story + 6 tutorial + 6 challenge + `Test`, `StageResource` schema
`0x3c9ae32e`) and `stage-mission-tables.md` documents the six sub-records
including the `Phase_N` block with `MapPath`/`MapMesh`/`AsteroidDefinition`/
`BackgroundResourceID` — the exact four fields I measured. Nothing to add. So the
iteration moved to the open question those docs make answerable.
✅ **24/24 named.** Hashing **every string that appears in any IDXD object on the
disc** — rather than guessing filenames — resolves all of them:
`stage\StageParameter_S01…S16.tbl` (story), `S24…S29` (challenge),
**`StageParameter_Tutorial.tbl` shared by all six tutorials**, and
`StageParameter_Test.tbl`. **16 + 6 + 1 + 1 = 24**, which is why the settings
family is 24 against 29 stage records: the tutorials do not get one table each.
✅ **`IsBoss16Enable` confirmed independently.** Predicted last iteration to mark
stage 16; the object carrying it is `0xEECC84F2` = `StageParameter_S16.tbl`.
⚠️ **The names are NOT `AUTO_SETTINGS`'s.** That record lists
`stage01_settings.tbl` … `challenge06_settings.tbl`, and **none of those 28
hashes to any of these 24 objects** (19 prefixes tried). Two different naming
schemes for stage-scoped parameters; the pak holds only `StageParameter_*`.
With names attached, earlier findings acquire stages: **`GravityFactor` is
non-zero in S10 (700), S11 (400), S03 (250), S27 (250)**; the three objects that
zero their score multipliers are **S24, S27, S28**; the object without a
`SplinterCell` record is **`_Test`**.
🔴 **Refuted on the way:** TOC order is not stage order. The 24 objects sit in a
separate TOC region (661, 905, 9681030) from the 29 resource objects (622771),
and the `IsBoss16Enable` object is 17th in TOC order, not 16th — the TOC is
hash-sorted, which is arbitrary with respect to stage. Also, neither the
`StageResource` template (13 fields) nor a real record (19) names the settings
table, so the link is not through the stage record. ⚠️ I first sampled
`res[0]` and got the `_Test` **template***never conclude from one sample*.
**Method note:** the win was harvesting *all* disc strings and hashing them,
after guessing filenames had failed twice. The real name resembled nothing I
would have guessed.