How-To: Get the Building Blocks

Goal: get the three pieces every other page assumes you can reach - the manager subsystem, the project settings, and the two content data assets. Bookmark this page; the task pages link back here instead of repeating these chains.

1. The manager subsystem

UCrimsonLoadingScreenManager is a game-instance subsystem: it exists once, for the whole session, and survives every level change. All runtime reads and event bindings go through it.

Screenshot pendingImages/CrimsonLoadingScreen/bb-get-manager-bp.png
Right-click -> search 'Crimson Loading Screen Manager' -> pick the getter under Game Instance Subsystems. It is a pure node usable in any graph (widgets, actors, components).
Verify
The getter returns a valid manager in PIE. It is null on dedicated servers (the subsystem never creates there) - guard any server-shared code path accordingly.

2. The project settings

All configuration lives on UCrimsonLoadingScreenSettings at Project Settings -> Crimson -> Crimson Loading Screen and persists to Config/DefaultGame.ini. Sections: Display, Timing, Tips, Backgrounds, Cinematic Preview, Debugging (full table in API Reference).

C++ reads the settings object directly:

cpp
#include "CrimsonLoadingScreenSettings.h"


const UCrimsonLoadingScreenSettings* Settings = GetDefault<UCrimsonLoadingScreenSettings>();
const int32 ZOrder = Settings->LoadingScreenZOrder;
No Blueprint settings object
The settings class is not Blueprint-exposed. Everything a widget needs at runtime (current tip, background, render target) surfaces through the manager's pure getters from step 1 - you never need the settings object in Blueprint.
Verify
Changing a value in the panel writes it under [/Script/CrimsonLoadingScreen.CrimsonLoadingScreenSettings] in DefaultGame.ini.

3. The content data assets

Tips and backgrounds are plain data assets - the plugin ships none, you author them. Create both the same way: Content Browser -> right-click -> Miscellaneous -> Data Asset, then pick the class.

Screenshot pendingImages/CrimsonLoadingScreen/bb-create-data-assets.png
Right-click -> Miscellaneous -> Data Asset -> pick CrimsonLoadingTipsCollection (name it DA_LoadingTips) or CrimsonLoadingBackgroundCollection (DA_LoadingBackgrounds).
Verify
Both classes appear in the Data Asset class picker. If they are missing, the plugin is not enabled or the editor was not restarted.

4. Reading live state

All manager reads are pure Blueprint nodes (and plain C++ getters). This is the complete read surface:

GetterReturnsEmpty/null when
GetCurrentTipFText of the tip for this loadNo TipsCollection set, or no tip matched the filter
GetCurrentTipCategoryFGameplayTag of that tipSame as above
GetCurrentBackgroundUMaterialInterface*No BackgroundCollection set
GetShowcaseRenderTargetUTextureRenderTarget2D*bUseLivePreview is off, or no render target assigned
GetCachedCharacterInfoFCrimsonLoadingCharacterInfo snapshot from when the screen openedNo provider found (check MeshComponents is non-empty)
GetLocalPlayerCharacterInfoLive provider query (use outside loading, e.g. menus)No provider found
GetLoadingScreenDisplayStatusbool - widget currently on the viewport-
GetDebugReasonForShowingOrHidingLoadingScreenFString explaining the current state-

See also

  • How-To: Show Tips & Backgrounds - fill and register the data assets from step 3.
  • How-To: React to Loading Screen Events - event-driven alternative to polling the getters.
  • API Reference - the full settings table and every signature.