getTouchingParts() doesn't work?

[Pokemoncraft5290 (Based)]

local items = game:GetService("ReplicatedStorage").Buildings

game:GetService("ReplicatedStorage").ClientPlaced.OnServerInvoke = (function(player, itemName, location)
	local itemTemplate = items:FindFirstChild(itemName)
	
	if (itemTemplate) then
		local item = itemTemplate:clone()
		item:SetPrimaryPartCFrame(location)
		local cScript = item:FindFirstChild("CoreScript")
		if cScript then
			cScript.Disabled = false
		end
		item:SetPrimaryPartCFrame(location)
		if item.Name == "Mining Drill" then
			local oreChecker = item:WaitForChild("OreChecker")
			print(oreChecker.Parent)
			local oreDeposits = oreChecker:GetTouchingParts()
			print(oreDeposits[1])
			for i, v in ipairs(oreDeposits) do
				print(v)
				if v.Parent.Parent == workspace.OreDeposit then
					item.Parent = workspace.Base.ItemHolder
					return true
				end
			end
			return "No ore deposit found"
		end
		item.Parent = workspace.Base.ItemHolder
		return true
		
	end
	return "Item Template doesn't exist."
end)

I have a part that should be on top of another part, and I’m trying to detect that using GetTouchingParts(). However, despite them being on top of each other and them both having canCollide turned on, it will always return nil.

[dthecoolest]

I believe the issue is caused by not GetTouchingParts but instead by this operation:

@Pokemoncraft5290

		item:SetPrimaryPartCFrame(location)

Why? It is known that :SetPrimaryPartCFrame isn’t exactly accurate due to floating point errors from this post.

:SetPrimaryPartCFrame() gradually offsets component parts

I made an animated barrier thing that uses :SetPrimaryPartCFrame() to move portions of the barrier. Here is its progress over time: When I first open it up in run mode: [image] I minimized studio and left it alone for a while. A little short of an hour later and it’s turned into this: [image] Notice how some of the pieces are no longer connected. Leaving it for a day resulted in this: [image] Here is a picture that shows the individual models: [image] local interpolation = require(scri…

Consequently, it’s possible that the model is slightly levitating above the ground with a stud difference of 0.0000001 due to the aformentioned floating point error. To solve this maybe just move the model a bit more downwards I guess?

[SkoobiDoobiDoo (Skoobi)]

Does OP need a touch interest too?

oreChecker.Touched:connect(function() end) --Create a touch interest
local oreDeposits = oreChecker:GetTouchingParts()

[Pokemoncraft5290 (Based)]

Both parts are pretty large, so I doubt floating point errors could result in that.

[Pokemoncraft5290 (Based)]

Why would I need a touch interest? According to the dev hub, gettouchingparts doesn’t need a touch interest if the part has can collide turned on.

[SkoobiDoobiDoo (Skoobi)]

Ah, wasn’t aware of that. I apologize. I’ve been working with :GetTouchingParts() recently and had to do that, never actually read the API reference.

[dthecoolest]

Hmm, perhaps there is a possibility that you are trying to detect contact the moment before the model movement occurs but I’m not really sure how :SetPrimaryPartCFrame moves the rest of the model relative to the primary part and if it’s synchronous or not.

Honestly, to debug the issue I would create a connection to run service every heartbeat and just print out what the clone of the model’s ore checker is detecting

--runservice connect to hearbeat
function ()
local oreDeposits = oreChecker:GetTouchingParts()
print(oreDeposits[1]) -- try detecting
end

Otherwise, it may even be a syntax error are you sure the part is called “OreChecker”? Maybe even the collision box of the oreDeposits if it’s a mesh, if so then maybe turn on complex collision detection for that.

Other possible solutions include using a different method to detect ore deposits such as raycasting.

[Pokemoncraft5290 (Based)]

I am so stupid and I just figured out the issue. Apparently the parent of the model has to be set to workspace for getTouchingParts() to work.