Asset type dispatcher Confirmed

Calling convention

result = FUN_8001f05c(byte *src_data, u32 type_and_size, int param3, int copy_only);

• type_and_size packs type in the high 8 bits, size in the low 24 bits.
• copy_only != 0 → asset is uncompressed; the dispatcher calls FUN_8001A8B0 (memcpy).
• copy_only == 0 → asset is LZS-compressed; the dispatcher calls FUN_8001A55C (the LZS decoder - the game's dictionary decompressor).

Type table

The full type space. A nice detail: the names aren't guesses - the developers left per-type malloc-error strings in the executable (s_Tim_Malloc_Err_800104E8, s_tmd_malloc_err_80010504, …), so each type byte comes with its original dev-side name.

Return-value bitfield

Every return is a small bitfield:

Both call sites (FUN_8002541C streaming-walker and FUN_80020224 descriptor walker) OR all returns into one accumulator and return that union, so the FLAG sentinels become high bits in the streaming-walker's "what was in this stream" summary value:

return_value & 0x00FF  = bit per data-bearing asset type seen
return_value & 0xFF00  = bit per FLAG-type marker seen

Why FLAG types exist

The FLAG cases let the dispatcher accept chunks whose type_byte falls outside the data-bearing range without aborting the streaming walk. The data bytes are still skipped by the walker (advance = 4 + (size & ~3)), but the dispatcher never reads them. So FLAG chunks act as stream-level out-of-band markers - any code that calls FUN_8002541C and looks at the returned bitfield can detect that "this stream contained a 0x14-typed marker chunk" without that marker carrying a parsed asset.

Where the markers are consumed is open; possibly by code that reads past the streaming terminator (the DATA_FIELD trailer).

AssetType Rust enum

pub enum AssetType {
    Tim,        // 0
    TimList,    // 1
    Tmd,        // 2
    Man,        // 3
    Mes,        // 4
    Move,       // 5
    Anm,        // 6
    Vdf,        // 7
    Sin,        // 8
    Tmd2,       // 9
    Move2,      // 0xB
    Flag(u8),   // 0xA, 0xF, 0x14
    Unknown(u8),
}

Where the dispatcher actually gets called

In retail SCUS (SCUS_942.54, the game's main executable), only FUN_8002541C's 0x14 (DATA_FIELD) branch reaches the dispatcher from inside the executable's static call graph. The other static call site is FUN_80020224 - a descriptor-pair walker with zero static xrefs in SCUS (no compiled-in caller anywhere in the executable). It IS called at runtime from the town/field overlay (a chunk of MIPS code the game loads into RAM on demand - most game logic lives in these overlays, not the executable): FUN_801D6704 → 0x801D6B0C with a0 = 0; see asset descriptor.

See also