Skip to main content
Below is a Blueprint-oriented version of your Custom Container + Saveable example. It’s written as something you can drop straight into the docs as an integration pattern, not a promise of built-in functionality.

Blueprint Example: Custom Container (With Save Support)

Disclaimer:
This example is not part of UMI out of the box.
It shows how you could build a custom world container in Blueprint that:
  • Stores FItemInstance entries
  • Implements a Saveable interface
  • Registers itself with your own SaveSubsystem
    You’ll need to adapt names and structs to match your project’s save system.

1. Create a “Saveable” Blueprint Interface

Create a Blueprint Interface, e.g. BPI_Saveable, with these functions:
  1. GetSaveGuid
    • Return Type: Guid
  2. GetSaveBucket
    • Return Type: Name
    • Example: "World_Containers"
  3. BuildSaveRecord
    • Return Type: FSaveRecord (your project’s save record struct)
  4. ApplySaveRecord
    • Input: FSaveRecord (Record)
This mirrors the C++ ISaveable interface, but in Blueprint form.

2. Create a Custom Container Blueprint

Create a new Actor Blueprint, e.g. BP_MyCustomContainer. Add Components/Variables:
  • (Optional) Static Mesh for the container (chest, barrel, etc.)
  • Variable: ContainerGuid
    • Type: Guid
    • Instance Editable: ✔ or not, your call
    • SaveGame: ✔ (if you’re using UE’s SaveGame flags)
  • Variable: StoredItems
    • Type: Array of FItemInstance
    • SaveGame:
Implement Interfaces → Add BPI_Saveable to this Blueprint.

3. BeginPlay: Generate GUID and Register with SaveSubsystem

In Event BeginPlay:
This matches your C++:
  • If ContainerGuid is invalid → create a new GUID
  • Register this container with your save subsystem so it participates in saving/loading.
In your docs you can just say:
“On BeginPlay, we ensure the container has a GUID and register it with the save system.”

4. Implement GetSaveGuid (BPI_Saveable)

In the BPI_Saveable function GetSaveGuid:
Same as:

5. Implement GetSaveBucket

In GetSaveBucket:
This groups all container records under a common bucket. C++ equivalent:

6. Implement BuildSaveRecord

This part depends on how your FSaveRecord struct is exposed to Blueprint. Conceptually:
  1. Create a local FSaveRecord variable, e.g. Record.
  2. Set its Type (or similar field) to something like "MyCustomContainer".
  3. Serialize StoredItems into the Record, using whatever approach your save system uses.
Pseudo-graph:
In C++ you did this with FMemoryWriter and FItemRecord:
In Blueprint, you’d typically replace that binary work with:
  • A helper function that converts StoredItems to something storable in FSaveRecord
  • Or a more direct approach like an Array<FItemRecord> field on FSaveRecord.
For docs, you can phrase this as:
“In BuildSaveRecord, serialize StoredItems into the save record using your project’s preferred method (Blueprint Function Library, struct fields, or a custom serializer).”

7. Implement ApplySaveRecord

This is the inverse: clear current items, then rebuild from the save data. Pseudo-graph:
This is the Blueprint-equivalent of:
Again, in Blueprint you’ll lean on:
  • A helper node like BytesToItemArray(Bytes) → StoredItems, or
  • Direct struct/array fields on FSaveRecord.

8. Hooking It Up to UMI

Once you’ve got StoredItems working with your save/load:
  • Use UMI’s container/interaction logic to:
    • Open the container UI and show StoredItems
    • Allow transferring items between player inventory and StoredItems
    • Optionally use UMI helpers for adding/removing items in this container
You might, for example, treat StoredItems exactly like a secondary inventory array and reuse your existing UI logic.

C++: