Quick Start

By the end of this page your own widget appears automatically whenever a level loads, showing a random tip and a background image, and disappears when the new level is ready. No Show/Hide calls anywhere.

Prerequisites
CrimsonCommon and CrimsonLoadingScreen are installed, and your project has at least two maps so you can trigger a level travel in PIE. Tips and backgrounds are optional extras added in step 2 of How-To: Show Tips & Backgrounds - this page wires the minimum.

1. Enable the plugin

Open Edit -> Plugins, type Crimson in the search box, tick CrimsonLoadingScreen's checkbox (and CrimsonCommon, its dependency), and restart the editor when prompted. For a Blueprint project that is the entire install - you never hand-edit the .uproject or any .Build.cs.

Screenshot pendingImages/CrimsonLoadingScreen/qs-enable-plugin.png
Edit -> Plugins -> search 'Crimson' -> tick CrimsonLoadingScreen's Enabled checkbox -> restart the editor.

C++ projects: after enabling the plugin, add its module to your build file so your game code can use its types:

csharp
// YourGame.Build.cs
PublicDependencyModuleNames.Add("CrimsonLoadingScreen");
Verify
CrimsonLoadingScreen shows as enabled in the Plugins window and the editor restarts without errors. The manager is already running - it starts with the game instance.

2. Create the loading screen widget

The loading screen is a standard UMG UUserWidget you design yourself; the manager creates it, adds it to the viewport, and removes it. Give it a full-screen Image for the background and a TextBlock for the tip, then read the manager's current values when the widget constructs. The tip and background are picked before the widget is created, so the values are always ready in Construct.

Screenshot pendingImages/CrimsonLoadingScreen/qs-widget-construct-bp.png
Create WBP_LoadingScreen (User Interface -> Widget Blueprint). Designer: a full-screen Image (BackgroundImage) + a TextBlock (TipText). Graph: Event Construct -> Get CrimsonLoadingScreenManager (search 'Crimson Loading Screen Manager', under Game Instance Subsystems) -> Get Current Tip -> SetText (TipText), and Get Current Background -> Branch (Is Valid) -> Set Brush from Material (BackgroundImage).
The manager node is a subsystem getter
Right-click in any graph and search Crimson Loading Screen Manager - the pure getter node lives under Game Instance Subsystems. All the manager's read functions (Get Current Tip, Get Current Background, ...) are pure nodes, so no exec wiring is needed.
Verify
The widget compiles/saves. With no tips or backgrounds authored yet it will simply show its design-time look - that is fine for now.

3. Register the widget in Project Settings

Open Project Settings -> Crimson -> Crimson Loading Screen and set Display -> Loading Screen Widget to your widget class. This is the only required setting - everything else has working defaults.

Screenshot pendingImages/CrimsonLoadingScreen/qs-settings-widget.png
Project Settings -> Crimson -> Crimson Loading Screen -> Display -> Loading Screen Widget = WBP_LoadingScreen.
If you skip this
The manager falls back to a bare spinner (SThrobber) and logs an error to LogCrimsonLoadingScreen - useful to know when diagnosing a 'my widget never appears' report.
Verify
The setting shows your widget class and is written to Config/DefaultGame.ini under [/Script/CrimsonLoadingScreen.CrimsonLoadingScreenSettings].

4. Trigger a load and watch it work

Press Play, then travel to your second map - Open Level (by Name) from any Blueprint, or type open YourMapName in the console. The widget appears during the transition and disappears once the new level has begun play.

PIE behaves differently from packaged builds
Two things are editor-only by design: input is not blocked in PIE (FLoadingScreenInputPreProcessor only eats input in packaged builds), and the post-load hold delay is skipped in the editor unless you tick Debugging -> Hold Loading Screen Additional Secs Even In Editor. If the screen flashes by too fast to inspect, run CrimsonLoadingScreen.AlwaysShow 1 in the console to pin it up while you iterate, then set it back to 0.
Verify
Your widget (not a throbber) covers the screen during the travel. The Output Log shows LogCrimsonLoadingScreen lines with the show/hide reason.
What's next
Learn the getter chains once (How-To: Get the Building Blocks), then add content (How-To: Show Tips & Backgrounds), keep the screen up until your game is really ready (How-To: Hold the Loading Screen from Game Code), and go cinematic (How-To: Showcase the Player's Character, How-To: Live Render Target Preview).
On the full Crimson stack
CrimsonCore ships a ready-made base widget (W_LoadingScreen_Base in its content) you can point Loading Screen Widget at instead of authoring your own, and its ACrimsonCorePlayerCameraManager votes to hold the screen until the player camera is placed. You still assign the widget in Project Settings and author your own tips, backgrounds, and showcase content.