Full-game ladder: New Game to the credits

At a glance

Test

crates/engine-shell/tests/full_game_ladder.rs (part C in full_game_ladder/continuous.rs)

Spine

scripts/replays/full_game_spine.toml - the milestone list, New Game (opdeene) to the credits crawl (edlast)

Baseline

scripts/replays/full_game_baseline.toml - every score is asserted >=; a drop is a finding

Part A

The spine is anchored, ordered and routed through the disc's scene graph

Part B

The segmented ladder: each segment seeded from its milestone's retail save and scored on four cumulative tiers

Part C

The continuous run: one New Game, never re-seeded, reloading only its own saves after a wipe

Needs

Your disc (LEGAIA_DISC_BIN), the extracted tree and the save library; without them every part prints [skip] and passes. Anchor bytes are read at test time and never committed.

Three terms recur below. A scene's script records live in partitions: P0[n] holds placed props and doors, P1[n] NPC and entry records, P2[n] walk-on and spawned records. A walk-on band is a run of tiles that starts a P2 record when stepped on. A story flag is one bit of the system-flag bank, written like 0x227; op 0x3F is the field VM's scene change.

How it relates to the other ladders

The chapter ladders are deeper where they reach; this one is shallow and wide. A stall here names where to point the deep instruments.

The spine

The spine is the main-story milestone sequence. Each milestone names its scene and a retail anchor: a save on one of the library's memory cards (card file and save name) or a catalogued save state (scenario label and backup fingerprint). The ladder reads the anchor's SC save window, RAM 0x80084140..0x80086140 - exactly the block a memory card stores (save record) - so a card save and a live state yield the same thing: party records, bag, gold, the system-flag bank at 0x80085758, the scene label and the field position snapshot.

The order is the anchors' own. The two playthrough cards are one run whose play-time counters and flag populations rise together; chapter-1 anchors, which come from several sessions, are ordered by flag inclusion; the ending anchor is a debug credits run that anchors the scene but is excluded from the order check.

Part A re-derives all of it: every anchor loads into the scene the spine names, the flag-inclusion order holds pair by pair, every reach flag is set in its own anchor, and a route between consecutive milestones exists in the disc's scene graph. It prints that route with its hop kinds:

Routes are cheapest-first with walk-on hops preferred, so a => in a route means no all-walk-on route exists. What "reached" means is per milestone: scene (in the scene, walking), control (and the pad is back) or flags (and every reach flag is set). A reach flag is one the anchor gained over its predecessor that a clean partition-2 SET site in that scene writes, per the disc-wide system-flag census; entry-script writes are excluded because they fire on every visit.

Waypoints

The cheapest route is not always the story's. A milestone can name via scenes - story waypoints the anchors show the retail run passed through - and they are visited in order, each with its beats pass played, before the route heads for the milestone itself. Each is justified in the spine by the flags that put it there. Typical reasons:

• An item behind a detour. The Fire Path milestone goes through stone, which holds the Star Pearl that opens the tunnela door; the cheaper elevator route only opens after Xain.
• A flag another scene waits on. conc3 P2[10] sets the 0x3E5 the juui1 hand-off in conc2 tests; dohaty P2[13] sets the 0x1D4 every station placement waits on.
• An errand. Sol Tower B2 visits koin2 and koin4 for the Sage's Gate chests and the bread they ask for.
• A shortcut that leaves the dungeon. In garmel and vozz the cheapest route walks back out to the overworld; the story's way on is a boss or a scripted flight.

A milestone may instead name continuous_via: waypoints only the continuous run plays, where a seeded segment starts past the story or its seated hand cannot play it. Dr. Usha's research and Nivora are the case.

Segments, tiers and seeding

One pad run cannot cross the game, so the ladder is segmented: segment i seeds the engine at milestone i and asks how far it gets toward milestone i + 1. Segment 0 is seeded by BootSession::start_new_game - the cold opening, not a save. The tiers are cumulative:

The headline is how many milestones a cold New Game reaches contiguously at progresses and at pad, plus the tier sum over all segments.

