Autopilot · write-up
Level 5 resident-C validation — 2026-10-04
Latest full-level result: R305 collected both opening POWERUPs and completed Level 5, including the spaceship, with all three lives intact. Four earlier damage frames and two missed spaceship coins remain. See pickup correction and complete incident report.
Follow-up: the stall begins at the right-mount transition, 41857–41868, before the monitor's late report. The center route initially exists, but mission ownership, clearance rejection and camera advance prevent traversal. A local C correction now clears this chamber from three tested starts; remaining damage/pickup limitations and the older source comparison are in LEVEL5_DIAGONAL_GATE_20261004.MD. The original failed-run evidence below is retained as history.
Recording:
E:/xenon_runs/level5-full-render-audit-20261004-r289.validation/level5-full-render-audit-20261004-r289.x2events.
Both -original.avi and -sprite.avi, the optional level5-trace.log,
150-frame checkpoints and the manifest/source snapshot are in the same directory.
The run is not a Level 5 pass. It stopped at a persistent stall before the tank, shop and final boss. Recording started at 39693; the passive raw audit covers 39695–45031, including frames captured during graceful finalization. Shield fell from 39 to 35; all three lives remain. No installed weapon was lost.
Both Hatari and the replay DLL were rebuilt using hatari_dev.ps1 through
validate_campaign.py native-run --build. This was visible, fast-forward,
resident-C gameplay with no Python per-frame controller and no cash cheat.
It resumed the unmodified r278 campaign checkpoint, not an attachment probe.
Both AVIs pass the structural audit, each with 21287 indexed frames. Cleanup
finalized the AVIs and closed the owned emulator; no Hatari process remains.
Incidents
All frames below refer to the recording named above.
| Frame | Problem | Evidence |
|---|---|---|
| 39946 | Missed POWERUP #132972. | Pickup expired below the playfield; nearest hull gap was 13.15 px at 39899. |
| 41194 | Directional projectile #140276 caused 4 shield damage. | Update $4180, source bounds (31,140)..(37,146) overlap player (16,146)..(33,166); collision scroll was 3279. |
| 42009 onward; detected 42908 | Trapped at the right side below the diagonal gate, near world (304,2834). |
No meaningful progress; persistent-stall stop requested at 45029, driver finalized at 45030. |
Stall evidence and next correction
The affected group is level5-tile-pair-r172-c09, native group 10. The
central tile is visibly intact in Original AVI. Replaying captured observations
through the current C session also reports the group closed. This is not an
already-destroyed gate that the persistent map incorrectly retains.
The actual C trace at 45029 shows:
player=(304,2834) scroll=2657 tactic=11 target=0
goal=(156,164,2794,2798) proposed=0x00 planned=0x02 applied=0x02
gate=10 egress=0 destination=(168,2844)
The neighboring frame has neutral input and world Y=2833. The controller
repeats this one-pixel camera oscillation instead of positioning below the seal.
Captured camera bounds at 42908 still allow 15 pixels of backscroll
(scroll=2658, backward limit 2673); it has not exhausted all available retreat.
In choose_diagonal_entry() the authored entrance is selected once player
world Y is 2848 or less. If attack_group() cannot connect a forward or side
firing station, the fallback clears the route and emits the seal's center as a
direct goal. That goal does not describe a route around the diagonal wing. The
stale destination printed beside it is not an active waypoint: the C replay
probe reports an empty route at 42009–42010. These are distinct fields and
should not be interpreted as a valid retreat plan.
The next correction should be local to this diagonal-gate approach: retain a reachable staging/retreat waypoint below the wing, use the available backscroll before attempting the lateral crossing, and align forward weapons with the intact seal. If no station connects, report/recover from that failure rather than repeatedly aiming through terrain. Validate from several earlier approach checkpoints, then rerun the whole level. This run did not change combat/navigation rules in response to the failure.
Pickups and cash
The second POWERUP #133137 retired beside the ship at 39915 and the Drone changed from power 0 to power 1 in that frame, confirming its collection. Health Power 2 #139481 and two already-maximal Side Shot drops #140590/#140943 also retired beside the ship; the generic pickup audit labels these likely collected, not explicit collection events. No Rear Shot was taken.
Of 13 captured cash drops, seven were collected (600) and six expired (500). No boss reward was reached. Detailed identities, pickup lifetime evidence and loadout changes are in r289-audit.json. AVI verification is in r289-avi-audit.json.
Reproduce from the repository root, choosing a new run name:
python xenon_tools/validate_campaign.py native-run NEW-LEVEL5-RUN --output-root E:/xenon_runs --resume E:/xenon_runs/level4-full-after-level3-20261003-r278.validation/checkpoints/f39693-periodic.sav --frames 30000 --checkpoint-interval 150 --build --build-type Release --build-directory out/build/codex-validate --fast-forward --memory-trace off --png-level 3 --port 6932 --continue-after-life-loss --continue-after-stall
For the native trace, set XAP_LEVEL5_TRACE_FILE to an absolute output path
before launching. The live incident monitor is validate_campaign.py's native
observer; audit and screenshots read captured state without running a Python pilot.