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
| System | Key Types | Purpose |
|---|---|---|
| Policy / layout core | UCrimsonUIManagerSubsystem, UCrimsonGameUIPolicy, UCrimsonPrimaryGameLayout | 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. |
| Activatable widget base | UCrimsonActivatableWidget, ECrimsonWidgetInputMode | Per-widget input routing (Game / Menu / GameAndMenu), mouse capture, move/look input blocking, and InputMode.* tag baseline on activation |
| HUD layout + escape | UCrimsonHUDLayout, ACrimsonHUD, UCrimsonGameViewportClient | 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 |
| Dialogs & messaging | UCrimsonMessagingSubsystem, UCrimsonGameDialogDescriptor, UCrimsonConfirmationScreen | Yes/No/OK confirmations pushed to UI.Layer.Modal with a result callback, from C++ or a single Blueprint async node |
| Tag-driven visibility | UCrimsonTaggedWidget | HUD elements that hide while the player's ability system holds any of a set of gameplay tags |
| MVVM bases | UCrimsonViewModelBase, UCrimsonScreenViewModelBase, UCrimsonEntryViewModelBase | ViewModel bases with ULocalPlayer access and FieldNotify list-row index support |
| Indicators | UCrimsonIndicatorManagerComponent, UCrimsonIndicatorDescriptor, UCrimsonIndicatorLayer | Pooled world-space markers projected onto the screen, with clamp-to-edge arrows and five projection modes |
| Context menus | UCrimsonContextMenuSubsystem, FCrimsonContextMenuRequest, UCrimsonContextMenuWidgetBase | 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 |
| Common widgets | UCrimsonTabListWidgetBase, UCrimsonListView, UCrimsonTileView, UCrimsonDragDropOperation, UCrimsonButtonBase | Tabs with runtime registration, list/tile views that pick a widget class per item type, payload drag-drop, countdown buttons, input-glyph buttons |
| Touch input | UCrimsonJoystickWidget, UCrimsonTouchRegion | On-screen widgets that inject synthetic Enhanced Input values - gameplay code never knows touch exists |
| Perf stats | UCrimsonPerfStatWidgetBase, UCrimsonPerfStatContainerBase | Single-stat text/graph widgets and a display-mode container; you supply the data source |
| Loading screen bridge | UCrimsonLoadingScreenSubsystem | Per-map / per-mode loading-screen widget override that survives level transitions |
| Extension points | UCrimsonUIExtensionPointWidget | Named slots in your HUD that GameFeature actions (or code) fill with widgets at runtime |
Plugin dependencies
| Type | Name |
|---|---|
| Crimson | CrimsonCommon (policy/layout/extension base layer, UCrimsonCommonGameInstance, UCrimsonCommonLocalPlayer, perf-stat enums, context-menu tags, logging) |
| Engine plugins | CommonUI, 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.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).
- 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.