Sleeping Parts system is completely broken, refusing to keep parts with slow-moving constraints awake

This is a bug currently making it difficult to release an update on my over 70 million+ played game.
When you have a part moved by a physics constraint - whether Linear Velocity or Align Position or anything else -
and said constraint has a relatively small (under 0.5 speed) velocity to it…

It just doesn’t work. It literally does nothing but move a foot then stop.
it’s so bizarre, because you’d think, it *has a constraint mover in it, surely it knows it shouldn’t stop?

But, evidently, it sleeps. Forever.

Like, surely a single line of code to check if something has a constraint with velocity in it should prevent this sleeping from happening, on roblox’s end?

Expected behavior

Parts should not be allowed to asleep if they are floating mid-air while un-anchored or have a physics constraint turned on in them

Period. If I wanted this part to sleep I would not leave it floating mid-air, and I would not have left a constraint in it that is literally telling it to move. I do not know why this is happening.

Replication Steps

Open up a new place, put a linear velocity into a part, set it to a low value, press ‘Run’ and watch it do nothing.

10 Likes

Thanks for the report! We’ll follow up when we have an update for you.

4 Likes

Bump because there has been nothing done since this. Parts still go to sleep with slow moving constraints and it is a constant headache since we don’t get any control to manually tell the physics engine to not allow specific parts to go to sleep. As a result we need to resort to hacky methods such as using a script to constantly change a parts velocity to keep it awake. Modules such as AlarmClock were made for this exact purpose.

4 Likes

Yeah it’s incredibly annoying, I wish there was a proper way to wake a part up to have it ready for action that didn’t involve constantly giving it a little ‘nudge’…

Any updates? I’m working with a team on a bowling game and it’s bad enough one instance that the ball bounced right off the pins, and those didn’t even move.

Hi! Thanks for posting, this is a subtle feature of the sleep system.

As described in this article, we use both the position and velocity of an assembly to determine if it should be put to sleep.

In the case you posted, there is a (small) net force acting on the body, which produces an acceleration (and therefore a nonzero velocity). The larger the mass of the part, the smaller this velocity will be. Internally, we put a part to sleep if its velocity is less than some small (but nonzero) threshold. The reason we need a threshold is because, due to floating point and numerical drift, most parts that are visually stationary will not have a perfectly zero velocity. You can observe this by disabling sleep in studio (Studio Settings → Physics → Allow Sleep), and simulating a block resting on the baseplate. Over long enough time, the block will move, since each simulation step introduces a tiny bit of drift in its position. To make sure that parts go to sleep in these cases, we introduce a small threshold velocity value, and put parts to sleep if their velocity is below this value.

Back to the example you posted, the constraint force you are applying is producing an velocity that is below the threshold value, so it is being put to sleep. We cannot simply check if unanchored parts have a physics constraint attached to them and keep them awake if they do. For example, consider the case where two LinearVelocity constraints were applied to a part, with equal and opposite VectorVelocity values. In this case, the part velocity will be zero (up to floating point precision), and should go to sleep. We would erroneously keep the part awake if we kept it awake simply because it had a physics constraint attached to it.

We are working on more thorough documentation of the sleep system for the Creator Hub which will also provide additional guidance for developers, stay tuned!

2 Likes