Hello, I’m fairly new to replication and I’m trying to replicate a punch animation but it replicates seemingly randomly so I don’t understand what I’m doing wrong.
I linked a video of what’s happening and screenshots of my blueprints.
Hi, so first of all, your “Switch Has Authority” is redundant since you will do the same thing in both cases, just pluck your Server RPC there.
Secondly, I wouldn’t handle such a case using the animation tree, instead you can use a montage. This looks like a one-shot animation, since you set the boolean back to false in the next tick and montages are there to handle these one shot animations.
Now, what I believe this problem could be: Animation blueprints are oftentimes multithreaded which can lead to all sorts of misbehavior when setting variables directly and replicating the calls that set them. I am unsure when rpc’s are processed but based on the fact that you have obviouse problems lead to my suggestion that the animation might sometimes update before the next tick of your actor has happened and sometimes after it, leading to the problem, that you sometimes already reset the boolean back to false, thus never entering the “Attack” state in your animation blueprint.
This is just my guess, you could try adding another wait until next tick, but it would be best to swap that animation for a montage
I agree with @RealNyntexx, Use a Montage for the punch. You should also have conditional logic to check if you can punch.
If you’re using character movement component (CMC) you should fire the punch execution locally, then RPC the server to do it. CMC uses client-side prediction. All your added actions should use the same approach.
e.g. punch, kick, swing a sword, fire a weapon, dodge, roll etc
- Client input → Can I do this (true) → execute it locally → Srv Punch
- Srv Punch → Can I do this (true) → Multicast Punch
- Multicast Punch → Branch:(is server or simulated proxy)[true] → Punch
The conditional branch on the multicast ensures that only the server and sims can process the punch. Client has already done it maintaining client-side prediction implementations.
Hits would applied in the same manner. Client detects a hit, it should then handle its local VFX/Audio to accommodate. Server doesn’t do VFX/Audio. Yet you can either have the server multicast to sims or allow the sims themselves handle them based on local results.
RPC’s are bundled with movement updates which are sent at a defined rate. It’s not every client tick because each client ticks differently (FPS). Typically if the server is running at 30Hz clients will update at 60Hz. A 2:1 ratio is common.
Both client and server process and send at start of tick. Never in the middle.
If the clients send rate is 60Hz (16.667ms) it will send what’s ready at the start of the next tick for each 16.667ms interval. Regardless of client FPS, but always at the start of a tick.
If a packet is received at tick 1000 it will not be processed until tick 1001 start. On the server the results for 1001 won’t be flushed until tick 1002 start.
e.g. If the server receives a punch RPC in tick 1000, it won’t process that RPC until 1001 start. The multicast RPC won’t send until tick 1002 start.
How much of a delay that is depends on where in tick 1000 it was received. A 30Hz server has a 33.333ms interval between ticks. If it lands say 2ms into the tick, it will sit buffered for 31.333ms. If it lands at 29ms into the tick, it will sit buffered for 4.333ms. From here you add a full tick interval for processing, so 33.333ms.
Big picture this means your RPC could take 65.333ms to be processed and then flushed on a 30Hz server. Then there’s your ping. It takes on avg 50% of ping time to reach server.
100ms ping = 50ms update travel time → thus a 115.333ms potential delay before your RPC is received, processed and flushed.
Thanks a lot for the answers and all of the informations, it is what you both said !