CrimsonUI is the UI foundation for any Crimson project. It builds on Epic's CommonUI plugin: a policy creates one root layout per local player, screens push onto gameplay-tag-keyed layers inside that layout, and every pushed widget declares how it wants input routed (game, menu, or both). Around that core it ships a dialog/messaging subsystem, MVVM base classes, a world-space indicator system, a context-menu system, tab/list/drag-drop widgets, simulated touch input, and performance-stat display widgets. Every class is a base meant to be subclassed in your project - the plugin contains no game-specific widgets.
New here? Read in this order
Do Quick Start first (one working UI stack), then How-To: Get the Building Blocks - it shows the exact Blueprint nodes and C++ for reaching the subsystems and layout that every other page assumes you have. Use the Blueprint / C++ / Both switch at the top to see the path for your project type.
One root layout per local player; screens push to UI.Layer.* tag-keyed stacks. The policy and layout base classes live in CrimsonCommon; CrimsonUI ships the manager that boots them from UCrimsonUISettings.
Always-present HUD root that binds the Escape/Pause action and the console controller-disconnect screen; HUD actor for GameFeature component injection; cursor-aware viewport client
Cursor- or world-anchored action popups (Use / Drop / Inspect). The menu gathers its actions from the target via CrimsonCommon's UCrimsonContextActionGatherer (the same path the server re-runs on execution); entries confirm on click natively, with disabled-with-reason states, sections, destructive styling, and dialog / hold-to-confirm friction
UCrimsonGameUIPolicy, UCrimsonPrimaryGameLayout, UCrimsonUIExtensions, and the UI extension subsystem are defined in CrimsonCommon (CrimsonUI's one allowed Crimson dependency) so other plugins can push UI without depending on CrimsonUI. This wiki documents the full setup including those types - each is labeled with the plugin it lives in.
Two hard boot requirements
The UI stack only boots when (1) your Game Instance derives from UCrimsonCommonGameInstance and (2) your Local Player class is UCrimsonCommonLocalPlayer (or a subclass). The UI manager subscribes to the game instance's player-added events and silently ignores any local player of another class - miss either and no layout is ever created, with no error. Quick Start step 2 covers both.
Shipped example content
The plugin's Content folder is a working reference implementation, not just default assets. Every widget type below has a complete, shipped Blueprint you can open and study - the How-To pages point at these instead of walking you through rebuilding them node by node. Duplicate one into your project as a starting point, or subclass it to customize.
Show Plugin Content
Plugin assets are hidden by default. In the Content Browser open Settings (top-right of the panel) and tick Show Plugin Content - the CrimsonUI Content folder then appears in the source tree, and every /CrimsonUI/... path on this wiki becomes browsable.
Asset
Path
Demonstrates
W_CrimsonOverallUILayout
/CrimsonUI/UI/
Root layout (UCrimsonPrimaryGameLayout): one activatable stack per UI.Layer.* tag + the Register Layer calls.
B_CrimsonUIPolicy
/CrimsonUI/UI/
UI policy (UCrimsonGameUIPolicy) wired to the root layout.
W_CrimsonHUD_Layout, W_CrimsonDefaultHUDLayout
/CrimsonUI/UI/, /CrimsonUI/UI/Hud/
HUD layouts (UCrimsonHUDLayout) with escape menu, escape action, and controller-disconnect screen set.
W_CrimsonGameMenu
/CrimsonUI/UI/Hud/
A complete activatable screen (UCrimsonActivatableWidget): input config, buttons, back handling.