6b50fc0b84
0x82448AA0 and 0x82448C50 are not strcmp. Both pass the name to 0x82447DF0 and use the result as a key: the first binary-searches a table of 16-byte records (x16 for the end, /16 for the count, >>1 for the midpoint), the second packs the hash into a three-word key and calls 0x8244E338. Decoded 0x82447DF0 from the disassembly as ((sum of extsb bytes) & 0xFF) << 24 | (rolling mod 0x00FFFFDF) -- i.e. tag_hash. tools/re-capture/unitgroup.py::tag_hash already documents itself as "a transcription of sub_82447DF0", so this was in the corpus; the useful part is that it identifies which hash the ARCHIVE uses. That exposed a defect in my previous sweep: it probed name_hash (0x00FFF9D7, lowercased) only, while the archive keys by tag_hash (0x00FFFFDF, case-sensitive). Re-ran with BOTH: 1380 names -> 2148 distinct hashes, 41 paks, 26443 records. STILL ZERO. The pak-record hypothesis is now refuted with the right hash rather than merely unsupported. Left open: the XEX's compressed/encrypted region (default.xex never decrypted here), plus two untried static threads -- the second pair of SCRIPTS/GP_SCRIPT references at 0x82262374 / 0x822622bc, in a different function, and tracing [r31+80] back to whoever opened the archive being name-tested.