Seeding

A seed goes through the host's own resume path, BootSession::resume_save, so a segment is a load of a real save. The import carries the whole system-flag bank, the party count and roster, and the field position snapshot where the resume seats the party. The anchor's Field Move option comes in with the other options words, as retail's card load restores it, so the ladder's player runs or walks as the anchor's player did - timed scripts are paced for it. A state anchor taken mid-field has a live position that differs from its snapshot, so the ladder arms SceneHost::set_entry_seat with the live one; a card save seats from its own snapshot.

The continuous run

Every segment above starts from the retail save at its milestone, so it plays with the party, bag and gold a retail player had there. That scores each stretch's doors and scripts; it does not say whether the engine's own run arrives at a stretch able to clear it. Part C asks that. It seeds one session with start_new_game and plays the pad pass toward each milestone in turn, never re-seeding.

• The story state is the engine's from the first frame. The next anchor's flags still steer the beats pass - they are route knowledge - but nothing of an anchor's party or bag reaches the session.
• It keeps its own saves. At each milestone reached it takes World::save_full; after a party wipe it reloads that save, with the same guard retry and reload allowance the pad tier has.
• It stops at the first milestone it cannot reach and prints the stall.

What only a continuous run exercises

A seeded segment starts from state retail wrote, so anything the engine would have had to write itself before that point is never asked of it. The continuous run is the only pass in which those writes are load-bearing:

• Scripted grants. A flag, item or equipment change an earlier script makes is in every later anchor whether or not the port runs the op correctly. Op 0x3B (SET_EQUIP_SLOT, how a Ra-Seru is put on and grows a stage) is the case in point: a mis-applied port still passed every segment, because each seed already wore the Ra-Seru.
• Joins after a reload. A member who joins takes a level-1 record from the starting-party template, which a seeded save (already holding all four records) never reads.
• The pause menu, the shop screen and the Point Card. No seeded pass buys; the continuous hand drives the merchant's op 0x49, the buy list, the quantity stepper and the recipient picker, and with the card held every purchase runs its accrual and toast.
• Growth and captured Seru. Levels, gold and the bag are what the run earned, and a party that fights learns Seru magic and casts it into rounds where a target may already have died - the turn picker's dead-target redirect.

How the continuous hand plays

The continuous hand is the pad tier's hand plus what a player who means to finish does between fights. On arrival in a field scene it runs one upkeep pass, in this order:

1. Shops. It talks to each merchant with a priced stock list, buying healing items for each present member, then the affordable equipment that improves a slot the most, then more heals. Stock is counted in healing restored, not item count, and a counter that sells heals is visited first.
2. Equipment. Start, Equip, the Best Equipment row for each member; empty Goods slots are filled best passive first. Because Best Equipment ranks a weapon by stats alone and an off-class weapon raises the arm command's AP cost (arts command gauge), the hand then swaps in a weapon that swings cheaper.
3. Rest. Under four fifths of its HP (or low MP) in a scene that rolls no encounters, it takes the scene's rest: a bed's walk-on band or a keeper whose record runs the 4C 82 restore.
4. The scene's story. It plays the beats pass without waiting for a door to refuse, for further rounds while a round still raises a new flag.
5. Training. While a member is more than a level short of the target - the anchors' own level curve a few milestones ahead - it trains from the bed, taking the fights it prices as winnable.

In a fight it takes the random encounters it expects to win, pricing each from what the run's fights have cost so far, and runs from the rest; it saves MP for fights it cannot flee, aims its strikes and casts at the foe they land hardest on (stepping retail's angular target ring with Right), and runs past encounters on the way to a staged boss so the party's HP and bag are the boss's. Its options travel with its saves, and it switches Field Move to Run when walking is what holds it - the playthrough's player had by Mt. Rikuroa.

The carried-state diff

Under LEGAIA_FGL_TRACE the run prints, at each milestone and at the stall, the engine's own state beside the retail anchor's: levels, XP, HP, MP and equipment bytes, the party, gold and bag, and the flags each side holds that the other does not. It is what tells an engine defect from a weak party:

