Yearn save states: keep key progress in separate slots

English translation of the Chinese original, translated on 2026-10-23. The article body uses automated translation; app descriptions, historical reading notes and video subtitles receive separate editorial checks. Original publication dates, attribution, code and version notes are retained.

Save states create checkpoints at identifiable moments, such as before a level, after an action sequence, or before new settings. Yearn's save list provides multiple slots. This article distinguishes saving from loading and verifies the scene a record restores instead of assuming that a timestamp means progress is safe.

Understand the two buttons' directions first

The save list in the game menu commonly offers Save and Load. Save writes the current runtime state into the slot; Load brings the slot's state into the running game. One changes the saved record, the other changes the current game. Pressing Save when you intended to restore old progress may overwrite it with the present scene.

Learn with one practice game and an empty slot. Write 'store = Save; restore = Load' in your notes and remember the current slot number. Do not make your first experiment on the only save from a long game or tap a button simply because its color is prominent. Read the action name first.

Give slots different purposes

Use the first slot for a fixed milestone, the second for current practice, and another for temporary comparisons. The app need not name their purposes automatically. Record them yourself, such as Before Level Two, Before Jump Practice, or Before Speed Adjustment. Then Slot and a timestamp are enough to identify each record.

Multiple slots preserve different checkpoints, not repeated copies of one state. Before saving, check the character's position, current menu, and existing timestamps. If you cannot explain why a slot should be overwritten, choose an empty one first. Verify the new record before deciding whether the old one is still needed.

Verify loading through scene changes after saving

Save at a recognizable position, return to the game, and move forward slightly or open another menu. Reopen the same slot, tap Load, and observe whether the scene returns. Character direction, objects, or menu options can be references, provided the before and after states are clearly distinct.

If the timestamp changes but the loaded picture does not visibly change, the two states may be too similar or loading may have failed. Try a more recognizable checkpoint and watch for errors or a waiting state. Do not judge by repeatedly pressing Load; allow time to observe each operation.

After success within one run, check reopening

After the first successful load, exit safely through the game menu, reenter the same game, and inspect whether the slots remain. This differs from testing in one run: it checks whether the app finds the associated records when it identifies the game again.

Rescanning, renaming, reimporting, and changing devices all require rechecking game-to-save associations. Complete this check on first use. If slots are empty after reopening, retain current app data and originals. Do not delete the game and retry or create many new records that overwrite useful diagnostic clues.

Treat game-version and core changes cautiously

Save states are generally tied to the game data and emulation state at the time. Do not assume another regional version, modification, or file sharing the same name can load an old slot. After app or core updates, test copies and noncritical records first. Identical filenames do not establish complete identity.

Keep the relationship among original ROM, app version, save time, and slot purpose. It is more helpful than only a Save Successful screenshot. Before trying another edition, make an independent backup rather than silently replacing active content through same-name overwriting.

Check the scene before overwriting an old slot

Before overwriting an old slot, recall its purpose and compare the displayed time. If the character is in a failed state, pause menu, or temporary test scene, choose another empty slot rather than replacing a reliable milestone.

Before a key scene, place a reliable milestone in a separately documented slot and use another slot for repeated temporary attempts. The list selects current records; it does not automatically retain history before every overwrite. Read the slot's purpose before deciding whether its old record is worth replacing.

Questions and final checks

Why is Load unavailable? Check whether the slot contains a record or shows Empty. An empty slot has nothing to load. If an existing record cannot load, note the game version, slot number, and error instead of overwriting it first.

Does a missing slot after exit mean its file was definitely deleted? Not necessarily. The visible list and its association with underlying records are different matters. Retain data and begin with backup and diagnosis instead of reinstalling and potentially removing material that still exists.

At completion, you should have two slots with different purposes, at least one verified scene restoration, and a record of the result after reopening. Apply the process to important progress only after confirming those facts. Keep failures as unresolved issues rather than replacing checks with 'it should have saved.'

Keep two checkpoints visibly distinct

Put one checkpoint before a level and another at a recognizable place within it. After loading, compare scene, character position, and menu state rather than only time. If the records are too similar, create an obvious difference in the practice copy and check again so nearly identical pictures do not make the button seem ineffective.