koobas.hobune.stream
RPCs and instantiations being dropped/appearing out of order
It seems that when a player on a particularly terrible connection connects to my server, the lag/packet loss causes some odd problems both for that player and the server. As far as I can tell, sometimes RPCs to/from that player appear out of order, sometimes even to the point of RPCs for an object arriving before it's been instantiated at all. Some RPCs are dropped entirely.
The only question I can find that seems even remotely related is this one, which seems to be talking about something different (the timing of RPCMode.All to already-connected players).
All of the NetworkViews in my game are either set to Unreliable or have state sync disabled entirely, but as I understand it, this shouldn't affect RPCs, only state sync.
RPCs are sent as UDP packets, but Raknet implements it's own reliable layer on top of UDP. The RPC calls are numbered, if an RPC call is missing the receiving side requests it again and hold the newer ones back until all RPCs have arrived in chronological order.
The state synchronisation works similar when you use reliable transfer. Of course when you use unreliable it's possible that an (unreliable) update arrives before the RPC arrives that should create the object. Such interferences depends entirly on the latency.
The point is, you simply can't play a realtime game (e.g. QuakeLive) with a latency of 500+ ms.
final note: The order of RPCs can only be kept for the same peer. If two users send an RPC almost at the same time, it can't be ensured that they are executed in the same order they have been triggered in realtime.
Of course when you use unreliable it's possible that an (unreliable) update arrives before the RPC arrives that should create the object.
This seems to explain the state sync part. I have been getting some errors there, but those are harmless, aren't they?
if an RPC call is missing the receiving side requests it again and hold the newer ones back until all RPCs have arrived in chronological order.
But this does not seem to match my observations. I'll have to do more testing next time the tester with the terrible connection is around, but so far it would seem that this is not the case.
