I’m working on a “Drop” class to represent any physical dropped item in my game. When the item is initially dropped, it might bounce around a roll a bit. In order to save physics processing time due to a lack of a hard limit on the amount of dropped items allowed, I’m looking to anchor the dropped items once they’ve stopped moving after spawning.
Is there any way to check if an assembly is sleeping so I can anchor it after it stops moving from spawning?
There isn’t really anything exposed to developers to monitor the sleep state of physically-simulated assemblies (via Lua, that is. You can turn on settings in Studio to visualize these elements, but you can’t really interact with them).
You’d instead likely need to implement logic that is similar to what the engine already uses to determine conditions that would satisfy a sleep state and anchor the part when that happens, such as an assembly’s velocity exhibiting a zero-to-very-low magnitude for a period of time. This offers the opportunity to be more aggressive with your sleep logic than the engine’s logic, but that also risks anchoring assemblies that might not make sense to anchor yet.
1 Like
Before posting this I was doing this exact thing; it didn’t work out as I intended. For some reason when I listened to a .Changed
event on the assembly’s root part checking for zero velocity, I was able to get Roblox to crash. Not sure how, but it might be worth checking out again.
Anyways, I appreciate the help and I’ll look more into the solution.
That’s strange. Which property were you listening for?
Either way, a lot of the position/velocity properties don’t trigger .Changed
when modified by the physics engine presumably for either stability reasons or because the 240 Hz nature of the physics engine is faster than most other cycles, so those values generally need to be evaluated in a RunService.Heartbeat
handler.
.Changed
will fire for those properties, but usually only when those values are explicitly set by Lua.
Regarding the crash: I was storing the connection in the class with a normal .Changed
event printing the assembly linear velocity. For some reason after the part stopped moving it would cause Roblox to crash.
For the second part: I had come to notice .Changed
isn’t triggered by the physics engine too. I though about checking the velocity every heartbeat but I wasn’t sure where to put it be be the most efficient. Should I create a new heartbeat connection whenever a new drop is created? Do I have a centralized heartbeat connection that iterates through every dropped item? The latter would require getting all aptly tagged parts and finding the corresponding matching index in a dictionary containing the class itself.
I think a unique listener for each drop should be fine, since they can disconnect themselves when the drops become anchored, and the encapsulated nature of each one having its own lister means the logic itself can stay simple.
1 Like