A way to split model network owner?

Hello,

I am currently working on a tank and want the main tank body owner to be set to the player, while turret is set to the person controlling the turret. At the moment, I have it setup where the driver is the owner and the gunner needs to use remotes to rotate the gun, which causes noticeable lag. Splitting them would fix the problem.

The tank is built using all constraints. No welds or motor6d.

8 Likes

AFAIK, you can’t. If you set a network owner of a part, it assigns it to all connecting parts within a physical unit (i.e. the whole tank).

Maybe there’s some trick to this that others might know about?

3 Likes

Even if you could this wouldn’t work at all. A possible solution would be to use Motor6Ds for turrets instead, since they aren’t physically simulated like a constraint turret would be, you can have it controlled on the client and then replicate it using a script.

6 Likes

When I used motor6d, it wasn’t persice enough. Its like it only moves in increments and it gives it an overall bad look. If there’s a way to fix this, then your method would work beautifully

This is a super annoying bug with Motor6Ds, but I find that simply putting something like Motor.Angle = 99999 immediately before the line that sets the angle to what you actually want fixes it.

1 Like

That is by far the weirdest solution to this problem, but thank you very much. It works perfectly

1 Like

Hey so I tried your method, but the motor6d is not showing any effect on the tank in game, even though the desired angle is changing. If the network owner of the vehicle isnt set, it works flawlessly, but not if its changed.

Ok, I just tried this out in a test server and man, this did not work as I expected. While it seems, ironically, that this does actually allow you have different network owners for the main vehicle and the turret, the motor did not behave how I expected it to, and actually started glitching out as one of the bricks was still on automatic network ownership that kept changing.

Scratch using the angle part of motors. This behavior seems to be undefined and likely to just break at some point even if we did find a work around.

Plan B would be to use the C0/C1 property of the motor to create the movement, but this is a lot more complicated in comparison as it would require you to create your own script that runs on .RenderStepped for each client to smoothly rotate the turret towards a desired rotation value.

1 Like

I think you’re overthinking it.

You should just use something that runs on renderstep every frame locally.
Just manipulate the CFrame of a model to “pretend” to be the turret.

  1. on the client who is the gunner, just let them move the turret however they want
    (and send the results to the server)

  2. on every other client, respond to the server event and render the change locally too.

This means the whole “tank” can be owned by the driver, and the turret is just a visual effect.

This should be done by changing the C0 and/or C1 of a weld or motor6D connecting the turret to the main vehicle, not by SetPrimaryPartCFrame

1 Like

Huh, I think you’re asking for trouble with the network ownership and physics if you make the turret part of the actual tank mechanism.

(I’m curious about this enough that I’m building an experiment … I’ll report back!)

Oof, well, just spent a bit of time experimenting with this.
I made a setup where the driver always has network ownership of the entire tank, and the gunner has no ownership, and attempting to “animate” things over the network to look correct.

My discoveries are as follows:

If you have network ownership of the entire tank: (eg: the driver)

  • Setting the CFrame of the turret in a localscript can cause the physics to explode. Don’t do that unless you disable all collision on the turret. Then it works.
  • Using a Hinge+Servo to animate the turret in a localscript works great (no doubt this is the ‘intended’ way to work with physics, too)

If you do not have network ownership of the tank: (eg: sitting in the turret)

  • Setting the CFrame of the turret works ‘visually’, but breaks replication somehow and the vehicle will not “move” even when driven by another player.

  • Trying to mess with the Hinge+Servo that you don’t have network ownership of does not work at all.

So… so far, there isn’t a working solution where the turret is a physics object (has collision) and you can also animate it with network data.

You MIGHT have to make the turret a completely visual-only effect for this to work.

2 Likes

Ill experiment with making the turret a visual effect. I might just change the vehicle to a 1 person vehicle where the driver can control the turret,because then all my problems are solved lol. Thanks so much for you help

Update: I tried to make this work using a weld.

There seems to be a weird thing with welds where if you change the C0 or C1 at runtime, one part will move and one will not - and there is no way to decide which one moves! (even reversing part0 and part1)

In my case it meant the body of my tank always moved, not the turret.

So I can’t vouch for if this works or not.

1 Like

Does this still occur if you give the tank body higher or lower root priority? I know welds are how other games handle things like turrets, but have not previously run into this issue myself.

1 Like

Oh! Messing with rootpriority did indeed fix it.

That’s a MUCH nicer solution.

So to clarify, madattak was exactly right with his initial answer. (Plan B)

Working solution with full collision detection:

  • Have the turret attached via a “weld” and c1 (motor6D would be ok too)
  • Set network ownership for the whole tank to the driver
  • On the client, you can freely animate c0 to rotate the turret, even if you have network ownership of it or not.

I’ll post a link to a uncopylocked place tomorrow.

3 Likes

Source code should be pretty easy to figure out what is going on.

12 Likes

Awesome! Thank you so much for your help!