How-To: Author Settings in the Visual Editor
Goal: build and reorganize a UCrimsonSettingsDataAsset in its own asset editor, rather than in a Details panel full of nested arrays.
UCrimsonSettingsDataAsset (Quick Start step 3). The editor ships with the plugin in its CrimsonSettingsEditor module - there is nothing to enable.1. Open the asset
Double-click the asset. It opens FCrimsonSettingsDataAssetEditorToolkit, not a generic Details view: a raw nested Sections[i].Settings[j] array is a poor way to see the shape of a menu, and it hides the one mistake that costs you at runtime - a duplicate DevName.
| Pane | What it gives you |
|---|---|
| Left - tree | The asset as its own shape: sections at the top level, their settings underneath, a type icon per row, the flags that change runtime behavior shown inline, and duplicate-DevName validation surfaced while you author. |
| Right - Details | Only what the tree has selected: one section, or one setting. It edits through property handles into Sections[i] / Sections[i].Settings[j], so undo, redo and asset dirtying are the ordinary ones. |
| Toolbar | Add Section, Add Scalar, Add Discrete, Add Action, Duplicate, Delete, Move Up, Move Down. |
2. Build the tree
Add Section first - a setting has to live in one. Select the section, name it in Details (DevName and DisplayName), then Add Scalar / Add Discrete / Add Action for each row. Selecting a row shows only that row's fields, and the ones that do not apply to its type are simply absent rather than grayed.
Order in the tree is order on screen. Move Up / Move Down reorder within a parent; Duplicate copies a row with its metadata intact, which is the fastest way to author five sliders that differ only in name.
DevName is the key a saved profile, a preset entry, and the keyed store all use. Renaming one after players have saved settings orphans every value stored under the old name. See How-To: Use the Ready-Made Collections -> Treat DevNames as a contract.DevName are flagged in the tree immediately, rather than tripping the registry's duplicate ensure at runtime.3. Or build the same rows in code
The asset is the recommended path because it is data - but nothing forces it. A registry can construct exactly the same settings directly, which is what the shipped default builders do.
UCrimsonSettingBlueprintLibrary is the factory. In a registry Blueprint's category hook:
Create Collection (Outer = self, DevName = Gameplay, DisplayName = "Gameplay") -> Create Scalar Setting (Outer = self, DevName = FieldOfView, DisplayName = "Field of View") -> Add Setting To Collection -> K2 Register Setting (the collection).
The other factory nodes are Create Discrete Setting and Create Action. All of them default their Outer pin to self.
PopulateFromDataAsset(Asset, ParentCollection) takes an optional parent. Pass one and each section in the asset becomes a nested sub-collection of it - rendering as a section header inside that tab instead of claiming a top-level tab of its own. Leave it empty for one top-level collection per section. That is how a project folds authored rows into a tab a builder made.See also
- How-To: Persist Settings with Zero Glue - the Storage category on each entry.
- How-To: Bind a Setting to Game Code - wiring an authored row to a live value.
- Concept: Value Types & Data Sources - what each entry type becomes at runtime.