Gunner isn’t actually IN the car, he gets teleported to safe area and he is able to shoot the turret only thanks to his camera placement to prevent one of gunner’s character body parts being welded to tank (otherwise it will cause all physics to have 5 FPS on gunner client).
I am really confused what to do on this one since i thought it was ‘NetworkOwnership issue’ which i solved by separating gunner and driver from each other, but it didn’t help.
This is a question and method I personally have not tested; however, the driver in the case wouldn’t mind about how the turret changes/moves w/ a delay.
Have we tried setting the turret to the networkownership of the gunner with the driver operating (all other parts are owned by the driver)?
It uses Weld.C0 to turn turret, and my turret turns via HingeConstraint.TargetAngle (it looks smooth without having to update it every frame which is very reliable). I just can’t figure out why it gives bigger delay when driver enters the tank.
Known issue. Have the gunner’s client sets their own Motor6D.C0 directly every frame. Best I’ve ever got it to work out. Also after, I just made them one player tanks. Got sick of the messing with it.
Maybe you just have to write your own replication for this one. A basic set up would be like:
Driver has network ownership for smooth driving
Gunner client moves the gunner completely smooth on their own client, then sends the motor transforms to the server every something like 0.1 seconds in an unreliable remote event
Server sends motor transforms to every other client in unreliable remote event
Each client interpolates between previous received position and new position, and try to account for delta time
Like he said, simulate the turret movement locally then send a replication event to the server at 20Hz or so. This is called prediction and is the way most fps systems and projectiles in general are done
Obviously this is just a high level plan, you should also implement your own network optimizations like not sending the replication event to the server if the CFrame of the turret hasn’t changed, packing, etc
One thing I wouldn’t do that he said is dumbing down the system just because of a temproary problem; you can keep it to two player vehicles and still have it work perfectly. I never reduce systems because of temproary bugs in an attempt to fix it faster
If you have more questions about custom replication for certain objects and generally how it just works let me know, I’ve wrote my own replication before
simulating it locally would be a problem that might cause desync (upon shooting turret uses current server-side rotation of the turret and it might look funky on client’s screen). this solution is best i can do anyway
Send packed barrel CFrame coordinates with the remote event to the server and validate it, it’ll work nearly perfect then. Make sure you pack it and properly optimize it though