How-To: Persist Settings with Zero Glue

Goal: save a setting per player without writing a getter/setter, a delegate, or a field on any class. This is the framework's generic keyed store - it holds opaque Key -> value pairs on the per-player save, so any setting persists by name.

Prerequisites
A UCrimsonSettingsDataAsset and a registry that populates from it (Quick Start steps 2-3).

1. Tick Persist To Shared Store

On a Scalar or Discrete entry, tick Persist To Shared Store under the Storage category. Optionally set a Storage Key - a stable, namespaced name like Audio.MasterVolume. Leave it empty to reuse the entry's DevName.

Screenshot pendingImages/CrimsonSettings/howto-persist-flag.png
Setting entry -> Storage: Persist To Shared Store ticked, Storage Key = 'Audio.MasterVolume' (or leave empty to use DevName).
Verify
Change the value in the screen, Apply, restart the game - the value is restored. Nothing else was wired.

2. Read the value back (when a consumer needs it)

The value lives in the per-player UCrimsonSettingsShared object, reached through UCrimsonSharedSettingsSubsystem. Read it by key with the typed accessors (Get Float/Int/Bool/String Value).

Screenshot pendingImages/CrimsonSettings/howto-persist-read.png
Get Crimson Shared Settings Subsystem (from the Local Player) -> Get Shared Settings -> Get Float Value (Key = 'Audio.MasterVolume', Default Value = 1.0).
Encoding
Scalars store as a number, discretes as their selected index. Get Bool Value reads both an explicit true/false and a discrete 1/0, so a two-option toggle reads cleanly either way.
Persist vs. bind - pick one intent
Persist To Shared Store is for options whose value you read back yourself (or that another system applies). If a setting must call a live game function the instant it changes, bind a delegate instead - see How-To: Bind a Setting to Game Code. You can do both, but for plain persistence the store alone is enough.

See also

  • How-To: Expose Another Plugin's Settings - the same store lets a plugin add settings with no dependency on CrimsonSettings' internals.
  • Concept: Storage Model - where the keyed store, UCrimsonSettingsLocal, and UCrimsonSettingsShared each fit.