Suppose you have PartA and PartB in workspace that intersect, but both are non-CanCollide (or only one of them is non-CanCollide):
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 handler before the call and disconnect it afterwards, all intersecting parts are returned:
local function GetTouchingParts(part)
local connection = part.Touched:Connect(function() end)
local results = part:GetTouchingParts()
connection:Disconnect()
return results
end
local results = GetTouchingParts(workspace.PartA)
print(#results) --> 1
This is presumably because, due to the Touched handler, the part starts participating in physics differently, which allows for the non-CanCollide parts that intersect itself to be found.
I figured I’d stick this here in case someone needs this functionality but doesn’t know this trick yet either.
We shouldn’t even have to do this
I wish there was an official implementation of this feature for all parts, no matter what their rotation and collisions are
Nice find though!
Super useful! This works because it adds a TouchInterest object to the part. The GetTouchingParts method looks for either can-collide parts or parts with TouchInterest.
I agree, but I believe that it’s because of how the physic engine works;
So when a part is CanCollide = false the physic engine will not register any TouchEvents or Detects Touch cause it doesn’t have to, and if it did then it would eat up more memory (as equal to a Part with CanCollide = true) then it would with it’s current behavior, when a part is CanCollide = false it’s not physically there, that’s why you can walk right through it.
Yes it would be nice if we don’t have to do all of that, as it should be done internally.
This isn’t true…any part with a TouchTransmitter instance inside will fire Touched events. I have tens of CanCollide false parts with Touched events that work perfectly fine.
I wish GetTouchingParts() took a parameter such as GetTouchingParts(bool IgnoreNonCanCollide = true). This way, we can specify. It would default to true for backwards compatibility in case any older games rely on the current behaviour.
Another way to do this would be to return all the parts and have the developer write a for loop and do an if statement for collisions if they really don’t want to act on non CanCollide parts. I’d be all for just returning all parts (CanCollide off and CanCollide on).
This seems like a hack. I’d be careful relying on this behavior.
In an ideal world, GetTouchingParts would just work regardless if there’s a TouchTransmitter involved.
If it is a hack, then the Developer Hub documentation should probably be adjusted. It currently insinuates that it is fine (or even intended maybe) that parts with TouchTransmitters (=Touched handlers connected to it) are picked up.
I mean, it is intended behavior and I’m not saying you shouldn’t use it, just be cautious is all. I personally think this shouldn’t be a necessity to make the function work with non-colliding parts.
