Would a temporary fix (not a replacement for this feature) be to record the velocity in a while loop and anchor it after X observations of its magnitude being below a certain threshold? (where X >> 1, otherwise we get the problem you’ve already described) If you check once every second and you have a single thread that manages all loose parts, that should not be as inefficient.
I’m not relying on anyone or piggy-backing. Velocity (if set properly, which is pretty difficult to screw up) mixed with rotation velocity will give nearly the same result without the lag that Explosions (for some reason) cause on lower end PC’s.
I use my methods here, where I dynamically create the fragments: Thing2 - Roblox
Kind of difficult to see what I’m mentioning in here, but I don’t have time to set up a demo with the specifics as my game just released yesterday. I’ll probably come back in a few days to explain better.
That sounds familiar.
Egos nonwithstanding, I think that checking the velocity on a loop to see if the part has stopped is the way to go here.
1 Like
.onGrounded is a really misleading name considering how BasePart/IsGrounded only states if the part anchored or welded to an anchored part (effectively anchored). That is, a part which is not welded to anything and is not moving is still grounded.
Only checking for zero velocity won’t work.
You can check for both zero acceleration and zero velocity as a stopgap.
Yeah, they shouldn’t have exposed .Touched either; it’s way too close to the physics engine for developers to deal with.
Seriously though, having access to sleep states via events would be really useful for optimizing physics-heavy games and managing debris. In this case, it would probably be the only robust and efficient solution.
BasePart.PhysicsSlept and BasePart.PhysicsWaked sound catchy.
1 Like
Yea I imagine onGrounded() is a bad choice, because I initially looked at the wiki and wrongly thought the isGrounded() property meant the part was sleeping, rather than being welded to an already anchored part.
Perhaps a better name would involve something like at .onSleeping or .onRest. Or if anyone can come up with a better name that is fine as well.
1 Like
In most cases, it would work from a gameplay perspective
But then if we look at it from that way, you might as well just anchor it on the first observation of having velocity << 1 and save the excess looping.
By having an arbitrary time gap (some number of observations over some interval) in between each loop check, you create the possibility that a player happens to walk on that part in between intervals and fling the part again.
You could “solve” this by having the intervals extremely short (1/30th of a second or even each renderstepped frame) but then you would arrive to where I started, because that’s what I’m already doing.
There are more clever ways to do that. DidNotMove = (thisPosition - positionAtLastCheck).magnitude <= 0.001
The path of the part is not the issue here. I don’t care about how the parts fly. You keep insisting on setting velocity to make parts fly. That’s not the point of this post at all.
My requirement is that they fly purely under Roblox’s physics because Roblox can handle collisions with CSG convex hulls.
Your test place misses that key detail. You create fragments that get anchored/removed at rest presumably by checking for velocity, but they are basic parts and how you simulate their flight is irrelevant.
You are not going to code a collision system for CSG Unions, which is why they need to fly and collide with Roblox physics.
I repeat: Anchoring parts when velocity is zero is already what I am doing and want to find an alternative to.
Whether you are using Roblox’s physics or your own custom “velocity” moving method for these parts, it doesn’t change a thing that it is physically wrong to be purely using the magnitude of velocity as a way to check if a part is at rest.
My objective is to assimilate fragmented CSG unions into the static map as soon as they come to a state of equilibrium where BOTH kinetic AND elastic potential energy are zero by awaiting a simple event trigger.
If something is already calculated by the engine and does exactly what it says it does and it is useful there is absolutely no reason at all that it can’t be exposed. If something is already calculated then it is a waste of time to recalculate it in a slower environment. There should be a clear way to detect whether or not a part is sleeping according to the physics engine.
7 Likes
What I have done for this in the past was for heavy concrete type parts, that don’t bounce. I just anchor it a second or two after it touches any stationary part. This also allowed for me to create some cool effects of debris breaking other walls.
Not prime, but it sufficed for me.