Resizing parts that use mechanical constraints freeze

Bug Reports Engine Bugs
,
1

If I try to resize a part that is connected via a mechanical constraint for example a spring the part freezes

here is a video of the problem

here is a project with the problem
ResizePhysics.rbxl (56.8 KB)

and here is the script within the project

local RunService = game:GetService("RunService")
local part = script.Parent

workspace.CurrentCamera.CameraType = Enum.CameraType.Custom
workspace.CurrentCamera.CameraSubject = part

RunService.Heartbeat:Connect(function()
	part.Size = Vector3.one * math.random()
end)

if the spring is disabled then it will works fine

2 Likes
2

I just tested to see if editable meshes have this same problem and they don’t

local AssetService = game:GetService("AssetService")
local RunService = game:GetService("RunService")

local options = {CollisionFidelity = Enum.CollisionFidelity.Hull, RenderFidelity = Enum.RenderFidelity.Precise, FluidFidelity = Enum.FluidFidelity.UseCollisionGeometry}

local mesh = AssetService:CreateEditableMesh()
local content = Content.fromObject(mesh)
local vertex1 = mesh:AddVertex(Vector3.new(0, 1, 0))
local vertex2 = mesh:AddVertex(Vector3.new(-2, -1, 0))
local vertex3 = mesh:AddVertex(Vector3.new(2, -1, 0))
local vertex4 = mesh:AddVertex(Vector3.new(0, -1, 2))
local face1 = mesh:AddTriangle(vertex1, vertex3, vertex2)
local face2 = mesh:AddTriangle(vertex1, vertex4, vertex3)
local face3 = mesh:AddTriangle(vertex1, vertex2, vertex4)
local face4 = mesh:AddTriangle(vertex2, vertex3, vertex4)
local normal1 = mesh:AddNormal()
local normal2 = mesh:AddNormal()
local normal3 = mesh:AddNormal()
local normal4 = mesh:AddNormal()
mesh:SetFaceNormals(face1, {normal1, normal1, normal1})
mesh:SetFaceNormals(face2, {normal2, normal2, normal2})
mesh:SetFaceNormals(face3, {normal3, normal3, normal3})
mesh:SetFaceNormals(face4, {normal4, normal4, normal4})

local part = AssetService:CreateMeshPartAsync(content, options)
part.Position = Vector3.new(0, 30, 0)
part.Parent = script.Parent

local attachment = Instance.new("Attachment")
attachment.Parent = part

local spring = Instance.new("SpringConstraint")
spring.Visible = true
spring.Attachment0 = attachment
spring.Attachment1 = workspace.Part2.Attachment
spring.Parent = part

workspace.CurrentCamera.CameraType = Enum.CameraType.Custom
workspace.CurrentCamera.CameraSubject = part

RunService.Heartbeat:Connect(function()
	mesh:SetPosition(vertex2, Vector3.new(-2 + math.random() * 2, -1, 0))
	mesh:SetPosition(vertex3, Vector3.new(2 + math.random() * 2, -1, 0))
	mesh:SetPosition(vertex4, Vector3.new(0, -1, 2 + math.random() * 2))
	part:ApplyMesh(AssetService:CreateMeshPartAsync(content, options))
end)
3

Can you set the script context to “server” and try it again? Thanks!

4

this is what happens if I make the server resize the part

but if I give the client network ownership and make the client resize the part then it works

but I also have another problem that I’m not sure if its 100% related to this problem


in this example the client has network ownership and if I resize the part it freezes the hole assembly
TestResize.rbxl (73.7 KB)
here is the project if you would like to test for yourself

one strange thing about this problem is if I rename the parts it fixes itself


after more testing just renaming Torso makes it work
I was not able to find any other word that broke it Torso is the only word iv found so far that breaks it and its case sensitive so torso works fine

Edit*
after more testing even renaming does not solve all problems for example instead of setting the size to 3 if you set the size to 1 it will freeze its very strange I’m not able to pinpoint the exact location that causes the problem

1 Like
5

image
image2707Ă—796 146 KB

In the video you shared, you were changing the context from server to client. Can you try with server context please? Thanks!

6

that is just to set the camera subject the script that is resizing has a context of server

7

I cannot repro the issue with the resizin script context set to the server. Can you share the updated placefile with me? Thanks!

8

Sure thing

ProblemA.rbxl (56.9 KB)

ProblemB.rbxl (73.5 KB)

and here are new videos of both problems

Problem A

Problem B

1 Like
9

Oh, I’m allowed to talk on the dev forum now- cool!

Anyway, I’ve experienced a similar issue with a previous version of one of my game concepts, where players would be given a tool midway through playing that attaches a rope to an unanchored object that already existed.
It’s hard to explain, but at random, one of the following would happen when the tool is equipped:

  • All players would see an accurate, (though laggy), view of the unanchored object being pulled by the rope behind whoever is holding it.
  • Only the player with the rope tool would get the previously described view, and from a server perspective the object would remain in place doing what it would normally do. When the tool is unequipped, the object will return to its true position for all viewpoints.

I’m trying to reiterate on this idea with more experience, and I’m planning to have the constraint attached to an object that follows the player rather than directly attaching it to the player, because it seems that the underlying issue is with a constraint being attached to a client sided object and a server sided object at the same time.

10

Hi, just picking off where my colleague left off.

If I copy the Part1/Part2 mechanism into a new experience, everything works fine. My player also spawns in when I hit Play.

When I hit Play in the ProblemA.rbxl file that you attached, my player does not spawn in. How did you create ProblemA.rbxl so that the player doesn’t spawn?

Thanks!

11

I simply turned off “CharacterAutoLoads”

Edit*
once I turned CharacterAutoLoads back on it now seams to work if the client has network ownership
but if the character is far away so that it does not have ownership or if I call

script.Parent:SetNetworkOwner(nil)

it gets stuck again

here is a video of it getting stuck with CharacterAutoLoads turned on

1 Like
12

Hi! Thanks so much for providing the excellent repros, I was able to dig into this.

The root cause (no pun intended) is the way that changing a part’s size changes its root priority. For example, increasing the size of a part increases its assembly root priority, which also increases the “mechanism root priority” of its parent assembly. See here for an excellent description of what’s going on.

Changing the size of the part in general changes the “mechanism root priority”, which can affect network ownership. In the examples you provided, the mechanisms freeze when their network ownership state becomes invalid. You can see this by visualizing the network ownership when you play the repro files.

The good news is that for the mechanisms you provided, there’s an easy fix. You can simply set the RootPriority of one of the parts to something large (e.g. 127) to make sure that the mechanism root priority doesn’t change when the part sizes change.

1 Like