Hi! Thanks for bringing this to our attention. Just to confirm your repro, I think there is a Weld missing. I added a Weld to Test.Part and set Part0 to Part and I was able to see the network ownership change you mentioned. Is that the correct change needed to get your repro to work? Thanks!
2 Likes
It should create a weld when you click the white/yellow buttons.
That gray box is ment to weld to the character. It gets cloned then welded.
1 Like
I believe there is a bug in the file that you attached, the weld is not being created:
Can you please verify that your place file is correct?
Uhhh this is weird. The reason why it’s broken is because I exported it as a rbxlx file
and it seems to just get rid of the Weld for some reason
aka. another Roblox bug.
Here is a version that just creates the Weld via a script… I’ll make a bug report for Welds not saving when exporting as .rbxlx…
bug_LinearVelocity_NetworkOwnership_2.rbxlx (129.4 KB)
btw. it welds weird to the character because the LinearVelocity seems to influence it too
2 Likes
Great, thanks! And thanks for submitting a bug report on the weld, that is very strange. Saving to rbxl should fix that.
I’ll route this to the networking team.
1 Like
Ok, just synced with my team. This is a known issue with LinearVelocity constraints, and we are still determining the best way to deploy a fix without breaking experiences.
3 Likes
I put it here Exporting an experience as a .rbxlx removes Welds that arent fully connected to something
but uhhh then it was closed, so now that is there, and that’s confusing
So sorry about that. Can you please open a new bug report, but don’t link this issue?
2 Likes
Done. I’ve posted it to the Bug-Support thing.
There is a fix available for this issue in the form of a new workspace property that is part of a three phase rollout. More details can be found here:
Let me know if Enabling the new property fixes the issue for you. Thanks.
2 Likes
Mainly yes, but when testing it even more I encountered this, not sure what this means
but the networkownership goes back to the client
Can you provide some additional details on what is going on in your latest video? I’m not seeing any changes in network ownership when Workspace.MoverConstraintRootBehavior is set to Enabled. Is there an additional step I need to perform in order to still see the issue? Thanks.
I can try to record a video and upload it here. Problem is, it needs to be lower than 10 MB.
It looks like I clicked the button at the end multiple times. Or stacked more than one cube and then swapped out the tools when clicking the last button.
This is with the MoverConstraints enabled
If it helps, here is my recording data for this Internal Plugin
To import it simply put the .rbxm file into here
Then you can playback my input, I hope that it works. 
userinputplayback_recordingfile1.rbxm (55.9 KB)
I had to separate the recordings because sometimes it wouldn’t save the recording. (Probably because too many bytes) Not sure if this even gets used internally at that point.
Turns out when I replay my own recordings it doesn’t even seem to click at the right position because of some reason with this recording plugin…
I haven’t had any luck replaying your recordings but I have managed to recreate the issue you are seeing by attaching multiple boxes to the character and then repeatedly clicking the third “scale” box. It looks like the issue is now independent of LinearVelocity constraint as I see similar behavior with it deleted. Can you confirm if you get the same behavior with and without LinearVelocity? If so, I think we can consider this particular bug fixed and we can potentially open a new issue for the behavior you are seeing.
I’m going to close this issue as Fixed as the original problem caused by LinearVelocity constraint is fixed by setting Workspace.MoverConstraintRootBehavior to Enabled. There may be some additional odd behavior relating to network ownership and repeatedly equipping tools but its unclear that anything is definitively wrong in that case.
Sorry, for some reason I missed out on the notification for this message.
I removed LinearVelocity.
And I managed to run into the same issues after Scale is ran.
It doesn’t always happen, but it does happen.
It is indeed a different issue. I just compared how the issue occured with Mover Constraint disabled and a LinearVelocity being present. And how it doesn’t occur without a LinearVelocity.
However, when multiple things are Welded and Scale is used, the issue occurs regardless of LinearVelocity.
It’s a corner-case. Not sure if it’s fighting between RootPriorities.
Wait…
MoverConstraint thing is affecting something though when I do Welds. When it’s enabled it doesn’t happen, never ever realized that this fixed a lot of things, I think.
But maybe it’s because these instances are present
Interesting. If I disable them I can safely disable MoverConstraint and apply the Constraints after… though I believe this would cause similar NetworkOwnership issues again, so it’s better to have MoverConstraint on.
Wait… this fixed another issue…
It looks like MoverConstraint also fixes what happens to Shift Lock when something is AlignOriented towards the HumanoidRootPart. Before Rigid would break, and now it doesn’t. That’s very cool.
I have troubles identifying an issue with AlignPosition and AlignOrientation compared to Weld. If they’re not the same thing, then eventually there’s some different issue with these two but I don’t really know yet.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.