Raycasting issue to replace over BasePart.Touched event

I have a part here, which contains 5 attachments which will rapidly shoot out rays to the part’s front direction. Every time the ray hits something, the code will print out the name of whatever it hit. However I had an issue which you can see in this video.

As you can see when the part goes through the wall, the ray detected the WALL part and start printing out the name, however after the part has gone through half of the WALL part, it stops printing out the name even though the ray is technically still firing, however it didn’t detect the WALL part. What’s wrong with my code?

task.wait(5)

game:GetService("TweenService"):Create(script.Parent, TweenInfo.new(10), {Position = Vector3.new(7.218, 5.206, -10.352)}):Play()

while task.wait() do
	for _, attachment in ipairs(script.Parent:GetChildren()) do
		if attachment:IsA("Attachment") then
			local result = workspace:Raycast(attachment.WorldPosition, (script.Parent.CFrame.LookVector * 2.1))
			if result then
				print(result.Instance.Name)
			end
		end
	end
	
end--]]

Visualise the attachment (click on it) and post it here. It could be too far in front?

2 Likes

Where exactly is the origin of the ray? If it’s on the surface of the part, that explains why it stops detecting after passing midway since the surface had already went through the part.

Also, have you considered using spatial queries instead of raycasts to replace .Touched?

Here’s an example of how to use it (not tested):

local param = OverlapParams.new()
param.FilterType = Enum.RaycastFilterType.Blacklist
local part = workspace.Part --something
param.FilterDescendantsInstances = {part} --blacklist the part itself

game:GetService('RunService').RenderStepped:Connect(function()
	local parts = workspace:GetPartsInPart(part, param)
	if #parts > 0 then
		print('inside part')
	end
end)

@Prototrode @SovereignFrost I placed 5 attachments behind the part and up a bit to make sure they’re 0.5 studs above the part.

I’m gonna use raycast still as it is the most performant way to create touched events in this case.

That doesn’t tell us exactly where you placed the attachment. Like @SovereignFrost said, could you show us an image of the attachments in workspace?

Have you done benchmarks to prove that raycasts are indeed more performant than the method I described?

If that doesn’t give an image, then you might as well just not help me. I already have enough details on how it looks like. I’m on mobile now.

Raycasting in this case is far more performant because I’m only shooting the rays with only a few studs. 1000 rays shooting at a certain direction with 2 studs is far more better than 100 rays shooting a certain direction with more than 100 studs+.

No, it does not. You’ve only shown us the problem and denied giving us any more information so that we can actually help you. You’ve only vaguely described your setup which we’ve already told you is not sufficient. Good luck getting help from anyone if you’re going to be this stubborn.

It seems rather hypocritical that you are talking about performance when you aren’t doing any testing to back up that claim. And you should never make a conclusion based on just guesses. So what if the rays are short? Have you even read the announcement post on spatial queries? If you’re that “concerned” with performance then you should definitely do some actual benchmarking. I’m giving you the alternative solution of using spatial queries, which in my opinion is way simpler than raycasting from attachments dotted over a part.

And why even bother with implementing a custom .Touched event?

2 Likes

You clearly do not have any experience on using Touched event, do you?

Mhmm. Yeah.

“Way simpler” isn’t going to make a difference in terms of performance.

By “No, it does not” I meant that your description of your setup does not give me an image.

1 Like

Then let me explain clearly one more time.

Imagine the part you’re looking at in the video is the front surface of it, behind it has 5 attachments, these 5 attachments are BEHIND of the part, then the 5 attachments are moved up just so it’s 0.5 studs above the part.

How far back are the attachments offsetted? Are they beyond the back end of the part? What is the part size, does that have something to do with why you are multiplying the LookVector by 2.1? What is the arrangement of those 5 attachments, like are they like a pentagon or like the face of a dice or just a row of them (vertical or horizontal)? How far apart are the attachments? Where is the RaycastParams and why aren’t you using them?

I believe the main issue would be that the attachments aren’t offsetted backward enough. It seems that they are right on the edge of the part, which explains why it stopped detecting when the back of the part pass through; the attachments are basically inside whatever it’s trying to detect that way

Instead of going back and forth, how about we wait until you have access to studio again so you can actually show us?

I am asking why you are trying to replace .Touched because of this
If it’s because of its accuracy and notorious reputation of failing then I believe I’ve proposed a pretty good alternative?

1 Like

From a little bit of testing in studio, it seems to be caused by raycasts not detecting parts that the origin is inside of. Is there any reason that this is an issue?

The origin points are the attachment’s WorldPosirion property value.

If I want to use raycast, then let me use it. Stop being off topic here and let me use raycast to do stuffs if you really want to help me.

Why are you trying to find a replacement for BasePart.Touched?

You didn’t answer my question. Why is this behavior undesirable?

I don’t know? That’s my question.