Walk-on trigger sidecar (.PCH) Confirmed

At a glance

Where

One PROT.DAT entry per scene: raw TOC index n + 1 for CDNAME #define <scene> n (= extraction entry n - 1). 97 entries.

Size

Always 0x800 bytes (one sector); param records of 4 bytes at +0x14

In RAM

At *(0x1F8003EC) + 0x12000, right after the scene's .MAP - on retail because one 40-sector read covers both

Marker

No magic - a header algebra (below)

Parser

legaia_scene_formats::scene_v12_table; CLI asset scene-v12 / asset scene-v12-scan

Confidence

Confirmed - header, record shape, one-sector size and the next-entry prescript hold across all 97 entries; loader and consumers traced statically

Used by

field locomotion (trigger block), cutscene routing, door shuffle

What it is

A trigger does not contain its event - it points at one. The scene's MAN (its script-and-data bundle) holds the named event records in partition 2; each trigger names a tile and the partition-2 record to spawn when the player steps there. The .PCH is a patch layer over the .MAP file's trigger block: same directory shape, same record form, a second lookup window the per-step tile check falls back to.

Three scenes have no .PCH (opurud, opkorout, edson - cutscene scenes with no trigger tiles). The developer build zero-fills their slot; retail simply reads whatever the following sectors hold, because it does not open the file at all.

Layout

The header is a directory of four sub-tables ("kinds"): for kind k, the body offset is the u16 at +4k+2 and the record count the u16 at +4k+4. Every retail .PCH populates kind 1 only; the empty kinds' offsets pack consecutively past the records.

Kind-1 count param is 0..=192 in retail; the empty kinds' offsets pack consecutively past the records, and their zero-length bodies sit at +N.

Header algebra

With N = 4 × param + 22 (the first byte past the records, plus 2), the header always satisfies u16[0] = N + 4, u16[5] = N, u16[7] = N + 2. The detector checks this tie plus the fixed words; across the 1233-entry PROT corpus it matches exactly the 97 .PCH entries with no false positives.

Trigger records

tile_x / tile_z address a 128-unit field tile; p2_record is the MAN partition-2 record spawned on step-on; gate is always 0x01 ("spawn on walk-on").

Records sharing a p2_record are multi-tile strips of one trigger - a gate three tiles wide gets three records. The spawned record's own story-flag gates still apply at spawn time. Example: garmel's table has 12 records, two of them 3-tile strips.

How the game uses it

1. Scene loadOn retail the field-asset loader issues one 40-sector read from the .MAP entry - 0x14000 bytes, four sectors more than the .MAP - so the .PCH and the prescript arrive with it. The three-file version, with a zero-fill when the .PCH is missing, is the developer-station branch.
2. Scene initThe map initialiser walks the kind-1 records and ORs footprint bit 0x400 into each trigger tile's event-cell word (+0x8000 grid).
3. Every stepThe tile lookup (field overlay 0897) scans the .MAP trigger block first, then falls back to the .PCH window; a hit spawns the partition-2 record.
4. Event runsThe spawned record is a field-VM script: cutscene, door, story beat (script VM).

In the port: parser legaia_scene_formats::scene_v12_table; the lookup is field_regions; the field locomotion page has the runtime contract.

The next entry: the event-script prescript

Raw TOC n + 2 - directly after the .PCH - is the scene's prescript: [u16 count][u16 offsets[count]] then per-record bytecode. Same shape as the standalone scene_event_scripts format. Parser scene_v12_table::parse_prescript_entry.

• The records are move-VM stager records ([i16 model_sel][u16 reserved][bytecode]), not field-VM scripts; the common 0xFFFF 0x0000 lead is model_sel = -1 (a pivot node), and 0x0008 terminates (move-VM Halt).
• The field VM installs one by id through the effect-tree stager (move VM). The real per-scene field scripts live in the MAN.
• All 97 scene blocks have one; count ranges 2..71. Town scenes' record 0 is the fixed 768-byte master ambient stager (scene bundles).

Who writes the window at runtime

Almost nothing. Sweeping the executable and all 83 mapped overlay images, the +0x12000 offset is built six times: twice in the loader's developer arm, once in the scene-init pass that only reads the directory, and three times inside the two-window tile lookup (the field overlay's, plus private copies in the fishing and dance overlays). The lookup's helper is called from nowhere else, so the record pointer it returns is the only other handle anyone has on the window.

Seven routines call that lookup and exactly one writes through what it returns: a field-VM arm - main opcode 0x4C, operand nibbles 8 then 3 - that walks a tile rectangle and, for every tile with an elevation-override record, sets that record's coarse step from its own operand and clears the fine quads. It is how a script re-floors a ramp or a bridge in the middle of a scene.

Two consequences. The header's trailing zero words are never filled at runtime - the writer patches a record the directory already counts and cannot append one, and nothing stores a count or an offset into the directory at all. And the empty kinds stay empty by construction: the one writer needs a record to match, every retail sidecar ships zero elevation records, and teleports and region boxes have no writer in any image.

How we know

Header, record shape, one-sector size and the position law n + 1 hold across all 97 entries; the loader and every consumer are traced from the disassembly.

Deep dive

use legaia_scene_formats::scene_v12_table;

let buf = std::fs::read("extracted/PROT/0093_map01.BIN")?;
let t = scene_v12_table::detect(&buf).expect("v12 header valid");

println!("N={}, param={}", t.n, t.param);
for (i, rec) in t.records.iter().enumerate() {
    println!("rec[{i}]: b0={:02x} b1={:02x} b2={:02x}",
             rec.b0, rec.b1, rec.b2);
}

Source of record: docs/formats/scene-v12-table.md.

See also