The endless camera orbit

At a glance

What stalls

The per-action battle state machine, parked in state 0x19 (attack approach)

Where

Battle-action overlay, PROT entry 0898, load base 0x801CE818

Trigger

Kemaro, then - inside one idle loop - a melee by its target, a monster with no walk animation, against an out-of-reach target

Affected

180 of 186 monsters take the affected path, but the clip lengths make Gaza 2 the one fight where the chain lines up in ordinary play

Fix

Nine same-size words at overlay offset +0x14D50; --approach-softlock-fix

Confidence

Confirmed - live captures on two emulator cores, replayed with the fix

What the orbit means

The orbiting camera carries no information of its own. The battle round driver sweeps the camera's idle azimuth every frame without consulting the action state machine, so an orbiting camera is what any stalled Legaia battle looks like. The component that stops advancing is the per-action state machine in the battle overlay.

Two independent live captures localise it. A poll-only emulator probe flags any action state held for thousands of frames; both captures park in the same state: 0x19, the attack approach.

Four ways out of an attack

Every physical attack enters approach setup, state 0x14. Its first act is a range check - “within reach” is a size-scaled radius, about 416 units for a boss-sized actor. From there the attack routes four ways:

The decisive branch is the walk gate. Out of reach, a monster attacker needs its approach-transition clip - action tag 0x20 in its per-monster action table. If the tag is missing, setup stages the ordinary tag-1 “Move” locomotion clip instead and drops into the wait-in-range poll. A sweep of the monster archive puts numbers on it: 180 of 186 monsters have no tag 0x20, bosses included. All 186 carry the Move clip - the float or walk cycle the enemy viewer shows.

An approach the state machine does not perform

The two approach mechanisms differ in one property. The walking states 0x15–0x18 contain the state machine's own stepping code - a monster in that chain is moved by the engine. The fallback state 0x19 contains none: it re-derives facing, re-polls the range check, and on failure bumps a counter that nothing reads as a timeout. All movement comes from the staged animation's playback: the Move clip slides the actor along its facing at about 19 units per frame.

Position captures of ordinary play show this working every time: a healthy boss melee starts out of reach (438–1,078 units against a ~416 reach - standard formation spacing is out of reach; the models are large enough that it reads as adjacent) and the Move clip walks the boss in over 28–67 frames. The path fails only if the animation stops, and no code can observe that it stopped: the clip is staged once, in 0x14, and never again.

The trigger: Kemaro, then the melee

The second capture logs the actor's animation pair - staged clip versus playing clip - every frame, which pins what kills the clip. Kemaro carries its target ~2,500 units off-arena and stages his hit reaction there, which sets the “exit to idle at clip end” flag. Its put-back starts his idle pose through the mid-clip commit, which keeps that flag, so the flag waits for the end of his idle loop - 360 vsyncs. When his next action inside that window is the melee, the Move clip carries the flag and is swapped for idle at its first loop end, about 12 frames in.

• The window is one idle loop. Kemaro → another combatant's turn → melee runs the same clip 64 frames to a clean hit: the turn in between outlasted the loop. A cast by the boss in the window spends the flag harmlessly.
• It reproduces on demand. Cast Kemaro with the caster acting directly before the boss, and the approach parks whenever his next action is the melee. A scripted run did exactly that on the first Kemaro, with the boss's HP and MP poked lower so that he melees; the patch's guard, poked into that park, unparked it.
• A plain hit cannot cause it. Every other hit reaction plays to its end before the action is over, and that end clears the flag. Only Kemaro's put-back keeps it.
• Gaza 2 is the extreme case. Of the 180 walk-less monsters he has the longest idle loop and the shortest Move loop, and the HP to survive Kemaro again and again. The few other candidates need a wide gap or die to Kemaro.
• It is not an emulator artifact. The same recipe parks under both PCSX-Redux CPU cores with an identical onset, and every length in the chain is counted in game frames. A failed repro elsewhere is most likely the chain not lining up.

v26536  summon cinematic: boss staged off-arena to (0,-2048),
        his damage-reaction clip plays (pair 2/2), restored, pair -> 0/0
v26867  summon action ends
v26873  boss melee starts DIRECTLY next - 0x14, target ~1022 away -> fallback
v26876  0x19, pair 1/1: Move clip ENGAGED, sliding ~19 units/vsync
v26888  pair 0/0: clip DEAD after ~12 vsyncs / ~236 units
        frozen at ~786 (> 416 reach) -> polls forever  = the softlock

The fix: teach the poll to re-stage

Two fixes are possible. Retargeting the walk-gate fallback straight into the strike (one word - attack from wherever you stand) closes the softlock but removes every monster's approach walk, because out-of-reach is the norm. The shipped fix addresses the defect itself: the dead clip that nothing re-stages.

There is no free space for new code - every verified-dead run in the executable is occupied by other patch features - so the guard replaces nine redundant words inside the poll itself. State 0x19 recomputes the actor's facing every frame, but the target does not move during an approach and both neighbouring states recompute it anyway. Nine words with no observable effect, exactly where the guard needs to live.

The guard reads the staged-clip byte each poll. While the clip is alive nothing happens - healthy fights are byte-identical. If the clip is dead while the poll still fails, the guard sets the state byte back to 0x14. That single write is enough because the staging logic already exists in retail: the 0x14 arm re-runs next frame, re-checks the range, re-stages the Move clip, and the attacker resumes walking. If the clip dies again, the guard fires again - a stuttering but monotonic approach that always arrives.

Apply the fix to your disc

The fix is seedless, composes with every other patch option, and the Balanced / Full Chaos presets enable it by default. See the patcher reference.

How we know

The full evidence trail is on settled RE threads.