How-To: React to Loading Screen Events

Goal: run logic when the loading screen shows or hides (pause music, mute input handling, start/stop a showcase) - event-driven, instead of polling GetLoadingScreenDisplayStatus.

Prerequisites
You can reach the manager (How-To: Get the Building Blocks step 1). Bind from something that outlives level travel - a GameInstance subclass, a game-instance subsystem, or a persistent actor that re-binds on spawn. The loading screen widget itself does not need events: it reads the pure getters in Construct.

1. Bind the visibility event

Fires with bIsVisible = true just before the widget is added, and false right after it is removed.

Screenshot pendingImages/CrimsonLoadingScreen/howto-bind-visibility-bp.png
Get CrimsonLoadingScreenManager -> drag off -> Bind Event to On Loading Screen Visibility Changed -> connect a Custom Event with a bool 'Is Visible' input. Same pattern for Bind Event to On Loading Screen Content Ready (Character Info input).
Verify
Travel between maps: your handler fires once with true and once with false per load.

2. Bind the content-ready event

On Loading Screen Content Ready fires just before the screen becomes visible and hands you the gathered FCrimsonLoadingCharacterInfo - the hook for preparing showcase content that is not an actor in the world (actors should implement ICrimsonLoadingCinematicInterface instead, see How-To: Showcase the Player's Character).

cpp
Manager->OnLoadingScreenContentReady.AddUObject(this, &UMyGameInstance::HandleContentReady);


void UMyGameInstance::HandleContentReady(const FCrimsonLoadingCharacterInfo& CharacterInfo)
{
    // CharacterInfo.IsValid() is false when no provider was found
}
Blueprint and C++ get separate delegates
C++ binds the native OnLoadingScreenVisibilityChanged / OnLoadingScreenContentReady; Blueprint binds the assignable mirrors (shown as On Loading Screen Visibility Changed / On Loading Screen Content Ready). Both fire at the same moments with the same payloads.
Event order and the engine's own loading screen
Order on show: content-ready fires first, then visibility-changed(true), then the widget is created. While the engine's startup preload screen is still active, the plugin does not create a widget - content-ready still fires, visibility-changed does not.

See also

  • Concept: Lifecycle & Show Conditions - the exact show/hide sequences these events sit in.
  • How-To: Showcase the Player's Character - the actor-side alternative for showcase levels.