Legacy BodyMover crash with MoverConstraintRootBehaviour enabled

We are experiencing server sided engine crashes in our game from legacy body movers: Waste Of Space [STAGING] - Roblox (the main version of the game is here and does not experience the crash)

The crash only occurs when MoverConstraintRootBehaviour is enabled, and it only occurs in live game servers, not in Studio.

When a part that contains a BodyGyro such as one of the game’s VehicleSeat objects is grounded and then becomes ungrounded by deleting a joint, the server crashes (most likely in some way due to recomputation of the assembly root part). Additionally when a part that contains a BodyVelocity has its Velocity property updated (I believe while the assembly is grounded, couldn’t confirm) the server also crashes.

Additionally, the crash does not occur within Studio or on the client, only live Roblox Servers appear to be affected such as in the context of our game.


Workaround

A viable workaround for this crash is to disable MoverConstraintRootBehaviour

Additionally by migrating some of the objects in our game to use the new constraints like LinearVelocity I was able to work around the crash for objects like thrusters. I however did not find this to be feasible for some objects that use BodyGyro as AlignOrientation does not support per-axis MaxTorque or MaxVelocity and no combination of the constraint modes seems to be able to reproduce the effect of setting MaxTorque to for example 0, 10000, 0 except for PrimaryAxisPerpendicular which does not align the primary axis to the goal but rather preserves that the primary axis is perpendicular to the goal vector allowing for the AlignOrientation to stabilize on two states (the problem I encountered here is essentially that the goal can be either right handed or left handed and there is no way to force one or the other). There may be a way to migrate these.

2 Likes

Arent the bodymovers deprecated? I dont think they’ll fix jt

Thank you for reporting this. Its very surprising that this property would be causing crashes with those instances as it doesn’t touch any of the code associated with them. I think you may be right that the crash has something to do with the assembly root part calculation but with the property enabled, we should be seeing less movement of the assembly root part so the crashes are still puzzling.

Do you have any MoverConstraints in the mechanisms that are crashing? Would it be possible to send one of the models that is crashing? I can run it with our internal debugging tools to try and find the source of the crash. Thanks.

3 Likes