network-programminggame-developmentreplicationunreal-engine5unreal-blueprint

Unreliable RepNotify Behaviour in Unreal Engine 5.3.2. Why does client not spawn all decals when server does?


Im trying to spawn a decal actor at the hit location of a players hitscan weapon (linetrace). For simplification I have set up the part of the code that produces the issue in a new project using the first person template.

Here is all the blueprints that I have added to achieve the goal of spawning the decal, the rest of the project is purely template code. enter image description here

SpawnDecal is set to Not Replicate.

When testing in the Play in editor setup as listen server with one client, the listen server spawns all decals without issue (seen on the right) while the client does not reliably spawn all decals, seen on the left. enter image description here

Why could this be happening? Shouldnt the play in editor setup assume a perfect server and connection with infinite bandwidth, no loss and no ping unless network simulation is enabled (which it is not in this case)? In that case I dont see how the client could ever miss spawning a decal with this code while testing with Play in editor.


Solution

  • So it seems that the issue here is that either the listening server is able to process the next frame and replicate the new data before the recieving client is able to use the data from the previous frame, overwirting it. Another possible reason could be that the data for the previous frame sometimes arrives later than the data for the current frame due to UDP stuff and is therefore discarded or that the value is updated before the server can replicate it.

    I've found two possible solutions:

    1. Store all recieved data in a queue and have the client work through it on its own pace instead of using one constantly changing variable.

    2. Use a ForceNetUpdate node after setting the replicated variable to ensure the value is replicated successfully before its overwriten and resent.

    I went with option 2 and it works nicely without any noticable performance impacts. However I an not certain that if using ForceNetUpdate nodes frequently is a good idea and i'd lean on trying to avoid it if I encounter the same issue again.