Third Party [PUN] Local bullet rickochete sync

Hello, I have a bullet instantiated with RPC (AllViaServer), the bullet is Rigidbody (just for collision detection) with frozen constraints and I'm moving it with transform.Translate (bullet.forward * speed).
In OnCollisionEnter method I'm calculating reflected direction based on first contact point and change bullet's facing vector. The problem is that sometimes (rather often) bullets are reflected in different directions on each client, is there any way I can fix this?

 

Send the direction to all clients when this change ?
And also the position when changing and a timestamp to recalcul position with the bullet speed, to be completely sure all is well sync.

 

Hi, I've tried to do this way, but due to network delay and decent desync, bullet just jumps to another position and this is very noticeable, so this way does not fit my game...

 

does anyone know, would the masterClient - authoritative implementation fix this?

 

First of all, you shouldn't be detecting bullet collisions with rigidbodies. Instead, try raycasting at each FixedUpdate frame from the previous position to the current position. Not only will this be 100x more reliable, but it'll also be way better for performance (especially if you were using Continuous Dynamic collision detection. And if you weren't; your bullets would be missing a lot of collisions)

So now, regarding the network syncing: only the server should be handling bullet ricochets. When the server detects that a bullet ricochets, it sends an RPC to all clients telling them to place that bullet at its ricochet position, to orient it at its ricochet orientation, and to give it a new velocity. Basically, the clients will never be checking for bullet collisions. They'll just wait until the server tells them that it happened.

However, if the delay is too noticeable... sometimes there are just no real solutions to these things. How do you make something that takes 1 second take 0 seconds instead? This is basically what we're trying to solve here.

This isn't a situation where you can come up with a clever deterministic approach, since it's basically a dynamic physics problem with unpredictable player inputs entering the equation. The "solution" in this case would be to either accept the delays, or make ricochets handled by the owning clients. But in that case, you'll be at risk of hackers modifying their game so that every ricochet directly headshots the nearest player.... and according to several people in game dev communities, if your game can be hacked, it most likely will be. No matter how small