New-game starting-party table Confirmed

At a glance

In the game

The moment NEW GAME is confirmed - the party's opening stats, names, bag and gold

Where

Table at SCUS VA 0x80078C4C; bag and world-state seeds are instruction immediates in FUN_80034A6C / FUN_800560B4

Size

4 records × 26 bytes (8 × u16 stats + 10-byte name)

Expands into

The live save records at 0x80084708 + n × 0x414

Parser

legaia_game_tables::new_game (StartingParty, StartingInventory, new_game_seed_words, seed_live_records); CLI asset new-game <SCUS> [--json]

Confidence

Confirmed - byte-search of the executable cross-validated against a live town01 save state; seed stores read off the disassembly

Used by

Boot, Level-up, Randomizer

What a New Game is made of

Confirming NEW GAME launches the field overlay with a fresh game state built from four sources. Only the first is a table.

At a true New Game only Vahn has joined; the other rows are the templates used as each character is introduced.

Record layout

One row per character, 26 bytes, no header: eight little-endian u16 stats and a NUL-padded name.

Decoded values

Starting bag and world state (code literals)

The new-game data-init routine holds the save-context base in a register for its whole body and writes fixed values at offsets from it. The bag is one (id, count) pair in the owned-item array at SC + 0x1818 - a single ordered list shared by every item category, which the menu merely filters into Items / Goods / Key tabs. A seeded slot can therefore hold any id, which is how the randomizer's starting-bag toggles seed keys and accessories.

Widths come from the store opcodes (sb / sh / sw), not from the decompiler's globals naming. StartingInventory decodes the bag by replaying the routine's register-sourced stores, so it reads back either the retail byte pair or the randomizer's packed halfword (id | count << 8).

The entry seat

Three further stores in the same routine are absolute rather than save-context cells: 0x80073EF4 = 0xE40, 0x80073EF8 = 0x2DC0, 0x80073EFC = 0. They are the field initialiser's destination-entry operand - the same words a door's scene change or the world-map arrival writes. The first scene a New Game loads is the prologue opdeene, so the seed seats the player there at world (0xE40, 0x2DC0), tile (28, 91); opdeene's entry script reads the seat once to pick its region (and view window) before the opening record moves the player on.

Starting level and experience

The template expander also initialises each live record's progression cells. The shown level is read from +0x130 directly, never re-derived from experience: a record with level-10 experience but +0x130 == 1 shows LV 1.

+0x131 is write-only. The seed's li $v0, 0x1 at 0x800561C4 feeds sb $v0, 0x6F9($s0) (+0x131) at 0x800561C8 and sb $v0, 0x6F8($s0) (+0x130) at 0x800561CC, and 0x800561C8 is the only instruction anywhere on the disc that touches the byte: sweeping SCUS_942.54 plus every based overlay image for a lb/lbu/sb at displacement 0x131, or at the four slots' 0x6F9/0xB0D/0xF21/0x1335 off the 0x80084140 game-state block, returns that store alone, and no wider access covers it. The "magic-rank candidate" reading is therefore retired - the magic-rank counter is capture-pinned at record +0x9C.

In the port

legaia_game_tables::new_game reads the table and the seed routine's literals from the user's own SCUS_942.54 (same address-to-file-offset resolver as the item-name table): StartingParty for the rows, StartingInventory for the bag (it replays the routine's stores, so it reads both the retail byte pair and the randomizer's packed halfword), new_game_seed_words for the world-state cells and seed_live_records for the expander's record stores. CLI: asset new-game <SCUS> [--json].

Retail's seed loop fills all four live records, so a member who joins later (field op 0x3C) already has a level-1 record. The engine's New Game roster is Vahn alone and keeps the template beside it; when a party list names a slot the roster has no record for, World::set_active_party seeds that slot from the template, so a joining member fights with real HP rather than an empty record counted alive.

How we know

The table base comes from a byte-search of the executable for Vahn's stat run and name, cross-checked field by field against the live record in an early town01 save state; the bag, gold and seat literals are read off the seed routines' disassembly.

See also