Setting a property of a Physics Controller to a NaN breaks ALL other Physics Controllers owned by the same Server/Client

[Bitsfps]

When using a BodyPosition i’ve mixed up two variable names and made a NaN Vector3, which then set that same BodyPosition’s Position value, which is controlling the position of an independent scenario part, which then disappeared (as it should), the problem is, it also broke all things in the game which were using Physics Controllers.

Tested it on a new place, it breaks.
Tested it on both Server owned and Client owned physics, only affects the Physics controlled by that source.

---

How to reproduce it:

Introduce some Physics Controllers on different Parts. (tested with LinearVelocity, BodyPosition and BodyGyro)

Make sure they’re Enabled (even if any projected force is 0).

Crash one of them (in my tests it worked with LinearVelocity and BodyPosition, but not with BodyGyro’s Rotation)

ALL Physics Controllers will be go wild, some of them (BodyPosition) will vanish together with it’s Part, others will be launched around, in sum, chaos.

---

Simple way to break the Physics of the LinearVelocity with a Null Vector3:

[Path Of LinearVelocity].Position=CFrame.new(Vector3.new(1,0,1),Vector3.new(1,0,1)).LookVector*1

---

In the matter of Physics-related Beta features:

I am using: Aerodynamics, Dragger QOL, EditableMesh.
I am NOT enrolled in Simulation Pause.

Expected behavior

That single PhysicsController should break with having a NaN (null) property, instead of all other unrelated Physics.

[music_man1996]

Hey! Thanks for the report. I found someone at Roblox to take a look.

[eronaught]

Hi Bitsfps!

Thanks so much for reporting! I’ve attached a repro file with parts that have the various constraints that you mentioned, including a LinearVelocity constraint that “breaks”. However, I don’t observe the behavior you mentioned in your post. Would you please provide a minimal repro file that demonstrates the behavior?

Thanks!

PhysicsControllers.rbxl (51.5 KB)

[Bitsfps]

Hi, your script is trying to break it by setting the position of the Object being controlled to a null value, but it should be setting a value on the controller itself.

same repro provided by you, but instead of

workspace.Crash.Position

you should be crashing

workspace.Crash.LinearVelocity.VectorVelocity

or other values which control physics directly on the physics controllers, like “Position” in a BodyMover.

By changing mentioned line in this repro file, both parts that are being controlled by the LinearVelocity disappear, instead of just the one.

[eronaught]

Ah, I see! I’m able to repro the behavior now, stay tuned!

[eronaught]

Hi again,

You exposed a very subtle quirk with how we treat anchored bodies in the physics solver. In this case, all of the constraints are connected to the baseplate. (their second attachment is connected to the baseplate). By setting a NaN value for the property of one of the constraints, that NaN value is able to propagate to the other constraints that are connected to the baseplate, causing the explosions.

This is an amazing find! I don’t think this behavior has ever been reported to our team, great work!

We’re planning to “filter out” these NaN values to prevent such explosive propagations in the future.

Thanks!