Player battle files (data\battle\PLAYER1..4) Confirmed

At a glance

Where

PROT extraction entries 0863..0866 (Vahn / Noa / Gala / Terra); in-RAM TOC index char_id + 0x360. The edstati3 filename labels on 0863/0864 are the CDNAME +2 label shift.

Size

338 / 303 / 222 / 47 sectors. Header 16 bytes, descriptor entries 12 bytes, slot region from file offset 0x8000.

Magic

None - detected by shape (header words ordered clut_a < clut_b < budget, descriptor chain contiguous).

Parser

legaia_actor_formats::battle_data_pack (walker), ::battle_char_palette (palette chain), ::battle_char_assembly (splice, poses, uploads), editing in legaia_patcher::equip_transplant.

Confidence

Confirmed - loader disassembly plus byte-exact captures of the assembled mesh, VRAM bands and palette.

Used by

Character meshes, characters page, patcher equipment editor, battle scene.

Not to be confused with the monster archive (entry 0867), the TIM-pack, the DATA_FIELD stream or the field-pack - all nearby, all different containers.

Load chain and index space

FUN_80052770 points each party character's asset-table entry at the dev path data\battle\PLAYER<n> and opens it through the dual-mode wrapper FUN_800558FC. The retail ISO9660 branch is a trap stub on this build, so the open always resolves through the PROT reader with the raw in-RAM TOC index char_id + 0x360 - extraction entry char_id + 0x35E (PROT.DAT). FUN_80052FA0 then assembles the character.

The footprint is the file. The sector gap to the next TOC entry is the true size: the slot region tiles each file’s footprint exactly. An extracted 0865 of about 16 MB is Gala’s file followed by its neighbours (Terra’s file and most of the monster archive), the read window of the superseded entry-size expression - not a “16 MB battle_data container”.

File layout

The 16-sector prologue (header, record[0], descriptor table) is read in one go; slots are then streamed by seeking from one selected slot to the next. The header itself is four words:

0x8000 is a loader constant (the fixed 16-sector prologue read), not a header field. Measured header values:

Descriptor table: one section per equipment slot

Entries run in sections of descending ids, each closed by an id = 0 default. The five sections are the character's five equipment slots, in the order of the equipped-item bytes of the character record (+0x196..+0x19A). Terra's file has only the five defaults.

A section is bone geometry, not an attached object

A slot carries whole skeleton bone objects; selecting it replaces the bare object with a re-authored one that includes the gear. Vahn's right hand is 40 vertices bare, 71 with the Survival Knife, 109 with the Astral Sword; Hunter Clothes takes his torso from 79 vertices to 64. A full endgame set re-authors ten of his fifteen bones.

The item is still separable - by palette, not geometry. A weapon draws from its own CLUT column and no primitive across all 81 held-item records mixes columns; the flesh half always reaches the bone origin, the item never does. This is what powers the characters page's equipment diff and the item-alone .glb export.

Inside a slot

Each slot is [u32 dec_size][LZS stream]; the decoder stops on the output count, so give it a generous input slice. Decoded, every slot is a 32-byte header, a loader frame wrapping a Legaia TMD, and a texture pool.

On disc, at 0x8000 + offset:

Decoded - the header's self-relative offsets locate everything else:

frame_off = 0x14 + 4 × attach_obj_count in every retail slot; the pool is uploaded only when upload_flag != 0.

The assembler reads one bone-id byte per object while obj_index < attach_count, then tags surplus objects 0xFF (per-clip swap variant) or 0xFE (extra animated part). Assembled objects are also effect-read: the Spirit charge samples authored vertex indices of specific objects, so a rebuild must keep a real vertex pool in every slot even when it draws nothing.

Where the textures land in VRAM

The assembler runs once per present party member, with p the member's 0-based ordinal (not the character id). It uploads up to seven blocks: the two record[0] image blocks at fixed rects, plus one block per flagged section at the rect from a static SCUS table. Pixels go to (x0 + 0x200 + p×0x80, y0 + 0x100), the CLUT to row 0x1E1 + p with the STP bit set on every non-zero colour. The seven rects tile the member's 128×256 band exactly - texpages 0x18 + 2p / 0x19 + 2p, the pages the mesh relocation retargets.

Port: battle_char_assembly::{SECTION_TEXTURE_RECTS, RECORD0_TEXTURE_RECTS, character_texture_uploads}. It matches captured battle VRAM per member except for the facial animator's current frame. mednafen-state clut-trace confirms placement from the other side: sliding each decoded slot’s pool over captured VRAM finds every hit inside its section’s banded rect, consecutive pool offsets stepping one VRAM row per 0x40 bytes.

