Player Character repels a CanCollide = false part?

What force or effect could be causing this? Is there something about Character models the applies or changes forces on nearby parts before they touch?

A part with CanCollide = false, some small Velocity value, and a VectorForce that counters gravity for the part seems to work fine until it gets near a Player Character model, which seems to suddenly repel the part at a much higher velocity.

Script in ServerScriptService:

local p = Instance.new("Part")
p.Shape = "Ball"
p.Size = Vector3.new(2, 2, 2)
p.CanCollide = false
p.Anchored = false
p.Position = Vector3.new(0, 5, -40)
p.Velocity = Vector3.new(0, 0, 4)

local a = Instance.new("Attachment")
a.Parent = p

local vf = Instance.new("VectorForce")
vf.Attachment0 = a
vf.RelativeTo = "Attachment0"
vf.Parent = p
vf.Force = Vector3.new(0, workspace.Gravity * vf.Parent:GetMass(), 0)

p.Parent = workspace

In Studio, press Play. Distance seems to be somewhere between 10-20 studs when the change in force occurs.

Why does the Character model repel the floating part without touching it?

Try setting the VelocityForce's RelativeTo to “World”.

1 Like

That worked, thanks!

Why does RelativeTo = “Attachment0” cause that behaviour?

This is happening because the vector force is applying forces relative to the part’s orientation, and that orientation was changed microscopically through a change in its network ownership, most likely because its rotational velocity changed a bit. It’s actually relative to the attachment, but the attachment has and will have the same orientation as the part, so same difference.
This change is very small, but the sensitivity of your system lets it balloon out of control.
By changing the force’s .RelativeTo property to World, this no longer becomes a problem, because the force is now relative to the world, not the part, and the world obviously can’t change orientation.

1 Like

Hadn’t considered network ownership, which in retrospect makes sense now.

Originally had been thinking that of course the VectorForce needs to be RelativeTo the Attachment because that sounded like it should be the default for applying a force to a specific part.

What is an intended good use case for RelativeTo = Attachment?

Feels like that could be demonstrated or described in the API Reference for clarity:
https://developer.roblox.com/api-reference/property/VectorForce/RelativeTo

I guess a good use case would be for when you want to create an aircraft with physics, and you could use a VectorForce pointing forward to simulate force from the propeller. Although, it would still be much simpler to create this by manipulating the position and velocity of the aircraft directly albeit not accurately.

Another (better) example would be making a swing with physics, using a VectorForce relative to the swing’s seat to make it swing back and forth. This is especially simple, and not much else can really top it if you already have everything set up.

1 Like

Ah yes, a swing makes sense. Thanks for responding. Back to experimenting.

1 Like