CrimsonUI

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.

What's included

SystemKey TypesPurpose
Policy / layout coreUCrimsonUIManagerSubsystem, UCrimsonGameUIPolicy, UCrimsonPrimaryGameLayoutOne 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.
Activatable widget baseUCrimsonActivatableWidget, ECrimsonWidgetInputModePer-widget input routing (Game / Menu / GameAndMenu), mouse capture, move/look input blocking, and InputMode.* tag baseline on activation
HUD layout + escapeUCrimsonHUDLayout, ACrimsonHUD, UCrimsonGameViewportClientAlways-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
Dialogs & messagingUCrimsonMessagingSubsystem, UCrimsonGameDialogDescriptor, UCrimsonConfirmationScreenYes/No/OK confirmations pushed to UI.Layer.Modal with a result callback, from C++ or a single Blueprint async node
Tag-driven visibilityUCrimsonTaggedWidgetHUD elements that hide while the player's ability system holds any of a set of gameplay tags
MVVM basesUCrimsonViewModelBase, UCrimsonScreenViewModelBase, UCrimsonEntryViewModelBaseViewModel bases with ULocalPlayer access and FieldNotify list-row index support
IndicatorsUCrimsonIndicatorManagerComponent, UCrimsonIndicatorDescriptor, UCrimsonIndicatorLayerPooled world-space markers projected onto the screen, with clamp-to-edge arrows and five projection modes
Context menusUCrimsonContextMenuSubsystem, FCrimsonContextMenuRequest, UCrimsonContextMenuWidgetBaseCursor- 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
Common widgetsUCrimsonTabListWidgetBase, UCrimsonListView, UCrimsonTileView, UCrimsonDragDropOperation, UCrimsonButtonBaseTabs with runtime registration, list/tile views that pick a widget class per item type, payload drag-drop, countdown buttons, input-glyph buttons
Touch inputUCrimsonJoystickWidget, UCrimsonTouchRegionOn-screen widgets that inject synthetic Enhanced Input values - gameplay code never knows touch exists
Perf statsUCrimsonPerfStatWidgetBase, UCrimsonPerfStatContainerBaseSingle-stat text/graph widgets and a display-mode container; you supply the data source
Loading screen bridgeUCrimsonLoadingScreenSubsystemPer-map / per-mode loading-screen widget override that survives level transitions
Extension pointsUCrimsonUIExtensionPointWidgetNamed slots in your HUD that GameFeature actions (or code) fill with widgets at runtime

Plugin dependencies

TypeName
CrimsonCrimsonCommon (policy/layout/extension base layer, UCrimsonCommonGameInstance, UCrimsonCommonLocalPlayer, perf-stat enums, context-menu tags, logging)
Engine pluginsCommonUI, EnhancedInput, GameplayAbilities, ModelViewViewModel
Engine modules (public)Core, CoreUObject, Engine, UMG, Slate, SlateCore, CommonUI, CommonInput, GameplayTags, EnhancedInput, DeveloperSettings, ModularGameplay, ModelViewViewModel, InputCore, ApplicationCore
Engine modules (private)GameplayAbilities
The base layer lives in CrimsonCommon
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.
AssetPathDemonstrates
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.
W_CrimsonConfirmationDialog / Default / Error, W_CrimsonControllerDisconnected/CrimsonUI/UI/Foundation/Dialogs/Confirmation screens (UCrimsonConfirmationScreen) with the four required BindWidget names; the controller-disconnect screen.
W_CrimsonButton, W_CrimsonButtonTab; W_CrimsonMenuButton, W_CrimsonMenuButton_Modal, W_CrimsonArrowButton/CrimsonUI/UI/Foundation/Buttons/; /CrimsonUI/UI/Menu/Button bases (UCrimsonButtonBase) implementing UpdateButtonText / UpdateButtonStyle; the tab button (UCrimsonTabButtonBase); styled menu variants.
W_CrimsonBoundActionButton, W_CrimsonBottomActionBar/CrimsonUI/UI/Foundation/Widgets/BottomBar/Per-input-method button styles and the CommonUI bound-action bar.
W_CrimsonHorizontalTabList/CrimsonUI/UI/Foundation/TabbedView/Tab list (UCrimsonTabListWidgetBase).
W_ContextMenu_Modal / World / Radial, W_ContextMenuEntry/CrimsonUI/UI/Foundation/ContextMenu/All three context-menu presentations plus the entry button, with the required ContentPanel / EntryBox naming.
W_CrimsonSingleTextStat, W_CrimsonSingleGraphStat, W_CrimsonPerfStatGraph, W_CrimsonPerfStatContainer_*/CrimsonUI/UI/PerfStats/Perf-stat widgets and containers (UCrimsonPerfStatWidgetBase / UCrimsonPerfStatContainerBase).
Crimson_CommonUIInputData, Crimson_IA_UI_*/CrimsonUI/Input/CommonUI input data (Click/Back preset) and the five UI input actions.
CommonInput_KeyboardMouse, CommonInput_Gamepad_*/CrimsonUI/UI/Foundation/Platform/Input/Per-platform controller-brush data for key glyphs.
Styles: Crimson-ButtonStyle-*, Crimson-TextStyle-*, Crimson-BorderStyle-*/CrimsonUI/UI/Foundation/Buttons/, .../Text/CommonUI button/text/border style assets the shipped widgets use.

Where to go next

  • Quick Start - a working policy, root layout, and HUD, end to end.
  • How-To: Get the Building Blocks - the exact nodes/code to reach the layout, subsystems, and settings (read this second).
  • How-To: Build the Boot Assets by Hand - build the root layout, policy, and HUD layout yourself instead of assigning the shipped ones.
  • Task pages: push screens, HUD layout and escape menu, dialogs, tag-driven visibility, buttons, tabs, lists, drag-drop, MVVM screens, indicators, context menus, touch, perf stats, loading screens, extension points.
  • Mental model: Concept: Policy & Layout Architecture, Concept: Input Routing & Activatable Widgets, Concept: Full-Stack Integration & Multiplayer.
  • Looking up a signature? Jump to API Reference.