I was helping @ImFirstPlace and we ended up discovering a bug.
Description
For some reason, the any Constraint that can apply force onto things (such as a Prismatic Constraint) can now sleep instead of remaining awake, if the force (such as Velocity) is a small number, such as 0.15.
Re-production Steps
I’ve attached a video and re-production place file
Create 2 Parts
Create a Prismatic Constraint
Give it a Motor and set the Velocity to 0.15
Turn Allow Sleep in the settings off
F8 to play test, the Primsatic Constraint should move
Turn “Allow Sleep” back on
Notice how it will freeze now
Indicating that this is a Physics Sleep issue.
Expected Result
The thing that is being moved by the 0.15 Velocity Prismatic Constraint should not physics sleep.
Things where force is applied, should not fall physics sleep if its purpose hasn’t been completed. Even if the purpose is infinite.
Actual Result
Any weak force now sleeps…
Also, when fixing or if fixing this already, please consider to add a new API that will disallow destroying Parts when they’re attached to a constraint, unless the entire assembly has fallen down
Anything moving with a linear velocity lower than 0.33 stud/s will fall asleep, see our dev forum post on the new sleep system for details. You’ll need to bump that velocity up to keep the part awake.
We don’t look at whether a constraint has satisfied its target velocity to determine if should sleep. For example, other constraints/forces may be acting on the part being moved by the prismatic which would prevent it from ever reaching the target speed, so we have to consider the part’s velocity and acceleration to determine if it should sleep.
The type of constraint doesn’t matter, could be a rope pulling, a contact pushing, a servo moving, we only consider the velocity and acceleration of a part to determine if it should sleep.
Does the Roblox Engine have anything that determines whether a Part is connected to a constraint, so that there could be an option for it to not sleep?
Assembly Velocity is like the final thing of a Part, that sounds like it is being used to determine whether something should sleep or not. It doesn’t care about what it is being moved by.
Property changes on the part or attached constraint will also keep the part awake, so you could modify the speed of the servo a tiny bit every so often to keep it awake. For example, toggle the speed between 0.15 and 0.151 every other frame.
For slowly rotating parts, you can weld a large, massless, non-collidable invisible part to the part you’d like to rotate and it will stay awake as long as the angular velocity multiplied by the “radius” of the large part is greater than 0.42 stud/s.
Would Roblox ever consider a “keep-awake” separate option? For individual things?
In this issue though, it’s just a narrow down. The original issue was from an Elevator that @ImFirstPlace created. When it goes up it would sleep. But it would not sleep at the second time.
What their design was, seemed to be to start the Velocity at a much greater power, like 3 and make it go slower once it gets closer to the end. The goal they had was to align the moving Platform with the Floor the Elevator was meant to go.
The problem is it never reaches the end, because Physics Sleep force it to sleep before the end was ever reached. We could say that this Constraint wasn’t only used to move something slow, but to animate something… and it’s distruptive that it would fall asleep mid there.
Their other approach was Ropes, but since the new sleep system goes after the velocity. The new sleep system enforces sleep regardless of context.
And I think this is an issue.
I titled this report “things sleep when they shouldn’t” where the issue here is that Roblox thinks it should sleep, but in my head I think some things shouldn’t sleep, but how can either party know? Which just all speaks about “context” and the lack of ability to actually control this context.
Meaning that their only suitable fix for them that I could imagine, was to force awake it.
Where my new thought would be this exact option, to let Creators exclude separate things from sleeping.
many things in the physics system is almost completely useless because of auto sleep, so many times I’ve had to script custom physics or whatever because of this which in many cases can have worse performance. i have the freedom to make a garbage performance heavy loop but can’t set specific parts to not sleep for a slight performance loss? its silly. even a compromise like a method to force awaken a part for a few seconds would be great.
Could we get at least an official reason why introducing a property/method would degrade performance? I assume it’s more nuanced than “assemblies that never sleep use more resources”.
The thing is, we have to resort to hacks like changing CustomPhysicalProperties every frame, which is already a major performance degradation not to mention buggy. I can’t imagine how a built-in property would be more problematic than what we’re forced to do now.
The worst risk is that this “always stay awake” is infectious: It’s very easy for one thing always staying awake to cause a cascade of other stuff staying awake too, even well beyond the scope the developer may have been intending to impact.
Not all of our games use physics at a scale as large as NDS or whatever (due to more serious issues like network ownership). The majority of our uses for physics are almost exclusively client-sided and detached from other assemblies, like ragdolls, moving platforms, smooth model animations etc.
And if the cascading issue was actually that big of a deal, I think we would’ve noticed it with our current workarounds already.
I want to also say that i dont care if it affects performance as a game dev i want to choose whether my game performs horribly or not. Roblox doesnt stop us from crashing the client with buffers, so why should we be limited with this?
I maintain a popular elevator controller and when it has the physics option enabled it fails to level properly due to the part falling asleep which causes the controller gets stuck because it relies on the platform level meeting the distance threshold with the floor level position. If you allow us to control when a part falls asleep that would allow our controller to function properly. See video attached: Observe how the elevator falls asleep when leveling causing it to get stuck, I had to drop an unanchored part to get the elevator to level properly.
Why can’t we be trusted with physics when scripts have no limit on how much lag they can cause on the client/server or the amount of laggy high tri count meshes in-game? You can see that i’m handling physics responsibly already with the anchored property already here.
FYI this elevator can either run on physical ropes expanding and contracting with a prismatic constraint with no motor or simply a prismatic constraint with an actuator motor the issue happens with both methods.
Remember we are requesting for individual parts not the whole game.
Roblox could allow us to set the min velocity a part has to be for it to sleep (0 would be disabled).
I think that the reason the sleep team cant give us a Keep Awake option is because awake parts keep their neighbors awake as well so its a bit contagious.
Naturally all parts should be able to sleep but if 1 part is awake then its neighbor will be kept awake by it, then the neighbor of the neighbor will be kept awake, and the neighbor of the neighbor will be kept awake and the neighbor of the neighbor of the neighbor will be kept awake……
Soon enough your whole game will be awake and calculating physics just because 1 part is awake and the server is being throttled. So you see why they are so cautious with it.
Tho what youre experiencing here is not actually fully because of the sleep system but more because of how network ownership works.
The thing is most game objects are set to automatic network ownership which transfers ownership to the client. That Ownership transfer actually has a latency as its a data package.
That means that if an object is on the server and the client tries to wake it the time needed for it to wake is the same time the data package needs to travel - aka Latency. So nothing will wake until the data package is received.
The fix for that is to make separate physics groups - if you need to move something either set it to the client or server network ownership but dont have assemblies that have physical interaction which wakes them be kept on auto network ownership or their components have a different than each other network ownership.
Simple Terms - Elevator Network ownership is set to the server while operational
Replying to @eronaught and @tnavarts comments this issue still persists (the part falls asleep) if the player which is awake is already touching/moving on the part. The system seems a little too aggressive butchering physics elevators for example (if the doors didn’t open early the controller would be stuck forever). I have to keep the elevators physics set to the server for smoothness otherwise there may be horrible jolting when passing network ownership to the client and also for security reasons too.
See the video attached in the reply to see how the sleep system negatively affects physics elevators.
I also found out it doesn’t just happen once the first time its kind of random.
