How-To: Build the Boot Assets by Hand
Goal: build the root layout, UI policy, and HUD layout yourself instead of assigning the shipped W_CrimsonOverallUILayout / B_CrimsonUIPolicy / W_CrimsonHUD_Layout. Do this when you need a custom layer set, a custom policy, or a bespoke HUD - otherwise the Quick Start assign-the-asset path is faster and identical at runtime.
1. Build the root layout
The root layout is one widget Blueprint deriving from UCrimsonPrimaryGameLayout (CrimsonCommon). It holds one UCommonActivatableWidgetStack per layer and registers each stack under its tag.
W_CrimsonOverallUILayout (/CrimsonUI/UI/W_CrimsonOverallUILayout - tick Show Plugin Content in the Content Browser to see it). It is exactly the widget this step builds: in the Designer, an Overlay with five Common Activatable Widget Stack children (one per standard layer), each slot set to fill; in the Event Graph, Event On Initialized feeding one Register Layer call per stack. Study or duplicate it rather than rebuilding from a description.Create a Widget Blueprint BP_RootLayout with parent Crimson Primary Game Layout. In the Designer add an Overlay, then four Common Activatable Widget Stack children named GameStack, GameMenuStack, MenuStack, ModalStack (each slot set to fill). In the Event Graph, from Event On Initialized call Register Layer four times: (UI.Layer.Game, GameStack), (UI.Layer.GameMenu, GameMenuStack), (UI.Layer.Menu, MenuStack), (UI.Layer.Modal, ModalStack). Add a fifth stack + Register Layer for UI.Layer.ContextMenu if you use context menus. Register Layer is callable because your Blueprint is the layout class - it does not appear on external references.
2. Build the policy
The policy (UCrimsonGameUIPolicy, CrimsonCommon) decides which layout class to spawn and how local multiplayer shares the screen. Create a Blueprint Class with parent Crimson Game UI Policy, name it BP_UIPolicy, and set:
| Property | Value | Notes |
|---|---|---|
LayoutClass | BP_RootLayout | Required. The root layout instantiated per local player. |
LocalMultiplayerInteractionMode | PrimaryOnly (default) | PrimaryOnly = only the first local player gets UI. SingleToggle = one player at a time owns it. Simultaneous = every local player gets a layout (couch co-op). |
B_CrimsonUIPolicy (/CrimsonUI/UI/B_CrimsonUIPolicy) is this exact asset: a Blueprint of UCrimsonGameUIPolicy whose Class Defaults set LayoutClass = W_CrimsonOverallUILayout and LocalMultiplayerInteractionMode = PrimaryOnly. Open its Class Defaults to compare against yours.BP_UIPolicy as DefaultUIPolicyClass (Quick Start step 6), press Play, and the Widget Reflector shows one BP_RootLayout instance.3. Build the HUD layout
Create a widget Blueprint BP_HUDLayout with parent Crimson HUD Layout (UCrimsonHUDLayout) - the always-present root HUD screen. Design your HUD into it, then push it onto the Game layer exactly as Quick Start step 7 shows (just swap W_CrimsonHUD_Layout for BP_HUDLayout). Wire its escape/pause menu and controller-disconnect screen in How-To: HUD Layout & Escape Menu. Two shipped reference implementations exist: W_CrimsonHUD_Layout (/CrimsonUI/UI/, fully wired) and the simpler W_CrimsonDefaultHUDLayout (/CrimsonUI/UI/Hud/).
BP_HUDLayout inside the Game layer stack, and your escape binding opens the pause menu once wired.See also
- Quick Start - the fast path: assign the shipped
B_CrimsonUIPolicy/W_CrimsonHUD_Layoutinstead. - How-To: HUD Layout & Escape Menu - wire the pause menu and controller-disconnect screen.
- How-To: Get the Building Blocks - reach the layout / push API at runtime.
- Concept: Policy & Layout Architecture - what the manager / policy / layout actually do.