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--]]
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)
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?
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?
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?