Thanks Alex,
Our server ticks at 20Hz and our server to client bandwidth is 2Mbps per connection. We do have a custom character movement component but that lives outside of what we’re currently interested in. We have some known bandwidth issues at the moment (lots of actors wanting to replicate a decent amount of data every frame). We see in the server logs that the character movement component wants to send an adjustment and sends it via RPC, but we don’t actually see it getting processed client side until N seconds later. It’s very hard to repro, but it does happen at least a couple times a day during playtesting.
The bandwidth led me to digging into reliable vs unreliable, as I know the ClientAck is unreliable and so at the very least I would have expected the ack to get dropped on the floor and never even go out the door server-side. But it did, the question then is did it leave late or did the client hold on to it for a long time. My guess is it’s the former. I strongly feel like client acks/adjustments shouldn’t wait and should be treated as truly unreliable. Curious what your thoughts are, and if it makes sense for us to pursue using SetRPCSendPolicyFlags for client acks/adjustments.
One more note with respect to this comment: “as this is done to make sure these RPCs are executed in the expected order.” Why then is it only done for unicast? Would multicast not suffer from this same problem?
Lastly, if we were to end up going the route of using OOB for client acks/adjustments where does it make the most sense to call SetRPCSendPolicyFlags?
Thanks again!