fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

re: WITHDRAWN — "FormationID does not hash into the table". It does.

Browse Source 
The refutation used the wrong hash function. A record key is tag_hash of the
record's own name, not the pak-TOC name_hash which lowercases and uses a
different modulus:

  tag_hash("Formation_4_Bird")  = 0x22a5eeed   <- exactly the record key
  name_hash("Formation_4_Bird") = 0x6286edad   <- the wrong hash, hence
                                                  the recorded "0 of 16"

Formation_4_Bird IS a record name in FormationSet_S02.tbl and every record in
that table keys by tag_hash of its name. Across all 28 UnitGroup_S<NN>.tbl the
same holds for field keys: 6960 of 6960 are tag_hash(field name), 0 are
name_hash. So FormationID resolves by a direct hash lookup and the roster
indirection is NOT required for it.

This is exactly the trap idxd-container.md warns about, and it cost this file
a spurious refutation. The original text is kept below the correction.

The squadron half of the claim still stands and is marked so: a squadron
record's key is not tag_hash of the squadron id either -- tag_hash("TCN001")
is 0x760cdeaa against keys running 0x659aff47 -- because the record's NAME is
not the squadron id. That roster indirection is real.

Also closes the file's standing "the key derivation stays open, a second hash
function is unidentified": that function is tag_hash, recovered since.

Found while checking a subagent's claim rather than taking it -- it reported
the hash correction, and verifying it turned up that the FormationID half was
a stronger result than reported.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PMRJjbxLqZtsb5Vb7KunPE
This commit is contained in:
Sylpheed RE agent
2026-08-26 01:48:14 +00:00
parent 1daf2d6171
commit 217c339fa7
1 changed files with 30 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

33
docs/re/structures/unit-group-table.md
View File

@@ -157,7 +157,32 @@ observation that `n = 9` does not match the `_30` in
`Formation_ADAN_Turret07_30` is correct and **not** evidence against `n` being a
count: 9 units occupy 9 of that formation's 30 slots.
### ✅ How `FormationID` resolves — the same roster trick
### ❌ WITHDRAWN — "`FormationID` does not hash into the table"
**It does.** The refutation below used the wrong hash function. A record key is
[`tag_hash`](idxd-tag-hash.md) of the record's own name — *not* the pak-TOC
`name_hash`, which lowercases and uses a different modulus. Checked directly:
```
tag_hash("Formation_4_Bird") = 0x22a5eeed <- exactly the record key
name_hash("Formation_4_Bird") = 0x6286edad <- the wrong hash, hence "0 of 16"
```
`Formation_4_Bird` **is** a record name in `FormationSet_S02.tbl`, and every
record in that table keys by `tag_hash` of its name. Across all 28
`UnitGroup_S<NN>.tbl` the same holds for field keys: **6960 / 6960** are
`tag_hash(field name)` and **0** are `name_hash`. So `FormationID` resolves by a
direct hash lookup and the roster indirection is **not required** for it.
This is the exact trap [`idxd-container.md`](idxd-container.md) warns about, and
it cost this file a spurious ❌.
🟡 The *squadron* half of the original claim still stands: a squadron record's
key is not `tag_hash` of the squadron id either (`tag_hash("TCN001")` =
`0x760cdeaa`, against keys running `0x659aff47…`), because the record's **name**
is not the squadron id. The roster maps id → record, and that indirection is real.
### The original text, kept
`FormationID` does **not** hash into the table: `name_hash("Formation_4_Bird")`
= `0x6286edad`, and the record key is `0x22a5eeed` — 0 of 16 resolve that way.
@@ -181,5 +206,7 @@ record inside the table, not by hashing the name.**
they stand — but the earlier note rejected `n = 387` as *the* craft count on
the assumption that everything deploys at once, and that assumption is still
untested.
* The **key derivation** stays ❔. The roster makes it unnecessary, but the tag
is not `name_hash`, so a second hash function is still unidentified.
* ✅ The **key derivation is no longer ❔**: the "second hash function" is
[`tag_hash`](idxd-tag-hash.md), recovered since this was written. Record keys
and field keys are both `tag_hash` of their own name — 6960 / 6960 field keys
across all 28 `UnitGroup` tables, 0 matching `name_hash`.