Although a quite old thread, I just found the same problems and wanted to share my experience. (being on 4.26 now) In fact, I also tried multicast RPC and I’m quite sure, that you also have some DestroyActor following the RPC call to remove the actor (this is my basic assumption here and having this allows to reproduce issues like that). It looks like this causes the troubles.
Solution 1 (still using multicast): I only could get it to work by setting the MCAST RPC to reliable. This solution works for me, it looks like setting that flag somehow delays the final actor destroy untill all reliable stuff has been handled. I did pass the hit location to the multicast to have a fixed location.
Now revisiting this again, because I did not like the idea of using Multicast at all and even more, using a reliable multicast (avoiding mcast if possible is a good practice).
Solution 2 (no multicast is needed at all): Finally, I found a much simpler solution: If you destroy your actor, just override the Event Destroyed (this one is fired on server and client) and just spawn the effect here.
The only thing I found is, that theres a slight offset in ActorLocation between server and client:
LogBlueprintUserMessages: [BP_CharTestAI_C_16] Server: KILLED Object17 at X=780.399 Y=1382.579 Z=864.785
LogBlueprintUserMessages: [BP_CharTestAI_C_14] Client 1: KILLED Object17 at X=791.955 Y=1366.583 Z=861.380
looks like it is just one frame off…
But this is no issue for me, and in your example, you do not pass a location at all, but instead use GetActorLocation on the multicast event as well, so that same offset should be present in your case also.
It you need a really exact location fixed at time of hit, the reliable multicast should be your friend. Otherwise just drop that multicast stuff completely - no problem if some explosion spawns 20cm off…
BTW: Happy to be able to login to answerhub again, after this failed for several months 