Fix: Gameplay Cue Not Playing on Client in Unreal

Your fire spell works perfectly in PIE with a single player. Particles erupt, sounds play, screen shake triggers. But the moment you test with a dedicated server and a second client, the casting player sees nothing. The server applies the damage correctly — the enemy’s health drops — but the visual and audio feedback from the Gameplay Cue is completely absent on the client. This is one of the most common Gameplay Ability System (GAS) issues, and it trips up even experienced Unreal multiplayer developers.

How Gameplay Cue Replication Works

Understanding the replication flow is essential to diagnosing the problem. Gameplay Cues don’t replicate directly. Instead, they piggyback on Gameplay Effect replication through the Ability System Component (ASC).

The flow works like this:

1. A Gameplay Ability executes on the server and applies a Gameplay Effect
2. The Gameplay Effect has a Gameplay Cue tag (e.g., GameplayCue.Ability.FireBlast)
3. The ASC replicates the active Gameplay Effect to the owning client
4. The client’s ASC receives the replicated effect and looks up the matching Gameplay Cue Notify
5. The Gameplay Cue Notify executes locally on the client, spawning particles, sounds, etc.

If any step in this chain fails, the cue won’t play. The Gameplay Effect must be applied on the server (not predicted on the client), the ASC must replicate effects to clients, the cue tag must exactly match a loaded Notify asset, and the Notify must be discoverable by the GameplayCueManager.

Fix 1: ASC Replication Mode

The Ability System Component has a replication mode that controls how Gameplay Effects are replicated. This is the single most common cause of missing Gameplay Cues on clients.

The three modes are:

• Full: All Gameplay Effects are replicated to all clients. Every client sees every effect on every actor. High bandwidth but reliable.
• Mixed: Gameplay Effects are replicated to the owning client only. Other clients receive minimal replication through Gameplay Cue RPCs. This is the recommended mode for most multiplayer games.
• Minimal: Gameplay Effects are not replicated to clients. Only Gameplay Tags are replicated. This mode is intended for AI-controlled actors where clients don’t need to see effects. If your player character uses Minimal, Gameplay Cues will never play.

Check your ASC initialization code:

// In your character or player state constructor
AbilitySystemComponent = CreateDefaultSubobject<UAbilitySystemComponent>(
    TEXT("AbilitySystemComponent"));
AbilitySystemComponent->SetIsReplicated(true);
AbilitySystemComponent->SetReplicationMode(
    EGameplayEffectReplicationMode::Mixed); // Not Minimal!

If you’re using Minimal for player characters, switch to Mixed. If you’re already using Mixed, make sure SetIsReplicated(true) is called — the ASC won’t replicate anything if this isn’t set.

Fix 2: Gameplay Cue Tag Naming

Gameplay Cue tags must follow a strict naming convention. The tag must start with GameplayCue. followed by your custom hierarchy. If the tag doesn’t start with this prefix, the GameplayCueManager won’t recognize it as a cue tag and won’t look up a Notify for it.

Correct tag examples:

• GameplayCue.Ability.FireBlast
• GameplayCue.Status.Burning
• GameplayCue.Weapon.Impact.Metal

Incorrect tag examples:

• Ability.FireBlast — missing the GameplayCue. prefix
• GameplayCue_Ability_FireBlast — using underscores instead of dots
• gameplaycue.ability.fireblast — tags are case-sensitive

The tag in your Gameplay Effect’s Display > Gameplay Cues section must exactly match the Gameplay Cue Tag in your Gameplay Cue Notify blueprint. Open both assets and compare the tags character by character. A single mismatched character will cause a silent failure with no error in the log.

Fix 3: Gameplay Cue Notify Loading

Even with correct tags and replication, the cue won’t play if the GameplayCueManager hasn’t loaded the Notify asset. The manager scans specific directories for Gameplay Cue Notify blueprints at startup. If your Notify is in an unscanned directory, it won’t be found.

Check your project settings under Project Settings > Gameplay Abilities > Gameplay Cue Notify Paths. By default, this includes /Game, which covers your entire content directory. If you’ve modified this or if your Notifies are in a plugin’s content directory, add the path explicitly.

You can also verify that a Notify is loaded by checking the GameplayCueManager at runtime:

// Debug: Check if a cue tag has a registered handler
UAbilitySystemGlobals& Globals = UAbilitySystemGlobals::Get();
UGameplayCueManager* CueManager = Globals.GetGameplayCueManager();

if (CueManager)
{
    FGameplayTag CueTag = FGameplayTag::RequestGameplayTag(
        FName("GameplayCue.Ability.FireBlast"));

    // Log whether the tag has any registered handlers
    UE_LOG(LogTemp, Warning, TEXT("Cue handlers for %s: %s"),
        *CueTag.ToString(),
        CueManager->HasAnyCueHandler(CueTag) ? TEXT("Yes") : TEXT("No"));
}

If this returns “No,” your Notify isn’t being loaded. Verify the file exists, the tag matches, and the directory is in the scan paths. Also check that the Notify blueprint compiles without errors — a blueprint with compilation errors may fail to register silently.

Fix 4: Net Execution Policy on Gameplay Abilities

The Gameplay Ability’s Net Execution Policy determines where the ability runs. If the ability only runs on the client (Local Predicted) but never confirms on the server, the Gameplay Effect may not be applied server-side, which means it won’t replicate back to the client through the normal replication path.

For abilities that need to trigger Gameplay Cues on remote clients, use Server Initiated or Local Predicted with proper server confirmation. With Local Predicted, the client applies the effect immediately for responsiveness, and the server confirms or rejects it. The Gameplay Cue plays immediately on the predicting client and replicates to other clients when the server confirms.

If you’re using Local Only, the ability runs entirely on the owning client and never touches the server. Gameplay Effects applied in a Local Only ability won’t replicate because the server never sees them. Switch to Local Predicted or Server Initiated for any ability that needs multiplayer-visible cues.

These GAS replication bugs are notoriously hard to reproduce without a proper multiplayer test setup. Players will report “no visual effects on abilities” or “spells are invisible” without realizing it’s a network replication issue. Having device and network context attached to bug reports — which Bugnet captures automatically — lets you immediately distinguish client-side rendering bugs from replication issues based on whether the reporter was the host or a remote client.

Check the ASC replication mode first. It’s Minimal when it should be Mixed about 80% of the time.