Asset descriptor format Confirmed
A small table-of-contents layout: a list of (type_size, data_offset) pairs, each pointing at one asset inside a buffer and saying what type it is. The walker that consumes it is FUN_80020224 (a Ghidra-traced routine in the game's executable) - and the interesting part is that nothing in the executable ever calls it. It's reached only at runtime, from an overlay (a chunk of MIPS code the game loads into RAM on demand). Implementation: crates/asset/src/lib.rs::parse_player_lzs.
Layout
u32 count
u32 (header word, purpose unknown)
u32 type_size_0 u32 data_offset_0
u32 type_size_1 u32 data_offset_1
...Each descriptor pair is (type_size, data_offset) where data_offset is byte-relative to the buffer start, and type_size packs the asset-type byte (the 8-bit tag saying TIM / TMD / MES / …) in the high byte.
How FUN_80020224 is reached
Static analysis of SCUS_942.54 (the game's main executable) finds zero cross-references to the walker - which looks like dead code until you follow the overlays. FUN_801D6704 (the town overlay's MAIN_INIT) calls FUN_80020224 at 0x801D6B0C with a0 = 0. The result is stored at 0x80087AF8. So the format IS exercised by retail gameplay - through a runtime overlay rather than the executable's static call graph. (This "zero static callers but alive via overlay" pattern recurs across the whole codebase.)
Strict-scan against the disc
Strictly scanning all 1233 PROT entries (the numbered slots of PROT.DAT, the disc's main asset archive) against this format finds zero hits. That's consistent with both "format isn't on disc as a top-level entry" and "format is on disc but indexed differently" (e.g., embedded inside a scene asset table or a compressed payload). The parser is left in place for when a real on-disc consumer surfaces.
Note on naming
The Rust function is named parse_player_lzs for historical reasons - the format was first encountered while investigating player.lzs chains. The format itself isn't player-specific.