How-To: Keep Your Assets in a Cooked Build

Goal: make sure the equipment definitions your game loads at runtime actually ship in the packaged build.

Prerequisites
How-To: Author an Equipment Definition and How-To: Save and Restore Equipment.

1. Know which references the cooker can see

The cooker walks hard references from things it already decided to cook. A definition reached by a hard TSubclassOf pin - named in a data table you cook, or referenced by an item Blueprint that ships - comes along for free. A definition reached only by name at runtime does not.

How the definition is reachedCooked?
A hard TSubclassOf reference on an asset that ships (an item definition, a data table row, a curated list)Yes.
Only from a save file, through the saved Equipment Definition class referenceNo. A save file is not scanned by the cooker.
Only through Source Object Path, the soft path in a save entryNo. Soft paths are not hard references.
Only by a class name assembled at runtimeNo.
The failure mode is silent, and only in a packaged build
In the editor every asset is on disk, so a definition that was never cooked works perfectly in PIE. In the packaged build the class fails to resolve, Restore From Save Data warns about a null definition and skips the entry, and the player's gear is simply gone with no error dialog.
Verify
Package a build, load a save whose gear is reachable only from the save file, and check the log: LogCrimsonEquipment warns about skipping an entry with no definition.

2. Give every definition a hard reference that ships

The fix is to make something the cooker already cooks point at your definitions. Any one of these is enough:

  • A data table or curated data asset listing every equipment definition, referenced by something that ships. This is the usual answer and the easiest to audit.
  • Your item assets. If each item definition already holds a TSubclassOf of its equipment definition, and the items ship, the equipment definitions ship with them.
  • Additional Asset Directories to Cook in Project Settings -> Project -> Packaging. Add the folder holding your definitions. This is the blunt route - it cooks the whole folder whether or not anything references it.

The Blueprint route is the curated list. Create a Data Table (or a simple data asset with a TSubclassOf<Crimson Equipment Definition> array), add a row per definition, and reference that table from something that already ships - your GameMode, a game instance, or an item catalog. The cooker then follows the table to every definition in it.

Check your work: right-click a definition -> Reference Viewer, and confirm the table appears as a referencer.

Primary assets are the other route
If your project already registers content through the Asset Manager, adding a primary asset type for your definitions gives the same guarantee with per-asset control.
Verify
Package again and load the same save: the gear comes back, and the definition-null warning is gone.

3. Verify before you ship

  1. Package a build, load a save written before the fix, and confirm every piece of gear returns.
  2. Right-click a definition in the Content Browser -> Reference Viewer and confirm at least one referencer is an asset that ships.
  3. Search the packaged log for LogCrimsonEquipment warnings about skipped entries.
Verify
The packaged run restores the same equipment as the editor run, with no LogCrimsonEquipment warnings.

See also

  • How-To: Save and Restore Equipment
  • API Reference