Part whose faces touch: (unexpected behavior)
print(#workspace .Part:GetTouchingParts())
0
Part intersecting: (expected behavior)
print(#workspace .Part:GetTouchingParts())
1
Part whose faces touch, but was unanchored and fell on top of another: (kind of expected behavior…?)
print(#workspace .Part:GetTouchingParts())
1
2 Likes
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.
digpoe
(digpoe)
June 9, 2015, 7:26pm
#5
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()[1]
print(#b:GetTouchingParts())
b.Touched:connect(function(hit) print(hit) end)
print(#b:GetTouchingParts())
Output:
0
1
Touching faces though :\
1 Like
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
NOTE: This is obsolete in favor of better bounding box checking API now: https://devforum.roblox.com/t/introducing-overlapparams-new-spatial-query-api/1435720
Suppose you have PartA and PartB in workspace that intersect, but both are non-CanCollide (or only one of them is non-CanCollide):
[image]
You might know that the following call will not yield any results in that case:
local results = workspace.PartA:GetTouchingParts()
print(#results) --> 0
However, if you attach an empty Touched ha…
neat post… Thank BuildThomas
No need to turn collisions off or on.
Edit: wait this post is 5 years old what
1 Like
tnavarts
(tnavarts)
August 3, 2020, 10:24pm
#10
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.
2 Likes