How the two passes play a segment

The seated tier

Seated traversal follows the route hop by hop. On a field scene it seats the player one tile off a walk-on door and then onto it, so the engine's own tile-change dispatch fires the door record; on the overworld it seats the player on the installed portal. The engine does the scene change; the ladder only places the player. A hop that still fails after the scene's beats have run marks its edge dead, and the route is recomputed around it.

The beats pass runs once per scene visit - and again when the story returns to a scene with new flags - when the scene is the target with its reach flags unset, at a waypoint, or when a hop's door does not fire. It approaches every boss stager whose park gate is clear, every round until a contact gains nothing, and talks to the NPCs whose records reach a flag the next anchor carries or a destination the route needs.

The pad tier

The pad tier repeats the route from a fresh seed with the random-encounter roll armed, and plays the same waypoints and beats with pad input only. It plans with an A* search over the collision lattice (World::field_dir_blocked and the actor boxes) and follows the plan with a walker that inverts the live camera remap. The planner models the two ways a field map joins its own parts - a town's house interiors sit in the same map as its street:

• a kind-0 teleport tile is an edge to its landing cell, and a closed door prop standing over one counts as open, since pressing into it is the touch that opens it (31 00);
• an object door - a touch-class or interact-class prop whose record reaches 31 00 - opens itself on contact or on the action button, which the follower taps when held against it.

Where the start's walk component cannot reach the door, a pad hop tries a crossing scene. Ledge hops, warp pads that read their own floor list, clocks and timed switches are each modelled where the route needs them.

Input conventions in both passes

• Scripted sequences get Cross on a press-2-release-14 duty cycle, and nothing while no script holds the frame.
• The naming prompt's Yes/No confirm gets Up first, since it opens on No.
• A menu press waits out the field pad hold (_DAT_8007B6B4): every map install seats 0x28 frames of it, the field-back load after each fight included, and a conversation's release 0x10. The pad controller and its menu accept sit it out, so a Start sent into it is lost; the heal and dress passes after a fight press only once it is out.
• An all-party restorative (Healing Bloom, Magic Fruit) is confirmed on its party-wide confirm, which picks no row.
• BootSession::tick routes the naming prompt's pad edges and drains the per-tick queues as both play hosts do, so a headless driver that only ticks crosses the opening.

How fights are played

A battle is fought through the command ring, one pad edge at a time, by a fighter shaped like a player. For each member, in priority order:

1. Revive a member who is down.
2. Heal a member in danger - a party heal when two or more are, else the smallest single heal that lifts the worst-off clear. Heals already committed this round count as landed.
3. Cast the strongest affordable damaging Seru spell.
4. Attack through Command, entering the longest art the command pool pays for and spending the rest on plain directions; whether a matched art fires is the queue builder's call. Rotted limbs (+0x16E & 0x38) close their own directions, and the plan keeps to the open ones.

