Network ownership is removed after connecting a mechanism to anchored part via ropeConstraint

Bug Reports Engine Bugs
,
#1

Currently when I connect 4 individual ropes to a car mechanism (One rope attached to each wheel), the network ownership will be lost. This can be replicated using the attached private repro file using these steps:

  1. Enable “Are Owners Shown” in studio settings

  2. Hit play solo

  3. You will see that the car matches your own character’s network ownership

  4. Click the green part to connect the ropes to the car. The network ownership will now be removed

This does not happen if you just connect a rope to a regular part. It has something to do with this mechanism. I could really use this functionality for an upcoming update, so any fix or workaround would be appreciated!

(@Khanovich @kleptonaut @m0bsterlobster may be relevant?)

Expected behavior

I would expect the client with the network ownership to take full physics ownership of the rope. While the server other clients only display a local visual rope model between the positions of Attachment0 and Attachment1

A private message is associated with this bug report

1 Like
#2

Unfortunately this is the expected behavior at this time. Constraining an assembly that isn’t the mechanism root to an anchored part is going to force the ownership back to server. The best way to address this is just assign ownership again after creating the rope.

To be clear, you do not need to call SetNetworkOwner on every part. You could just call it on the main body of the car and the whole mechanism will be assigned correctly.

You see it work with one part (assembly) because if you have one part, it is the mechanism root. As soon as you have more than one assembly, and you want both to be roped to an anchored part, the ownership will change.

Yes this is confusing. This is something we have been aware of as a limitation, and will be working to address it in the next year.

#3

What’s the chance we can get an API that just persists our preferred network owner.

local preferredOwner = Instance.new("NetworkOwnerHint")
preferredOwner.Player = game.Players.Quenty
preferredOwner.Priority = 1
preferredOwner.Parent = part

Right now I have to centralize my network owner logic in this class:

So that overrides don’t occur. This is really painful to work with.

1 Like
#4

Alright I see. My main use-case for this fix would really have been to get a more stable physics result for a scenario I was working on, since the rapid swaps of Physics Ownership seemed to be causing glitches (Unless it’s something else with ropes entirely)

https://twitter.com/Panwells/status/1722971652047135128

If I run the scenario in the video above, but I don’t disconnect the ropes before the explosion happens, the vehicle will go NaN 90% of the time:

  1. Connect ropes to all 4 wheels
  2. Return network ownership immediately after
  3. Explode the car, destroying 2 of the connected wheels and several other parts (Also applies a powerful impulse clientside)

If I do this instead (Current implementation), it will work:

  1. Connect ropes to all 4 wheels
  2. Return network ownership immediately after
  3. Disconnect ropes and enable network ownership again (Might be redundant)
  4. Explode

Is it possible this could be a different issue? The current workaround seems to be working for now at least