Slots, backups, and autosave
Review draft. This source page has not completed website editorial and release-specific verification.
Slot storage
Section titled “Slot storage”A slot is exact SlotName plus UserIndex. Names are not normalized; require nonempty after trim, at most 128 characters, and no control characters. User index is nonnegative. Physical storage uses Unreal’s SaveGame abstraction.
FSaveGameDirectorSaveRequest::bAllowOverwrite controls replacing an existing slot. If overwrite is enabled and setting bKeepPreviousSlotBackup is true, existing data is copied first to <SlotName>.SaveGameDirectorBackup.<UserIndex>. Backup read/write failure fails the save before replacing the main slot. C++ exposes DoesSlotExist and DeleteSlot.
Memory
Section titled “Memory”Use SaveToMemory to create a canonical USaveGameDirectorSaveGame; retain it and pass to LoadFromMemory. Blueprint sync and async memory APIs exist. Do not change encoded data.
Autosave
Section titled “Autosave”Project settings control enablement, requested/minimum intervals, rotation count, asynchronous default, and diagnostics. Current defaults: enabled, 300 seconds, 30 second minimum, three rotating slots, async. Autosave uses the common operation pipeline and advances/wraps through its configured slot rotation.
Call StartAutosave after safe gameplay initialization. It can be prevented by disabled settings, unready lifecycle, invalid interval, or blocker IDs. Use AddAutosaveBlocker / RemoveAutosaveBlocker around unsafe transitions and ensure every path removes its blocker. TriggerAutosaveNow submits through normal coordinator queue/coalescing rules. StopAutosave stops future scheduling but does not cancel an active operation.
There is no separate profile/account manager. Slot name and Unreal user index are the available addressing model.