- The
StartPostab’s Set and Load actions use Akron’s persistent StartPos snapshot for the selected StartPos slot. - The Speedrun Tool Capture State and Speedrun Tool Restore State bindings drive Speedrun Tool’s active 1-9 savestate slot and are unrelated to StartPos.
StartPos capabilities
Setting a StartPos captures an in-memory native clone for same-process loads while a worker builds and validates the restart-safe v12 snapshot. After a restart, or when the in-memory copy is unavailable, Load reconstructs the state from that snapshot file. It contains room entities and components, their reference relationships, movement, timers, state machines, animation, coroutine progress, callbacks, registered helper state, Celeste’s random generator and nested random stack, visual runtime entities, gameplay render-buffer pixels, and audio state. Akron holds the Set or Load state through fixed-timestep catch-up updates until Celeste renders it. No external savestate or TAS mod is required. Room state still restores in full. Time and death statistics are the documented exception and do not rewind. Use theStartPos tab for player workflows: setting, loading, clearing, selecting a slot, mouse placement, and configuring respawn at StartPos behavior.
Why persistent StartPos Set or Load may fail
Persistent StartPos Set or Load may fail if:- A Set capture is still finishing.
- Celeste is paused, transitioning rooms, or running or skipping a cutscene.
- The saved StartPos belongs to a different map SID or save-file slot.
- The v12 snapshot file is missing, damaged, or incomplete.
- The map, save file, mod set, runtime, or snapshot format differs from the capture environment.
- The slot was set by an earlier Akron that built fresh rooms differently, so its restart copy uses a superseded snapshot format.
Recovery steps
1
Wait for a stable room
Resume Celeste, finish any room transition or cutscene, and wait for the previous Set capture to finish.
2
Use a non-submission setup
Use a non-submission setup for room-lab routing or tests that involve StartPos.
3
Verify the StartPos slot
Confirm that the active StartPos slot is set, belongs to the current map and save-file slot, and names the intended destination room. The room you load from can differ.
4
Check the snapshot
If the in-memory state is unavailable, confirm that the matching v12 snapshot still exists and was created with the current map, save file, mod set, runtime, and snapshot format.
5
Set the slot again after a snapshot format change
A slot the format move emptied leaves the slot list, so loading it reports that it was saved by an older Akron that built rooms differently. That slot predates a snapshot format change and cannot be recovered. Set the StartPos again. Akron does not convert older snapshots: an older snapshot describes a fresh room that this build no longer produces, so there is nothing correct to convert it into.
6
Document the issue
If the problem remains, record the map SID, save-file slot, Akron setup, StartPos slot, visible error, and logs. Attach screenshots when they show the failure.
Snapshot format changes
A StartPos snapshot records map identities, ownership relationships, and structural paths into a clean room reload. Reconstruction checks that evidence before applying the saved graph; a matching list index alone does not establish entity identity. The snapshot format changes when those assumptions change or a snapshot needs additional required state. The current format isakron-reconstruction-v12, which records whether Akron owned the saved global timescale and the clock value it replaced. Older snapshots lack that ownership and cannot safely restore timing under map restrictions. Akron refuses them rather than partially restoring them.
Slot positions, spawn settings, keybinds and every other setting survive a format change. The saved room state behind each slot does not, and has to be captured again with Set. .akr setup packs carry the same snapshots, so a pack made before the change has to be exported again as well.