What if we had another property to BasePart, “AnchorForce” or something (im not good at coming up with names ok).
Essentially, you can supply how much force would be needed to break the anchor.
Just a thought off the top of my head. 
2 Likes
I think that would solve the issue. I think we had ‘Glue’ which did this with less control, I’d love to see something similar.
Plus, it wouldn’t conflict with anything currently, and it’d open up a huge gateway to making neat things. Like you said previously, there is so many use cases for this.
There has to be an approach that both Roblox engineers are happy with, and we are happy with. But this is something that’s been needed for far too long, and should definitely happen.
One benefit of this property is that you wouldn’t need to script collisions yourself - it could even operate like CustomPhysics does, and you pass in a “Blah.new(x,y,z)” type deal to the property to further customize how it reacts with collisions.
An extra thing I’d enjoy if this were to ever happen would be:
Force applied to the part breaking the anchor - this would allow you to customize how much the car slows down when it collides. A bush should barely slow the car down, whereas a stop sign should significantly slow it down.
Definitely an interesting thought. Surely someone can polish these ideas into something that the staff agrees with, then maybe we can get the ball rolling and sometime in the future have a much more smooth, advanced, and yet user friendly collision system.
After all, collisions are a big part of (practically) every Roblox game.
As far as I know, unanchored parts have a network overhead that stacks with the number of parts. You have a forest of unanchored trees just sitting there waiting for someone to hit them, and you have a large network overhead. I don’t have any statistics, but that would be much more intensive than a forest of anchored trees that get unanchored one at a time and then can be de-spawned so you have maybe 2-8 unanchored trees at max.
1 Like
Fully support, this would allow me to make vehicle crashes look better because the vehicle wouldn’t be bouncing away from the object first and then exploding.
2 Likes
I had the impression that unanchored parts would fall asleep and they would lose their network overheard until awaken. Is that not the case?
That is how it is meant to work, provided there is nothing moving or accelerating the parts just enough to keep them awake (like an unstable constraint or something). Sleeping parts are treated as having infinite mass, the same as anchored parts, and they will wake if you ram into them, so the end result should be the same as an anchored part becoming unanchored just in time. That said, I have not profiled a large forest to see if there is a meaningful difference in the overhead of sleeping parts vs anchored parts. If there is, you might still make a case for this feature. It might also still be useful if you want this behavior on something that actually can’t balance and stand on its own unanchored.
1 Like
I agree with Allyourblox, we need to see more of the problem
- Cases where unanchored vs sleeping parts is a problem
- Is there a performance hit
- etc…
I do agree this is hard but the feature requests needs to reflect what specifically is
impossible in the engine
But we are listening and I do like cars crashing into trees in game. 
Ive got a pretty decent file that displays when sleeping parts fail to wake up in time. I’m hesitant to believe that this event would fix this issue.
JeepSleepingParts.rbxl (1.4 MB)
Usually its not as bad as it is in this screen capture (this was captured in a local test server and perhaps the screen capture was making the issue easier to replicate)
1 Like
Did anyone get to the bottom of this? As I tried this recently and what is most confusing is that 50% of the time, it behaves as expected, and 50% of time you bounce off the tree. It seems like if it already works 50% of the time, why can’t it work 100% of the time?
I know there are other workarounds, but it seems weird to have to do these workarounds when its so close to just working anyway.
2 Likes
I still want this feature!! I do understand why it’s not the prettiest solution, though.
6 Likes
What’s even more annoying is that I made a workaround, but it still failed and caused the car to bounce off the tree 1% of the time, and I had to work around the work around
1 Like
I still need this. I’m trying to make characters break windows if they are fast enough (custom physics based characters) and I’m forced to have a non-collidable part constantly change size depending on the direction the player is moving to break it and not bounce off. I’m also trying to simulate vehicles breaking fences and other objects and it is almost impossible without expensive workarounds.
2 Likes