Weird replication behaviour
Hello, today I encountered an odd problem with replication of actor spawn. I managed to fix it but was wondering if there is cleaner solution. To quickly explain:
And that's how it goes, I hope it's understandable. The fix was to add UFUNCTION(Client, Reliable) ClientOnRecieved(MyCharacter*), it can be completely empty, but it forces client to sync and spawn weapon so that function can be called on it. What's strange is that the pointer to owner character that is valid in OnRecieved (on server) is null on client. Shouldn't character be already spawned on clients during GameMode::SetPlayerDefaults? Can I somehow force the engine to execute spawn actor before RPCs, even if next RPC is on another object?
It's better not to force any property replication to avoid messing up prioritization. And sending an RPC that assumes any property as being already replicated is error-prone. I think you could make the weapon set itself as the player's current weapon as soon as it spawns. Or make you current weapon a UPROPERTY and rely on replication for switching weapons on the client (with ReplicatedUsing).
answered Aug 12 '15 at 10:35 PM
I agree with ilookha, the best solution over-all is definitely not to force the replication. The easiest setup is to simply have the server handle important things like this. So adding, switching, dropping, ect. of weapon is just done there and you rely on replication. You can get some better "feel/response time" if you mask some of the delay locally with animations and whatnot, but for first pass I would suggest taking it easy and go with what the engine is good with.
I wanted to clarify something, "since client should always have most up-to-date equipped weapon" is incorrect. Only the server has the most-up-to-date info; it is the authority.
Hope that helps!
answered Aug 13 '15 at 02:01 AM
Follow this question
Once you sign in you will be able to subscribe for any updates here