Turret's server-to-client turning latency increases on gunner client after driver enters vehicle

In case image is not enough:

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.

2 Likes

@twinkyman26 bumping since you helped me on previous network ownership problem, would appreciate you also helping me on this one

1 Like

And an uncopylocked game with the working demo: Tank Experiment - Uncopylocked | Play on Roblox

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)?

If i change turret’s network owner to gunner while someone is driving the tank, driver would simply not be able to drive.

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.

1 Like

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
2 Likes

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

2 Likes

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

2 Likes

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

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.