One unflagged record is a stripped pool, not an empty one. Noa’s Force Blade (0x25, section 3) is her Short Sword record up to the pool - same attach list, TMD and pool offset - with the upload flag cleared and the decode ending at the pool. Its blade samples a rect only that missing pool fills, so under retail’s loader it draws whatever the rect last held, in a fresh VRAM nothing at all. Retail never reaches the record: the equipment table makes the Force Blade Vahn’s alone. The port uploads the Short Sword’s pool for it (battle_char_assembly::stripped_pool_donor); it is the only such record in the four files.

Battle animations (record[0])

The player files are also the party's in-battle pose source. record[0] opens with a u32 action-offset table (12 disc slots) of action entries in the same family as the monster archive's: the first byte is the action tag, the rate byte sits at +0x78, and the packed [u8 parts][u8 frames][9-byte TRS] keyframe stream at +0xAC (monsters keep theirs at +0x8C). Frame 0 of the idle is the combat-stance rest pose the assembled mesh is socketed into.

• Persistence. Only the region below clut_a_off survives the battle: the five sections decode over the rest of the same buffer. An edit that adds per-frame data must grow that region.
• Swing records are per-equipment animations: each selected section's record at slot-header +0x04 (and +0x08 for section 4) is installed at action slot 0xC + section − 2. Its first byte is the per-strike power run head, not a runtime slot (art-data).
• Art bank (record[0] +0x58): [u32 count] then 0xD0-stride records - a 0x24-byte matcher head (command combo, stream index, inline art name) followed by a standard action entry. Keyframes live outside the file, in the "ME" archives of readef.DAT; win poses (0x11..=0x18) decode from the base archive, everything else from main.
• Facial tracks (entry +0x8C eyes, +0x98 mouth) are stamped over the head section's texture rows per frame; during the victory quote the mouth comes from a static SCUS table instead.
• Equipment-variant track (entry +0xA4): two [start, end] frame windows that swap a 0xFF variant onto its attach-bone channel - a mesh swap, not a stamp. Live windows exist only in Noa's file. The port keeps retail’s per-channel model table (legaia_engine_battle::battle_attach_swap): the world steps a party seat’s table on every battle pose, and both play hosts draw only the objects it names for the playing stream’s channels, which also hides the 0xFE extras outside surplus-channel streams. The after-image walk re-runs the swap per ghost, so on a ghosted frame the live body draws the table the last ghost left, as retail’s does.

Editing: carrying a weapon into another character's file

A file only holds records for the items its character can equip, so a weapon handed to another character through the owner mask alone lands on that character's bare-hand default. The patcher's --equip-owner builds the missing record (legaia_patcher::equip_transplant):

1. Cut the weapon's primitives out of the donor record (item-alone cut; CLUT columns remapped onto the target section).
2. Merge them channel by channel into the target's weapon-section default - the held sections are the same three arm bones on every skeleton, only numbered differently - and re-seat each channel through a rigid transform calibrated from the weapons both files carry (equip_hand_frame, per weapon class).
3. Carry the donor's texture tile as the pool under the weapon's palettes; sections 2 and 3 share a texpage and differ only by tile row.
4. Keep the target default's header, loader frame, attach list and swing records; set the swing record's +0x74 to the donor weapon's cost.

Not unlocked this way: Ra-Seru forms, body, head and footwear - those records are a whole re-sculpted limb on the donor's skeleton (above), and Terra's file has no equipment sections.

Parking the records in DMY.DAT

The loader never bounds a file by its TOC span - after the prologue read it streams slots by seeking a 32-bit gap forward from the previous slot. A rebuilt file that outgrows the free sectors between entries 863..865 therefore keeps its first 0x8000 bytes in place and puts its whole slot region, in chain order, into DMY.DAT, the unused developer-fixture file at the end of the disc, with every table offset displaced accordingly. The image keeps its size, so a PPF carries it. Two rules follow: slots must stay in chain order (the gap is unsigned), and old record sectors are simply left unread.

Not the monster archive

The monster stat archive (extraction 0867, legaia_actor_formats::monster_archive) shares the [dec_size][LZS] → mesh + texture pool shape but nothing else:

How we know

CLI

# Inspect one player file's slot table.
asset battle-data-pack extracted/PROT/0865_battle_data.BIN

# Dump every decoded slot to a directory.
asset battle-data-pack extracted/PROT/0865_battle_data.BIN --out /tmp/0865_records

# Bulk-scan a directory of PROT entries for this shape.
asset battle-data-pack-scan extracted/PROT --cdname extracted/CDNAME.TXT

Full reference, including the texture-block catalog and replacement commands: docs/formats/battle-data-pack.md.

See also