Quick Start

By the end of this page you have a settings screen with a couple of options that persist per player - no game-code binding, no fields added anywhere. Making an option actually change the game comes next (How-To: Bind a Setting to Game Code).

Prerequisites
CrimsonCommon and CrimsonSettings are installed, and you have a UI layer to push a screen to (e.g. CrimsonUI's primary game layout, or your own).

1. Enable the plugin

Open Edit -> Plugins, type Crimson, tick CrimsonSettings (and its dependency CrimsonCommon), and restart when prompted. For a Blueprint project that's the whole install.

Screenshot pendingImages/CrimsonSettings/qs-enable-plugin.png
Edit -> Plugins -> search 'Crimson' -> tick CrimsonSettings' Enabled checkbox -> restart the editor.

C++ projects: add the module to your build file so your code can reference settings types:

csharp
// YourGame.Build.cs
PublicDependencyModuleNames.Add("CrimsonSettings");
Verify
CrimsonSettings shows as enabled in the Plugins window and the editor restarts without errors.

2. Create a settings data asset

Right-click in the Content Browser -> Miscellaneous -> Data Asset -> CrimsonSettingsDataAsset. Add a Section (e.g. Gameplay), then add Settings entries. For each entry set the Type, DevName, DisplayName, and - to persist it with no code - tick Persist To Shared Store (leave StorageKey empty to reuse DevName).

Screenshot pendingImages/CrimsonSettings/qs-data-asset.png
DA_GameplaySettings -> Section 'Gameplay' -> a Scalar 'FieldOfView' (Range 60-110, Default 90) and a Discrete 'InvertY' (Options Off/On). Tick Persist To Shared Store on both.
Unrelated fields collapse
Type-specific fields hide when they don't apply: a Scalar shows range/step/default; a Discrete shows options/default index; an Action shows its button text. DevName must be unique within a registry.
Verify
The asset lists your section with its entries, and each entry shows Persist To Shared Store ticked under the Storage category.

3. Create a registry

The registry turns the asset into live settings. Make a Blueprint child of UCrimsonSettingRegistry, and in one of the category hooks call Populate From Data Asset with your asset.

Screenshot pendingImages/CrimsonSettings/qs-registry.png
BP_GameplaySettingsRegistry (parent UCrimsonSettingRegistry) -> override K2_RegisterGameplaySettings -> Populate From Data Asset (DA_GameplaySettings).
Verify
Populate From Data Asset accepts your asset with no warnings in the Output Log.

4. Create the settings screen

Make a Blueprint widget child of UCrimsonSettingScreen. Add a UCrimsonSettingPanel named exactly `Settings_Panel` (a bind-widget). Override `Create Registry` to return your registry, initialized for the owning local player.

Screenshot pendingImages/CrimsonSettings/qs-screen.png
WBP_SettingsScreen (parent UCrimsonSettingScreen) -> add a Crimson Setting Panel named Settings_Panel -> override Create Registry -> New Object (BP_GameplaySettingsRegistry) -> Initialize (Owning Local Player) -> return it.
Verify
The widget compiles with Settings_Panel bound (no "BindWidget" error) and Create Registry returns your registry class.

5. Push the screen

Push the screen onto a UI layer from a menu button (or BeginPlay for a test).

Screenshot pendingImages/CrimsonSettings/qs-push.png
On a menu button: Push Widget To Layer Stack (Layer = your Menu layer tag, Class = WBP_SettingsScreen).
Verify
The screen lists your options. Change them, click Apply, close and reopen the game - the values are still there. They persist per player because you ticked Persist To Shared Store.
What's next
Make an option do something (How-To: Bind a Setting to Game Code), expose another plugin's options with no dependency (How-To: Expose Another Plugin's Settings), or add polish (How-To: Presets & Profiles, How-To: Live Preview & Confirmation).