CrimsonSettings
A modular settings framework (a Crimson-prefixed port of Epic's GameSettings). You declare options in a data asset, choose how they persist - a generic per-player keyed store with no glue, or a delegate bound to your own game code - and present them with a CommonUI screen that ships search, tag filtering, presets, named profiles, live preview, confirmation countdowns, and a first-run wizard.
Two ways to read this
Use the Blueprint / C++ / Both switch at the top of the window. Blueprint readers get editor screenshots; C++ readers get code; Both shows them side by side.
What's included
| System | Key Types | Purpose |
|---|---|---|
| Declare | UCrimsonSettingsDataAsset | Author sections + setting entries (scalar / discrete / action) in the Content Browser - no code |
| Persist (zero glue) | UCrimsonSettingsShared keyed store, UCrimsonSharedSettingsSubsystem | Tick Persist To Shared Store and a setting saves per-player by key - no delegates, no fields to add |
| Bind to code | UCrimsonSettingValueScalar_BP, UCrimsonSettingValueDiscrete_BP | Route a setting's get/set to your own functions via K2_BindSetting when it drives live game state |
| Advanced (C++) | UCrimsonSettingValueScalarDynamic, FCrimsonSettingDataSource | Reflected getter/setter data sources for resolution, scalability, gamma, etc. |
| Registry | UCrimsonSettingRegistry | Builds and owns the settings; PopulateFromDataAsset, category hooks, presets, profiles |
| Storage backends | UCrimsonSettingsLocal, UCrimsonSettingsShared | Machine-local (GameUserSettings.ini) vs per-player save (follows the account) |
| Screen | UCrimsonSettingScreen, UCrimsonSettingPanel, UCrimsonSettingListEntry | CommonUI screen + scrollable list + per-row widgets with dirty / default / conflict indicators |
| UX | search, tag filter, presets, profiles, live preview, confirmation, wizard | AAA polish available out of the box, each opt-in |
Plugin dependencies
| Type | Name |
|---|---|
| Crimson | CrimsonCommon (logging, UCrimsonCommonLocalPlayer, ICrimsonInputBindingProvider) |
| Engine plugins | CommonUI, EnhancedInput, AudioModulation |
| Engine modules | Core, CoreUObject, Engine, UMG, Slate, SlateCore, CommonUI, CommonInput, GameplayTags, InputCore, EnhancedInput, DeveloperSettings, AudioMixer, RHI (+ private ApplicationCore, PropertyPath, AudioModulation) |
The generic keyed store is the headline
You never add a typed field to CrimsonSettings to persist a new option. Tick Persist To Shared Store on a data-asset entry and it saves into a generic
Key -> value store on the per-player save. That is what lets any plugin (or your game) add persistent settings without editing CrimsonSettings - see How-To: Persist Settings with Zero Glue and How-To: Expose Another Plugin's Settings.Where to go next
- New here? Quick Start builds a working settings screen whose values persist per player.
- Task pages: persist with zero glue, bind a setting to game code, expose another plugin's settings, presets & profiles, live preview & confirmation.
- Mental model: the Concept pages (three layers, storage model, value types & data sources).
- Signatures: API Reference.