Quick Start: Saveable Systems
By the end you'll have a system - a subsystem, component, or plain object that owns gameplay data - that writes its data to a save fragment and restores it on load.
1. Enable the plugin
Open Edit -> Plugins, type Crimson in the search box, tick CrimsonSaveSystem's checkbox, and restart the editor when prompted. For a Blueprint project that's the entire install - you never hand-edit the .uproject or any .Build.cs.
.uproject or .Build.cs to edit. The editor writes the plugin entry for you. The C++ step below is needed only when you reference CrimsonSaveSystem types from your own C++ code.2. Implement ICrimsonSaveableSystem and register it
This is the step that actually makes an object saveable. Implement the ICrimsonSaveableSystem interface, return a unique fragment name, and register with the save manager on startup. Until a system is registered nothing it holds is saved - the SaveGame flag in the next step does nothing on its own.
Open your Actor or Actor Component Blueprint and add the interface: Class Settings -> Details -> Interfaces -> Add -> Crimson Saveable System. In My Blueprint -> Interfaces, double-click Get Fragment Name to open its graph, and feed a string literal into the Return Node (Return Value = MyInventory). That name has to be unique across every registered system - it becomes the fragment's file name.
Then register on startup, in the Event Graph: Event BeginPlay -> Get Crimson Save Game Manager -> Register Saveable System (System = Self). The manager getter is a pure node - right-click in the graph, search Crimson Save Game Manager, and take it from under Game Instance Subsystems.
UGameInstanceSubsystem, which cannot be created in Blueprint. In a Blueprint-only project, implement Crimson Saveable System on an Actor or Actor Component (e.g. an inventory component) instead - Get Fragment Name and Register Saveable System work identically. For a player-owned system, also override Get Player Save Key and return Resolve Player Save Key (Crimson Save Player Identity).bVerboseLogging on (Project Settings -> Crimson -> Crimson Save Game Manager), the output log shows your fragment name registering when the system starts up.3. Mark the data you want saved as SaveGame
Now that the system is registered, tag each field you want persisted with SaveGame. The manager captures every SaveGame-tagged property on the registered object automatically (via FObjectAndNameAsStringProxyArchive) - no fragment subclass needed for simple data.
For each variable you want persisted: select it in My Blueprint -> Details -> Advanced -> tick `SaveGame`. The flag sits inside the collapsed Advanced section of the variable's Details panel, so expand that arrow first. There is nothing to wire - ticking the box is the whole declaration, and it works the same on any Actor, Component, or Blueprint that participates in saving.
SaveGame field is captured only because its owning object implements ICrimsonSaveableSystem and is registered (step 2). Ticking SaveGame on an object that never registers saves nothing. World actors are the exception - they opt in through a different interface, no registration; see Quick Start: World Actors.4. Save and load
Trigger a save server-side. RequestNewGameSave creates a slot and writes every registered fragment; RequestSaveProgress re-saves the active slot; RequestLoadFromSlot restores it. All save calls are server/standalone only.
Hang all three calls off one manager node. Get Crimson Save Game Manager -> Request New Game Save (Slot Index = 0, Character Name = Aldric) creates the slot. It returns a bool alongside an Out Error Message text pin, so Branch on the return value and surface Out Error Message when it comes back false.
Off that same Get Crimson Save Game Manager pin: Request Save Progress re-saves the active slot, and Request Load From Slot (Slot Index = 0) restores it. Every save call is server/standalone only - from an actor graph, gate the chain on Has Authority (Branch, True) first. A menu widget lives only on the machine that owns it, so a client's Save button must route through a Server_ RPC on its player controller rather than calling the manager directly.
SaveGame value, call RequestSaveProgress, then RequestLoadFromSlot - the value comes back. With the default storage provider on PC, a fragment named Slot0_F_<GetFragmentName>.sav appears in Saved/SaveGames/. Want a ready-made save menu instead? See How-To: Turnkey Save Setup with CrimsonCore.5. Wire your GameMode (multiplayer, optional)
If your game is multiplayer, forward PostLogin and Logout so the save manager can handle per-player fragment loading and flushing. The full wiring rules live in Concept: Multiplayer & Save Scopes.
Two chains in your Game Mode Blueprint. Event On Post Login -> Get Crimson Save Game Manager -> Notify Player Logged In (Player Controller = the event's New Player pin). And Event On Logout -> Cast To PlayerController (Object = the event's Exiting Controller) -> Get Crimson Save Game Manager -> Notify Player Logged Out (Player Controller = the cast's As Player Controller pin).
Wire both Player Controller pins explicitly: they default to Self, and a Game Mode is not a controller. No authority branch is needed here - a Game Mode only ever exists on the server. Event On Logout fires while the exiting controller is still valid, so there is no ordering to manage from Blueprint.
NotifyPlayerLoggedIn/Out are no-ops.