How-To: Get the Building Blocks

Goal: reach the five CrimsonUI pieces every other page assumes you can reach - the local player, the root layout / push API, the messaging subsystem, the context-menu subsystem, and the UI settings. Bookmark this page; the task pages link back here instead of repeating these chains.

1. The local player

Most CrimsonUI entry points key off ULocalPlayer, not the PlayerController. Inside a widget you already own one; elsewhere derive it from a PlayerController.

Inside a widget: Get Owning Local Player. Elsewhere: Get Player Controller -> Get Local Player From Controller (from Crimson UI Extensions, category Global UI Extensions).

Verify

Non-null once the player controller exists on the owning client. On a dedicated server it is always null - UI code must never run there.

2. The root layout and the push API

Blueprint never needs the layout object itself - UCrimsonUIExtensions (a Blueprint function library in CrimsonCommon) pushes and pops by local player. C++ can grab the layout directly for the typed template push.

Right-click -> search 'Push Content To Layer For Player'. Two nodes appear: the synchronous one from Crimson UI Extensions (takes Local Player + hard class, returns the widget) and the async one (takes Player Controller + soft class, has Before/After Push pins). Pop Content From Layer removes a pushed widget.

Sync push: Push Content To Layer For Player (Crimson UI Extensions) - inputs Local Player, Layer Name (UI.Layer.* picker), Widget Class; returns the created widget. Async push: the same-named async node - inputs Owning Player (PlayerController), soft Widget Class, Layer Name. Removal: Pop Content From Layer with the widget reference.

Verify

A test push of any UCommonActivatableWidget subclass appears on the chosen layer; Pop Content From Layer removes it.

3. The messaging subsystem (dialogs)

UCrimsonMessagingSubsystem is a ULocalPlayerSubsystem. Blueprint reaches dialogs through the async nodes (which find the subsystem internally); C++ gets the subsystem from the local player.

Right-click -> search 'Show Confirmation'. Use Show Confirmation Yes No / Show Confirmation Ok Cancel / Show Confirmation Custom (async nodes, category Crimson|UI|Dialog). No subsystem getter needed.

4. The context-menu subsystem

UCrimsonContextMenuSubsystem is also a ULocalPlayerSubsystem, and its API is fully Blueprint-exposed.

Right-click -> search 'Crimson Context Menu Subsystem' -> the Get CrimsonContextMenuSubsystem node (context: Local Player). Feed it the local player from step 1, then call Show Context Menu / Close All / Get Active Widget.

5. The UI settings

UCrimsonUISettings holds the policy and dialog classes. It is a UDeveloperSettings (Config=Game) - edit it in Project Settings -> Crimson -> Crimson UI. Reading it at runtime is C++-only (GetDefault), and you rarely need to: the manager and messaging subsystem read it for you.

cpp

#include "Infrastructure/CrimsonUISettings.h"

const UCrimsonUISettings* Settings = GetDefault<UCrimsonUISettings>();
TSoftClassPtr<UCrimsonGameUIPolicy> PolicyClass = Settings->DefaultUIPolicyClass;

The UI manager itself

UCrimsonUIManagerSubsystem (game-instance subsystem) is plumbing you normally never touch: no Blueprint API, and its GetRootLayout(const UCrimsonCommonLocalPlayer*) / inherited GetCurrentUIPolicy() accessors are C++-only. Everything user-facing goes through the push API (step 2) instead.