Part whose faces touch: (unexpected behavior)
Part intersecting: (expected behavior)
Part whose faces touch, but was unanchored and fell on top of another: (kind of expected behavior…?)
Also, is there a reason it only works with CanCollide = true parts?
Sounds like :GetTouchingParts() could use an argument to include can’tcollide
unsure if that is a bug, or intended behavior
I think that would be a bit redundant. You could just loop through the result and remove everything that was CanCollide = false if you wanted only CanCollide = true parts.
It doesn’t include CanCollide=false parts because physics aren’t simulated for those parts?
Or does it not include them even when you add a .Touched event?
But :GetTouchingParts() works in Edit mode from the command bar when physics aren’t running, so I wouldn’t think it depends on physics.
[quote] It doesn’t include CanCollide=false parts because physics aren’t simulated for those parts?
Or does it not include them even when you add a .Touched event? [/quote]
Just checked, it does include can’tcollide parts if those are connected to touch events. Looks like the function was set up that way intentionally.
Intersect a can’tcollide part with the baseplate and run this code in edit or solo (I tested with both edit and solo)
b = game.Selection:Get()
b.Touched:connect(function(hit) print(hit) end)
Touching faces though :\
I found a fix, make the part you’re calling GetTouchingParts() on’s CanCollide property true, then call GetTouchingParts(), then turn CanCollide back off, it worked for me.
I remember coming across this post which allows collisions to be off and having the ability to use GetTouchingParts
neat post… Thank BuildThomas
No need to turn collisions off or on.
Edit: wait this post is 5 years old what
This is not a bug, getTouchingParts ignores 0.0002 worth of overlap, so if two parts are exactly adjacent they won’t be considered overlapping.
What you really want here is a feature request for explicit control over the overlap tolerance that the function uses.