13117df0bd
My earlier negative was under-scoped: it probed 35 paks, missing hidden/resource3d/ and dat/movie/. Redone across every *.pak on the disc -- 41 archives, 26443 indexed records, 768 distinct name hashes -- still ZERO hits. The scripts are not a pak record under any of those names. Located the three loader strings by VA (the .pe is a flat VA dump, VA = 0x82000000 + offset) and pulled their xrefs from sylpheed.db: SCRIPTS 0x820a823c <- 0x8225f1b8, 0x82262374 GP_SCRIPT 0x820a8244 <- 0x8225f168, 0x822622bc MISSION1 0x820a8264 <- 0x8225eed8 Disassembling sub_8225EE20 shows both archive-name references call THE SAME routine 0x82448AA0 with (object, string) and test the result with cmpi -- so the loader COMPARES a name against an already-open archive rather than building a path like dat\GP_SCRIPT.pak. That fits GP_SCRIPT being a name an archive reports, which is why no such file exists to find. Next concrete steps recorded: identify 0x82448AA0 (strcmp/strstr/hash-compare) and its neighbours 0x82448C50 / 0x8216F218, and trace [r31+80] -- the object being name-tested -- back to whoever opened it. That names the container.