Unexpected behavior when constraint body movers are set to (nan, nan, nan)

Bug Reports Engine Bugs
#1

All sorts of mischief occurs when VectorForces, AngularVelocities, and Torques have their forces/velocities/torques set to (nan, nan, nan).

Observations

  • Assemblies will pop in and out of existence, i.e. their positions are set to (nan, nan, nan) but they still exist in Workspace.
  • Random shadows will appear and disappear.
  • When a part is broken off from an assembly, the rest of the assembly remains at (nan, nan, nan) permanently.

Client/Server

  • When performed on the client, it does not replicate to other clients.
  • Does not work when performed server-side.
  • Works in production servers.

Repro file: ConstraintsRepro.rbxl (20.0 KB)
Repro code:

workspace.A.VectorForce.Force = Vector3.new().Unit
workspace.B.AngularVelocity.AngularVelocity = Vector3.new().Unit
workspace.C.Torque.Torque = Vector3.new().Unit
5 Likes
#4

This also happens with BodyForce / other body mover instances.

#5

Why and what defined behavior should happen at nan?

#6

That thought occurred to me as soon as I posted this. It’s not really an “unexpected behavior,” as you can achieve lots of weird effects from using really big numbers throughout the API. Lighting and part reflectance come to mind.

So on second thought, I don’t think this is a problem that needs to be addressed.

EDIT: I suppose if anything, the assembly should be destroyed. That’s what happens when you perform it on the server.

2 Likes
#7

We will still investigate. We try to catch NANs before they can affect the simulation system and degrade it, but checking for NANs in some cases isn’t free. We can see if this is reasonable to sanitize.

Thanks for the report.

3 Likes