Ren'Py Schema Changes: fix_rollback() vs Disabling Rollback for Save Compatibility

Direct Answer

Call renpy.fix_rollback() after the schema change has been applied to the live game state (i.e., after migration logic runs and new defaults are in place). This prevents rollback from rewinding into pre-change snapshots while keeping old saves loadable. Disabling rollback entirely is a heavier-handed fix that removes a player-facing feature and is rarely necessary.

Why This Works

Rollback restores pickled object snapshots. When you add a field to a class, old snapshots lack that attribute. Post-change code reading the new field on a rolled-back snapshot raises AttributeError. renpy.fix_rollback() truncates the rollback log at the call point, so the player cannot roll back past the migration boundary. The save file itself is untouched—old saves still load.

A safer alternative

To make the schema change rollback-safe by construction, give the field a class-level default or use __getattr__/defaultdict-style fallbacks. This ensures old own resolve the attribute without needing to truncate the history.

Recommended Pattern: One-time migration

The goal is to apply the field default on load (e.g., via an after_load or init-time migration), then call renpy.fix_rollback() so players cannot roll back into the unmigrated state.

init python:
    def migrate_schema():
        for obj in store.affected_objects:
            if not hasattr(obj, 'new_field'):
                setattr(obj, 'new_field', default_value)
        renpy.fix_rollback()

config.after_load(migrate_schema)

Disabling Rollback: Trade-offs

Disabling rollback globally (via config.rollback_enabled = False) eliminates stale-snapshot restores but does not fix old saves—it only stops the crash path. This is a visible regression for players who rely on the mechanic.

• It removes the feature globally or per block.
• It does not migrate existing save data.
• Only use if the schema change is fundamentally incompatible.