-
Notifications
You must be signed in to change notification settings - Fork 0
FAQ & Troubleshooting
- Does it have a Saveable Component?
- Are the variables ticked Save Game?
- Turn on Verbose Logging (Project Settings > Debug) and search the Output Log for
captured- your actor's name should appear during a save.
Renaming a level-placed actor changes its save identity: the old record no longer matches, the actor is treated as missing and (with Respawn Missing Level Actors on) respawned next to the renamed one. Delete old saves after renaming actors, or avoid renaming shipped actors.
They do - On Loaded fires on clients too. If you see defaults, check the client log for the lines in Step 09. Most often the PIE Net Mode is Play Standalone, which has no networking at all.
It should not be: a departing player is snapshotted at logout and written to the active slot (see Step 06). If data still goes missing, check that Save Players and Save Players On Logout are on, and that the session had an active slot (at least one save or load had happened - before that, the snapshot lives in memory and is written with the first save).
Just mark them Save Game - they are captured and restored automatically, keyed by the player id. A Saveable Component on the PlayerController or PlayerState does nothing (the world save ignores controllers entirely) - the component belongs on the pawn and on ordinary world actors.
Under Restore Into Current Pawn, position is yours to apply - the automatic load restores only the pawn's SaveGame data, never its transform. The world save never captures or moves a player's pawn under this policy (not even one you dragged into the level), so this cannot come from the plugin. If it happens with a slot written by an older plugin version, delete that slot: old files could carry a world record of the pawn. Otherwise look for your own Blueprint calling Restore Player Pawn or a Set Actor Location.
GameMode End Play -> Save Game and Begin Play -> Load Game is the supported pattern: the system snapshots the world at the start of the shutdown (before actors are torn down) and an End Play save writes that snapshot. Controlled by the Capture World On Teardown setting - see Step 07.
A crash cannot corrupt a slot: every write goes to a temp file first, is CRC-verified, and only then swapped into place - a crash mid-save leaves the previous file untouched. You lose at most the progress since the last completed save, so on servers run autosave at a short interval and keep Keep Backup File on as a second safety net.
Nothing to do - writes are atomic and a .bak of the previous save is kept
(Keep Backup File setting). A corrupt file fails CRC and the load recovers from the backup
automatically; the result struct reports Recovered From Backup = true.
Adding or removing variables never breaks saves (serialization is name-based). Class renames and removals need a migration step - a full walkthrough with the built-in Class Remap and Drop Class steps is in Step 11: Save Versions & Migration.
YourProject/Saved/SaveGames/ (packaged: the project's Saved folder), unless you set
Default Save Directory. A slot is one .sav file plus sidecars: .players (player
records), .global (persistent/custom objects), and optionally .bak backups.
Yes. WP runtime cells are keyed to the owning map, so actor identity survives grid/layout changes. Save keeps the records of actors sitting in unloaded cells (carry-over); load defers them until their cell streams in, then applies state (including tombstones) to just that cell. Nothing to configure - a load auto-mounts the slot for cell streaming.
World Partition streams only level-placed actors. An actor spawned at runtime belongs to no cell - it stays loaded forever, but the GROUND under it is a cell and streams out; physics then drops the actor. This is engine behavior, not the save system. Handle it in gameplay (e.g. disable Simulate Physics on spawned props when the player leaves the area). The save side is unaffected: whatever state the actor is in at save time is what loads back.
Yes, by seed. PCG content is procedural, so the system saves each PCG component's Seed (actor needs a Saveable Component) and on load a differing seed is applied and the content regenerates deterministically. Individual changes to generated actors are not tracked - treat the seed as the source of truth. Toggle: Save PCG Component Seeds. Works without the PCG plugin installed (it simply no-ops).
slot.players holds per-player records keyed by a stable player id: PlayerState/Controller
SaveGame variables and the player's per-map position - so a fresh GameMode pawn can be filled
after travel or on rejoin (multiplayer). Under Restore Into Current Pawn the world save
never touches a player's pawn, so position always comes from Restore Player Pawn or
Get Saved Player Transform. Under Persistent World Pawn the body is a world actor and
.sav restores it in full - no Restore Player Pawn needed there.
The streaming path is built for millions of records: chunked files, one sub-chunk resident at a time, a per-frame time budget and a memory ceiling. See Step 07 and tune the three Performance settings.
Obfuscate Files adds light tamper deterrence, not real security. For a competitive game, treat client-side saves as untrusted regardless of encryption - that is why multiplayer saving is server-only.
Everything logs under LogUSS. The two most useful lines:
Save 'Slot': wrote N record(s) ...
Restore: N in place, N respawned, N tombstoned, N skipped, N removed (X ms)
Turn on Verbose Logging for per-actor detail. When asking for support, paste the lines
around the first Warning: - the startup line includes the plugin version.