How-To: Tag-Driven HUD Visibility
Goal: make a HUD element hide itself while the local player's ability system holds any of a set of gameplay tags (dead, in cinematic, UI hidden) - no tick, no manual wiring.
Prerequisites
The owning player's PlayerState implements `IAbilitySystemInterface` (any GameplayAbilities setup that owns the ASC on the player state). Without an ASC the widget just stays visible.
1. Subclass and configure
Create your HUD element with parent Crimson Tagged Widget (UCrimsonTaggedWidget, a UCommonUserWidget - passive, never takes focus). Set in Class Defaults:
| Property | Type | Behavior |
|---|---|---|
HiddenByTags | FGameplayTagContainer | While the player's ASC has ANY of these, the widget applies HiddenVisibility. |
ShownVisibility | ESlateVisibility | Applied when no hidden tag is present. Default Visible. |
HiddenVisibility | ESlateVisibility | Applied while hidden. Default Collapsed. |
Example: a WBP_AbilityBar with parent Crimson Tagged Widget and Class Defaults Hidden By Tags = State.Dead, UI.Hidden.Cinematic, Shown Visibility = Visible, Hidden Visibility = Collapsed disappears while the player is dead or in a cinematic. No graph is needed - the base class does the tag watching.
SetVisibility still works
Calling
SetVisibility on a tagged widget records your intent: ask for a visible state and the tag logic still gates it; ask for a hidden state and it stays hidden regardless of tags.Verify
In PIE, granting the player one of the
HiddenByTags (e.g. via a debug ability or the AbilitySystem.DebugAbilityTags tools) collapses the widget; removing the tag restores it.See also
- How-To: HUD Layout & Escape Menu - where tagged widgets typically live.
- Concept: Full-Stack Integration & Multiplayer - how the ASC reaches the client.