Triggering Gameplay Ability with Parameters in Multiplayer

Development Programming & Scripting Blueprint
1

Hello,

I’ve been trying to create a knockback system under the premise that the victim owns a GA which is triggered by the attacker, who is supposed to send knock parameters such as distance, direction and duration.
I am aware that this can be done through a gameplay event trigger. The problem is gameplay events are not replicated, which means the GA only triggers on the server possessed pawn. Clients dont receive the event.
I have found 2 ways of solving this issue but both are fragile.
The first one was multicasting the gameplay event so clients receive it too.
The second was creating attributes and using them as parameters, then having the attacker apply a GE to override those parameters, f.e. 100 distance 1 duration etc
And then have the attacker apply another GE that triggers the victim GA to read the attributes and execute the knock following the parameters.

But like I said both of these are very fragile and I’ve been trying to find a more proper method…
Im wondering on what the industry standard for this is.

Also blueprint only project

2

Hi there, welcome to the community.

Short answer, yes: Send Gameplay Event to Actor would do the job. You don’t need to multicast it to every client.

So when you execute the TryKnockBack_ABP ability, which should run on the server, and confirm that it is a valid knockback:

ValidKnockBack
→ Build Gameplay Event Data
Target = Victim
Event Magnitude = Strength
Additional Data = The data you need

→ Send Gameplay Event to Actor(Victim)

This runs on the server and triggers the victim’s ability, which then handles its internal logic such as LaunchCharacter(), root motion force, etc. Since that movement logic is server-authoritative, it will replicate through the normal movement system.

This is the proper way of doing it. Gameplay events don’t have to be replicated; you need to send the event on the server.

Another possible method is having the victim read the data from the attacker. For example:

AttackerAbility -> Hit Confirmed -> Apply Effect(Victim)

The attacker stores the knockback data, and the victim’s knockback ability reads it from the instigator through an interface such as GetLastValidKnockbackData() .

This can work for a most cases, but it has a more fragile lifecycle. When the victim’s ability activates, it is reading shared data stored on the attacker rather than data belonging directly to that specific hit. If multiple hits or victims are processed close together, the previous data can be overwritten or the wrong hit data may be read. So managing lifecycle on this method becomes more important.

Because of that, passing the parameters directly through the Gameplay Event payload is generally the safer approach. So you just need to Send Gameplay Event to Actor() on Server

Edit : If your ability is crafted and somehow you cannot make it ServerAuthorative but LocalPredicted then ability activation can stay local but you can make an RPC Remote Procedure Call as you mentioned to workaround the problem to send event of Send Gameplay Event to Actor on Server.

Basically when you are sending data →

CustomEventServer [Replicated, Server] (Data) → SendGameplayEvent

Normally LocalPredicted executes on both server and local so you should check if the data exist on server 1st then send event, cause it won’t work otherwise better option is to make ability Server Authorative.

1 Like
3

Thank you.

Thats crazy, setting it to run on server only actually made it work as intended.
I cannot believe the fix was such a silly thing.
Why does it work like this if I may ask though?
I had it set to local predicted and client or server on net security, and the ability was not activating at all, not for the client nor its instance owned by the server.

Thanks again

4

Glad that it works.

It’s basically all about authority and ownership on the network.

Server owns the authoritative state. Clients can predict and run their own abilities, but the attacker client does not own the victim’s ASC, so it cannot properly activate an ability that belongs to the victim.

When you send the Gameplay Event on the server, server has authority over both attacker and victim, so it can activate the victim ability and replicate the result.

Client executes its own ability → server can validate it.
Client tries to execute victim ability → server does not accept that ownership.
Server executes victim ability → clients receive the replicated result.