Detailed usage

1. Configure the system

System configuration is performed in a Data Asset.

Open DA_ADS_SaveSystemConfig to configure the system. The plugin loads this asset at this location, so do not move, rename, or delete it. The parameters are detailed below:

2. The subsystem

Access the subsystem

ADS Save System is a Game Instance Subsystem. Retrieve a reference to the subsystem in the Blueprint that needs to use it.

Functions

The functions below are accessible from a subsystem reference.

Event Dispatchers

The subsystem Event Dispatchers let participants, menus, and project logic react to operations. Participants must subscribe in their BeginPlay to On Save Requested and On Load Requested to handle their own portion of the data.

3. Save Game Object

Create a child Blueprint of ADS Save Game Object and add the project variables to retain (with the SaveGame option). The system automatically fills in the version, UTC date, level, type, index, slot name, and, if requested, thumbnail.

For generic data per participant, you can use Set Part Data, Get Part Data, Remove Part Data, Clear Part Data, and Has Part Data. A part has a name, version, text content, and binary content. For common data, however, prefer explicit variables in your child Blueprint: they remain easier to read and maintain.

4. Register participants

A participant is the object that has data to write into a save or reapply when loading. Each participant is responsible for its own registration: do not centralize this call in another Blueprint.

In each participant’s BeginPlay event, retrieve a reference to the subsystem. From a subsystem reference, call Add Participant, specifying the participant object and whether it takes part in profile, manual, and/or automatic saves.

When a participant is no longer needed, call Remove Participant from a subsystem reference. Use Clear Participants or Cleanup Participants from the object that deliberately manages all participants. Never create a new context: always reuse the one received through the event. The Is Saved Cache Complete, Is Loaded Cache Complete, Get Pending Participant Count, and Is Operation In Progress functions help diagnose the flow.

5. Save

Trigger a save

From a subsystem reference, call Save Slot, specifying the slot type and index when the type is manual. For an automatic save, the index is resolved by rotation. The Capture Thumbnail option saves a JPEG thumbnail of the current view before writing.

Save Slot triggers the overall operation: the subsystem prepares the save object, then delegates data saving to every participant registered for that slot type. Once the operation ends, the subsystem calls the On Save Completed dispatcher with the context, success, and a failure reason. Call Cancel Active Operation to stop an operation in progress; no cancelled save is written to disk.

Participant saving

In its BeginPlay, each relevant participant subscribes to the On Save Requested dispatcher. When this dispatcher is triggered, the participant receives the context and handles its save. It writes its own portion of data into Save Game Object, then calls Set Part Saved from a subsystem reference, using the same context with Success set to true. The subsystem waits for every participant to respond before writing the slot.

6. Load

Trigger a load

From a subsystem reference, call Load Slot with the configured save class. The subsystem retrieves the slot, can automatically open the saved level, then delegates applying data to the participants after the map has loaded. Apply Pending Load is intended for a custom flow or debugging; normally it is called automatically.

Once the operation ends, the subsystem calls the On Load Completed dispatcher with the context, success, and a failure reason.

Participant loading

In its BeginPlay, each relevant participant subscribes to the On Load Requested dispatcher. When this dispatcher is triggered, the participant receives the context and handles its load. It reads its own portion of data from Save Game Object, applies it, then calls Set Part Loaded from a subsystem reference using the same context. The overall load finishes only when every expected participant has responded.

7. Project logic

Introduction

ADS Project Save Behavior is an optional object for project-specific logic. The subsystem creates it from the class configured in the runtime asset, then uses it to notify lifecycle, operations, and save conversions.

Create the logic

Create a child Blueprint of ADS Project Save Behavior, then assign this class to Project Save Behavior in DA_ADS_SaveSystemConfig. Implement only the events required by your project. The functions below are events to override in this child Blueprint. Override only those your project needs.

Functions

Manage save versions

From a subsystem reference, use Check Save Version, Get Save Version From Slot, or Scan Saves Needing Conversion to identify old saves. If conversion is required and Auto Convert Without Confirmation is disabled, project logic receives Handle Need Convert. After confirmation from your interface, call Continue Convert; otherwise call Cancel Convert.

In Convert Save, adapt the save-object data to the new version. A save created with a version newer than the project version cannot be loaded.