Game-instance-driven loading screens that show and hide themselves — no manual Show/Hide calls, ever.
Free · Utility · Unreal Engine 5
Loading screens that just work — automatic, frame-accurate, zero glue code.
A UGameInstanceSubsystem evaluates 16 conditions every frame — world validity, GameState replication, pending and seamless travel, and your own readiness checks — then shows or hides the loading screen for you. It blocks input, switches the shader pipeline to fast batch mode, suspends hitch detection, and restores everything on hide. You write a widget; it handles the rest.
Why CrimsonLoadingScreen
Everything a shipping loading screen needs — condition-driven, performance-aware, and fully Blueprint-readable.
Automatic show & hide
The subsystem checks 16 conditions every frame — null world, un-replicated GameState, pending or seamless travel, missing player controllers — and drives visibility itself. No manual Show/Hide calls anywhere in your game code.
Hold it until *you* are ready
Implement ICrimsonLoadingProcessInterface on a GameState, PlayerController, or component — or spin up a Blueprint UCrimsonLoadingProcessTask — to vote the screen up while your own async data loads, then release it.
Performance hooks built in
On show it switches FShaderPipelineCache to Fast batch mode, disables world rendering, raises loading priority, and suspends the hitch heartbeat — then restores every setting on hide. A configurable hold delay (default 2 s) lets texture streaming catch up.
Input blocking that respects PIE
An FLoadingScreenInputPreProcessor registered at Slate priority 0 eats all input in packaged builds, so players can't act behind the screen — while passing everything through in the editor for painless iteration.
Weighted tips & background pools
Drive tip text and background materials from UDataAsset collections: weighted random selection with optional GameplayTag category filtering, and a pool of UMaterialInterface backgrounds picked per-load. Both are read straight into your widget.
Debug tooling for fast iteration
Console variables (AlwaysShow, per-frame reason logging), a non-shipping -NoLoadingScreen flag, heartbeat logging, and an MCP tool crimson.loading.get_state that reports visibility, the live debug reason, and the current tip.
A closer look
Install once, then forget it exists
Tick CrimsonLoadingScreen and its dependency CrimsonCommon in Edit → Plugins, point a setting at your UUserWidget, and you're done — Blueprint projects edit no .uproject or .Build.cs. The manager starts automatically and never needs a manual call. It also returns false from ShouldCreateSubsystem() on dedicated servers, so there's no widget, tick, or overhead there.
Keep the screen up while your data arrives
Built-in conditions cover engine travel; your game covers everything else. A GameState component can hold the screen until all players are ready; a client PlayerController can wait on its initial inventory sync. Implement ShouldShowLoadingScreen() and return true with a reason, or create a UCrimsonLoadingProcessTask and call Unregister() when the work finishes. Any external UObject can register as a processor too.
Show off the player's character while they wait
An ICrimsonLoadingCharacterProvider snapshots the player's full build — leader and overlay meshes, materials, plus mounts, pets, and props — before the pawn is destroyed. A showcase director implementing ICrimsonLoadingCinematicInterface dresses a preview stand from that snapshot, and an optional SceneCapture2D feeds a live render target straight into the widget background.
Technical details
- Engine
- UE 5.8
- Platforms
- Windows, Mac, Linux
- Blueprint-ready
- Yes
- C++ required
- No
- Network replicated
- No
- Dependencies
- CrimsonCommon, GameplayTags, UMG, Slate, PreLoadScreen, RenderCore
- Last updated
- June 2026
Frequently asked questions
Do I need C++ to use it?
UCrimsonLoadingScreenManager; all settings live in Project Settings → Crimson → Loading Screen; and UCrimsonLoadingProcessTask is Blueprint-callable for holding the screen. C++ is there if you want to implement the process or character-provider interfaces in native code.Do I have to call Show or Hide manually?
Can I keep the screen up while my own data loads?
ICrimsonLoadingProcessInterface on a GameState, PlayerController, or one of their components, or create a UCrimsonLoadingProcessTask and release it when your async work completes. Any other object can also register via RegisterLoadingProcessor(). The manager polls all of them every tick.Does it depend on other Crimson plugins?
Is it free?
Ship a polished loading screen this afternoon
Enable the plugin, point it at a widget, and the subsystem handles show, hide, input blocking, and performance tuning for you. Add tips, backgrounds, and a character preview when you're ready.
Ready for more? Add a premium system
You're already on the Crimson foundation — these paid systems drop straight in, no glue code.
Layout-agnostic, fully replicated inventory and crafting.
- Pluggable Topology
- Runtime Constraints
- Scoped Containers
- Crafting
- No RPCs to Write
Replicated, GAS-native skill trees with a two-graph editor.
- Two-Graph Editor
- Material Splines
- Server-Authoritative
- Atomic Respec & Loadouts