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 GAS setup that owns the ASC on the player state - CrimsonAbilitySystem and Lyra-style stacks do). 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:

PropertyTypeBehavior
HiddenByTagsFGameplayTagContainerWhile the player's ASC has ANY of these, the widget applies HiddenVisibility.
ShownVisibilityESlateVisibilityApplied when no hidden tag is present. Default Visible.
HiddenVisibilityESlateVisibilityApplied while hidden. Default Collapsed.
Screenshot pendingImages/CrimsonUI/howto-tagged-widget.png
WBP_AbilityBar (parent: Crimson Tagged Widget) Class Defaults: Hidden By Tags = State.Dead, UI.Hidden.Cinematic; Shown Visibility = Visible; Hidden Visibility = Collapsed.
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.