CDNAME.TXT - entry name map Confirmed

Overview

#define init_data 0
#define gameover_data 1
#define town01 3
#define town0b 12
#define town0c 21
...
#define vab_01 1072

Implementation: crates/prot/src/cdname.rs.

Block-start semantics

Each #define name N marks the start of a block: the name applies to entry N and every subsequent entry until the next define. Subsequent PROT entries inherit the name of the most recent block:

• entry 3 → block town01
• entry 11 → block town01 (since town0b starts at 12)
• entry 12 → block town0b

Most blocks correspond to one scene (a town, dungeon room, or menu) and reserve a handful of entries for that scene's assets. prot-extract uses these names to produce filenames like 0148_retock.BIN.

Numbering space (the −2 correction)

The boot TOC loader copies PROT.DAT verbatim (8-byte header included) into RAM at 0x801C70F0, so raw index = extraction index + 2 (see PROT TOC § In-RAM TOC). The default NNNN_<name>.BIN naming is kept for stability; legaia_prot::cdname::block_for_extraction_index resolves the retail-space name for an extraction index, and scripts/asset-investigation/cdname_shift_analysis.py reproduces the full quantitative analysis against a local extraction.

Evidence

Loader-constant identities (strongest - retail hard-codes raw-TOC indices for dev-named files, and each constant equals the same-named define):

Structural (scene region, defines 3..864): the per-scene v12 fixup table recurs once per scene block, and scene block lengths vary (7..11 slots), so its slot position is shift-sensitive. At shift 0 the 96 scene-region v12 tables scatter across slots 4..10; at −2 all 96 sit at slot 1. The identity anchors pin −2 exactly. The universal field-.MAP-at-define − 2 rule is this same fact: each scene's .MAP is retail slot 0 of its block, the v12 table slot 1, the event prescript slot 2, the 7-asset table slot 3.

Semantic scoring: over the name blocks with checkable expectations (VAB/SEQ shapes for the sound blocks, the \DATA\MOV*.STR program table for move_program_no, OTHER<n> overlay banners for other_game), shift −2 outscores shift 0 - e.g. vab_01 → extraction 1070..1192 is 121/121 VAB-headed.

Consequential relabelings

Per-entry content claims on this site stay in extraction space (unambiguous); the retail-space names below are what the dev defines actually cover. The most consequential corrections:

Exceptions and caveats

Residual caveats (none contradict the uniform −2):

• level_up → extraction 0890 is a DATA_FIELD streaming carrier (its VABs are wrapped inside), so bare-magic checks miss it at every shift.
• Extraction 0888 (in sound_data2) and 1062 (in music_01) are unidentified non-VAB blobs under any shift.
• other_game: only 2 of 6 entries carry an OTHER<n> banner; the rest are banner-less minigame data, undecidable by name.
• Extraction 0893 (summon.dat) opens with a [u32 2][u16 table…] shape that mimics a sound-address bank - a shift-0 reading “confirms” monster_se on it spuriously; the byte-pins show texture streaming slots. Trust byte-pins over shape coincidences.
• One v12-shaped header sits at extraction 1227 (other7 region), outside the scene region.
• Opaque names (other1/other4/other5/other6/other7, card_data) are unscoreable; nothing about them conflicts with −2.
• other7 (extraction 1226+, define 1228) is a dev-leftover earlier revision of koin3's field MAN: its 8 partition-2 records are a name-exact prefix subset of koin3's 12 (koin3 appends four later records), and its partition-1 pool shares koin3's gate flags (0x431/0x4CA/0x3DA at matching record shapes). No captured code loads it (no path string, no raw-index loader) - orphaned content, consistent with its leftover-JP text.

Engine consequence: scene windows are the retail block

Scene::load (engine-core) converts the raw-TOC block range to the extraction frame (raw - 2) so a scene's entries are its retail block: the first entry is the scene's .MAP file, the second typically its v12 trigger sidecar. An unshifted window is two entries late - it drops those and bleeds in the next block's first two, which mis-frames any scene whose load-bearing entry sits at a block edge (an unshifted rikuroa window picks up geremi's v12 sidecar and loads Jeremi's MAN under the rikuroa label; the “suimon == dolk2 MAN” identity is the same bleed). The two head defines (init_data 0, gameover_data 1) sit inside the TOC header rows where the conversion has no content to land on; those blocks keep their unshifted legacy windows.

Block names can still mislead

A block name describes the developer's organisation, not the runtime semantics of every entry inside the block - and any name read off an extraction filename must first be corrected by the +2 numbering shift above. Once that shift is applied, the dev names turn out to be accurate far more often than the historical “label gotcha” catalogue suggested: vab_01 really is wall-to-wall VAB banks, battle_data really is the player battle files, bat_back_dat really names the battle side-band summon.dat/readef.DAT files (extraction 893/894). When a (shift-corrected) block name still conflicts with what the bytes look like, trust the bytes: re-derive structure from the leading magic + the loader-call constant in SCUS, not from the CDNAME label.

Per-scene asset reservations

Most scene blocks reserve 6–8 PROT slots for asset variants. Unused slots get filled with the dev placeholder pattern documented in pochi-filler. The edstati3 block (likely "ending station 3", possibly cut content) is almost entirely pochi-filled.

See also