countsie is pointing at the right thing, and your tests are actually consistent with each other once you account for where the ability graph runs. your controlled swap test also rules out the activation path theory i gave earlier, so credit for that isolation.
plain playmontage is not replicated, full stop. what makes it confusing is that the ability graph itself executes on more than one machine. a locally predicted ability activates on the server and on the owning client, so a bare playmontage node inside it runs locally on both. in a two window pie test that covers every window you have: the server window is the host (autonomous on the server), the client window is the owner (autonomous on the client). both play the montage on their own machines, nothing crosses the network, and it looks exactly like replication. the only spectator that could expose the difference, a simulated proxy watching the caster, does not exist in a two window setup.
so the flip flop between your runs is observation, not the node: what you verified when you bypassed playmontage (the cue and state changes) is genuine replication, and what you saw when you reconnected it was the second local execution, not the network.
two things settle it:
run three clients (or two clients plus the server) and in each window watch the other player’s pawn, not your own. plain playmontage: the caster plays it, everyone else’s view of the caster idles through it. playmontageAndWait: every window sees the caster play it, because that task routes through the ability system component, which replicates the montage params so simulated proxies play it too. that is the entire discrepancy between the two nodes.
also check the asc replication mode on your player state/character (default is mixed). if it somehow got set to full, the ability graph spawns on every client and even a bare playmontage plays everywhere, which would replicate for the wrong reason. mixed or minimal is what you want, and under those modes countsie’s description is exact: only server and predicting client run the graph, everyone else gets attributes, tags and multicast cues.
for hit reactions specifically i’d second the cue pattern: a gameplay cue with playmontage inside, fired from damage application with MakeGameplayCueParametersFromHitResult so the cue carries the hit info. cues multicast to all clients including simulated proxies, they work on npcs with no ability running at all, and they keep cosmetics decoupled so any damage source can trigger the reaction without activating an ability. reserve playmontageAndWait for montages that are genuinely part of the ability state, where the completed and interrupted callbacks gate the rest of the graph.
