Something is wrong with LinearVelocity and Tools, unexpectedly changing the NetworkOwnership

This is reproducable even on HIGH-END PCs and Mobile

Info

System: Windows 10 - 64bit
Studio Version: Version 0.605.3.6050660 (64bit)
Occurs on the entire Roblox Engine

Description

I have this setup

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.

Get the bug re-pro game here:
bug_LinearVelocity_NetworkOwnership.rbxlx (129.1 KB)

Reproduction steps

  1. Turn this on

Green means the client has the ownership. You want to look out for white boxes.

 

  1. Launch the bug repro

image

It’s better if you just get my example reproduction game here.

  1. Click on the button
    image

  2. Click on this
    image

  3. Click on the last button, then equip any of the tools in your inventory. They’re just a pure cube.

  4. When you do this, should see the green turning to white.
    image

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.

3 Likes

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!

1 Like

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.

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

1 Like

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.

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.

1 Like

Mainly yes, but when testing it even more I encountered this, not sure what this means

but the networkownership goes back to the client