From b273ee9f48f4f70aa31696126f4f236126b9b3b7 Mon Sep 17 00:00:00 2001 From: Sylpheed RE agent Date: Wed, 26 Aug 2026 01:48:14 +0000 Subject: [PATCH] =?UTF-8?q?re:=20WITHDRAWN=20=E2=80=94=20"FormationID=20do?= =?UTF-8?q?es=20not=20hash=20into=20the=20table".=20It=20does.?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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.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) Claude-Session: https://claude.ai/code/session_01PMRJjbxLqZtsb5Vb7KunPE --- docs/re/structures/unit-group-table.md | 33 +++++++++++++++++++++++--- 1 file changed, 30 insertions(+), 3 deletions(-) diff --git a/docs/re/structures/unit-group-table.md b/docs/re/structures/unit-group-table.md index 96cf149..911af1d 100644 --- a/docs/re/structures/unit-group-table.md +++ b/docs/re/structures/unit-group-table.md @@ -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.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`.