CrimsonUI · Lesson 3 of 9
Set the Boot Classes
Before you start
- Completed: Enable the Plugin
Chapters
The two hard requirements
The policy that creates your layout boots from the Game Instance, and it targets each Local Player. Both classes must be Crimson types:
| Setting | Class |
| Game Instance Class (Maps & Modes) | a subclass of UCrimsonCommonGameInstance |
| Local Player Class (DefaultEngine.ini) | UCrimsonCommonLocalPlayer |
| Game Viewport Client Class (Engine → Default Classes) | UCrimsonGameViewportClient |
Wrong class = nothing, silently
If either the Game Instance or Local Player class is wrong, no layout is ever created and no widget ever appears — with no error. When 'nothing shows up', check these two first.
1. Game Instance
UCrimsonCommonGameInstance is Abstract — subclass it first (a Blueprint parented onto it, or your C++ game instance re-based), then set it in Project Settings → Maps & Modes → Game Instance Class.
2. Local Player
Set the Local Player class in Config/DefaultEngine.ini:
[/Script/Engine.Engine]LocalPlayerClassName=/Script/CrimsonCommon.CrimsonCommonLocalPlayer
3. Viewport Client
Set Project Settings → Engine → General Settings → Default Classes → Game Viewport Client Class to CrimsonGameViewportClient. CommonUI's input routing runs through the viewport — without it, activatable widgets can't own input.