And I use :SetNetworkOwnership on it, and it changes back on its own whenever :ScaleTo is used. And the reason for that is LinearVelocity and it just doesn’t make sense.
When I equip a Tool after SetNetworkOwnership has been used on the Model’s Part. When :ScaleTo is used, my NetworkOwnership just changes… which is unexpected.
When you do this, should see the green turning to white.
This means that you lost NetworkOwnership, even though we just set it…
You have reproduced the issue.
Expected Result
The NetworkOwnership doesn’t change? Not sure, there’s not much documentation that explains why this is happening.
Actual Result
Due to me holding out the Tool before :ScaleTo() gets used on the Model named “Test”, my NetworkOwnership just goes away. Which is an issue. When the NetworkOwnership is owned by the server, The Seated State type of the Humanoid while NetworkOwnership is on the server, would cause to make me sit anyways. RootPriority doesn’t tweak the issue.
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!
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.
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.
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.
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.
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.
