Field-pack format Confirmed

At a glance

Where

Eight PROT.DAT entries (extraction names): 0002_gameover_data, 0003 / 0004 / 0005_town01, 0020_town0b, 0021 / 0022 / 0023_town0c

Magic

0x01059B84 - raw in only four of the eight carriers, referenced by no code

Size / stride

Schema: 97 × u32 (388 bytes), slots 0x60..0x16651; block ~91 KB

Parser

legaia_asset::field_pack::FieldPack + CANONICAL_SCHEMA; CLI asset field-pack / field-pack-scan

Confidence

Confirmed as a detector and for the constant-block finding (corpus byte scan, disc-gated field_pack_real.rs); per-slot meaning is Inferred from size clustering only

Used by

scene bundles, asset loader, world viewer

Layout

The eight carriers

• The block is a global constant. A region byte-identical across unrelated scenes is a shared template, not the scene's own field data.
• The magic is decorative. The same block ships stamped in town01 and unstamped in town0c, and no code references the word. 0005 / 0023 are the same template-only entry, one stamped and one not.
• The preamble is the scene. In 0003_town01 it opens with 63 records: record 0 a fixed 768-byte dispatch table, records 1.. word-aligned actor / event stager records (0xFFFF 0x0000 lead, 0x0008 terminator) - not field-VM bytecode. Field files that carry no block at all open with the same prescript.

What the slots look like

Because the schema is identical everywhere, slots with the same slot[i+1] - slot[i] are the same kind of record. Three uniform-stride runs dominate - the shape a field scene uses for NPC slots, event triggers and hit regions - and five 8 KB slots match the TIM count in the town01 files. asset field-pack <PATH> --groups prints the clusters; SlotKind in the parser is derived from them.

How it reaches RAM

No loader checks the magic. A scene change copies the new name into the scene-name table and raises a pending-transition bit; the field overlay's transition orchestrator then calls the field-asset loader, which streams the file and dispatches its descriptors by type.

The 97 slots are consumed at static offsets - there is no slot-iteration loop in any captured code. The consumer treats the buffer as a fixed in-RAM template and reads by hard-coded index; the specific per-NPC / per-event handlers need a scene-init execution trace to pin.

The field-file RAM base is _DAT_8007B8D0 - 0x12800 in any save (capture_observations::field_pack_load::recover_base): 0x80139530 in a town01 capture, 0x800A25F0 in a town0c one.

How we know

Deep dive

asset field-pack <PATH>                # show schema + slot sizes
asset field-pack <PATH> --all-slots    # all 97 slot offsets/sizes
asset field-pack <PATH> --groups       # cluster slots by size
asset field-pack-scan <DIR>            # find every field-pack in a PROT dir

use legaia_asset::field_pack::{CANONICAL_SCHEMA, canonical_slot, iter_canonical_slots};
assert_eq!(CANONICAL_SCHEMA[0], 0x60);
let (off, size) = canonical_slot(5).unwrap();          // size is None for slot 96
for (i, kind, off, size) in iter_canonical_slots() { /* SlotKind per cluster */ }
// On a parsed file: fp.slot_kind(i), fp.iter_slots(buf)
// (bytes are non-empty only when the block sits at offset 0, e.g. 0005_town01).

Source of record: docs/formats/field-pack.md.

See also