Vive Motion Controller Multiplayer 4.13

[mordentral]

@ddbrown30;598234

The replication of the character movement component is done using RPCs, yes, but it also has a delay timer to ensure that the RPC is not sent too often in order to prevent connection saturation. This time fluctuates based on the strength of the connection (fewer sends on a slower connection). Looks like their min time (0.0222) would put it at about 45 sends per second when the character is moving. That’s high, but accuracy for characters is important and the packets are optimized. If you had that kind of bandwidth usage for every object in your game, you would quickly saturate your connection.

I didn’t realize that the properties are only synced in a single direction (like I said, still learning the net engine for UE4), but that makes sense.

Just as a disclaimer, everything I’m saying here comes from years of making multiplayer games and are general concerns. It’s totally possible that UE4 has a bunch of magic going on in the background to streamline writing net code so that most users don’t have to think about it. I have no idea, as I’m still learning. Please correct me if anything I’m saying sounds off.

In servers with 10 or less players the player movement defaults to 90 htz send rate, also there is significantly more information in the movement replication than in his RPCs. That being said you are correct that there is no real reason to replicate at the full tick speed and it shouldn’t be replicated at all if the change in position is below a threshold to begin with. Something like 30 htz doesn’t look that bad and any positional offsets can be corrected for by sending the controllers location at the time of important events (like grabbing something).

I wasn’t arguing against what you said about the bandwidth, I was arguing against you saying that RPCs shouldn’t be used as there isn’t really an alternative.

Its all good though.