I want to crash into stuff and knock it over, preferably without it first absorbing the entirety of my velocity.
I’ve tried unanchoring the model shortly before hitting it, but that’s unreliable. I’ve tried making the object heavy enough to stand on it’s own until rammed, but that comes with it’s own problems. Primarily that it only takes a small force to topple something heavy. And I don’t want small objects like signs to have huge weights.
What else can I try?
Have you tried creating joints? So, you have an unanchored model, and you call :MakeJoints() upon the model. This keeps the model together, allowing it to stand comfortably, but once a strong enough force is applied, it will break.
I don’t know of any joint that has that behavior besides glue, which just causes the object to flop around wildly with PGS.
I would set up a CollisionGroup for the things you want to be broken by vehicles. Have the vehicle and these items never actually interact physically and simulate it instead.
Obviously touched events aren’t going to go off, though - so I’m not sure how great of an idea this is.
But how is that an issue? You can just add a bounding box part attached to the car and have it in the same collision group as the things to be hit, but make it CanCollide false, right?
Is this online or in a local server? If you’re ramming an object with a car online, you’ll need to set the objects network owner to that of the player driving the car.
That definitely won’t work even if you do it locally. By the time that you get a touched event it’s already too late, the physics solver has already eaten part or even most of your momentum.
He said shortly before hitting it, I thought there would have just been a cancollide off bounding box around it to trigger the event before the collision happens?
Script simulation runs at 60 Hz. If you’re going at 60 studs per second (which is a pretty reasonable speed for a Roblox car) then you need a full stud worth of slop on the bounding box to reliably catch the touch before it gets hit.
Whether the slop necessary will be visually acceptable depends on how fast your cars are going I guess.
Thought of that but that would just let the player cruise right through objects if their velocity isn’t high enough to trigger the destruction.
Maybe I can move the car in and out of the collision group depending on it’s velocity? Though that would limit me on creating different force-breakage thresholds for different types of objects.
Is that the only issue? I can make some space. I figured the server just couldn’t relinquish ownership that fast.
You could make it so as you reach different accelerations/velocities more items are put into the CollisionGroup, so you’re constantly monitoring what can be destroyed vs what can’t. @stravant makes a good point about having a Collision Part purely to pick up Touch events but it might be better to just check what is in front of the vehicle ahead of time based on how fast it’s going (larger area of check if you’re moving at a higher speed)
You’re correct about the networking concern. You’ll definitely have to handle the collision / collidable updates on both the client and the server to get it working well.
Someone could correct me if I’m wrong. If what Stravant holds to be true about the 60 hz, 60 sps logic. You could make collision boxes on your car. One that is one stud out, one that is two studs out, and one that is three studs out. The 1 stud would detect items that are breakable at 60 sps or lower. The one that is two studs out would detect breaks at 120 sps or lower, and the third would detect at 180 sps or lower, and so on.
You could run touch events for breakable objects, and even label certain objects to only be breakable at higher rates of speed. (Make a bounding box around the breakable object, and label it as such: Break60, Break120, Break180)
Then use the bounding boxes around the car, detect when one of those are hit and detect the car’s speed. Also include a bounding box at the center of breakable object that should detect that an actual piece of the car has hit and broken it. If not, reset it back to a normal state.
When the bounding boxes touch, and the speeds are within the correct range, change the item over to the client to be broken. Then the way the object breaks is based on the overall Roblox physics to handle.
I could probably draft up an idea of what all this would look like if the way I’m explaining it sounds too stupid.
Edit: For bonus, you can also use collision groups with all this. Make one called unbreakable where if the speed is too low the object is anchored, and the car smacks right into it. Make one called breakable where the item can be broken, and when the center bounding box that detects the item has been broken, make a broken collision group (which will allow hit with the default collision group, but not the car/player collision group so the debris doesn’t affect the car, unless you want it to) And lastly, you could get rid of the debris after like 25-30 seconds, and then regen the broken object after a minute or two if you’d like that to be a feature.
Backtrack the car’s velocity via interpolation by half the players ping or have the player report the collision velocity (which is no less secure than the existing distributed physics code)
Physics simulation runs at higher FPS than script simulation, so even if you’re recording the velocity once per script frame there’s going to be artifacts after a touch which destroys the momentum because there’s imprecision in both your measuring of the velocity and your timing of restoring it.
That’s really the root of the issue here, trying to find ways to work around the fact that a script can’t just patch the situation up after the fact.
You guys need breakable constraints. In this situation a simulated weld that has a threshold force that makes it break.
When you say need, you mean as in, it doesn’t currently exist, and is something that would be cool to feature request?
it doesn’t exist but it can be requested.