The settings menu every game needs. Declared in data, not code.

Almost never: options are authored in a data asset, the registry and screen are Blueprint subclasses, the five default collections are Blueprint-callable, and binding a setting to game code happens through K2_BindSetting delegates. Two exceptions worth knowing before you buy: registering the GameUserSettings class is a DefaultEngine.ini line with no in-editor equivalent, and the advanced tier (Dynamic value classes with reflected data sources for engine-level settings) is C++. For keybind glyphs the docs also recommend one UCommonActionWidget subclass so a pill can pin itself to a device and read the Enhanced Input user settings while a menu is open.

Settings are a client-owned preference concern, and the framework treats them honestly as one: the screen and the per-player keyed store run on the owning client, with UCrimsonSettingsShared saved per local player, and nothing in either storage class replicates. Where a preference affects gameplay, send it to the server through your own validated path; you shouldn't drive authoritative gameplay from a client's preference value, and the plugin doesn't pretend otherwise.

No. CrimsonSettings builds and runs on its own with three engine plugins: CommonUI, EnhancedInput and AudioModulation. The screen pushes onto whatever UI stack you run, and the shipped keybind rows rebind plain keys through Enhanced Input's user settings.

CrimsonCore, the free integration layer from the Crimson Discord, joins CrimsonSettings to the rest of the suite: modifier-chord capture and chord-aware conflicts on keybind rows (with CrimsonInput), the Performance Stats page and the per-stat choice a HUD readout follows (with CrimsonUI), and mapping the gamepad sensitivity presets onto CrimsonInput. Without it, each has a public hook: KeybindingSettingClass and the keybind row virtuals, K2_RegisterSettingInParent for extra pages, and the UCrimsonSettingsShared getters.

Yes, that's the point of the generic keyed store. CrimsonSettings never gains a typed field for your option: you author an entry with a stable Storage Key, tick Persist To Shared Store, and read it back by name through UCrimsonSharedSettingsSubsystem. A consumer module that depends on both plugins applies the values, which is the only place the two names ever meet.

Treat a DevName the way you would a database column. It is the identity used by the keyed store's storage key, a saved profile's map, and a preset entry. Renaming one after players have saved settings orphans every value stored under the old name, and nothing migrates it for you. The framework does make collisions loud: duplicates are flagged in the asset editor while you author and asserted by the registry at runtime.