692a8045f0
Each of the 60 builds a 40-element array of 24-byte string objects: addis 0x820B + addi fetches the literal, addi r30,r11,12944 fixes the array (0x828E3290 for the first), bl sub_8217FA08(dest, literal, -1) assigns, the rest of the object is zeroed, addi r3,r30,24 steps on. Why they have no callers: each appears exactly twice in the image - once in the .pdata unwind table, where EVERY function appears as (address, prolog/ length word) and reading it as a registry is a trap - and once as a slot of a null-terminated 182-entry function-pointer array at 0x82870018-0x828702EC, 170 of whose targets have zero direct xrefs. That is the static-initialiser list. Zero callers here means "static ctor", not "dead code". The teardown side confirms it: 39-43 functions sit between consecutive clones (median 40), the dominant size in 0x8281xxxx-0x8284xxxx is 11 instructions (2280 of them, about 60 x 40), and three consecutive ones call sub_823F3D68 on 0x828E3290, +24, +48 - one destructor thunk per element, same stride, same global, all zero-xref. rot_n001 and rou_e202 ARE on the disc: a raw byte sweep finds rot_n001 26 times in 7 archives (DefTables included) and rou_e202 6 in 6, exactly one per GP_MAIN_GAME_<lang> pack. Controls: rou_e201 151/8, rou_e901 917/8, mob_n500 46/8. Narrows the earlier claim to "not GameResourceID values". Not settled: what reads the arrays. An exact-address search returns 2347 functions outside the 60 - too broad to be a consumer list; the globals sit in a dense data region and that route has no power. All fifteen artefacts byte-identical.