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:
@@ -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, 968–1030) from the 29 resource objects (622–771),
|
||||
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.
|
||||
|
||||
Reference in New Issue
Block a user