A member is in danger when it is under 45% of its HP (three fifths against a boss far above the party's HP), or cannot survive another loss the size of the biggest it took between two of the party's command windows - a round, not a hit.

Random encounters that interrupt a segmented pad walk are fled through the round prompt's Run, unless the fight forbids running; after two failed runs with nothing to heal with, against foes the party can plausibly beat, the hand fights instead. Guards and boss reads: a foe that winds up - a charge body that sets its caster's ability latch and deals nothing - is guarded against on the turn its blow lands, and a boss lost to once is retried with its element guarded.

Tick caps. A fight runs at least 60 000 ticks and continues while a foe's HP is still dropping, up to 600 000; it is unresolved only once 36 000 ticks pass with no foe losing HP.

How to read a stall

Part B prints one table row per segment and a stall list. Each stall line is one level down from the tier that failed:

Under each failed seated segment the ladder lists the flags the next anchor has that the engine never set, each with the disc sites that set it (scene, partition, record) from the system-flag census - usually naming the record to look at next.

A third shape is a boss the anchor's party cannot outlast: the hand's damage rolls are right - every term reads off the disassembly - but the party saved at that anchor cannot survive the boss's turns, and the fix belongs in what the fighter chooses (guards, healing order, MP top-ups) rather than in the engine.

Diagnostics

With its wall-clock fields stripped, the trace of part C and of part B is byte-identical across runs of one binary on one stream. Nothing the hand does may follow a std HashMap's iteration order, which is drawn per process: town0d has three talks that lead to jou, and the order they are walked in moves every later frame number in a run that still reaches every milestone. A trace that moves on one binary is checked first by preloading a getrandom that returns a fixed stream, which pins the hash keys and leaves time, threads and heap addresses live.

Trace switches, all environment variables:

How to run

The extracted tree and the save library default to extracted/ and saves/library/ under the repo root; point a worktree at the main checkout's copies:

The ratchet asserts every per-segment tier, both headline counts and the tier sum >= the baseline. Raise the baseline in a reviewed edit from the block the run prints; never lower it to make a red run green. A full continuous run is a whole New Game, so the seed set is run one seed at a time.

Solid NPCs

Both play hosts make NPC bodies solid; the ladder's pad tier leaves them passable unless LEGAIA_FGL_SOLID_NPCS=1 arms them. Armed, a body stops the walk exactly as it stops a player, and the pad hand has to go round it or be let past by the story:

• A person is walked round, not spoken to. A press held against an NPC re-plans from where the body stands instead of tapping the action button, which in the misty Rim Elm starts a fight.
• The planner reads the bodies the walk collides with, and leaves out the one on the goal tile: that is who the walk is going to.
• A body the camera's window hides is still planned round. It is solid again by the time the walker reaches it, and some are plugs: in the Bio Castle corridor an invisible item stands in a gap the scene opens in the wall, and on retail it still blocks the gap after it is picked up. A body outside the room's latched region box stays passable until the next warp, and is left out.
• Bodies that seal a route are dropped in stages, first all but those within eight tiles, then all of them, and a failed plan is remembered only while the bodies stand where they stood.
• A talk side inside a wall is skipped, and a lean another body stops short steps along the counter and leans again.
• A door contact that lands on the tile it is pressed from is not an exit.
• A wall corner the planner reads open is stepped off sideways. The walk's leading probes reach past the player's own column, so a walk a few units off a narrow corridor's line presses into the wall beside it; after eight frames without moving it takes one sideways step and goes on.

A body can also be a story gate, and then no route is the right answer: some guards stand in the only way on until a story branch moves them, and the route plays the scenes that do. Nivora Ravine is one: sixteen BLOCK placements stand round the landing until Dr. Usha's research is done, and the entry script retires them only then. A run that left Dr. Usha's lab town without that flag reached Nivora boxed in, which is how the solid-body run found that its hand stood in the intercom's box a few units short of where the intercom answers.

What it cannot measure

• The seated tier places the player. It proves doors, scripts, gates and the scene graph, not locomotion; the pad tier is the locomotion claim.
• The segmented hands do not shop, and pick conversation options by rotation. A beat that waits on a purchase or an equip reads as a stall there; only the continuous hand buys.
• The segmented fighter is narrow. It guards only a foe that hits hard every other round, takes the target cursor where it opens, changes equipment only to guard a boss's element after losing, and flees random encounters. A fight that needs anything else reads as a wipe.
• Crossings are found by trial. The pad planner does not read which side each door of a crossing scene lands on, and a crossing whose side is story state needs that beat played first.
• Transports a script spawns on a flag are not graph edges. Routes follow 0x3F names and FMV hand-offs; a flight or cart an entry script spawns is taken on arrival, which the graph does not model.
• Waypoints are hand-set from the anchors' flag differences; a stretch whose retail path left no flag the census can place has none.
• Chapter-1 anchors come from several sessions, some with cheat-seeded parties, so they seed faithfully to that session rather than to one canonical playthrough.

Route notes

The full page keeps a long list of scene-specific facts the route and the pad hand depend on, each a property of the disc's scripts cited by scene and record. They fall into four groups:

See also