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.

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).

Get Crimson Shared Settings Subsystem (right-click in any graph and search it - the getter sits under Local Player Subsystems, and its Player Controller pin takes Get Owning Player) -> Get Shared Settings -> Get Float Value (Key = Audio.MasterVolume, Default Value = 1.0).

Get Int Value, Get Bool Value and Get String Value sit beside it under Settings | Keyed, each with the same Key + Default Value shape. The default is what you get when the player has never touched the option, so make it the value your game would have used anyway.

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.