I’m using my own implementation for movement replication, so I’m calling RPC inside tick function in order to replicate movement state (location, rotation, velocity, etc), would it flood the net buffer even if the net update frequency is set to 100 or below?
I’ve tested it previously in LAN and it works just fine. If the server has good internet connection it works good too, but if it has not, clients join and after a sec they disconnect.
How many bytes would be an acceptable IN and OU rates for an online game (“Stat Net” command)?
I am getting the following warning and clients are closing connection with the server when playing from the internet:
Warning: Closing connection. Can’t send function ‘Server_SetMovementState’ on ‘Helicopter_BP_C_0’: Reliable buffer overflow. FieldCache->FieldNetIndex: 3 Max 4. Ch MaxPacket: 512.
If you’re getting a reliable buffer overflow, you’re probably sending those messages as reliable every tick? That means you’ll make the server buffer new ones to resend one that was dropped… for no reason, since it’s going to be overwritten by the next one with more recent data that could have been sent instead.
Location, rotation, velocity, etc doesn’t depend on the data from the previous frame so you should mark those RPCs as unreliable.
Yeah, you need to make it unreliable - and the system needs to account for missing packets itself. CharacterMovementComponent does this by working out how much delta time has passed between receiving packets to work out how the Server should simulate a client.
See FNetworkPredictionData_Server_Character::GetServerMoveDeltaTime()
To reduce network bandwidth use, you also need to see if you can combine multiple moves into one send, or better yet - avoid sending redundant moves altogether. CharacterMovement also does a bunch of this.
I did a quick look at the character movement component and the truth is that I would expend too much time trying to understand what is going on there…
There is a huge amount of things happening which was a bit confusing for me at first.
Currently, I am not doing any fancy stuff… I just check a valid movement state then I send it via Server RPC for propagation.
The idea of propagating a timestamp interested me, I’ll definitely take another look at that class again.
Well, I am using it inside tick and it is working great. I was concerned if it would saturate the network, and my findings show that it doesn’t really matter, since I am using unreliable RPCs, data would be overwritten by new ones till next “net tick” anyway… of course one could do some of the optimizations **TheJamsh **has mentioned… I am thinking about implementing it latter among others.