Pochi-filler placeholder slots Confirmed
Nothing a player ever sees - and that is the point. 266 of the 1233 entries in PROT.DAT (the disc's single big asset archive) are unused placeholder slots, padded with the repeating ASCII word pochi - a common Japanese dog name (ポチ), the kind of fill pattern a developer picks so that uninitialised data is instantly recognisable in a debugger. Each is exactly one 2048-byte sector of fill and nothing else. The game never loads them; tools must learn to step over them, and the one rendering bug ever blamed on them turned out to belong to the entry next door.
At a glance
- In the game
- Never loaded. Reserved slots a scene's asset block set aside and never filled.
- Magic / marker
- ASCII
pochiat offset 0 and a DOS end-of-file byte0x1Aat+0x786 - Lives in
- 266 PROT.DAT entries, each exactly one 2048-byte sector, clustered at fixed positions inside scene CDNAME blocks
- Parser
- Detection class
pochi_filler/Class::PochiFillerincrates/asset/src/categorize.rs - Confidence
- Confirmed - measured over the whole corpus and asserted as a test: every slot is one sector, none carries a parseable TIM.
Byte layout
0x1A, scratch to the sector end.| Offset | Size | Field | Meaning |
|---|---|---|---|
+0x000 | 1926 | fill | ASCII pochipochi... - 37 lines x 52 bytes + a trailing po |
+0x786 | 1 | EOF | 0x1A, the DOS end-of-file marker |
+0x787 | to 0x800 | tail | Scratch / leftover fill to the end of the single sector - no format, no second sector |
Detection is two checks: buf.starts_with(b"pochi") && buf[0x786] == 0x1A.
Why 266 of them exist
The archive's entries are grouped into named blocks, one per scene, by CDNAME.TXT (the disc's plain-text map of entry names). Each scene's block reserves a fixed run of 6-8 slots for asset variants, but most scenes only fill some of them; whatever a scene didn't use got pochi-filled. That's why the filler slots cluster at fixed offsets within their CDNAME block - typically positions 2, 4, 5, 6.
Some scene blocks are almost entirely pochi. The edstati3 block (likely "ending station 3", possibly cut content) has 36 of ~38 pochi entries.
What a contributor must do
Treat these slots as known-empty:
- Don't run format detectors against them.
- Don't include them in TMD/TIM bulk-scan totals.
- Skip them in any "what's still uncategorised" tally.
- Size every entry as the sector gap to its successor (PROT TOC) - a pochi slot then has no reach into its neighbour at all.
The engine's field VRAM pre-pass skips Class::PochiFiller entries outright (legaia_engine_core::scene_resources). The disc-gated regression field_ground_texture_pages_disc pins both halves: every pochi-filler entry is one sector carrying no TIM, and the built VRAM does not contain the neighbour's page.
The ground-atlas hazard belongs to the next entry
A rendering bug is worth keeping on this page precisely because its symptom points at the wrong entry. Two 64 x 256 texture pages land at framebuffer (768, 0) and (832, 0) - a scene block's battle-side character pages, CLUT rows 473 / 479 - and fb (768, 0) is tpage 0x0C, where most field scenes put their ground-tile atlas (the per-cell page in the .MAP object record's +0x15; see world-map "Ground texturing"). Uploaded last, they erase the atlas and the ground quads sample character / backdrop texels: Jeremi's floor becomes a grid of grey "tombstones", Mt. Dhini's a repeating vine/crack pattern.
Those pages are the scene_tmd_stream entry that follows the pochi slot - its FUN_8001FE70 type-0x01 chunks. A "scan every entry in the CDNAME block for TIMs" sweep reached them by standing on the pochi slot and reading past its end. Rim Elm escapes because its sibling slots are all scene_tmd_stream entries, which the field build already excludes - which is the same statement about the neighbour, read as a statement about the slot.
History: the "stale scratch that parses as a TIM" reading
An earlier reading held that the bytes after the 0x1A were mastering leftovers, and that in most scene blocks they parsed as a complete, valid 256x256 4bpp TIM - the pages described above. That reading is falsified: every one of the 266 slots is exactly one sector and zero of them carry a parseable TIM. The pages came from the neighbouring entry, reached through the superseded entry-size expression that spanned neighbouring entries (corrected in prot). The symptom was attributed to the slot a sweep was standing on rather than to the entry it over-read into. Catalogued on do not re-walk.