Having a ton of unanchored parts is usually not a good idea in a very intensive and dynamic game. However, sometimes I would rather let roblox physics handle collisions with flying objects temporarily rather than code a custom physics engine and setting CFrames on anchored objects.
What I want to be able to do is track when a part has finished flying, landed, and is in a state of equilibrium where I can then safely anchor that part for good and lock it into the static part of the map.
We can sort of check if a non-anchored part is at rest perhaps by checking if the magnitude of its velocity is zero. However, using a loop to check for that would be terribly inefficient and awkward to manage on the lua side.
I propose an “onGrounded()” event that triggers whenever a part has lost all of its kinetic and potential energy and is at rest while not being anchored, essentially when the part has achieved an equilibrium state. This way, I can safely anchor a part knowing it would not be in the air floating and has fully stopped moving.
Here is an actual example of what I plan on using this for.
Notice in the print message when I print out “Part X at rest”. I use a loop to repeatedly check for the part’s velocity and then anchor it when it stops moving. This feels incredibly awkward and inefficient to do on the lua side.
Also it is important to know that this method of checking for velocity is flawed because it doesn’t take into account of potential energy from elastic collisions at the instant of collision where velocity is at zero. I don’t know how to determine if a part has no potential energy (except for positional potential energy) from a collision, which is why a onGrounded() event would be far superior than what is possible on the lua side.
GAMEPLAY ASPECT:
Why I actually need to anchor those fragments:
You can bind it to Changed, but that fires for all property changes, so when the Position/Rotation changed, it’d fire again and again – you’d be checking more often than you would with a while wait(x) do loop. Changed also doesn’t take into account elastic potential energy which was mentioned in the OP.
There is a setting under explosion called BlastPressure, but if he’s going for optimization I’m confident he’s just setting Velocity, which doesn’t care for density or anything.
Increasing BlastPressure would affect players and send them flying. Velocity resets the next physics step and the only way you could use it to send the chunks of wall flying was if you continually set it on RenderStepped. OP clearly states he wants ROBLOX to handle physics and not do it manually.
This is your idea. If you know what you are doing, then show it.
Relying on someone else to get your point across only illustrates you piggybacking off of someone else’s knowledge without their permission. I remember someone else did exactly what you did here and Trey was not happy about it.
This statement makes me feel like you didn’t understand the problem completely.
For clarification, I set the part’s velocity once upon the explosion to simulate a force. It takes into account the part’s mass. Everything after the initial explosion is completely handled by roblox physics. If I used BlastPressure from the explosion for the force, it would make no appreciable difference.
As the part is flying purely with roblox’s physics engine:
I’m not setting anything every physics step, I am only checking for velocity.
Velocity does not take into account of potential energy from collisions
I set velocity once as the initial force yes. I do take into account density as I take in account for mass. But here is a demonstration of why that setting the initial velocity is irrelevant.
This is an explosion with an arbitrarily large blastpressure, nothing sets the part’s velocities. The only difference I see from the OP examples is the direction of the parts flying. I still get the same results.
